Can you believe that G.W. Bush defeated one million other spermatozoa about fifty years ago ? :-P

I am more and more convinced each day that Selectors need a way to specify that the subject of a selector is not the last sequence of simple selectors (ie be able to select an element based on its children or following siblings), and a way to match the depth of an element (ie :nth-depth-of-type(an+b)).

I dislike the new <l> element proposed by last XHTML 2.0 Working Draft. It is supposed to replace <br/> and I strongly disagree it can do it. Here is why. Consider a normal paragraph without explicit line breaks.Wrapping is done automatically by the UA if needed, where it is needed.

<p>Combien sont ces six saucissions-ci ? Ces six saucissons-ci
   sont six sous. Si ces six saucissons-ci sont six sous c'est
   six sous trop cher.</p>

And let's suppose we want to materialize a mandatory line break after the period. With <br/>, we have:

<p>Combien sont ces six saucissions-ci ? Ces six saucissons-ci
   sont six sous.<br/>Si ces six saucissons-ci sont six sous c'est
   six sous trop cher!</p>

Simple, easy, fast. Works just fine. Dozens of implementations.

With <l>, what do we have ?

<p><l>Combien sont ces six saucissions-ci ? Ces six saucissons-ci
   sont six sous.</l>Si ces six saucissons-ci sont six sous c'est
   six sous trop cher.</p>

The <l> element does not represent a single line because the WD says "Whether the line should wrap or not visually depends on styling properties of the element.".

Conclusion 1 : <l> is not needed, it's just a span with a collapsable line break before and after. That should be, in the spirit of XHTML 2, expressed by style languages only, right ?

Let's edit our document fragment, putting the caret just after <br/> or the end tag </l>. Let's type a backspace in our editing environment to aggregate the two pieces of text before and after the line break. What happens ?

In the <br/> case, we just hit an empty element and we remove it, period. Just like when we hit backspace after an image or any replaced element. In the <l> case, we need to completely remove the <l> element and replace it by its contents. That's far more expensive than the <br/> solution but I could live with it. But wait ! What if the following style rule applies to the document ?

l { font-weight: bold; color: red; }

I know this is unlikely to happen often but it's possible. So let's consider the case. Then the only choice is to cast the <l> into a <span> carrying inline style equivalent to that rule. Grrrr. But wait again, XHTML 2.0 dropped the style attribute. Oooh, you need now to create a special style rule with a pseudo-random class or ID for that span. This becomes far too complex for a simple operation like backspace after a line break.

Conclusion 2 : <l> element is just not usable in a wysiwyg editing environment.

And then

Conclusion 3 : <br/> is considerably simpler to understand and use than <l>. We should stick with it. XHTML 2.0 is ugly.

Now implemented in nightly builds of Mozilla. Thanks David.