Re: DogFood (and inline/block constraints)

Michael(tm) Smith wrote:
> Sam Ruby <rubys@us.ibm.com>, 2007-12-06 00:21 -0500:
> 
>>  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.
> 
> We had some discussion about that on IRC yesterday, with sort of a
> similar comment from Philip Taylor:
> 
>   http://krijnhoetmer.nl/irc-logs/html-wg/20071205#l-343
>   There are far more significant errors on most web pages, so
>   perhaps more benefit would come from a conformance checker that
>   people will use more often because it doesn't complain at them
>   so much about minor things with little practical benefit, rather
>   than a conformance checker which flags more issues and drives
>   away more users. 

Ian's point about wanting to continue to flag a <p> element as an 
immediate child of <ol> is a good one; the issue here is that the 
current restrictions disallow things that cause no ambiguity or interop 
issues.  An example of this would be the notion of a "strictly inline 
element", like an <a>, which excludes the possibility of it being the 
only element in a <footer> like I have done, merely because a <footer> 
deigns to allow block level elements as an alternative.

I also like Maciej's point, which I interpret as the notion that a given 
element can be thought of as exclusively block or exclusively inline is 
somewhat quaint, i.e. dates back to the days before CSS, and 
unrealistic, given the existing markup that browsers need to deal with 
anyway.

But even so, perhaps the prohibition against having putatively inline 
and putatively block elements as siblings should remain; perhaps the 
solution is to treat many of the new elements as if they were block 
(from the point of view of editing tools, validators, and non-visual 
UA's), but not burden them with any implicit CSS rules as that merely 
means that there will be more work for designers to undo, and such 
implicit CSS would not be respected by backlevel UA's anyway.

Perhaps such a solution would make the spec simpler too.

- Sam Ruby

Received on Thursday, 6 December 2007 07:43:29 UTC