Benoit Piette

En développement Web, le dicton « Ce n’est pas parce qu’on peut le faire que c’est une bonne idée de le faire » est particulièrement vrai. Par contre, il y a des jours où l’on peut pas s’en empècher, et on pond un peu de javascript fondamentalement inutile, juste pour « le fun ». Voici donc une preuve de concept comme quoi nous n’avons pas besoin de Flash ou de SVG pour faire du graphisme simple sur une page Web. Avant de suivre un des liens qui suit, je dois vous avertir que le javascript a le potentiel de faire crasher votre fureteur si vous l’utilisez trop longtemps, ou encore de ralentir fortement votre machine. À utiliser avec prudence.

• Inutile partie 1 : Les lignes (cliquez avec votre souris plusieurs fois pour activer la fonction)
• Inutile partie 2 (pas besoin de clics, mais plus dangeureux!)

Dernière note : vous aurez certainement remarqué que l’exemple n’est ni accessible ni sémantiquement correct pour le HTML, cela ajoute à l’inutilité de ce code. Je n’ai pas testé avec autre chose que Firefox et IE, j’imagine que cela devrait marcher avec une version récente d’Opera et de Safari.

On sent que des remous recommencent dans le développement Web lorsque de nouveaux buzzwords apparaissent. Le dernier est le AJAX ou Asynchronous Javascript et XML. On pourrait traduire par Javascript et XML asynchrone ou JEXA. Nommé par Adaptive Path, celui-ci désigne un ensemble de technologie, la plupart standards, qui commencent à pouvoir être utilisées pour effectuer des applications Web riches (autre vieux buzzword), car celles-ci ont atteint un bon niveau de maturité et peuvent maintenant fonctionner sur la plupart des fureteurs (Internet Explorer, Mozilla, Safari et Opera).

Ces technologies sont les suivantes :

• (X)HTML standard
• CSS
• Javascript
• Le composant XmlHttpRequest
• Manipulation du DOM (comme XSLT)

La grande différence entre le AJAX / JEXA et le DHTML est la possibilité de rechercher ou d’envoyer des informations à un serveur Web et d’effectuer des manipulations complexes de l’interface utilisateur, sans avoir à la rafraîchir complètement la page. Ceci se fait à l’aide de la composante XmlHttpRequest. Sur Internet Explorer, cette composante est un contrôle ActiveX et sur les autres fureteurs, celle-ci est native.

La technique a été popularisée par Google, avec leurs applications Google Mail, Google Suggest et Google Maps.

Je vais essayer d’ici quelques semaines de vous concocter un petit exemple pour démontrer les capacités de cette technique.

Tiens tiens… On n’a pas toujours le temps de faire de l’assurance qualité sur un blogue! Et oui, j’ai trouvé quelques erreurs de XHTML sur mon site et sur mon blogue. Quelle honte! Moi qui normalement sermone tous ceux qui ont plein d’erreurs de validation sur leur code (X)HTML. Pfff! Enfin, je vais vous donner les quelques trucs que j’ai momentanément oubliés. Cela pourrait soit servir à quelqu’un d’autre, ou encore me servir de rappel pour les prochaines fois!

(Lire la suite…)

Aujourd’hui j’ai le goût de vous parler du choix que j’ai fait en fonction de l’utilisation des standards Web pour le HTML. Après réflexion, qui ne s’arrêtera certes pas après la publication de ce billet, je crois que la meilleure dialectique est d’utiliser quand on le peut le XHTML 1.0 Strict envoyé comme du text/html. Oui, cela signifie envoyer de la soupe de balise, le XHTML devrait de façon optimale être envoyé comme du application/xhtml + xml. Le problème, et dans le fond la solution aussi, est que le Web est optimisé pour la soupe de balises. Le grand avantage de la soupe de balises réside dans sa gestion gentille, voire molle, des erreurs. Comme on n’améliore pas un produit qui marche sans de bonnes raisons financières à court terme, la plupart des produits qui s’intègrent au Web ne respectent pas, mais alors pas du tout les standards. Cercle vicieux, les fureteurs n’ont donc pas le choix d’être optimisés pour effectuer le rendu de la soupe de balises.

(Lire la suite…)

Je viens de terminer de regarder le premier épisode de la nouvelle série de Doctor Who. Ce n’était pas mal. Je dirais que comme premier épisode pour un Docteur cela ce situe un peu en bas de la moyenne. Un peu à cause qu’une histoire = un épisode maintenant. C’est assez bon pour que je regarde les autres épisodes.

Ouf! Le petits ont leurs biberons, ma fille a son jus, ils écoutent un film de Disney, je peux maintenant corriger quelques fautes d’orthographe présentes sur mes billets.

Je ne vais pas par contre mettre des tirets sur toutes les modifications que j’effectue sur les billets. Cela aurait l’air d’un travail d’adolescent corrigé plein de rouge. Il y a des jours où je me dis que je devrais retourner suivre des cours de grammaire! Mais bon, il y a tellement de bons carnets bien écrits que je me trouve un peu en bas de la moyenne ces temps ci. Mais c’est en se pratiquant que l’on devient meilleur. C’est ce que je me dis en tout cas. Pour le reste, je considère mon carnet en version beta et je me permets quelques écarts de conduite le temps que j’en arrive à un bon rhytme de croisière. Je vais peut-être faire comme Google et le laisser en version beta pendant quelques années. On verra.

Aucun commentaire laissé jusqu’à maintenant. Cela veut dire que je ne suis pas assez populaire pour que cela dérange quelqu’un! Yé!

Parfois, il nous arrive d’avoir à mettre de vrais tableaux sur des pages HTML, et ce, même si on a presque pris l’habitude de les transformer en <div> au cas où ce serait un tableau de présentation!

Et comme les designers s’en donne à coeur joie à rendre la vie difficile aux intégrateurs HTML, cela arrive que l’espacement horizontal entre les bordure de cellules soit différent de l’espacement vertical. Sans compter aussi tous les coins ronds…

Le W3C propose une fonctionnalité de CSS 2 qui règle un de ces problèmes à merveille : le border-spacing, qui prend deux valeurs, l’espacement l’horizontal et vertical et s’applique pour tout le tableau. (ex : border-spacing : 10px 2px;).

(Lire la suite…)