- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 5 Dec 2007 22:47:35 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Sam Ruby <rubys@us.ibm.com>, public-html@w3.org
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