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

On 3/24/11 9:29 PM, Nicholas Zakas wrote:
> <div>
>      <style>.foo { color: red; }</style>
> </div>
>
> works just fine in browsers today
 > and the style information is applied to the entire document.

And it continues to work when they implement the proposed spec, yes.

> This is considered invalid HTML5 (tested using html5.validator.nu) because the scoped attribute is missing.

Right.

> Fixing the issue results in:
>
> <div>
>      <style scoped>.foo { color: red; }</div>
> </div>

The correct fix for this issue is to put this <style> in the <head>, 
isn't it?  Why would would you fix it by adding @scoped?

> It seems like the scoped attribute should be optional when<style>  is used as flow content

What are the use cases for wanting this?

> while also ensuring that the spec reflects current browser behavior.

The part of the spec that defines what browsers are supposed to do 
already reflects current browser behavior.

There's a difference between specifying what browsers should do and 
deciding what markup is valid.  For example, if we consider this markup:


   <b><i>Bold and italic</b> just italic</i>

then the spec defines that browsers should render it so that it is 
self-describing (which they do).  But the markup is nevertheless invalid.

> Pleasant side effect is that everyone with<style>  as flow content will have on less validation error to worry about.

That would be one reason to allow <style> as flow content: so that 
legacy pages that use it thus don't need to change anything.

However such pages don't care about validating anyway, since in HTML4 
<style> is _only_ valid as a child of <head>.  So why are we worrying 
about making it easier for them to validate?

Are there any other reasons to allow <style> as flow content?  That is, 
are there good use cases for it?

-Boris

Received on Thursday, 24 March 2011 18:37:43 UTC