Je vous ai rapidement parlé de The HTML Framework Project qui propose de réfléchir ensemble à la mise en place d’un environnement de travail pour rendre le démarrage d’un projet de site web moins ennuyeux. Le projet en est à la phase 1.1 : définir. Il est évident que produire un bon code HTML est un métier, un art qui peut difficilement se faire comme on élève des poules en batteries. Pour autant, il doit être possible de dégager parmi les bonnes pratiques de travail, quelques concepts récurrents que l’on pourrait utiliser au démarrage d’un projet.
###C’est quoi un framework HTML, au juste ?
Un Framework HTML devrait inclure une structure de fichiers normalisée, quelques trucs pour mettre les navigateurs au garde-à-vous et des fichiers HTML servant de fondations pour des maquettes différentes. C’est aussi simple que ça : un jeu de fichiers et de répertoires pour amorcer le travail dans la joie et la bonne humeur 😉
###Sur quelles bases construire ce framework ?
S’assurer que le Framework HTML est conforme avec les points suivants :
* Éviter les `tables` pour la présentation,
* Séparer le fond et la forme,
* Réserver la partie présentation aux CSS,
* Prendre en considération la « sémantique » des balises HTML,
* Intégrer des noms de classes signifiants,
* Valider en accord avec les spécifications du W3C.
###Un mot d’ordre : la flexibilité
Pour que ce framework HTML soit utile aux développeurs, il faudra :
* Ne pas gêner les *web designers* (les graphistes doivent pouvoir laisser libre-court à leur créativité),
* S’adapter aux contraintes propres d’un projet (être un plus, pas un obstacle),
* Rester léger en excluant les fonctionnalités superflues,
* Être extensible pour faire face aux besoins futurs.
###Participer à la discussion
On parle beaucoup (ou pas) de HTML5. J’ai donc lancé l’idée de bâtir les fondations du framework sur la base des spécifications du HTML5, notamment pour la partie structure en accord avec la partie sections du W3C :
* `section` — Chapitres, onglets des menu, etc. La page d’accueil d’un site web pourrait être découpée en sections : introduction, news et informations de contact.
* `nav` — Menu principal ou secondaire d’un site web.
* `article` — Partie indépendante d’une page, d’un document ou d’un site : contribution sur un forum, article de magazine, billet de blog, commentaire, etc.
* `aside` — Barre latérale ou contenu adjacent,
* `header` — Regroupement de sections ou de balises `h1`, `h2`, etc.
* `footer` — Pied de page d’une `section`,
* `address` — Informations de contact, idéalement placées dans le `footer`.
Dans le framework HTML, ces éléments pourraient se traduire par :
Les autres éléments de HTML4 étant utilisés — comme d’habitude — de manière à coller au plus près du sens véhiculé par le contenu.
### Pour conclure
L’avantage de calquer les `id` et les `class` sur les balises prévues par HTML5, c’est de voir loin tout en s’adaptant dès maintenant aux nouvelles habitudes de structuration des contenus avec HTML5. Et comme le suggère jdgraffam il est envisageable que le framework définisse un plan pour passer du framework au HTML 5 quand ce dernier sera pris en compte par les navigateurs, tout en restant rétro-compatible !
Faites tourner et n’hésitez pas à partager ce que ce projet vous inspire. Si vous avez des idées et quelques connaissances en anglais, je vous invite à commenter ce billet, ou ici, si vous êtes plus à l’aise en français 😉
hum je crois que j’aime bien l’idée… Faudra que j’aille explorer les liens de ton billet.
Juste pour ton exemple, je pense qu’actuellement, tous les « portages » des notions de sections désirées pour HTML 5 devraient être implémentées en div dans les pages actuelles. Pour faciliter par la suite l’évolution vers HTML 5 justement. Il me semble pertinent de « diviser » sa page en « zone de section » pour coller au concept. Tu vois ce que je veux dire ? (je dis ça sans y avoir réfléchi des heures et après un mauvais réveil, tout changement d’avis par la suite sera donc justement par cette simple phrase :p)
@burningHat:
Justement, c’est l’idée que j’ai en tête et que j’ai proposé. Mais ça risque de ne pas suffir car d’après ce que j’ai lu des brouillons de spécifications HTML5 il faudra certainement rendre les notions de :
Metadata content
Flow content
Sectioning content
Heading content
Phrasing content
Embedded content
Form control content
Interactive content
(certainement par des classes CSS normalisées) pour pouvoir faire une mise-à-jour aisée lors de l’adoption de HTML5 par l’ensemble des navigateur. (c’est pas pour tout de suite, mais bon, autant y penser dès le départ).
J’avais déjà commencé à réfléchir à cette idée de « framework » d’une façon indirecte il y a un peu plus d’un an, en réfléchissant à un cours sur la création de site web qui partirait des contenus et des différentes manières de les organiser sur la page (header, content, sidebar, footer, etc.).
Généralement, cette organisation par section est déjà présente non ?
Le « petit » risque je vois avec un tel FW, c’est éventuellement tomber dans du template et se limiter niveau disposition des blocs. Je me trompe peut-être 🙂 (en tout cas j’espère)
@bruno yop, je disais ça par rapport à ton exemple de <p class=aside> en fait 😉 Mais on est bien d’accord, et comme tu l’indiques, ça ne serait valable vraiment que pour le découpage des sections mais pas pour les « types de contenu » où là un ensemble de classes standardisées me paraissent aussi bien plus opportunes.
@cut_here pas forcément si c’est vraiment fait dans une optique framework et donc extensible voir suffisamment abstrait pour pouvoir s’en échapper. Sinon c’est clair que ça serait pas très intéressant.
@CUT HERE:
Si tu veux dire par là, que toute page web est découpée d’une façon ou d’une autre, c’est pas faux. L’intérêt d’un Framework pourrait être de normaliser ce découpage qui est plus souvent soumis à des contraintes externes qu’aux contraintes spécifiques aux contenus.
Par contraintes externes, je fais surtout allusion à la présentation via CSS qui pèse lourdement sur le balisage HTML alors que ce dernier devrait avoir la priorité. Bref, on pense souvent les composés HTML en fonction de nos capacités à les styler par la suite.
Ce n’est pas forcément un gros défaut, et cette démarche peut même être systématisée sous forme de designs pattern (cf. ce commentaire de Marin Gatellier). Ce qui peut être une manière de réfléchir au framework par la bande en partant des micro-contenus avant de gérer la structure et les sections. A creuser 😉
@burningHat: Pour moi, c’est assez clair qu’un framework est un peu plus qu’un template ^^
Je me demande même dans quelle mesure on ne pourrait pas s’inspirer de Markdown pour générer une version du framework adapté à chaque projet sous forme de listes imbriquées où chaque noeud deviendrait un dossier et chaque élément de liste un fichier avec la description des sections qui le compose jusqu’à descendre au niveau des micro-élements ^^
(Comme tu vois, j’esssaie de te trouver des trucs ultra-motivants pour t’inciter à y réfléchir de près 🙂 )
@Bruno yop, j’en doute pas que c’était bien assez clair pour toi, et c’est pour ça que je répondais à cut-here et pas à toi à ce sujet-là en fait :p Par contre, quand tu dis moi je me demande si tu cherches pas plutôt à me filer la migraine ! 😀 Je vois l’idée mais comme je ne me suis jamais intéressé à la syntaxe Markdown plus que 12 secondes, faudrait en plus que je me renseigne à ce sujet-là 😉
Bonjour Bruno et bjour tlm,
apparemment le projet semble être arrêté. Mort avant d’avoir réellement démarré. Mort « tué dans l’oeuf ». C’est bien dommage.
… pourquoi pas reprendre le concept et redémarrer le projet avec une nouvelle équipe ?