[whatwg] Parsing: Disallow slashes in unquoted attribute values?
Ian Hickson
ian at hixie.ch
Thu Oct 19 19:45:13 PDT 2006
On Fri, 20 Oct 2006, Bjoern Hoehrmann wrote:
>
> But neither of that makes the problem above not a good reason to make
> the case above non-conforming. I don't claim this is a good enough
> reason to change the draft, but you were just asking for a good reason,
> and this is one. You see, certain HTML advocates claim that the lack of
> a requirement to quote attribute values is a cool feature, and if you
> refuse to quote them you are cool.
>
> If you adopt that thought, and just remember that you have to escape
> user input before echoing it, you'll write code as above--which is very
> bad. If the markup above comes from some kind of script, and the
> document is checked by a HTML 4.01 checker, the checker will complain,
> you'd go fix your script and have removed the problem. A "HTML5" checker
> probably won't complain and the author won't fix the script for a long
> time.
There is no way we can make any unquoted attribute value non-conforming;
it's widely used and has always been allowed. So the question then becomes
whether we should make some subset of unquoted attribute values
non-conforming, and whether there's a good reason to do so.
I do not see how the uses that you cite are a good reason here. Assuming
the field is one where users usually type in words, e.g. their username,
then the HTML4 validator won't catch the error either.
> I would expect the specification to at least have a strong warning
> that unquoted attribute values can be dangerous and should be avoided in
> dynamically generated code.
It's likely that the section on the syntax from the author's point of view
will warn authors of such risks, yes.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list