Re: DogFood, take 2

Ian Hickson wrote:
> 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>?

Partially because I feel that these noise elements express no additional 
semantics, so I felt that one that affirmatively asserts the 
non-semantic value of the make-work markup seemed appropriate.  :-P

In addition, I didn't want to have to figure out what I needed to undo 
because of the additional implicit layout characteristics implied by the 
<p> tag.  For example, I'm pretty sure that I would have had more 
vertical white space between the lines that say "..." and the lines that 
say "nn comments".

Note: this work is done and behind me.  Some parts of it are specific to 
the html5 template I produced for this activity, but others were made to 
my code in ways that are reflected on my "life" site.  The only reason 
why I haven't deployed this live is the severe visual impact it has on 
MSIE users.

I mention this because I feel it is important to distinguish between 
things that impact me (of which there are none remaining save the answer 
to the question about the proper placement of inline SVG in XHTML5) and 
ones that I feel will inhibit the adoption of conformant HTML5 markup.

> 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:
> 
>    <body>
>     <h1>Demo</h1>
>     Unmarked up text as a child of BODY is fine, it implies a
>     paragraph around it.
>     <hr>
>     This is a second implied paragraph as the HR element is a
>     block-level element.
>     <aside>
>      This sidebar doesn't require an explicit P element anymore
>      because the text gets a paragraph implied around it.
>      <ul>
>       <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.
>      </ul>
>      This text is part of the same implied paragraph as the text
>      before it and as of the list.
>     </aside>
>     <section>
>      On the other hand, here we have a FOOTER element at the end
>      of the section.
>      <ul>
>       <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.
>      </ul>
>      <footer>
>       ...
>      </footer>
>     </section>
>    </body>
> 
> 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.

You're looking to impose more restrictions when I think less 
restrictions would make HTML5 more widely adopted in a conformant manner.

Thought experiment: I realize that it is against the tradition of HTML1 
through HTML4, but what would break if *all* content model restrictions 
that deal with the distinction between block and inline elements were 
dropped?  Could specific restrictions then be added back in which 
address specific problems (either of ambiguity or of interoperability)?

>> 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:
> 
>    <ol>
>      <li>
>        text
>        <p> text
> 
> ...or something else?

The mistake I had made was of the form

  <ul>
    <li><p>text</p></li>
    <li><p>text</p></li>
    <li><p>text</p></li>
    <p>text</p>
    <p>text</p>
  </ul>

This clearly is bogus, and I'm glad that the conformance checker flagged 
it.  The fix was to move the final </li> to after the final </p>.

- Sam Ruby

Received on Friday, 7 December 2007 00:51:49 UTC