- From: Robert Burns <rob@robburns.com>
- Date: Sat, 4 Aug 2007 10:37:21 -0500
- To: liorean <liorean@gmail.com>
- Cc: "HTML WG" <public-html@w3.org>
On Aug 4, 2007, at 10:16 AM, liorean wrote: >>> On 04/08/07, Robert Burns <rob@robburns.com> wrote: >>>> I don't see any problem with DIV with a strictly inline-level or >>>> inline-level content. Right now the draft says: >>>> >>>> "followed by either zero or more block-level elements, or inline- >>>> level content (but not both)." >>>> >>>> So what's wrong with inline level content? Historically,, DIV has >>>> either been used as either 1) a sectioning element (block-level / >>>> structural only); or 2) as a more flexible P element (structural >>>> inline-level or strictly inline-level). With our current draft, I >>>> think the sectioning elements practically remove any need for >>>> DIV in >>>> the first role. SECTION seems generic enough for any way DIV might >>>> have been used as a generic in that way. That only leaves DIV as an >>>> inline container (structural or strict). In some ways DIV could >>>> just >>>> serve the content model need of P for the text/html serialization. >>>> The semantic space left for DIV is really not any broader than that >>>> for P (in the XML serialization). We could even add a minimized >>>> boolean to DIV to declare this paragraph usage, for example: >>>> >>>> <div p>My structural inline-level paragraph content</div>. > > >> On Aug 4, 2007, at 4:53 AM, liorean wrote: >>> Well, first of all that would make many valid HTML4 documents >>> invalid >>> HTML5 documents. > > On 04/08/07, Robert Burns <rob@robburns.com> wrote: >> How so? There would be no requirement that a DIV have this boolean >> set. It >> could just as well be: >> >> <div>My structural inline-level paragraph content</div>. >> >> or >> >> <p>My strictly inline-level paragraph content</p>. >> >> both of which are HTML4 valid. > > But it would make valid HTML4 snippets like the following invalid > in HTML5: > > <div> > <ol><li>...</li></ol> > <blockquote><p></p></blockquote> > </div> No, that would be valid HTML5. That's exactly the type of (structural) inline-level content I was referring to that the P element uses in the XML serialization of a <div p> element could serve in HTML5 (i.e., a DIV with an extra @p, boolean for paragraph, to indicate it's a paragraph). That's exactly the use of DIV that I think remains in HTML5. There may be other more esoteric cases, but that is the primary one. >> On Aug 4, 2007, at 4:53 AM, liorean wrote: >>> Second, the way I understood the intent of adding the section >>> element >>> is that section is a content grouping mechanism primarily for giving >>> related text an explicit grouping instead of as is the case with the >>> h# elements in HTML4*. The div element on the other hand is also a >>> content grouping mechanism but it doesn't have any explicit grouping >>> purpose, textual or otherwise. The grouping purpose is given to >>> it by >>> it's usage - such as class or id attributes for styling or >>> scripting, >>> attaching events to it, or simply the effects on the DOM tree >>> from the >>> div being there, etc. > > On 04/08/07, Robert Burns <rob@robburns.com> wrote: >> Yes, certainly that's true. However, my point was that after >> establishing >> HEADER, FOOTER, NAV, ASIDE and SECTION, there's very little left >> for DIV to >> do in this area (that it did or does historically). There still >> might be a >> small niche here for a generic sectioning element — one that >> doesn't get >> involved in the outline mechanism — but that's a small role. It >> could be >> covered by DIV without the @p boolean set. Or a DIV with a >> @section boolean >> set. Or whatever. > > I actually think a block level grouping element that does not get > involved in the outline mechanism is more useful than one that does. AS I said, there may still be a need for something like that. Right now blockquote is one element that meets that, but I'm not sure why that's included among the sectioning elements anyway. We could have a way to distinguish DIV for that use (e.g., <div s> to indicate a sectioning DIV that didn't participate in the sectioning/heading algorithm). Or we could come up with another new element for that role (which is very different from a DIV used as a structural-inline / strictly-inline container. > Divs are often used for entirely different reasons than the textflow, > and can wrap very different types of content, everything from wrapping > the entire content of the page Again, we have all of the sectioning elements now that do most of that. Including ARTICLE that I forgot to mention. Where's a place for block-level content model for DIV with a document tree (abridged) like BODY HEADER NAV SECTION ARTICLE SECTION ASIDE SECTION ... ARTICLE ... FOOTER > to wrapping one particular element or > set of elements to catch events from them or give them style. I understand all of those DIV uses in HTML4, but HTML5 (especially its XML serialized version) eliminates many of those legacy needs for DIV. It's still needed as catch-all structural container, but those catch-alls are much less frequent. >> In any event, the sectioning elements create very little need for >> DIV with a >> block content model. Almost the only role left for DIV is as an >> inline >> container. That was the point of my post: to defend the use of DIV >> with an >> inline content model. I don't think a document containing DIV with >> an inline >> content model should be considered a low-quality document. > > Well, that's another issue entirely to me. I don't think the div > element with the %flow content model is made obsolete by the section > element at all, it's just been relieved of a few of many different > uses. This is the issue I'm trying to address. In other words, Hixie raised the "problem" of DIV with elements using an inline content model as an indication of a low-quality document. I'm saying that, with HTML5's sectioning elements, that is virtually the only role left for DIV to play (other than a possible need for a sectioning element that doesn't participate in the sectioning TOC algorithm). Remember with HTML5 we have two kinds of inline content models: strictly inline- level and inline-level. Take care, Rob
Received on Saturday, 4 August 2007 15:37:36 UTC