Re: DIV as an inline container

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