Re: DogFood (and inline/block constraints)

On Dec 5, 2007, at 10:22 PM, Ian Hickson wrote:

>
> On Thu, 6 Dec 2007, Sam Ruby wrote:
>>
>> 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"
>
> If you are asking why the spec doesn't allow elements to have a mix of
> inline-level and block-level child elements, the reasons the spec  
> doesn't
> allow it include (off the top of my head):
>
> * Mixing inline and block content makes it hard for non-visual UAs to
>   determine where to pause (the "paragraph breaks" for lack of a  
> better
>   term)
>
> * Mixing inline and block content makes it very hard for editors to
>   properly allow editing of content.

For what it's worth - I don't think this creates huge problems, at  
least in WebKit. We consider mixed inline/block content to have block  
boundaries where blocks begin and end. For example:

<div>
I don't know how I feel about this kind of markup.
<p>It seems kind of messy.</p>
Doesn't it?
</div>

This edits basically as if it had three paragraphs (and I think is  
read as such, too, by VoiceOver, though I'm not 100% sure on that).  
Due to the CSS display property and the possibility of invalid HTML,  
we have to handle cases like this anyway, as well as even more  
annoying things like blocks inside inlines. Handling all this in the  
editing code is not always fun but I don't think the resulting user  
experience of editing such markup is particularly bad. And it's  
certainly better than the experience of editing in the face of layout  
tables, CSS inline-block, CSS floats, or CSS positioning.

I don't feel qualified to comment directly on the semantic issues; but  
I think it's probably ok to focus on those as the driver for this  
design issue.

Regards,
Maciej

Received on Thursday, 6 December 2007 06:47:51 UTC