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

On Nov 4, 2014, at 3:24 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:

> On Sat, Nov 1, 2014 at 5:18 PM, Simon Pieters <simonp@opera.com> wrote:
> 
>> A bare <link> or <style> in body means that you have to re-evaluate
>>>> previous elements. With scoped you don't have to do that. IIRC this was
>>>> the
>>>> main reason for the current authoring requirements in the spec.
>>>> 
>>> 
>> Without looking at the negative side your line of reasoning would equally
>> apply to allowing e.g. <font> (developers use it, browsers support it).
> 
> 
> 
>> If <style> doesn't have the properties that we want from existing impls but
>>> 
>>>> we think that restricting authors to only using scoped stylesheets in
>>>> body
>>>> is a good idea, we could add the scoped attribute to <link> and allow
>>>> <link
>>>> scoped> in body.
>>>> 
>>> 
>>> Sounds like an interesting idea! That said, I'd treat this as a new
>>> feature
>>> and a separate discussion from above (simply allowing <link> in body in
>>> the
>>> spec).
>>> 
>> 
>> OK, but I'm still interested in knowing if scoped is a limitation for this
>> use case or not. If it is not practical for developers to use scoped
>> stylesheets for this then that seems like it would overrule the negative
>> effect. If it is practical then we can still avoid the negative effect (as
>> far as authoring conformance goes anyway).
> 
> 
> Based on the discussion in the room at TPAC, the feeling was that scoped
> semantics (a) added a lot of UA complexity (there wasn't much interest from
> IE/Safari/Chrome folks for this one), (b) require re-engineering existing
> sites (and tricky to deploy, since older browsers would leak styles and
> cause havoc on the page), and (c) are implementable by developers via
> Shadow DOM (styles are scoped to the shadow root).
> 
> 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.

- R. Niwa

Received on Wednesday, 5 November 2014 00:05:06 UTC