Re: [whatwg] allow <link> in body + DOM position as a rendering hint

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 Friday, 23 January 2015 00:37:10 UTC