[whatwg] Parsing: Disallow slashes in unquoted attribute values?

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.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 19 October 2006 19:45:13 UTC