Re: DogFood (and inline/block constraints)

Ian Hickson wrote:
> On Wed, 5 Dec 2007, Dan Connolly wrote:
>>> Even "Bad value text for attribute type on XHTML element input." is 
>>> technically correct although not exactly helpful (see error class 4 
>>> below). This message is the #1 usability bug, BTW.
>> I think it's a spec bug.
>>
>> I don't think it's cost-effective to try to constrain authors in this 
>> respect. I hope this constraint is dropped from HTML 5.
> 
> It's actually a relaxation of constraints in HTML4. In HTML4 the element 
> isn't allowed there at all, but we figured that was too strict when it 
> came to the type="hidden" value elements, since those don't affect the 
> user at all (they're hidden by definition).

Do the browsers behave differently when faced with the input I provided? 
  Which of these messages indicate a specific and real interop problem?

If the answer to the question of "why does the html5 conformance checker 
produce this message?" is "because the spec says so"; and the answer to 
"why does the spec say so" is "because previous specs said so"; and the 
"solution" in many cases is to simply add back in "noise" <div> tags, 
then this non-answer coupled with the unfriendliness of the conformance 
checker messages (something I have great sympathy for as it is often 
very hard when faced with bad input and complicated/confusing specs to 
make correct and simple suggestions) coupled with the sheer number of 
messages produced coupled with the perceived "make-workness" of the 
answer will cause many people to not bother.

My 0.02 anyway, for what it is worth.

- Sam Ruby