On Sat, 01 Nov 2014 02:34:42 +0200, Ilya Grigorik <igrigo...@gmail.com>
wrote:
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.
I think this line of reasoning is missing one consideration, namely the
negative effect of using <link> or <style> (without scoped) in body:
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).
You might disagree that the above is negative, but then you'd have to
explain why.
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).
--
Simon Pieters
Opera Software
