- From: Ilya Grigorik <igrigorik@gmail.com>
- Date: Tue, 11 Nov 2014 10:17:47 -0800
- To: Ian Hickson <ian@hixie.ch>, Simon Pieters <simonp@opera.com>
- Cc: Jeremy Keith <jeremy@adactio.com>, WHATWG <whatwg@whatwg.org>, public-web-perf <public-web-perf@w3.org>, Domenic Denicola <d@domenic.me>, Ryosuke Niwa <rniwa@apple.com>
I've opened a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27304 On Tue, Nov 4, 2014 at 4:44 PM, Ilya Grigorik <igrigorik@gmail.com> wrote: > > On Wed, Nov 5, 2014 at 9:08 AM, Ryosuke Niwa <rniwa@apple.com> wrote: > >> > Re, re-evaluation previous elements: note that UA *can*, just as it does >> > today (modulo some error conditions), hold painting until it finds all >> the >> > stylesheets, regardless of the <link> position in the document. So, >> > assuming that's the default behavior, allowing <link> in body doesn't >> > change anything short of reflecting what developers are already doing. >> That >> > said, the UA *could* use the position of the <link> element in the body >> as >> > a hint to optimize how it renders -- the exact logic here is deferred to >> > the UA... Similarly, assuming UA follows the render-optimization >> heuristic, >> > the developers *can* optimize the content of the positioned stylesheets >> to >> > minimize reflows, etc. >> >> I talked more with a rendering & layout expert in our team, and he >> pointed out that we may need to add a new attribute to trigger this >> behavior since many existing websites have link elements to load >> stylesheets that affect contents above it. But that should be a relatively >> simple & straightforward change to the proposal. > > > Makes sense, Jason (IE) also mentioned that we might need some <meta> > opt-in flag, or some such... That said, before we go there, I'd love to see > if we can gather some data on potential impact of making this opt-in vs > opt-out. > > ig >
Received on Tuesday, 11 November 2014 18:18:54 UTC