Toutes les notes

Flux RSS des notes

La sortie de la bêta d'Internet Explorer 9 est prévue pour le 15 septembre prochain, autant dire que cette version est attendue avec impatience ! Étant donné le piètre support de HTML5 et CSS3 (entre autre) dans les précédentes moutures d'IE, tous les espoirs se focalisent sur cette nouvelle version. En revanche, il faudra avoir Vista ou Seven pour faire tourner cette bêta (au moins sur des machines virtuelles). Quelques liens dans l'actu :

Un copieux article dédié aux microformats vient d’être publié par Oli Studholme sur l’excellent HTML5 Doctor : Extending HTML5 — Microformats. L’auteur commence par survoler les moyens dont nous disposons pour ajouter plus de sémantique à nos pages : HTML 4 (éléments meta, attribut rel, etc.), les différences avec HTML5 (dépréciation de l’attribut rev, intégration de ARIA), puis liste les 33 « spécifications » des microformats (dont 17 sont en brouillon, et 7 décrivent de bonnes pratiques de structuration − les design patterns). Finalement, c’est la conclusion de cet article qui m’intéresse le plus. Outre le problème du support plus que limité de ces micro-spécifications, c’est la logique même de leur conception que l’auteur met en cause, et je suis entièrement de son avis : les microformats sont construits par-dessus HTML, sans espaces de nom, et utilisant exclusivement des attributs HTML existants (class, rel, etc.). En clair, c’est un gros hack en attendant d’avoir mieux… c’est à dire RDFa. Si vous n’avez pas la moindre idée de ce qu’est RDFa, je vous invite à consulter ce très bon article de David Larlet : Le point sur RDF et RDFa. Pour plus d’infos sur le RDFa et plus généralement le web sémantique, vous pouvez aussi consulter le site du W3C : http://www.w3.org/standards/semanticweb/. Et vous, au-delà de ce que propose nativement HTML, quelles sont les solutions que vous mettez en place pour affiner la sémantique de vos pages web ?

Après avoir fouillé pas mal de coins et aussi quelques recoins, je me suis aperçu qu’il existait très peu de ressources sur le support des CSS d’impression dans les différents navigateurs. C’est tout à fait compréhensible, car CSS 2.1 offre peu de possibilités, qui sont de toute façon très peu implémentées. Mais avec les possibilités qu’offrent certains modules de CSS3 (CSS3 Media Queries, CSS3 Paged Media Module, CSS3 Generated Content for Paged Media Module), nous devrions bientôt pouvoir commencer à nous amuser ! J’ai donc commencé à créer quelques tests, ainsi qu’une page listant les résultats. Ce n’est qu’une base, mais elle devrait rapidement évoluer, surtout si une envie folle de participer vous emporte ! La page permettant de consulter les résultats est ici : http://bpierre.github.com/css-print-test/ Si vous souhaitez participer, vous pouvez télécharger l’ensemble sur la page du projet : http://github.com/bpierre/css-print-test/

Éric Daspet organise une soirée dédiée aux performances web, le 21 juillet 2010 à Paris. Vous aurez le plaisir, entre autres, d’y entendre Stoyan Stefanov, qui fait partie l’équipe performances de Yahoo!, et travaille sur des projets comme YSlow et Smushit!. L’inscription est gratuite, mais il est demandé aux participants de relayer l’information au maximum. Sympa non ? Vous trouverez tous les détails sur la page de l’événement : une soirée d'échanges à propos des performances web

Pour appliquer des styles différents lorsque JavaScript est activé, une bonne solution est d'ajouter une classe spécifique sur l'élément body. Mais si les scripts ont été placés en fin de page pour des raisons de performances, il peut y avoir un temps d'attente (grossièrement, le temps de télécharger la page, puis le script, et enfin d'exécuter le script) qui laissera apparaître un "flash" avec les styles prévus pour la version sans JavaScript. Le meilleur compromis que j'ai trouvé est de placer le script suivant juste après l'ouverture de l'élément body : 
<body>
<script type="text/javascript">
    document.body.className+=" js";
</script>
Et d'une manière raccourcie à l'extrême (attention, c'est-pas-valide) : 
<body>
<script>document.body.className+=" js"</script>
Connaissez-vous une meilleure solution ? Tiens, je me demande s'il ne serait pas plus logique d'avoir cette fonctionnalité directement en CSS, à l'aide d'une nouvelle règle @script par exemple : 
@script javascript {
    /* Styles spécifiques pour JavaScript */
}

jQuery Lint est un script permettant de vérifier automatiquement la qualité de votre code jQuery, en vous suggérant les améliorations possibles (par exemple, préférer .css({}) à .css("","")­.css("","")). Le projet est encore très jeune, et se base sur l'outil de test QUnit, déjà utilisé pour les tests de jQuery. Vous noterez que son nom est inspiré de JSLint, l'excellent outil de contrôle de qualité JavaScript réalisé par Monsieur Douglas Crockford (le papa de JSON). Mais attention, jQuery Lint n'a absolument pas pour objectif de remplacer JSLint. Ces deux projets n'ont ni les mêmes buts, ni le même mode de fonctionnement : JSLint analyse votre code source, tandis que jQuery Lint effectue ses tests pendant l'exécution. Et vous, de quelle manière testez-vous votre code JavaScript ?

L'excellent blog Software is hard (que vous devez connaître si vous suivez la veille des intégristes), tenu par les auteurs de Firebug, vient de publier un article sur l'utilisation de l'extension pour analyser en détail les requêtes HTTP. Vous y trouverez des exemples interactifs (pratique, Firebug utilise HTML/CSS pour son interface) à propos de la limite du nombre de connexions, du Pipelining HTTP, des connexions persistantes, des blocages liés aux scripts en ligne, ainsi que des redirections HTTP. C'est ici : Page load analysis using Firebug.

Notes plus anciennes