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

On Thu, Mar 24, 2011 at 9:29 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> It seems like the scoped attribute should be optional when <style> is used as flow content and disallowed when used in meta content. That way, you're adding the new functionality of limiting styles to a subtree while also ensuring that the spec reflects current browser behavior. Pleasant side effect is that everyone with <style> as flow content will have on less validation error to worry about.

Having <style> outside the <head> is undesirable because it will often
require the browser to reflow the page as it loads, since not all
styles will be loaded when the first visible elements start appearing.
 There's no real use-case for it -- put the <style> in the <head>, not
the <body>.  If an author only controls part of the page, they should
only be able to use <style scoped> anyway so as not to affect the rest
of the page.

As Boris says, the spec does match how *browsers* behave, and this is
only an *author* restriction.

On Fri, Mar 25, 2011 at 12:53 PM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote:
> Can you point me to that?

"""
If the scoped attribute is present, then the user agent must apply the
specified style information only to the style element's parent element
(if any), and that element's child nodes. Otherwise, the specified
styles must, if applied, be applied to the entire document.
"""
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-style-element

No distinction is made based on where the style element is in the DOM.

> And if the spec already specifies the current browser behavior, why does the definition of <style> require the scoped attribute in flow content? This seems very different than the improperly nested tags scenario you mention, where the parser needs to perform some error recovery.
>
> It just doesn't seem like requiring scoped at any point adds much value. It makes sense as an optional attribute, but I can't think of a reason why it should ever be required.

See here for rationale on author conformance requirements:

http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#conformance-requirements-for-authors

"Errors that result in disproportionally poor performance" is sort of
relevant, although not quite (since it's discussing only syntax
errors).

Received on Friday, 25 March 2011 10:57:53 UTC