• Received my first email from a .name TLD
• If you read french, read this article by John Le Carré. It's a longer version of the one he published in english on opendemocracy.net. It really deserves 5 minutes of your time.

[en] Select your preferred language for this entry if you have a :target enabled browser

Les Samedis du Libre is hosting tomorrow saturday 18th of january in Paris, from 2pm to 6pm, a seminar about Blind people's accessibility to GNU/Linux.

[fr] Choissisez dans quelle langue vous voulez lire cet article si votre navigateur implémente :target

Les Samedis du Libre organisent demain samedi 18 janvier de 14 à 18 heures à La Cité des Sciences une réunion sur l'Accessibilité des non-voyants a GNU/Linux.

If you're interested in linguistics, keep preciously this link in your bookmarks.

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)).

The more I read the comments in favor of XHTML 2.0, the more I am against it. It's just totally crazy. In substance, these comments say "the web is made of quality on one hand, and tag soup that could live with nroff on the other; and we care only about the former". I just can't believe that what is offered to our future sagacity is the following set: XHTML2, Schemas, XPath, XSL, ... Hey folks, wake up. These technologies are perfect for batch processing and I'll be retired, or even turned into a fossil, before a browser is available on the market with all that in. Karl, I strongly disagree with you, that's not much ado about nothing.

Si vous êtes francophones, ne vous y trompez surtout pas. La page d'accueil du site de mon ami Jean-Claude a beau ressembler au Web de 1995, vous êtes chez un gourou, un vrai. Windows (toutes versions) n'a strictement aucun secret pour lui, et IBM France voudrait bien que ses ingénieurs connaissent aussi bien Lotus Notes dans ses moindres recoins. Comme il le dit lui même, "La Connaissance s'accroît quand on la partage!". A partager sans modération.

Read this before buying a cellphone running under Windows...

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.

• Internet browser that quadruples surf speed wins Irish science prize (newsobserver.com, 780,000 lines of code)
• 16 year old whizkid writes new browser (online.ie, 1,500,000 lines of code)
• Student builds fast browser program (Taipei Times, first Internet browser in the world to actually incorporate a DVD sidebar)

www.stfinianscollege.com says absolutely nothing about this award... BUT I found this video (sorry, Real format, no mpeg)!!!

Here is the demo of the power of :target pseudo-class. Tabs and tabpanels only in CSS and without JS. Of course, it needs a browser implementing :target....