Re: DIV as an inline container

>> 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>

> 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.
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 to wrapping one particular element or
set of elements to catch events from them or give them style.

> 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.
-- 
David "liorean" Andersson

Received on Saturday, 4 August 2007 15:16:15 UTC