[whatwg] Why is @scoped required for <style> as flow content?

Mon Mar 28 23:18:37 PDT 2011

Eduard Pascual wrote:

> If you look closer at the scenario you describe (having control over
> sparse parts of the <body>, but not the full document), we don't
> really want to enable un-scoped stylesheets there: they could easily
> interfere with (up to completely screwing up) the parts of the
> document you are not supposed to have control over.

Any stylesheet can completely screw up rendering when applied in addition to 
some other stylesheet. The author needs to know, to some extent at least, 
what he is doing and in which context. Quite similarly, _any_ use of a 
scoped stylesheet requires due attention - especially in the most obvious 
(?) use case where a quotation or a syndicated article is used with its 
original stylesheet as such or as modified. (After all, a scoped stylesheet 
is applied in addition to any document-wide stylesheets that may be 
involved.)

> Allowing un-scoped stylesheets would, in addition to the performance
> impact, add too much potential to screw things up.

Un-scoped stylesheets in <body> are currently supported by browsers. This is 
my main objection to using the <style scoped> syntax: it does not degrade 
gracefully by being ignored by "old" (i.e., all current) browsers but 
instead gets interpreted as a document-wide stylesheet, quite contrary to 
the author's intent and with potential disaster.

> If you have some idea that:
> 1) Better addresses this use-case, and
> 2) would have a reasonable implementation cost
> then, by all means, bring it forward.

The current browser interpretation of <style> elements in <body> addresses 
this use-case well (the author can, if he so desires, effectively limit the 
scope to a particular element by using suitable selectors), and there is no 
added implementation cost as this has already been implemented.

As I wrote, allowing un-scoped <style> in <body> is one thing (useful, I 
would say), and defining <style scoped> is another. The common factor is the 
current browser behavior for the former.

>> By the way, there are undoubtedly cases where you would want to use
>> the same scoped stylesheet for different elements, e.g. for different
>> <blockquote> elements quoting from the same source. Yet another
>> reason for dropping <style scoped> in favor of an attribute
>> referring to an external stylesheet.
>
> You can use
> <style scoped>
> @import url(whatever);
> </style>

Right, I had not thought of that. Yes, so much about _that_ argument of 
mine.

> And this even enables you to add some specific styles (be them
> embeeded or from another external sheet) on a per-use basis if the
> need arises. For example, a long dissertation relying on many quotes
> may benefit from adding stronger visual highlights on the <em>
> elements within the last quote to reinforce the final conclusion.
> Thus there is no reason to drop the feature in favor of something
> that only covers a subset of the cases.

Point taken, but embedded stylesheets don't really add anything to the 
expressive power. You can use a different external stylesheet for the last 
quote, starting it with @import and continuing with an added rule.

> The only real benefit of your proposal would be to save typing a few
> extra characters.

I guess you mean my proposal regarding scoped stylesheets. The main benefit 
is that existing browsers would not do something very different from the 
intended behavior when they see <style scoped>.

The other proposal of mine, namely legalizing <style> inside <body> without 
the scoped attribute, has the benefit of allowing styling that would not 
otherwise be possible to authors working in restricted environments.

>>  The use case for unscoped <style> outside <head> is if you have full
>>> control over the <body> but no control over <head>.
>>
>> It is _a_ use case.
>
> Yep, it's just one use case. However, as of now it is *the only* use
> case brought forward on the discussion that is justified and not
> already addressed by <style scoped>.

The use case of restricted control over <body> is another one. It is not 
addressed in practice by <style scoped>, since <style scoped> cannot be used 
before all significant browsers support it (at least in the sense of _not_ 
applying the contained stylesheet to the entire document).

With complete control over <body>, or at least the very start of it, an 
author could live with <style scoped>, because in this case the scope would 
be the entire document.

Currently neither http://validator.nu nor 
http://jigsaw.w3.org/css-validator/ accepts <style scoped> as the first 
child of <body>. I presume this is a bug in the validators, as
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element
says that the element can be used "where flow content is expected, but 
before any other flow content other than other style elements and 
inter-element whitespace", and the <body> element is described with "Content 
model: flow content".

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/ 