- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 31 Dec 2008 00:29:44 +0000 (UTC)
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: public-html@w3.org
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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 31 December 2008 00:30:21 UTC