Présentateurs recherchés pour les prochaines réunions du W3Québec

Voici quelques sujets que j’aimerais retrouver à l’une des prochaines réunions mensuelles du W3Québec.

Si vous seriez intéressé à venir parler d’un de ces sujets, n’hésitez-pas à me contacter

  • Développement d’interfaces Web riches avec Adobe Air et Flex
  • Développement d’interfaces Web riches avec Silverlight et .NET
  • Développement d’interfaces Web riches avec Mozilla, XUL et Prism
  • Développement Web avec les librairies javascript (Dojo, ou YUI ou jquery ou prototype ou autres)
  • Accessibilité des applications à interfaces riches
  • Intégration d’application Google (Google Maps, Google Apps, etc)
  • Présentation d’application Web 2.0 québécoises (startups et autres)

Il a Samuel Sirois qui va venir nous parler de HTTP dans quelques mois, ce sera certainement intéressant. Ma présentation sur REST ma démontré que nous n’en savions pas assez sur le protocole qui est à la base de presque tout ce que l’on fait!!! J’avoue que je n’ai pas tout compris sur les différences entre POST et PUT (leur idempotence entre autres)

D’autres sujets sont les bienvenus aussi. Il manque de XML la dedans… (ben dans le fond il y en a indirectement)

L’utilité de l’attribut summary dans les tableaux HTML

Lors de la réunion mensuelle du W3Qc hier, je parlais avec Samuel Sirois (Trigosoft) qui suit présentement le cours de Jean-Marie D’Amour sur l’accessibilité. Nous discutions des éléments et attributs en accesibilité que HTML 5 prévoit peut-être laisser tomber, comme l’attribut summary pour les tableaux. L’argument est sensiblement celui-ci : lors de tests d’utilisation de l’attribut, il a tendance à ennuyer les utilisateurs plutôt qu’à les aider.

Or, Samuel me disait, cela est différent selon le type de document. Dans une application que quelqu’un utilise souvent, l’attribut summary est répété à chaque fois. Il est donc particulièrement désagréable (surtout s’il est long). Par contre, sur un site Web visité très peu souvent, l’attribut est beaucoup plus intéressant puisqu’il aide l’utilisateur à se faire un modèle mental du tableau avant que celui-ci soit exprimé.

Dans le premier cas, le modèle mental existe déjà et il est redondant. Dans le 2e cas, il est vraiment utile. La solution ici est bien plus au niveau d’utiliser l’attribut à des bons moments (sur un site Web plutôt que dans des applications Web, par exemple), ou encore que les agent utilisateurs donnent la possibilité aux utilisateur de ne pas faire répéter les descriptions de contenus qui ont déjà été exprimés.

Une solution pourrait être que pour une session, l’agent utilisateur ne répète pas les descriptions des éléments qui ont le même id ou la même class. Cela vaudrait peut-être un attribut spécial en css pour le spécifier.

En utilisabilité, on dit que c’est important de ne pas se répèter, en accessibilité aussi! Ce que je comprends, c’est qu’il y a beaucoup de méconception sur l’accesibilité et qu’il faut réfléchir bien comme il faut plutôt que suivre des recettes toutes faite qui peuvent si mal utilisées diminuer l’accessibilité au lieu de l’améliorer. Je crois aussi qu’il ne faut pas mélanger les fonctionnalités d’un langage et les bonnes pratiques. Les bonnes pratiques ne sont pas des recettes, mais des méthodes avec une philosophie derière. Si un élément d’un langage est le plus souvent mal utilisé, ce n’est pas le rôle de standardiseurs du langage d’enlever l’élément du langage, mais bien le rôle de ceux qui font la promotion des bonnes pratiques de promouvoir les bonnes utilisations de l’éléments (et ce, même s’il y en a des mauvaises). Cela passe effectivement par comment l’élément du langage est utilisé dans la vrai vie, et d’y trouver des bonnes utilisations. Il est vrai qu’il peut y avoir des éléments de langage qui n’ont pas assez de bonnes utilisations pour être retenus, mais je ne pense pas que ce soit le cas pour l’attribut summary.

Reste maintenant à spécifier quelques bons cas d’utilisation et en parler sur la liste du Working Group de HTML…

Planète XMLfr

J’ai été invité cette fin de semaine par Eric van der Vlist à faire partie des blogueurs de l’agrégateur Planète XMLfr. Je me rappellait avoir utilisé XMLfr lors de recherches à quelques reprises durant le passé et d’avoir été impressioné par la qualité de l’information. C’est donc avec enthousiasme que j’ai accepté l’invitation. Je ne considère par mes billets du même niveau de qualité, mais cela me donnera l’occasion de faire un effort constant pour les améliorer (un peu de pression ne fera pas de tort).

Je vais donc me présenter aux lecteurs de Planète XMLfr, question de donner le contexte dans lequel je blogue. Je me nomme donc Benoit Piette et je travaille dans le Web depuis 1996, tant comme développeur/programmeur qu’analyste, architecte technologique, spécialiste en qualité, chargé de projet, etc. J’ai toujours été intéressé par la standardisation ouverte du Web, je crois que c’est dans ma nature, mais aussi un peu puisque mon premier travail en tant que stagiaire était de nettoyer du code circa 1996 généré par l’une des première version de Frontpage. Du code qui ne respecte pas les bonnes pratiques, j’en ai vu, et pas juste un petit peu (et j’en ai probablement fait un peu aussi, mais pas trop quand même). Le Web pour moi doit être le plus accessible tant pour ceux qui l’utilisent que ceux qui le construisent et cela passe par les standards ouverts non encombrés par des brevets.

En 2003, j’ai découvert le W3Québec, fondé par Denis Boudreau du Cybercodeur. À un moment où l’industrie allait dans une direction Internet Explorer seulement, j’ai tout de suite sauté sur l’occasion de faire partie d’un organisme qui comprenait vraiment le Web. Le reste c’est de l’histoire et j’en suis maintenant le président. Je fais aussi partie du Working Group HTML du W3C comme expert invité. Je n’ai toutefois que très peu participé depuis le début, mais je regarde de près ce qui s’y passe. Je suis aussi parfois conférencier, j’ai été à Intracom 2007, aux Mercredi du libre et aux WebÉducation à quelques reprises.

Assez parlé de moi, je vais commencer à écrire mon prochain billet. J’espère que les lecteurs de XMLfr vont y trouver leur compte. Pour mes autres lecteurs, je vous conseille vivement d’aller faire un tour sur XMLfr. Il y a des articles particulièrement intéressants, je vous conseille de lire cet article sur le débat XHTML / HTML qui donne une optique différente de ce que nous sommes habitués de lire ces temps-ci.

Mauvaise expérience avec Vista

Je vais rajouter mon lot de mauvaises expériences à celles des autres par rapport à Vista. Vraiment, c’est le pire système d’exploitation par rapport aux attentes que j’ai utilisé. Je voulais une machine pour du développement .NET et Java qui servirait aussi aux jeux pour le reste de ma famille. C’est pour cela que j’avais choisi Vista Ultimate, pour la connexion à distance et Virtual PC. J’ai pas mal grincé par rapport au prix du OS, mais j’ai eu un bon prix pour la machine et je me suis dit qu’après un an Vista pouvait pas être aussi pire. Erreur, grosse erreur. J’ai de la misère à copier des fichiers de mon Mac vers le PC. Mon vieux Pentium II avec Windows 98 a moins de misère ! Va falloir que je brûle un CD ou que je transfère les fichiers sur un disque externe pour les amener sur le PC. De la sérieuse connerie je vous dis. Depuis septembre que j’ai acheté cette machine et je ne me sert presque pas. Comme je risque de ne plus faire de développement .NET et que je peux faire une bonne partie du développement Java sur mon iBook, je fini par utiliser l’écran du PC comme 2e écran pour mon iBook. C’est à peu près cela. Conseil : si vous achetez un nouvel ordi, ne touchez pas à Vista même avec un bâton de 30 pieds.

Billets HTML 5 dans le train

J’ai écrit une couple de billets au lieu de dormir dans le train de banlieue sur HTML 5, je vais les mettres (en fait je viens de les mettres) en ordre inversé de leur écriture juste pour que ce soit plus facile à lire, mais vous pouvez les lire dans n’importe quel ordre si cela vous chante.

Quand devrait-on utiliser HTML 5 ?

Faut comprendre que pour que HTML 5 deviennent un standard ouvert, il n’est pas nécessaire d’attendre que HTML 5 devienne une recommandation du W3C, ou même une candidate recommandation.

Et je crois même que de l’utiliser sera la meilleure pratique bien avant. Je n’attendrai certainement pas 2012 avant de l’utiliser. Sinon, c’est aussi bien de lâcher la patate et de considérer que Adobe Air ou que Silverlight ont gagné. Vous ne voulez pas un Web fermé ? Moi non plus. Fatigué de la soupe de balise ? Et moi donc!

Surtout que les standards actuels, XHTML1 et HTML 4 ont assez de problèmes et d’incohérences, que je ne vais pas attendre 2012, ni même 2009.

Je vais essayer de pondre quelques billets pour démistifier HTML 5 et comment nous pouvons en utiliser une partie tout de suite, quite à se tromper un peu et de rester à la fine pointe de ce qui est possible.

Le tout est nouveau, si vous voyiez des erreurs, n’hésitez pas à me le faire savoir

Alors sans plus tarder voici une série de billets sur HTML 5

HTML 5 ou HTML5 ou XHTML5 ou DOM5 HTML

HTML 5 est le standard qui défini des API (interfaces de programmation), des éléments de structures, des sérialisations de documents et du comportement des analyseurs syntaxiques

HTML5 (sans espace) c’est la sérialisation, donc ce qu’on code, pour les analyseurs syntaxique HTML (les navigateurs Web en possèdent un)

Par opposition, dans HTML 4, on parle d’analyseurs syntaxiques basés sur le SGML. HTML au départ, était basé sur SGML, mais les analyseurs syntaxiques HTML doivent prendre en comptes plein de choses reliés à la manière dont le Web a évolué qui n’on pas vraiment rapport avec SGML (par exemple javascript, le Document Object Model, etc).

XHTML5 c’est une sérialisation XML, un peu comme XHTML 1, avec la différence qu’il doit être analysé par un analyseur syntaxique XML, pas tous les navigateurs Web en possède, mais aussi tout autre analyseur syntaxique XML (écrit en java, C#, C, Perl, etc)

DOM5 HTML c’est la représentation mémoire de notre document HTML, c’est la suite des DOM level 1, 2 et ainsi de suite.

HTML 4 et XHTML 1 ne parlent pas des API, de la gestion des erreurs non conformantes, mais HTML 5 le fait. Le tout pour une meilleure intéropérabilité entre les implémentations du standard.

Est-ce que nous pouvons utiliser HTML 5 aujourd’hui et que ça marche sur tous les navigateurs modernes ?

Pas tout-à-fait, mais c’est possible en partie, en théorie. Commençons par les nouveaux élément de structure (section, aside, article)

Opera et Safari n’ont pas de problèmes à styler les nouveaux éléments HTML 5. Donc on peut utiliser les section, aside et ainsi de suite avec ces navigateurs.

Internet Explorer, évidemment, ne peux pas. Même pas IE7. Mais il y a un hack, qui nécessite malheureusement javascript. Il suffit de créer un élément DOM avec le nom de la balise utilisé pour que notre style fonctionne. Ex: document.createElement(“aside”);

Le plus gros problème cette fois vient de Firefox. Pour Firefox, tous les éléments non reconnus sont considérés comme inline (comme span). L’analyseur syntaxique ne permet pas de mettre un élément block (comme p ou div) à l’intérieur d’un élément inline, il pense que c’est une erreur alors il va fermer la balise.

Quelque chose comme section, p, texte, /p, /section, va devenir de façon interne à Firefox section, /section, p, texte, /p, section, /section, pas vraiment ce que l’on veut.

Tant que l’analyseur syntaxique de Firefox ne sera pas corrigé, impossible d’utiliser HTML5 de façon intéressante sur le Web. J’espère que ce sera réglé d’ici Firefox 3, mais c’est loin d’être certain. C’est sûr que je vais être très déçu de Mozilla (genre assez pour changer de navigateur) s’ils ne règlent pas ce bogue d’ici Firefox 3.

Qu’en est-il de XHTML5 ? Lui n’aura pas le problème d’analyseur syntaxique, la balise ne sera pas fermée, mais elle sera toujours inline. Il faudra donc spécifier que section est block dans le CSS. Pas trop difficile.

Donc, en théorie (parce que je vous averti que je ne l’ai pas testé) pour faire du HTML 5 maintenant il faut :

  1. Coder comme si c’était du XHTML5 (donc, sans noscript, sans entités autres que celles de XML, mais avec UTF8 pour les accents), mais sans autre namespace que HTML
  2. Lors de l’envoi du HTML par le serveur, quand c’est Internet Explorer, enlever la déclaration XML, ajouter le DOCTYPE et les namespace du HTML et envoyer le tout en text/html. IE va l’analyser comme de la soupe de balise (mais entre vous et moi, qui analyse autre chose que de la soupe de balise).
  3. Pour les autres, envoyer la version XML telle qu’elle. On peut aussi opter d’envoyer la version XML seulement à Firefox puisqu’il est généralement conseillé d’utiliser la sérialisation HTML5 (ça va faire plaisir à ceux qui pensent que XHTML ça ne sert pas à grand chose, faut bien leur donner leur nanane 😉 )

Voilà, je vous tiens au courant quand je l’aurai testé. Cherchez un peu sur le Web, je suis sûr que d’autres vont essayer cela bientôt.

Je vous ai tu dis que <br/> avec le trailing slash est correct en HTML5 ? Ça nous sauve pas mal dans notre cas. Voilà un bon coup pour le HTML5, ce sera facile de migrer notre XHTML 1 sans perdre de lisibilité.

Version 1.0 de Grails

Le framework de dévelopement Java agile GRAILS est maintenant en version 1.0. GRAILS est un framework ressemblant un peu à Ruby on Rails, mais qui au lieu de réinventer Rails en Java complètement, se base sur des technologies Java éprouvées, comme Spring et Hibernate. C’est le prochain truc que je veux apprendre et comme d’habitude, si j’en ai le temps, vous allez en entendre parler sur mon blogue. Je crois que ce framework a beaucoup de potentiel.