W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2014

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

From: Ilya Grigorik <igrigorik@gmail.com>
Date: Wed, 5 Nov 2014 08:24:17 +0900
Message-ID: <CAKRe7JFO+Lz63FY+yKHC33PXgWp-yYc1vWwGODKz4iJF77oBUg@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: Jeremy Keith <jeremy@adactio.com>, WHATWG <whatwg@whatwg.org>
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.

In short, allowing <link> in body doesn't make things worse, but it does
(a) reflect what developers are doing, (b) allows UA's to consider some
additional (and optional) rendering optimizations.

On Mon, Nov 3, 2014 at 3:05 AM, Jeremy Keith <jeremy@adactio.com> wrote:

> To clarify, should the second point ("hint to the UA that what is above
> the link tag should not be blocked") apply specifically to
> rel="stylesheet", or should it apply to any rel values? (like rel="import"
> that Steve mentioned)

Ideally, any rel value -- all the same reasoning applies.

On Mon, Nov 3, 2014 at 7:10 AM, Domenic Denicola <d@domenic.me> wrote:

> For import at least I think this change is important (insofar as any
> authoring conformance criteria is important). See e.g.
> https://github.com/bterlson/ecmascript/blob/master/spec/index.html for a
> usage of <link rel="import"> as a kind of "include HTML here" macro that I
> find to be a useful pattern.

Yep, and we're going to start seeing more and more of this moving forward.

Received on Tuesday, 4 November 2014 23:25:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:32 UTC