Il existe de très nombreuses ressources pour apprendre les langages du web HTML & CSS. Bien sûr, les spécifications du W3C en la matière sont un passage indispensable, mais il ne faut pas oublier qu’il existe des tutoriels plus… didactiques. Ceux que je vous présente vous prendront par la main pour que le plongeon dans le grand bain de l’intégration web ne se transforme pas en «plat» douloureux. →
Suite à l’arrivée W3C mobileOK Checker sur mon écran radar (merci @flashxman), je me suis dit qu’il pourrait être utile de faire une liste des outils proposés par le W3C pour vérifier la conformité de nos sites web par rapport aux standards, aux bonnes pratiques ou aux performances web. D’une manière générale, ces outils œuvrent pour l’amélioration de la qualité web. →
La réponse courte à la question « Combien de balises `h1` dans une page Web HTML5 ? » est : « Autant que nécessaire ! » En gros, chaque fois que vous avez une nouvelle section, vous pouvez mettre un `h1`. D’une manière générale, `h1` accompagnera `article`, `aside`, `nav` ou `section` avec brio ! (cf. Sectioning content). Allons voir ce que nous disent les spécifications HTM5 sur l’emploi des balises de titre `h1` — `h6`, notamment les exemples concernant les niveaux de titre. Ils sont assez parlant bien que parfois déroutant lorsqu’on a l’habitude du balisage utilisé jusqu’à présent. Les éléments `h1` — `h6` représentent les niveaux d’en-têtes de leurs sections respectives. Quant à l’élément `hgroup`, il regroupe un ensemble d’en-têtes composé d’au moins deux niveaux de titre, comme un titre et son sous-titre ou un titre et le slogan associé (un bon candidat pour Logo et Motto, faute de mieux). →
Les frameworks CSS ont fait couler beaucoup de pixels : d’un côté, ils proposent une méthode à l’épreuve des balles pour placer les blocs sur sur la page en tenant compte des contraintes cross-browser ; de l’autre, ils ajoutent des classes CSS superflues dans le code HTML pour la présentation des contenus, ce qui n’est pas jugé «sémantique» par les farouches défenseurs d’une séparation entre le fond et la forme. Voilà en gros l’avantage principal et l’inconvénient majeur qu’on peut dégager si on met de côté le faux problème du poids de ces frameworks. Après avoir donné mon point de vue sur cette question de «sémantique» j’expliquerais comment l’ajout de classes liées à la présentation dans le HTML peut s’avérer très pratique à l’heure du web «sur-mesure». →
Suite à mon dernier billet sur les différentes manières d’aborder le balisage HTML d’une hCard, Neovov et burningHat ont soulevé la question de la sur-sémantisation du code d’une manière générale et de la sur-utilisation des listes en particulier. Neovov, par exemple, ne voit pas pourquoi on devrait mettre des listes partout. burninHat quant à lui, se demande si l’on ne n’accorde pas trop d’importance à la description de notre code HTML… Magneto ! →
En lisant ce billet de Frédéric de Villamil sur le compte rendu du troisième WASP café France dans lequel il présente un exemple de structuration du microformat hCard, je n’ai pu m’empêcher d’ajouter mon grain de sel pour remplacer la divite et la spanite par une structure à base de listes imbriquées que je trouve comment dire… plus sémantique… →
