This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Consider the following example: <p><style scoped>/* first */</style><style scoped>/* second */</style> Should the second <style scoped> instance be reported as an error or not? The "Contexts in which this element can be used" section for the <style> element says, "If the scoped attribute is present: where flow content is expected, but before any other flow content other than inter-element whitespace". The first <style scoped> instance in the example above is flow content, so technically, the second <style scoped> instance in that example is not occurring before any other flow content. So maybe the text should be updated to say: "If the scoped attribute is present: where flow content is expected, but before any other flow content other than inter-element whitespace or another style element with a scoped attribute..." Or perhaps better yet: "If the scoped attribute is present: One or more style elements with a scoped attribute may occur together where flow content is expected, but before any other flow content other than inter-element whitespace..."
(In reply to comment #0) > "If the scoped attribute is present: One or more style elements with a > scoped attribute may occur together where flow content is expected, but > before any other flow content other than inter-element whitespace..." Or maybe even more clear: "If the scoped attribute is present: One or more adjacent style elements with a scoped attribute may occur where flow content is expected, but before any other flow content other than inter-element whitespace..."
> The "Contexts in which this element can be used" section ...is non-normative. The content model side of this just allows <style scoped> anywhere flow content is allowed. The prose for <style> is what restricts it; it says: # If the scoped attribute is present and the element has a parent element, # then the style element must be the first node of flow content in its # parent element other than inter-element whitespace, and the parent # element's content model must not have a transparent component. # # Note: This implies that only one scoped style element is allowed at a # time, and that such elements cannot be children of, e.g., a or ins # elements, even when those are used as flow content containers. This happens to also be how you interpreted the non-normative "contexts..." text, so it all seems consistent. But do you have a use case for allowing multiple <style scoped> elements in a row? We can certainly extend the spec to allow it, if necessary...
(In reply to comment #2) > But do you have a use case for allowing multiple <style scoped> elements in > a row? We can certainly extend the spec to allow it, if necessary... I don't have any specific use case. It's just that I suspect some authors are going to end up putting multiple <style scoped> elements in a row in their documents, and then wanting it to validate. As far as why they'd do that, well, some authors do odd things. One thing that does argue for multiple <style scoped> elements in a row valid is that UAs do actually apply all the styles from multiple <style scoped> elements in a row. e.g., the text in the following example will be rendered in red. <!doctype html> <body> <style scoped=""> p { font-style: italic; font-size: 200% } </style> <style scoped=""> p { color: red; } </style> <p>Am I red? I assume the UAs are doing that per-spec.
A better example: <!doctype html> <div> <style scoped=""> p { font-style: italic; font-size: 200% } </style> <style scoped=""> p { color: red; } </style> <p>Am I red? </p></div> <div> <p>Am I red? </div>
They do work, yeah. I'll allow it.
Checked in as WHATWG revision r8035. Check-in comment: Allow multiple <style scoped> blocks in a row http://html5.org/tools/web-apps-tracker?from=8034&to=8035