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

Fri Mar 25 09:53:55 PDT 2011

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

Can you point me to that? 

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.

-Nicholas

______________________________________________
Commander Lock: "Dammit Morpheus, not everyone believes what you believe!"
Morpheus: "My beliefs do not require them to."

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Boris Zbarsky
Sent: Thursday, March 24, 2011 6:38 PM
To: whatwg at lists.whatwg.org
Subject: Re: [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