Re: New block-level elements vs. Gecko

On Sep 15, 2007, at 11:46 PM, Robert Burns wrote:

> Hi Maciej,
>
>
> On Sep 16, 2007, at 1:01 AM, Maciej Stachowiak wrote:
>
>> While working on examples for the "Degrade Gracefullly" principle,  
>> I realized that the Gecko handling of unknown elements makes it  
>> pretty hard to do graceful degradation for new block-level  
>> elements. I thought initially that just adding a "display: block"  
>> style rule would cut it, and that does work as expected in Safari  
>> and Opera.
>>
>> However, in Firefox, the open tags of known block-level elements  
>> force unknown elements to be closed. This results in elements like  
>> <article> or <section> being siblings of their intended block  
>> children, rather than their parents, which makes it difficult to  
>> apply styling or event listeners.
>
> You might want to take a look at the wiki page "Thought Experiment  
> In Graceful Degradation".  We are actually accumulating some  
> valuable pages on the wiki and this one definitely helps  
> understanding these graceful degradation issues.

Seems like a good summary.

> It is collecting information on graceful degradation. The issue with  
> Firefox is that it actually assumes unknown elements that get block  
> elements added to them. For example, an unknown element could have  
> the same content model as a 'p' element and still work in Firefox.  
> However,  it cannot allow any structured inline or block level  
> elements or Gecko assumes that an authoring error has occurred that  
> accidentally omits the closing tag (or that the element is just like  
> a 'p' element and permits omitted closing tags).

I think that's pretty much the same thing I said, I think. It turns  
out, though, that almost all of HTML5's new block-level elements take  
block children. The only exception is <figure>, but that has its own  
issues (see upcoming follow-up email).


>> Note: handling of new block elements will be problematic in IE as  
>> well for other reasons. I'm writing a separate email about that.
>>
>
> Yes, IE treats unknown elements as void elements [1]. Its also worth  
> noting that all of the majjor browsers have similar shortcomings  
> when it comes to unknown head elements. It would be best to get all  
> unknown elements working better in both head and body (this would  
> facilitate spec updates better in my view).

That seems like an issue as well, though somewhat less of a problem.  
If new elements that are allowed in the <head> are also allowed in  
<body> and have "display: none" default rendering, then it is a  
reasonable graceful degradation strategy to simply put such elements  
in the body, or at least after all HTML4-known head elements. However,  
something like <section> is useless if it can't contain block  
children, and backup handling through script is more of a burden for  
authors than backup handling through style rules.

Still, if someone has a proposal for a common way to handle unknown  
elements in <head>, I'd love to hear it.

Regards,
Maciej

Received on Sunday, 16 September 2007 07:43:23 UTC