Re: Void elements in HTML (Was: ZIP-based packages and URI references into them ODF proposal)

On Tue, 30 Dec 2008, Julian Reschke wrote:
> > ...
> > > The problem can be fixed by stating once and for all the syntax for future
> > > elements.
> > 
> > That doesn't work. It would mean never introducing new void elements and 
> 
> ... which I think is no problem at all ...

Right, but we disagree on this, as noted earlier in this thread. I have to 
balance all the various needs here. Some of these needs are better 
satisfied by introducing lots of new void elements frequently; other needs 
are better satisfied by never introducing void elements. One has to 
balance these needs, which is how we end up with introducing a few void 
elements at very disparate intervals (on the order of decades).


> > never introducing new block-level elements. For example, in HTML5, it 
> > would mean not introducing <command>, <event-source>, <section>, 
> > <nav>, <aside>, <footer>, <header>, etc.
> 
> Could you please explain (or point to an explanation) why exactly it 
> needs to be known beforehand whether something is block-level or not? 
> It's certainly not needed for serializing a DOM, so I assume the parser 
> needs to know for some reason?

Block-level elements have to be known by the parser so that optional </p> 
end tags can be implied.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'