This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The HTML 5 specifications indicate that <style scoped="scoped"> can be used in flow content. While this validates OK under a parent <div>, it fails under other elements that expect flow content. For example, when coding a "breadcrumb trail": <nav> <style scoped="scoped"> li { display: inline } </style> <ul> <li>...</li> </ul> </nav> The validator reports the following: XHTML element style not allowed as child of XHTML element nav in this context. (Suppressing further errors from this subtree.) <style scoped="scoped"> Contexts in which element style may be used: ... If the scoped attribute is present: where flow content is expected, but before any other flow content other than other style elements and inter-element whitespace. Content model for element nav: Flow content. If a <div> is added inside the parent <nav> then it validates OK: <nav> <div> <style scoped="scoped"> li { display: inline } </style> <ul> <li>...</li> </ul> </div> </nav>
This is a known issue that has to do with the HTML5 schema used by the validation backend not being up to date with the spec. See bug 10348 also. I will try to get the schema updated soonish.
Not sure what bug #10348 has to do with this one since scoped is a boolean attribute and the rule that "The values 'true' and 'false' are not allowed on boolean attributes"** dictates that all of that issue's use cases would be expected to be "Invalid", which in fact are currently the actual results (even for the one that says "Valid") which means the validation backend _is_ up to date for that issue. ** Quote (from http://www.HTML-5.com/tutorials/converting-to-html-5.html) (I just double-checked to make sure this is current information, and it comes from Section 2.5.2 of the Working Draft 19 October 2010.) >> Note that the HTML 5 specifications explicitly state that: >> >> The values "true" and "false" are not allowed on boolean attributes. >> >> This is because browsers that look at the coded value for boolean attributes >> would treat the string "false" as false while browsers that only look for the >> presence or absence of the attribute would treat that code as true, resulting >> in very inconsistent behavior. Thanks for looking at both issues. Maybe bug #10348 could be closed.
Fixed. You can test at http://validator.w3.org/nu/