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

On Thu, Oct 30, 2014 at 8:51 AM, Simon Pieters <simonp@opera.com> wrote:

> Deprecated in Blink:
>> https://groups.google.com/a/chromium.org/d/msg/blink-dev/
>> R1x18ZLS5qQ/Bjuh_cENhlQJ
>>
>
> Why is that relevant? IIUC it is expected to be implemented again later.
>
>  Note that we're not looking for "scoped" semantics here either... adding
>> that adds a lot of other complexities and baggage.
>>
>
> OK. Can you elaborate? Does it limit something you want to do?
>

Before we get into the pros and cons of "scoped", I think it's important to
highlight that <link> in body is already a fact of life:
1) developers already put <link> tags in body, specs be damned.
2) all browsers support <link> tags in body because of #1.

Given the above conditions, the spec is out of sync with reality and I
think it's worth considering updating the spec to reflect this? Doing so
would also allow the browsers to convert this case from an error condition
into an optimization - e.g. we can treat position as a hint to optimize
rendering.


> 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.

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).

ig

Received on Saturday, 1 November 2014 00:35:46 UTC