- From: Ilya Grigorik <igrigorik@gmail.com>
- Date: Fri, 31 Oct 2014 17:34:42 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: WHATWG <whatwg@whatwg.org>, public-web-perf <public-web-perf@w3.org>
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