NB : ce billet aurait dû être publié le 26 Septembre dernier.
Je me suis abondamment moqué des comportements de MSIE quant aux standards, notamment le plus basique de tous, à savoir le HTML. Et surtout de son impact fondamental sur la construction des formulaires, ce qui est la base d'une interaction web, j'ai nommé la balise <button></>
.
Mais soyons honnêtes, Firefox n'est pas tout clean lui non plus.
Il se trouve que je suis tombé la semaine dernière dans un bug (en fait, associé à un deuxième) qui m'a fait devenir chèvre pendant deux jours. Et ce bug a fêté Vendredi dernier ses dix ans, dans l'indifférence la plus totale.
Ce bug est l'un des plus vieux ouvert dans Bugzilla, le système de contrôle qualité des produits Mozilla, Firefox inclus.
Bon, il est vrai que dans Bugzilla, on ne trouve pas que des bugs, mais aussi des demandes de fonctionnalités, des rapports de traductions, des organisations de boums, fêtes, pique-niques, et autres plaisanteries.
Pourtant, Firefox est un des navigateurs qui jouent à la fois sur l'excellence et l'avancée des normes. On lui doit le XUL, l'avancée dans le Javascript, l'intégration des RSS et tout comme d'autres navigateurs (open-source comme KHTML/Webkit ou closed comme Opera) participent à l'élaboration de nouvelles normes (HTML5, Webforms2, Microformats,...)
Mais là, on touche au fondamental du navigateur. Et alors que la créations de web-applications va en s'accélérant grâce au coup de boost donné cet année à Javascript (à son habitude, MSIE rame lamentablement sur la touche), ben il se trouve que Firefox est toujours incapable d'aligner les chiffres dans un tableau.
4 tables mal mises comme “exemples”
Table 1, paramètres d'aspect en attributs dans la balise html <TD>
(c'est mal)
Alignement normal | En haut à gauche | En bas à droite | Aligné sur, la virgule | sur le # dièse | lorem ipsum | ABCDE | FGHIJ | 0,15 | #AB2 |
Table 2, paramètres d'aspect en attributs dans la balise html <COL>
(c'est mal)
Alignement normal | En haut à gauche | En bas à droite | Aligné sur, la virgule | sur le # dièse | lorem ipsum | ABCDE | FGHIJ | 0,15 | #AB2 |
Table 3, paramètres d'aspect associé à TD.colX
via css
(c'est normal, mais le code est brise-burnes : pourquoi autant de répétitions ?)
Alignement normal | En haut à gauche | En bas à droite | Aligné sur, la virgule | sur le # dièse | lorem ipsum | ABCDE | FGHIJ | 0,15 | #AB2 |
Table 3bis, paramètres d'aspect associé en css à TD nth-child.
Et puis quoi encore ? On fait comment pour les cellules sur plusieurs colonnes ?
Table 4, paramètres d'aspect associé à COL via CSS (ce serait l'idéal)
Alignement normal | En haut à gauche | En bas à droite | Aligné sur, la virgule | sur le # dièse | lorem ipsum | ABCDE | FGHIJ | 0,15 | #AB2 |
Mais quel mouche le pique ?
Mon “combat” peut paraitre anecdotique, surtout que depuis dix ans un workaround existe en Javascript. L'application Google Documents ne s'en sert pas, l'handicapant dans les mises en formes de données financières. Ben pour moi, le simple fait que l'on soit obligé de créer ce genre de code est totalement anormal pour un navigateur qui a toujours clamé haut et fort qu'il respecterait les normes (HTML, CSS, Javascript,....). Ici, c'est la toute première qui n'est pas bafouée.
Il se trouve aussi que l'on parle d'une balise définissant un aspect dans le HTML, alors que cette fonction devrait être révolue à la CSS.
Ben oui...
...mais ça ne marche pas non plus en CSS !
Et la description en question est issu de la norme HTML 4.01. Sauf que la section des tableaux n'a jamais été décrétée obsolète, ni dans les normes XHTML 0.1, 1.1 et encore moins dans le brouillon HTML5.
C'est loin d'être la seule inconsistance par rapport à la norme HTML4 (dans le métabug 7954 , on note une gestion des sections marquées XML approximative)
En fait, la résolution de la plupart de ces bugs auraient été particulièrement utiles à l'ère du surf par modem ( comme le standby de la balise <object></>
, mais le workaround que j'emploie me semble plus élégant), ce en quoi, on a une approche pragmatique du progrès à la Microsoft (tu sais, cher lecteur, que dans ma bouche cette expression n'a rien d'un compliment). Je veux bien que le développement se fait par une équipe qui fut majoritairement bénévole, mais néanmoins, je m'étonne que le respect intégral des normes n'aie pas été considéré comme une priorité.
Aggravées circonstances atténuantes
Non, en fait, je pense que si ce bug a été soigneusement enterré (comme le bug 2212 et d'autres duplis), c'est tout simplement à cause des mauvais designers web, ce qui faisaient toute la mise en page avec des tableaux, dans d'autres tableaux. Vous savez, tous ceux qui vous ont ri au nez sur l'utilité des css ou de faire un code HTML sémantiquement propre.
Alors d'accord, <table>
c'est mal. À une exception près : Il se trouve que les tableaux, on peut en avoir besoin pour présenter des données tabulées. Par exemple, une grille tarifaire. Et ça, c'est exactement ce pour quoi un tableau est conçu.
Or l'alignement horizontal de chiffres, ça serait âchement cool si on pouvait faire en sorte que la virgule soit alignée verticalement. En fait, je suis prêt à parier que pour arriver à introduire fortement Firefox dans les grandes entreprises, ce genre de fonctionnalité permettrait de donner un sacré coup de jeune à beaucoup d'intranet.
En l'absence de son support, il existe des “solutions” assez bancales : utiliser l'alignement à droite et une police à chasse fixe. Gros problème, si vous utilisez une notation suisse pour les prix ronds (“95,—” au lieu de “95,00”), ou que vous mettez des lignes en gars, ça ne tient plus.
Aligné à droite | Aligné sur la virgule |
95,00 | 95,00 |
95,- | 95,- |
95,00 | 95,00 |
95,00 | 95,00 |
Manifestons !
Ce que vous pouvez faire :
- Si vous êtes impacté par ce bug, en parler
- Si vous êtes web-designer, web-developpeur ou utilisateur éclairé, vous pouvez votre pour la résolution de ce bug (lien “Vote” tout en bas)
- Si vous avez des potes à la MoFo, leur faire remonter l'info
Allez quoi, il a pas droit à un joli cadeau pour ses dix ans, ce bug ?
7 réactions
1 De Da Scritch - 23/10/2008, 18:30
Après tests, cela ne marche ni dans Firefox 3.0, ni dans Konqueror 3.5 (KHTML), ni dans Konqueror 4.1 (WebKit), ni dans Opera 9.6
Si ça marche dans MSIE, c'est la grosse loose
2 De TarValanion - 25/10/2008, 09:56
Je suis désolé d'avoir sali ce billet en l'ouvrant avec IE7, mais effectivement sur IE, je n'ai vu aucun problème. Alors que FF bugge... Je vais de ce pas voter pour la résolution.
3 De David Baron - 26/12/2008, 19:15
http://dbaron.org/log/20080515-age-...
4 De Da Scritch - 26/12/2008, 19:42
David, your words are very wise about reporting bugs and energy that might be used to solve them.
Does this little paragraph in the HTML specification and in the CSS one about text-alignment in tables should require some peoplepower to solve it ? My thoughts (in French upper in this page) : in 1998 we needed to convert drastically webdesigners to tableless code. In 2003, little were converted. But in 2009, very few make table design like in the prehistoric times of the WWW, and we need more features and strict standard respect to improve our web-applications. Character-alignment in tables is really useful for commerce-related application, intranets, and others data related presentations.
I hope someone will fix #915 and #2212. I do some business-related web applications, and not being able to align comas (or points, for english-readers) is a design and comfort issue.
But it will make those apps more professional on Fx than MSIE.
character alignment is not depreciated, still in XHTML and CSS standards.
So please, can a browser fix this ? Will Opera, Safari, or ... MSIE solve it before ? I hope MoFo will keep its leadership in standard-repects.
5 De Uqbar - 18/09/2009, 10:56
The point with bug 915 is quite simple in my opinion.
Firefox (up to 3.5.2) doesn't implement a part of the standard (http://www.w3.org/TR/html401/struct...) and a useful one. This is not a bug. Is a hole in the implementation.
(I'll skip the discussions on why the <COL> tag has been introduced.)
As a consequence, the usefulness of the <COL> tag is so limited that it makes little sense to use it (only the width property works so far).
Everyone says you can use CSS, Javascript and a number of other workarounds.
All of them end up by moving the column level definitions away from the <THEAD> section (where they should belong to and where an application would generate them) to somewhere else. This defeats all efforts done to make HTML as smart and useful as possible.
But these are just my opinions
6 De Dascritch depuis Twitter - 15/04/2011, 16:38
@karlpro En cours: On prépare une longue liste. Sinon c'est les bugs 915, 2212,... http://dascritch.net/post/2008/10/23/Les-dix-ans-dun-bug
7 De da scritch net works - 13/03/2012, 15:09
Me voici à Sud Web
Et bang ! J'ai encore du mal à y croire. Mais fin Mai, je devrais aussi assurer le show. Me voici orateur à Sud Web, la plus grande conférence technique du secteur au sud de Paris. Un festival de rock stars du web jouant de vertigineux solos de...