- From: Yoav Weiss <yoav@yoav.ws>
- Date: Fri, 20 Sep 2013 12:05:37 +0200
- To: Andy Davies <dajdavies@gmail.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, www-style <www-style@w3.org>
- Message-ID: <CACj=BEiJ6yvAtctd7oB6BhyY9UhksXyhPhMkAf1L6yOqoij3iw@mail.gmail.com>
Coming late to this extremely useful and interesting discussion, I have a few points to add: * While Kornel is right that we want picture to change its MQ evaluation when the environment changes, we don't want it to do so *during* the page's load. Maybe this racy behavior can be prevented/mitigated by requiring custom MQs to be at the top of an external CSS (possibly only the ones in the head). * Many of the custom MQs issues already exist with @viewport. The preloader now evaluates MQs in order to do load external stylesheets (at least in Blink & WebKit), where @viewport can cause a preloaded stylesheet to become irrelevant, or a non-preloaded stylesheet to become necessary. It'd be great if we could use a single mechanism to resolve both issues. * I don't believe authors would willfully abuse the tools we give them, harming their site's performance. If we allow adding custom MQ/@viewport to an external stylesheet, with a performance price tag on it, a console warning (e.g. "You're hurting your site's performance!!! Inline that instead.") may be enough to increase author awareness of this particular footgun. * Inline CSS and CSP don't mix well at the moment. CSP 1.1 has style nonces, which are hard to deploy. Hopefully we would soon have style-hashes (currently in discussion), which are significantly easier to use. On Tue, Sep 17, 2013 at 10:29 AM, Andy Davies <dajdavies@gmail.com> wrote: > On 16 September 2013 21:33, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > >> >> Oh good *lord* that's horrible. document.write is *verboten*. It's a >> terrible, terrible API that messes everything up. >> >> > Oh I know, tried explaining why is was a bad approach to someone on SO, > only to have them delete their answer and the thread that might have been > useful for others. > > DOM insertion approach also leads to undesirable behaviour in IE10 but not > in WebKit or Mozilla > >
Received on Friday, 20 September 2013 10:06:09 UTC