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
