W3C home > Mailing lists > Public > public-html@w3.org > December 2007

Re: DogFood, take 2

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 6 Dec 2007 21:44:02 +0000 (UTC)
To: Sam Ruby <rubys@us.ibm.com>
Cc: public-html <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0712062130020.7985@hixie.dreamhostps.com>

On Thu, 6 Dec 2007, Sam Ruby wrote:
> Second, I added what appears to me to be an entirely unnecessary <div> 
> element around the search form <input> elements [...]
> Fourth, in my article headers, I surrounded the time element with a div 
> tag. [...]
> Fifth, some of my articles summaries contain only strictly inline 
> elements and text.  Suffice it to say that this is common in weblogging.  
> I found that I had to add a <div> element in such cases. [...]
> Eighth (and finally), as my article footers consist solely of an anchor 
> tag, I found that I had to add a immediately vestigial <div> element.

Why <div> and not <p>?

What we could do is simply say that any run of inline content between 
block-level content implies a paragraph (though without a <p> element 
appearing in the DOM), much as we currently define that multiple <hx> 
elements in the same <section> element imply a section (though without a 
<section> element appearing in the DOM).

This would mean that:

    Unmarked up text as a child of BODY is fine, it implies a
    paragraph around it.
    This is a second implied paragraph as the HR element is a
    block-level element.
     This sidebar doesn't require an explicit P element anymore
     because the text gets a paragraph implied around it.
      <li>This list implicitly becomes inline-level, since it is
      within an element with children that all are valid as
      inline-level content.
      <li>However, <em>that</em> would mean that:
       <p>This paragraph is invalid, because it's a block-level
       element in an inline context.
     This text is part of the same implied paragraph as the text
     before it and as of the list.
     On the other hand, here we have a FOOTER element at the end
     of the section.
      <li>Therefore the parent section element of this list has
      block-level children.
      <p>Which means it is fine for this list to contain paragraphs.

That's somewhat confusing. I think if we go down this road we should 
remove the ability for certain elements to act as both inlines and blocks, 
as otherwise authors will get very confused as to when they're in an 
implied paragraph and when they're not.

> Seventh, I did find the issue in my content where a multi-paragraph list 
> item did not properly enclose all the paragraphs, i.e., some paragraphs 
> spilled out to into the void between the list items.  As it was well 
> formed and displayed "correctly" in Firefox, Safari, and Opera, I would 
> have been unaware of this if it weren't for the conformance checker.

Do you mean markup like this:

       <p> text

...or something else?

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 6 December 2007 21:44:15 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:24 UTC