For anyone interested in this topic.. Note that the conversation has moved to Bugzilla, please chime in with your thoughts and feedback there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c14 On Tue, Nov 11, 2014 at 10:17 AM, Ilya Grigorik <igrigorik@gmail.com> wrote: > 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 Thursday, 22 January 2015 18:30:38 UTC