Mes impressions sur le web, les standards et autres…


Sida ? La première maladie virtuelle de l’histoire !

Le Dr Robert Gallo, travaillant à l’Institut National de la Santé des USA, et qui avait commencé par annoncer la prétendue découverte du premier rétrovirus humain (HTLV-1) découverte qui ne fut jamais confirmée, a donné une tristement célèbre conférence de presse, le 23 avril 1984, en présence du Secrétaire d’État à la Santé, pour déclarer que la science américaine venait de découvrir un rétrovirus comme cause probable du sida. Aucune publication scientifique ne permettait de soutenir cette hypothèse ! Dès le lendemain, la presse a laissé tomber le mot "probable"… et depuis, la recherche sur le sida a sombré dans le domaine de la science-fiction. Sans aucune base scientifique, le dogme VIHSIDA = MORT fut mondialement accepté. Très rapidement, sous la pression du monde "gay" américain, le nom même de la maladie qui était Gay Related Immune Deficiency (G.R.I.D) fut changé pour enlever un signe discriminatoire intolérable. Un lobbying frénétique et insensé s’est développé pour produire en un temps record un traitement pour le Acquired Immuno Deficiency Syndrome (AIDS).

Sida ? La première maladie virtuelle de l’histoire !

Bon, je savais bien que ce billet provoquerait des réactions vives et variées :¬/ vous comprendrez donc pourquoi j’ai lâchement décidé de ne pas autoriser les commentaires sur ce billet (les rétroliens sont, eux, quand même permis; Je n’ai pas complètement fermé la porte aux réactions). Quelques précisions :

Ce billet n’est en aucun cas un quelconque reflet de mon opinion sur ce sujet. Le but de ce billet est uniquement de partager avec mes lecteurs la trouvaille d’un article interessant et semblant assez complet.

Benoit, lecteur régulier du blog webnaute, m’informe après recherche que l’auteur de l’article, Mark Griffiths, est décédé le 17 octobre 2004 et me communique également quelques liens :

Firefox 1.5 et extensions manquantes

La version 1.5 bêta de Firefox est désormais imminente. J’utilise quotidiennement depuis quelques jours les compilations nocturnes de la veille pour éventuellement y trouver un bug, tester les nouveautés apparues dans Gecko 1.8 et, plus simplement, pour profiter de la vitesse d’affichage fortement améliorée. Pas d’impression négative pour l’instant, si ce n’est quelques ratés avec le DOM inspector.

Quelques extensions ne fonctionnant pas sur cette nouvelle version de Firefox m’empéchaient cependant de lâcher définitivement Firefox 1.0.6 : View Cookies, Link Toolbar et surtout Web Developer.

Pour l’extension View Cookies, j’ai eu accés directement via le système de mise à jour de Firefox à la version 1.3 qui fonctionne très bien sur les dernières compilations. Concernant l’extension la plus utile pour moi, Web Developer, un contributeur a publié sur le forum de support un lien vers une version adaptée et fonctionnant sur Firefox 1.5 bêta.

Il ne me manque plus que la Link Toolbar. Les contributeurs à cette extension sont déjà à pied d’œuvre pour assurer la compatibilité.

Nouveautés dans Firefox 1.5

Après une nouvelle mise à jour automatique via le système de mises à jour de Deer Park, je constate qu’il a changé de nom pour reprendre l’appellation Mozilla Firefox (suivi d’un petit Beta 1). La chaîne UA confirme ce changement. La sortie de la première version bêta de Firefox 1.5 est désormais imminente (c’est une question d’heures). Profitons-en pour refaire un petit tour des nouveautés qu’apporte Firefox 1.5.

Éléments HTML, tabindex et attention (focus)

Les éléments possédant un attribut tabindex avec une valeur négative peuvent maintenant obtenir l’attention (Bug 171366). Bon point : Cela permettra une plus grande accessibilité pour les scripts générant des structures avec le DOM. Mauvais point : Ce n’est pas à priori en conformité avec la recommandation HTML, laquelle indique que cet attribut peut prendre une valeur entre 0 et 32767. Ceci dit, du strict point de vue de la DTD, c’est valide.

Par contre, la recommandation dit également : Les éléments suivants reconnaissent l'attribut tabindex : A, AREA, BUTTON, INPUT, OBJECT, SELECT, et TEXTAREA, donc évitez quand même les trucs du genre <div tabindex="-1"> en dur dans vos documents HTML ;¬)

Formulaires et élément OBJECT

Les éléments OBJECT présents dans un formulaire et possédant un attribut name font maintenant parti des données soumises lors de la validation du formulaire. La partie de la recommandation sur les commandes dans les formulaires n’est pas très claire sur ce qu’il est sensé se passer : la valeur initiale d'un élément OBJECT dans un formulaire est déterminée par l'implémentation de l'objet (i.e., elle n'est pas précisée par cette spécification). Avec ça, on est bien avancé tiens… (Bug 188938).

Support des citations imbriquées

Elles sont désormais supportées comme décrites dans la spécification CSS 2.1.

Ce mécanisme est en sursis en ce qui concerne la spécification CSS 2.1 mais est néanmoins bien présent dans le module CSS 3 sur le contenu généré.

Support de la pseudo-classe :only-child (CSS 3)

Bètement, ça sélectionne l’élément (ou n’importe quel élément si on ne le précise pas ou qu’on utilise le sélecteur universel) seulement s’il est l’unique enfant de son parent.

Surlignements CSS 3

Firefox supporte maintenant les propriétés outline, outline-width, outline-style et outline-color décrites dans CSS 3. Firefox 1.0.x les supportait déjà, mais uniquement avec le préfixe -moz-, et ce support était boiteux :

La propriété outline-offset est également supportée (Je l’utilise d’ailleurs sur ce site pour le menu).

Module Multi-column layout (expérimental)

Ce module est pour l’instant supporté à titre expérimental. Un bel exemple d’utilisation (et en bonus, des précisions sur cette implémentation).

Curseurs et CSS

Les nouvelles valeurs possibles dans CSS 3 pour la propriété cursor sont désormais supportées (bug 163174), de même que la syntaxe permettant de spécifier un icône de curseur avec une URL ( bug 286303). J’ose espérer que ce sera désactivable à l’aide d’une préférence dans about:config. Le document What’s new indique de toute façon que les curseurs animés (en SVG, GIF ou autre) ne sont pas supportés.

Autres nouveautés CSS

Support des propriétés overflow-x et overflow-y de CSS 3 (Ces propriétés sont supportées également au moins par IE). Ajout également de la propriété -moz-outline-radius (non standard et je n’en ai rien vu dans CSS 3).

Il y a aussi bien sùr une des nouveautés les plus attendues : Le mécanisme de génération de compteurs. Sauf que l’implémentation faite dans Firefox correspond apparamment à une mise à jour à venir de CSS 2.1, donc il y a peut-être quelques différences mineures avec l’implémentation existante dans Opera. Encores des maux de tête en perspective…

N’oublions pas également le nombre élevé de bugs CSS corrigés (grr… d’URL à rallonge).

Et pour JavaScript ? Et le DOM ?

À vrai dire, les nouveautés n’ont pas de quoi faire entrer en transe vu qu’il y en a très peu. Pas de diminution drastique de la ribambelle de bugs présents dans l’implémentation du DOM Events. Pas d’implémentation de l’interface nodeIterator (supportée par Opera). Pas de nouveauté percutante quoi.

Bon, il y a quand même, de façon globale, un nombre conséquent de bugs corrigés. Pour les quelques nouveautés, je vous renvoie au document dont j’ai donné l’URL au début de ce billet.

Support de SVG

Je n’ai que très peu de connaissances de ce format, mais c’est assez important donc je le dis : Firefox 1.5 supporte nativement le SVG ( de même qu’Opera si je ne m’abuse). Mozilla SVG Project (pour les infos et les exemples).

Support de XForms

XForms est appelé à devenir la prochaine génération de formulaires en lieu et place des basiques formulaires du HTML. Basé sur XML et disposant bien évidemment d’un espace de nom, il pourra donc être utilisé dans n’importe quel document XML le nécessitant, et notamment XHTML 2.0.

Le support de XForms dans Firefox ne sera pour l’instant disponible que via l’ajout d’une extension. Ça plus le fait que Firefox est, à ma connaissance, le seul navigateur à supporter XForms signifie que cela ne sera utilisable à court terme, et au mieux, que sur un intranet par exemple (mais c’est déjà pas mal si on fait abstraction de la complexité de XForms). Mozilla XForms Project.

En vrac

Parmi les autres nouveautés ou corrections importantes, citons notamment :

Voilà, je pense que ce petit tour d’horizon (qui ne concerne que la partie développement web des nouveautés de Firefox 1.5; voir aussi la catégorie dans laquelle est publié ce billet) est relativement complet. Pour la liste des bugs notables corrigés et concernant le développement web, je m’attelerai à la tâche ces prochains jours dans un autre billet.

Idéogrammes

Just for fun. "Au revoir" dans plusieurs langues asiatiques :

  • En japonais : さようなら (vous savez, le fameux "sayônara")
  • En chinois : 再見 (à priori, se prononce "zài jiàn")
  • En coréen : 안녕

Et pour "Bonjour" :

  • En japonais : こんにちは
  • En chinois : 你好
  • En coréen : 여보세요

Les "alphabets" basés sur des idéogrammes ont un certain charme, vous ne trouvez pas ?

Typographie : Le tiret

En typographie, les caractères ayant le plus de potentiel d’apporter de terribles maux de têtes sont les tirets et autres traits typographiques. Trait d’union, insécable ou non, conditionnel, tiret classique, cadratin, demi-cadratin — avons-nous bien ici un trait d’union ? —, signe moins arithmétique, … Arghh…

Vulgairement, le tiret est un trait horizontal, plus ou moins large, plus ou moins signifiant, tantôt conçu pour diviser, tantôt pour unir, parfois pour recenser. Mais c’est bien sûr le tiret canonique, le vrai, le noble et le puissant tiret sur cadratin, qui fascine le littéraire. Carnet de bord d’une épopée rectiligne.

Petit ajout parce que j’ai un problème qui me triture les méninges. Je viens de lire l’article sur les traits d’union (Hyphens) du wikipedia anglais.

Est-ce que le trait d’union classique (U+002D) — je l’ai appelé "tiret" plus haut, argh, /se fouette — autorise une césure à sa droite ? Si oui, à quoi sert finalement le trait d’union conditionnel (U+00AD) ? Sinon, à quoi diable peut servir le trait d’union insécable (U+2011) ?

L’article dit également que le trait d’union classique a deux fonctions possibles : comme trait d’union ou comme signe moins, pour des raisons de facilité. Unicode a gardé ce caractère (probablement pour raison de compatibilité) mais a défini deux caractères qui reprennent chacun une de ces fonctions :

  • Le trait d’union, qui n’a qu’une fonction, unir deux mots : U+2010 ( ‐ )
  • Le signe moins arithmétique : U+2212 ( − )

P.S : D’ailleurs, si quelqu’un sait comment faire sur Linux pour bien avoir le signe moins arithmétique lorsqu’on appuie sur la touche qui va bien dans le pavé numérique et non pas le trait d’union classique (celui qu’on obtient déjà par l’appui sur la touche 6/-), je suis preneur :¬)

Ah, il faut aussi que je trouve comment faire pour qu’en tapant la combinaison compose + `-` + `-`, j’obtienne un tiret demi-cadratin (et un tiret cadratin si je fais la composition en passant par le signe moins du pavé numérique tiens).

[ctrl] + [shift] + [code hexadécimal unicode] sur Gnome. Excellent ce raccourci, je connaissais pas :¬)

Nouveautés dans JavaScript 1.6

Parmi les nouveautés qu’apporte Firefox 1.5, il en est une que j’ai bètement passé sous silence dans le billet Nouveautés dans Firefox 1.5 : Le passage de JavaScript en version 1.6, imposé par l’arrivée de certaines nouveautés. Rappelé à l’ordre par Benoit, me voilà contraint de détailler dans ce billet les nouveautés en question ;¬)

ECMAScript for XML

De son petit nom, E4X. E4X est standardisé par l’Ecma sous l’appellation ECMA-357 et ajoute un support natif du XML dans l’ECMAScript (la version normalisée du cœur de JavaScript). Grâce à une syntaxe simple et intuitive, E4X se veut une alternative crédible aux méthodes DOM classiques d’accés à un document XML. Quelques exemples :

var xmlObject = new XML("<items>
    <item val="attrVal">essai1</item>
    <item>essai2</item>
    <item>essai3</item>
  </items>");

alert(xmlObject.text()); // affiche essai1 essai2 essai3 (avec les sauts de ligne et indentation)

var itemList = xmlObject.item;
alert(itemList); /* affiche 
  <item val="attrVal">essai1</item>
  <item>essai2</item>
  <item>essai3</item> */

alert(itemList.length); // affiche 3
alert(itemList[0].@val); // affiche attrVal

// Utiliser E4X en conjonction avec le DOM ? C’est possible !
xmlObject = new XML(document); // ou n’importe quel autre nœud DOM

Ce ne sont que de brefs exemples. Consultez les liens suivants pour en savoir plus :

Méthodes sur les objets Array

De nouvelles méthodes font leur apparition sur les tableaux JavaScript. Les méthodes indexOf() et lastIndexOf() sur un tableau permettent désormais de récupérer l’index d’une valeur donnée, éventuellement en partant d’un index donné. Exemples :

var aColors = ["rouge", "bleu", "vert", "orange", "violet", "vert", "marron"];
alert(aColors.indexOf("vert")); // affiche 2
alert(aColors.lastIndexOf("vert")); // affiche 5

// En spécifiant un index de départ

alert(aColors.indexOf("vert", 3)); // affiche 5
alert(aColors.lastIndexOf("vert", 4)); // affiche 2

alert(aColors.indexOf("blanc")); // affiche -1, cette valeur n’est pas présente dans le tableau

Cinq méthodes sont maintenant utilisables pour appeler une fonction sur chaque entrée d’un tableau.

every(callback[, thisObject])
Applique la fonction callback sur chaque entrée du tableau et renvoie true si la fonction callback a renvoyé true pour chaque entrée
filter(callback[, thisObject])
Applique la fonction callback sur chaque entrée du tableau et renvoie un tableau contenant les entrées pour lesquelles la fonction callback a renvoyé true
forEach(callback[, thisObject])
Applique la fonction callback sur chaque entrée du tableau
map(callback[, thisObject])
Idem que forEach(), mais la fonction callback est appliquée sur une copie du tableau, la-dite copie étant ensuite retournée par map()
some(callback[, thisObject])
Idem que la méthode every() sauf que cette méthode renvoie true si la fonction callback a renvoyé true pour au moins une des entrées du tableau

Consultez les liens suivants pour plus de détails :

Il y a aussi une section Array and String generics dans la page New in JavaScript 1.6 mais vide pour l’instant. Je complèterai donc ce billet ultérieurement.

IE7 : En vrac

Lu dans Hello from LA ! sur l’IEBlog :

  • Fonction Quick Tabs permettant à l’utilisateur de gérer dans une fenêtre les onglets ouverts sous forme de miniatures (j’espère que j’ai à peu près bien traduit)
  • Nouvelle fonctionnalité de zoom permettant de zoomer aussi bien les textes que les images
  • Améliorations sur Open Search
  • Améliorations sur la sécurité, et notamment, désactivation par défaut de la plupart des ActiveX
  • Intégration du navigateur avec le système de contrôle parental de Windows Vista
  • Modifications sur la gestion de certains éléments de formulaire (les <select> ne seront plus récalcitrants à passer derrière un bloc en position absolue)
  • Du fait de la désactivation des ActiveX, l’objet XMLHTTPRequest sera disponible nativement
  • Support des IDN
  • Développement d’une barre de développement web (à l’instar de l’extension Web Developer de Firefox) sous forme d’add-on (elle sera apparamment disponible aussi pour IE6)
    Nouveau billet publié sur l’IEBlog : Developer Toolbar for IE announced at PDC

Chris Wilson, directeur de l’équipe de développement d’Internet Explorer a publié un billet complémentaire à propos du bug concernant le doctype switching et le passage d’IE6 en mode de compatibilité si le doctype est précédé d’un prologue XML. Ce bug sera corrigé dans la version 7.

Il a également annoncé qu’IE7 ne supporterait pas le type de média application/xhtml+xml (traduction approximative) :

Pourquoi n’ajoutons nous pas le support de XHTML servi avec le type de média application/xhtml+xml dans IE7 ? J’ai pris la décision de ne pas essayer de supporter (Ndt : Je sais, c’est un anglicisme) ce type de média dans IE7 parce que personnellement, je veux que XHTML soit un succés à long terme. J’aime XHTML (regardez, mon nom est dans la liste des contributeurs à XML 1.0); cela permet une vraie interopérabilité si c’est bien fait.

Avec la plupart de nos plateformes de ressources dans IE7, en dehors de la sécurité, utilisées pour améliorer notre support de CSS, si nous essayions de supporter réellement XHTML dans IE7, nous devrions le finir en utilisant notre parseur HTML existant (qui se concentre sur la compatibilité) et hacker les structures XML.

Il est très peu probable que nous puissions supporter XHTML correctement dans ce cas ; En particulier, nous ne devrions certainement pas détecter quelques cas d’erreurs ici et là, et nous devrions supporter silencieusement ces cas invalides. Ceci, bien sùr, causerait des problèmes de compatibilités basés sur le gestionnaire d’erreurs du parseur dans le futur, ce que XML essaye précisément d’éviter ; Nous ne voulons pas causer d’autres problèmes comme avec la gestion actuelle des erreurs HTML (initiée pour la compatibilité avec les précédents navigateurs – vous pouvez me blâmer personnellement pour cela, mais pas IE).

J’aimerais beaucoup plus prendre le temps d’implémenter proprement XHTML après IE7, et avoir quelque chose de vraiment interopérable – mais j’ai voulu débloquer le déploiement de XHTML du mieux que nous puissions, c’est pourquoi nous nous sommes assurés de corriger le bug du prologue XML/DOCTYPE.

Le texte original :

Why aren’t we supporting XHTML when it’s served as the application/xml+xhtml media type in IE7? I made the decision to not try to support the MIME type in IE7 simply because I personally want XHTML to be successful in the long run. I love XHTML (go look, my name is in the credits for XML 1.0); it’s capable of being truly interoperable if done right.

With most of our platform resources in IE7 outside of security work being spent on improving our CSS support, if we tried to support real XHTML in IE7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs.

It is highly unlikely we could support XHTML well in this way; in particular, we would certainly not detect a few error cases here or there, and we would silently support invalid cases. This would, of course, cause compatibility problems based on parser error handling in the future, which XML is explicitly trying to avoid; we don’t want to cause another mess like the one with current HTML error handling (rooted in compatibility with earlier browsers – you can blame me for that personally somewhat, but not IE).

I would much rather take the time to implement XHTML properly after IE7, and have it be truly interoperable – but I did want to unblock deployment of XHTML as best we could, which is why we made sure to address the XML prolog/DOCTYPE issue.

Sept jours sans tabac

Samedi dernier dans la nuit, je n’avais plus qu’une cigarette et aucun endroit où en acheter — sauf un, mais j’avais trop la flemme de sortir. En fumeur raisonnable, je décide de garder cette cigarette pour le moment où j’irais me coucher. Finalement, je n’ai pas fumé cette ultime cigarette.

À partir de dimanche, je suis rentré dans la logique suivante :

  • Je n’ai toujours pas fumé cette cigarette, ce serait idiot de le faire maintenant, donc je dois tenir encore (= le défi)
  • Si jamais j’avais un "moment de faiblesse", je pourrais toujours fumer cette seule cigarette sans avoir besoin d’acheter un paquet neuf (achat du paquet = fumer tout le paquet = retour dans le tabagisme)

Pour l’instant, ça se passe plutôt mieux que je ne le craignais. Du stress, des difficultés à me concentrer sur ce que je fais, mais moins que prévu. Je pense que le cap le plus dur est presque passé (la première dizaine de jours).

Quand même, passer de 25–30 cigarettes par jour à 0, tout en bossant juste à coté d’un fumeur (il fume des clopes à la menthe mais bon… :¬)), avec un point de vente de tabac juste en bas de chez moi, et après huit ans de tabagisme, je me surprends moi-même. Je ne suis pas encore tiré d’affaire, mais c’est un bon début.