La subtile différence entre acronym et abbr...

Accessify.com fait la démonstration aboutissant à une règle fort simple:

  • Si c'est prononçable, il faut utiliser le tag <acronym>. C'est le cas, par exemple, pour SIDA ou OTAN. On reconnait bien mieux le mot sida ou Otan en le prononçant qu'en l'eppellant, n'est-ce pas?
  • Si ce n'est pas prononçable, il faut utiliser le tag <abbr>. C'est le cas, par exemple, pour SNCF ou HTML. Essayez donc de prononcer les mots sncf ou html sans les épeler lettre par lettre!

Quel intérêt tout ça? Les browsers vocaux ou les lecteurs d'écran ont besoin d'être prévenus lorsqu'un mot ne doit pas être pronconcé tel quel, mais eppelé (abbr). Quant à acronym, il permet simplement aux browsers d'indiquer la signification de l'acronyme, par exemple quand on place le pointeur de la souris dessus. Bien évidemment, les browsers graphiques (sauf IE6! :( )font de même avec abbr.

Voir aussi: Acrobot pour une liste d'acronymes et d'abbréviations...

Maintenant, le problème c'est qu'il est extrêmement pénible, quand on écrit, de signaler systématiquement les abbréviations et acronymes, autant écrire les expressiosn complètes directement! A quand un éditeur (X)HTML avec dictionnaire intégré qui s'en charge automatiquement?

Citation du jour

En discuttant de la complexité du tableless design, Karl m'a envoyé aujourd'hui un morceau d'e-mail que j'adore!! :D

Je pense qu'un vrai designer, c'est quelqu'un qui sait concevoir un produit. Le produit est ici un site Web. C'est comme si tu disais à un architecte que l'architecture est vraiment complexe dans l'exercice de son métier.




Le problème c'est qu'on enseigne pas aux designers le Web. Ils apprennent le graphisme sur d'autres médias: peintures, crayons, infographie, etc, mais ils n'apprennent pas ce qu'est le Web, d'où les catastrophes récurrentes.


Un bon designer devrait connaître la technique sous jacente comme le fait un couturier, un architecte, un dessinateur de voitures, etc...


Le problème est qu'il y a très peu de designers :)


-Karl Dubost

Design sans tableaux: C'est pas encore ça!

Mon précédent post sur le sujet a reçu un certain traffic dont beaucoup de visiteurs parlant plutôt l'anglais. (Merci à Erik!)

Du coup je me suis dit que j'allais écrire un article entier en anglais cette fois: Tableless Design: Not ready for prime time!. L'objectif de cet article est de montrer un exemple de pourquoi la mise en page HTML sans tableaux n'est pas encore vraiment prête pour être utilisée dans tous les cas de figure, contrairement à ce qu'en pensent un nombre grandissant de personnes... Read more!

Valid XHTML...

Je pense que l'on sous-estime systématiquement la rigueur nécessaire à la production de code XHTML valide... nos browsers sont TELLEMENT permissifs! :'(

Personnellement je m'en suis rendu compte en collant ce petit logo en bas de chacune de mes pages:
Valid XHTML 1.0!

On a si vite oublié un caractère accentué par ici ou un & par là... voire un / en fin de balide IMG... Le bouton sur chaque page aide à les vérifier... mais je dois avouer que je n'ai pas eu le courage de les faire vraiment toutes... :-/

Ceci dit, ma plus grosse perte de temps a été d'essayer de rendre valide les pages de blog, lesquelles contiennent des tags RDF permettant théoriquement aux clients de découvrir automatiquement l'adresse de trackback. Pas moyen de les faire accepter au validateur. Ca s'est fini entre commentaires HTML... comme préconisé par Movable Type...

PS: ah oui, à voir aussi: la méthode b2 pour rendre le RDF valide: si HTTP_USER_AGENT contient 'W3C_Validator' alors on n'envoie pas le RDF... PFOUAH! 8|

Tableless design

Vous avez peut être remarqué que les entêtes de pages et la navigation de ce site ont très légèrement changé... c'est le résultat de longues contorsions CSS pour supprimer tous les tableaux inutiles de ce site! (C'est à la mode! :P )

En fait, c'était plus un exercice de style qu'une réelle conviction que les tableaux doivent être définitivement bannis comme technique de mise en page HTML. Enfin plus précisément: oui IDEALEMENT il ne faudrait pas utiliser de tableaux à de seules fins de mise en page et tout faire en CSS, mais je pense que les implémentations actuelles de CSS dans les navigateurs les plus courants sont insuffisantes pour obtenir les résultats voulus. Alors certes, j'y suis (à peu près) arrivé mais ce fut beaucoup plus compliqué qu'avec des tableaux. On ne peut pas espérer, dans ces conditions, que la majorité des webdesigners se mette "à la page"!

PS pour les mordus: Je voulais que mes "rollovers" de navigation aient tous la même largeur. C'est ça qui complique tout (voir code source...) Si je m'étais contenté d'une largeur proportionnelle au texte celà aurait été enfantin (Je ne comprends d'ailleurs pas pourquoi Mark à fait tout un foin de ses onglets -- proportionnels évidemment! :>> ). Par ailleurs, je voulais que le tout soit redimensionnable en fonction de la taille de police choisie par l'utilisateur (et même sous IE). Finalement, il me reste un problème: du contenu invisible à droite de la boite de titre de la page. C'est gênant (enfin, je pinaille...), car il fait apparaitre un ascenseur en bas de page avant l'heure lorsque l'on réduit la largeur de la fenêtre! Si vous savez faire disparaitre ça (sans provoquer de retour à la ligne du titre dans certains browsers), vous êtes probablement un Dieu vivant du CSS pratique! :D