[whatwg] Allowing ">" in attribute values

[Boris Zbarsky]

On 6/29/10 5:56 AM, Skrol29 wrote:
>> It seems like what you want here is for browsers to parse as they
>> do now, but a particular subset of browser-accepted syntax to be
>> enshrined so that when defining your restrictions over content you
>> control you can just say "follow the spec" instead of "follow the
>> spec and don't put '>' in attribute values", right?
>
> That is not the idea. I'll try to explain deeper.

OK.

> But parsing could be faster and more secure for all purposes
> (I mean not only for browsers)  if">" is forbidden and to be replaced
> with">".

But existing content out there uses '>' in attribute values and isn't 
going to stop doing so.  Which means that you can't _forbid_ HTML 
parsers allowing '>' in attribute values.  In particular browser parsers 
will continue to allow it, period.

Are we agreed so far?

> Why changing the HTML spec instead of adding a restriction when we
> want ">" to be forbidden ? Because I think we should all want">" to
> be forbidden.

Well... But we don't, in fact.  We certainly don't want to forbid 
consumers to consume it.  So we're talking about a requirement on 
producers only, and then the question is what the benefit of the 
requirement is (compared to the drawback of making various existing and 
future content that would otherwise be just fine non-conforming).

> I understand that browser developers are not feeling  concerned by
> this because parsing is working well as is for them.

It's more than that.  Browser developers (and anyone else who needs to 
be able to accept HTML from people they don't have control over) needs 
to have the current parsing behavior, period.  Anything else just gives 
you a broken parser.

So given that, how was my characterization of my suggestion incorrect? 
Was the "for browsers" part incorrect?  Or the "particular-subset" part? 
  Or something else?

-Boris