Dans la famille des “Cadeaux Web Design qu’il vaut mieux donner que jeter à la poubelle”, voici une petite liste d’astuces CSS glanées au fil du temps. Elles est destinée à tous les niveaux, et peut être agrandie par vous-même en m’envoyant vos supers astuces, ou bien par moi-même si jamais d’autres idées lumineuses me reviennent…

Après mon tutoriel CSS : l’Art et la Science, voici un tutoriel sur l’autre partie importante de mon expérience d’intégrateur : WordPress le Tutoriel.

Je considère mes connaissances comme étant open-source. Et, de peur de les voir perdues à jamais, je préfère les écrire et les faire partager gratuitement avec la communauté des intégrateurs que nous sommes.

Ce tutoriel WordPress vous aidera à créer vous-même votre propre thème WordPress, mais contient aussi un thème WordPress vide gratuit sur lequel vous pouvez vous baser.

Si vous êtes friands de paysages arides, de reptiles sauvages ou encore de culture aborigène, abonnez-vous au flux RSS !

WordPress vient d’annoncer une Release Candidate pour la version 3. J’ai pour ma part installé et mis en prod la version Beta 2 qui, ma foi, est très stable. Si vous comptez l’installer, allez-y! Les mises à jour se font comme les WP actuellement, c’est à dire automatiquement. Et le système de template pour les thèmes est identique donc vos thèmes marcheront sans souci! Le seul souci est qu’il n’y a pas de version française encore mais bon, c’est uniquement pour l’admin qui est vraiment très simple en anglais.

Nouveautés WordPress 3

Dans les nouveautés, il y a :

• choisir son login et son mot de passe : au lieu d’avoir “admin” et un mot de passe généré automatiquement, on peut les choisir soi-même.
• un nouveau thème par défaut, bourré de nouvelles fonctions et qu’on va customiser dans ce tutoriel
• custom background : un outil dans l’admin pour pouvoir choisir un fond pour le site. Si vous développez des thèmes vous même, ça vous est inutile.
• Multi-sites! En fait, WordPress et WordPress µ ont fusionné : il est donc possible avec 1 seule installation WP de mettre en place autant de blogs différents que l’on veut. Par exemple : css.bbxdesign.com pour un blog de CSS, inspiration.bbxdesign.com pour un blog d’inspiration etc.
• Custom Post Types
• Custom Taxonomies

Je vais développer ces 2 derniers points car ils sont les plus intéressants.

Custom Post Types : vos propres Posts et Pages

Si vous utilisez WP, vous savez qu’il y a 2 grand types d’éléments pour poster :

• Posts : ce sont les billets du blogs rangés chronologiquement. Ils peuvent être dans des Catégories et avoir des Tags.
• Pages : ce sont des pages contenant du contenu fixe et intemporel. Il n’y a pas de notion de chronologie, ni de catégorie, ni de tags. Il y a uniquement une notion de hiérarchie (relation page parent/page enfant).

Si vous avez un blog, ces 2 types d’éléments sont parfaitement suffisants. Vous créez des billets avec les Posts et vous ajoutez une page “A propos” et “Contact” avec les Pages.

Mais imaginons qu’en plus de ça, vous voulez une catégorie Portfolio qui regroupe vos plus beaux travaux, avec un screenshot, une description et quelques infos sur le client. Comment faire ? Vous pouvez créer des Posts que vous classerez dans une catégorie “Portfolio”. Mais c’est non seulement fastidieux à mettre en place dans votre thème mais c’est aussi fastidieux à gérer dans l’admin.

On va donc créer un autre type de post : les “Projets“. Pour ça, on va utiliser le fichier functions.php.

Une fonction pour customiser l’admin

On va regrouper tout notre code dans une fonction qui sera appelée à l’initialisation de l’admin. Comme ça, lorsqu’on lance l’admin, on activera toutes les fonctions décrites dans my_custom_init :

add_action('init', 'my_custom_init');
function my_custom_init()
{
/* notre code PHP pour rajouter les custom post type */
}

Tout le code que je vais écrire maintenant devra être inclus dans la fonction my_custom_init.

Déclarer le Custom Post Type

Maintenant nous allons rajouter l’élément “Projet” dans notre admin :

register_post_type('projet', array(
 'label' => __('Projets'),
 'singular_label' => __('Projet'),
 'public' => true,
 'show_ui' => true,
 'capability_type' => 'post',
 'hierarchical' => false,
 'supports' => array('title', 'author', 'thumbnail')
));

Il faut utiliser la fonction register_post_type qui porte bien son nom : elle enregistre un nouvel élément, un nouveau type de Post. Il y a ensuite plusieurs paramètres. Ils n’y sont pas tous parce que beaucoup sont optionnels. J’ai mis les plus importants :

• ‘projet’ correspond au nom du nouvel élément. Il sera utilisé dans les fichiers de template.
• ‘label’ est le nom qu’on retrouvera dans la colonne de gauche de l’admin. Il est préférable de mettre un pluriel.
• ‘singular_label’ est l’équivalent au singulier
• ‘public’ définit si les posts seront publics ou non.
• ‘show_ui’ définit si ce nouvel élément apparaît dans l’admin
• ‘capability_type’ définit si le nouvel élément est identique à un Post classique ou à une Page classique. Ici on veut un titre et une image miniature donc Post. En général, les Posts sont beaucoup plus intéressants car ils ont davantage de fonctions que les Pages.
• ‘hierarchical’ définit si il peut y avoir une hiérarchie (comme pour les Pages). Ici, c’est non car chaque élément est au même niveau.
• ‘supports’ est un array qui définit quels éléments d’un Post normal on veut avoir. Ici je veux juste le titre, l’auteur du Post et une miniature. Il y a pleins d’autres éléments :
  • ‘title’
  • ‘editor’ (la fenêtre principale de contenu)
  • ‘author’
  • ‘thumbnail’
  • ‘excerpt’
  • ‘trackbacks’
  • ‘custom-fields’
  • ‘comments’
  • ‘revisions’ (la sauvegarde automatique de versions passées)
  • ‘page-attributes’ (choix de template pour les pages et gestion de la hiérarchie)

Pour avoir les thumbnails dans votre thème, il faut ajouter dans functions.php :

add_theme_support( 'post-thumbnails' );

Merci à benoit pour m’avoir rappelé de mettre cette astuce.

Si vous avez tout bien fait vous devriez voir :

Vous pouvez maintenant créer un nouveau projet en cliquant sur “Add New”

Whaaa, c’est vide! Eh oui : on a juste mis “title”, “author” et “thumbnail”. Et c’est tout ce dont on a besoin! Hop je rajoute un Projet “bbxdesign” avec un screenshot :

Ok c’est cool, j’ai réussi à rajouter un nouveau projet! Ca marche nickel dans l’admin. Sauf que pour l’instant, j’ai rien qui s’affiche dans le blog!

Afficher les Custom Post Type

Sur votre blog (sur la home par exemple), dans la boucle des posts, il y a actuellement les Posts normaux. Mais nous on veut afficher les Projets! Pour ça, il faut faire un query_posts avec comme post_type le mot “projet”. Sur index.php par exemple, mettez :

<?php
$home_paged = (get_query_var('paged'));
$arguments = array(
 'post_type' => 'projet',
 'post_status' => 'publish',
 'paged' => $home_paged
);
query_posts($arguments);
get_template_part( 'loop', 'index' );
?>

Le $home_paged est une astuce qui permet de récupérer la valeur de la page courante et ainsi éviter de casser la pagination! Ensuite vient un array d’arguments : post_type en projet, post_status en publish (pour éviter d’afficher les brouillons) et page avec la variable.
Ensuite on fait le query_posts avec ces options puis on appelle la boucle avec get_template_part. Il faut savoir que get_template_part est une nouvelle fonction de WordPress 3 qui permet d’inclure d’autres fichiers php. Ici on appelle le fichier loop.php. C’est d’ailleurs très pratique pour éviter de copier-coller la boucle WP dans plusieurs fichiers.

Si vous ouvrez le fichier loop.php du thème “twentyten”, vous verrez qu’il est vraiment très long. On va tout virer et mettre juste un peu de code pour la home, histoire de vous montrer facilement comment afficher les éléments pour un projet. Nous, tout ce qu’on veut, c’est afficher le titre (c’est à dire le nom du projet), ainsi que la miniature.

<?php while ( have_posts() ) : the_post(); ?>
 <div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
 <h2><?php the_title(); ?></h2>
 <?php the_post_thumbnail(); ?>
 </div>
<?php endwhile; ?>

Donc là, c’est très simple. On met la div avec le bon id et la bonne classe, on met le nom du projet (the_title) et l’image (the_post_thumbnail) et ça donne :

J’ai pris le thème de base “twentyten” et j’ai donc customisé les fichiers index.php et loop.php. La home contient donc des Projets et non pas des Posts. Mais vu que j’ai les 2, je peux faire une page /blog où j’aurais tous mes Posts!

Maintenant vous pouvez ajouter des projets à la volée, virer la sidebar, le header et gérer une partie Blog avec les Posts et une partie Portfolio avec les Projets.

Custom Taxonomy : de nouvelles catégories et de nouveaux tags

Derrière ce nom barbare de “Taxonomy” se cache tout simplement les Catégories et les Tags. Avec WordPress 3, vous pouvez créer d’autres taxonomies. Imaginons qu’avec ce Portfolio vous voulez ajouter 2 choses :

• le type de projet : un logo, un site vitrine, une animation flash….
• les couleurs utilisées

On pourrait utiliser les Catégories et les Tags, mais elles sont déjà utilisées par les Posts pour le Blog! On va donc créer d’autres catégories et d’autres tags, exclusivement pour le Portfolio.

register_taxonomy( 'type', 'projet', array( 'hierarchical' => true, 'label' => 'Type', 'query_var' => true, 'rewrite' => true ) );
register_taxonomy( 'couleur', 'projet', array( 'hierarchical' => false, 'label' => 'Couleur', 'query_var' => true, 'rewrite' => true ) );

On utilise la fonction register_taxonomy. Dans l’ordre on choisit

• le nom de la taxonomie
• l’élément auquel il s’applique (ça peut être ‘post’, ‘page’ ou un post type qu’on a créé, en l’occurence ‘projet’)
• ‘hierarchical’ definit si il y a une relation parent/enfant. Si oui, c’est comme les Catégories. Si non, c’est comme les Tags.
• ‘label’ c’est le nom plus descriptif qui s’affichera dans l’admin
• ‘query_var’ à mettre sur true pour qu’on puisse appeler cette taxonomie dans nos templates
• ‘rewrite’ c’est la chaîne de caractères présente dans les permaliens. Si on met “true”, ça prend la valeur par défaut, c’est à dire le nom de la taxonomie.

(Bien sûr, tout ceci est toujours à mettre dans la fonction my_custom_init commencée tout à l’heure.)

Si vous rechargez l’admin, vous voyez par magie :

J’ai déplacé les blocs “Type” et “Couleur” à gauche pour que ce soit plus lisible. Maintenant vous pouvez ajouter le type “animation flash”, “logo”, “direction artistique”… et les couleurs “vert”, “orange”, “bleu”… Ca ressemble à peu près à ce qui ai fait sur Steaw Web Design (sauf qu’on utilise des sous-catégories).

Afficher les Custom Taxonomies dans le thème

Ok c’est cool, vous avez vos Custom Taxonomies dans l’admin. Maintenant faut les afficher dans le thème! On va reprendre le fichier loop.php de tout à l’heure et rajouter ça :

<?php while ( have_posts() ) : the_post(); ?>
 <div id="post-<?php the_ID(); ?>" <?php post_class(); ?>>
 <h2><?php the_title(); ?></h2>
 <?php echo get_the_term_list( $post->ID, 'type', '<p>Type de projet : ', ', ', '</p>' ) ?>
 <?php the_post_thumbnail(); ?>
 <?php echo get_the_term_list( $post->ID, 'couleur', '<p>Couleurs : ', ', ', '</p>' ) ?>
 </div>
<?php endwhile; ?>

On utilise la fonction get_the_term_list pour afficher les taxonomies du post courant ($post->ID). C’est dans un paragraphe, et les éléments sont séparés par des virgules. En fait, la taxonomie c’est l’ensemble de la liste (ex: “Couleurs”) et terme c’est chaque élément de la liste (ex: “orange”, “vert”).

Visuellement, ça donne ça :

Vous remarquerez que ça crée des liens pour chaque terme. En cliquant dessus, on arrive à une archive. En local, j’arrive pas à le faire marcher mais ça fonctionne sur mon JukePod pour l’année 2004 par exemple.

Conclusion

Avec les custom post type et les custom taxonomy, vous pouvez créer plusieurs “flux” sur votre site, comme par exemple un blog et un portfolio, sans avoir à mélanger les deux ou à s’embêter avec des sous-catégories.

Par exemple, pour le blog Steaw et le portfolio Steaw, on a du créer 2 WordPress différents avec d’un côté des Posts, des Catégories, des Tags et de l’autre… ben pareil : des Posts, des Catégories, des Tags! On le ferait aujourd’hui, on utiliserait le custom post type Projet pour le Portfolio. Il y a même un gars qui a fait un IMDB avec WordPress 3…

Sources : Nettuts et kovshenin

Tumblr c’est magnifique. C’est très facile à utiliser, que ce soit pour poster des images, des liens, des vidéos… C’est un gros aggrégateur de tout et n’importe quoi, on a pas besoin de se soucier de l’hébergement, on peut utiliser son propre nom de domaine, il y a pas mal de services intégrés (Twitter, Feedburner entre autres) et surtout : créer un thème Tumblr est un jeu d’enfant!

Avec cette facilité pour poster tout ce que je veux (et vite!), et un système de template vraiment simple, je me suis dit que j’allais lancer mon petit site d’inspiration en web design, qui regroupera pleins de sites et d’éléments de sites (formulaires, headers, icônes…) : DDDSGN.

Pourquoi “DDDSGN” ?

Je voulais un nom court, simple et fun. Il fait bien évidemment référence à ffffound.

Pourquoi c’est tout noir et blanc ?

J’ai testé beaucoup de couleurs et de palettes de couleurs pour des designs parfois sympas mais qui ne mettaient pas assez le contenu en valeur. Avec un site en fond blanc et le texte en nuances de gris, les couleurs des images ressortent très bien! D’ailleurs, il n’y a aucune image appelée par la CSS. C’est que de la typographie et des couleurs. Plus simple à entretenir, tiens.

Je vous invite à visiter le site et pourquoi pas à vous y abonner !

Vous connaissez tous ces sites d’appli iPhone ? Depuis 2 ans, c’est devenu une tendance, une catégorie à part dans les designs de site. Personnellement, je les trouve très créatifs, modernes et pertinents. Et je m’en inspire pas mal, comme par exemple dans cette liste de 40 sites d’appli. Malheureusement, je n’ai jamais eu l’occasion de bosser sur un tel site.

C’est pourquoi j’ai forcé le destin. En découvrant Task This, une appli française gratuite de gestion de taches, j’ai tout de suite eu envie de proposer mes services pour faire la refonte.

Avant

Avant, c’était comme ça. Et ça l’est encore pour le blog, vu que Dotclear est un moteur de blog, et qu’il n’y avait pas de raison de le refondre. Il y avait plusieurs pages en front-end, et une partie d’administration (à laquelle je n’ai pas touché) pour les utilisateurs en back-end.

Le design était un thème très répandu : le thème Freshy 2. Bien qu’etant un thème sympa, il était pas du tout pertinent pour un site iPhone.

Après

Je suis donc parti sur une page unique, avec plusieurs sections : accueil avec un gros visu, fonctionnalités, témoignages et formulaire de contact. J’ai donc viré plusieurs pages de contenu parce que je pense qu’elles étaient superflues et que les gens ne les lisaient pas beaucoup. Pour le blog et le back-end, je n’y ai pas touché.

Avec pas mal d’inspiration et un peu de JS, je suis très content du rendu final et j’espère pouvoir bosser sur d’autres sites d’appli à l’occasion!

Dustin Curtis, un designer d’interfaces, devait réserver un billet sur le site (horrible) d’American Airlines. J’ai déjà eu à le faire aussi lorsque je suis allé à New York. Son expérience en tant qu’utilisateur n’ayant pas été très plaisante, il s’est dit qu’il allait proposer sa propre refonte du site.

Je suis personnellement très fan de cette refonte du bloc le plus important du site : la réservation. Il y a un côté aéré, léger (pour une compagnie aérienne, que demander de mieux ?) et efficace dans sa refonte. Je me rappelle que je voulais proposer une refonte du site l’Equipe.fr (un tout autre domaine, un tout autre rôle) mais j’ai pas pris le temps de le faire et entre-temps, leur refonte est plutôt réussie.

La réponse d’American Airlines

Ok, Dustin Curtis ne connaissait sans doute pas les raisons qui amènent American Airlines à garder leur site tel quel. Mais il a reçu une réponse de la part du User Experience Architect. Un extrait (repris sur Words on Design – “shameless self promotion…”) :

We could even redesign the AA.com home page without having to slog through endless review and approval cycles with their requisite revisions and re-reviews.

En résumé, dans sa lettre de réponse, il dit qu’American Airlines est une boîte trop grosse avec beaucoup trop de gens impliqués dans le design pour que l’équipe de design puisse faire son boulot correctement, ou devrais-je dire, puisse faire son boulot tout court.

Je sais exactement ce qu’il veut dire.

American Airlines a les compétences en interne pour avoir un site intéressant, mais ne les utilise pas. Un problème politique ? Je pense aussi.

La peur du vide ?

C’est sans doute la crainte des grosses entreprises d’avoir un site aussi aéré et léger, avec peu de contenu. Ils se disent peut-être qu’avec tout leur argent et la taille du trafic du site, ils doivent forcément avoir un site avec beaucoup de fonctionnalités, de contenu, des liens partout, des promos par ci par là…

Je sais pas. Le peur d’innover ? De faire confiance aux plus jeunes ? A ceux qui savent ? A ceux dont c’est le boulot ?

Je pense sincèrement que la qualité d’un design est (quasiment) inversement proportionnelle au nombre de personnes (ignares?) qui donnent leur avis dessus. Avoir une équipe de plusieurs designers, OK. Mais lorsque les services commercial ou technique y mettent leur nez, ça commence à sentir le roussis. Chacun son taf et tout ira bien!

Le HTML 5 est la prochaine version importante du HTML. Bien qu’étant en compétition avec le XHTML 2, le HTML 5 fait davantage parler de lui parce qu’étant plus facilement implémentable et plus pragmatique dans l’utilisation des nouvelles balises qu’il introduit.

Quoi de neuf chez les balises ?

J’avais déjà parlé du HTML 5 l’an dernier, en parlant notamment des balises visant à structurer le contenu. Mais l’intérêt du HTML 5 se trouve surtout dans ces balises qui vont grandement faciliter la création d’applications web.

• <canvas>
  Une balise dans laquelle on peut dessiner avec du JS. A priori on peut faire beaucoup plus avec.
  Exemples : dessiner, labyrinthe ou encore mieux : Bespin par Mozilla, un éditeur de code utilisant canvas et JS
• <video>
  La vidéo est aujourd’hui implémentée sur le web grâce à différents plugins (Silverlight, Quicktime, WMP et surtout Flash). Pourquoi ne pas utiliser une simple balise <video> ?
  Exemples : YouTube et Dailymotion font déjà des tests avec cette balise <video>, et Mozilla en parle.
• Geolocation
  La géolocalisation grâce à l’API de l’HTML 5.
  Exemple : Where Am I géolocalise en utilisant Google Maps (il faut Firefox Beta).
• App Cache
  Ca permet de sauvegarder des informations en local, pour travailler offline notamment.
  Exemple : des Post-It accessibles offline (il faut Safari Beta).
• Workers
  Un outil qui permet de mieux gérer la surcharge de JavaScript. En gros, plus de problème de ralentissement à cause d’un JS trop gourmand.
  Exemple : 2 scripts qui calculent le plus grand nombre premier. Le premier fait crasher le navigateur (j’ai testé…), alors que l’autre y arrive très bien.

Tous les exemples proviennent de la Google Keynote.

Qui s’y intéresse ?

Google

Google, le plus grand acteur chez les applications web, mise gros sur le HTML 5. Au départ, Google ne croyait pas que les applications web pouvaient rivaliser avec les applications de bureau. Mais avec le grand succès de Google Maps, leur état d’esprit a changé. Comme le dit le VP of Engineering Vic Gundotra :

We knew then that the web had won. What was once thought impossible is now commonplace.

La sortie de Google Chrome est un signe important. Le principal atout de ce navigateur est sa rapidité, grâce à son moteur JS très performant. Et en voyant les applications web utiliser massivement du JS, ce n’est pas un hasard.

Il y a aussi la sortie récente des Google Web Elements qui introduit l’idée de widgets exportables où l’on veut. Avec le HTML 5, ceci risque d’être encore plus simple.

La version Chrome d’Android supportera aussi le HTML 5.

Et puis, YouTube y porte aussi un certain intérêt.

Mozilla

Mozilla est le plus actif pour implémenter les nouveautés HTML 5 dans Firefox, suivi de près par Safari et Opera, si l’on considère cette liste d’implémentation du HTML 5 dans chaque navigateur.

La vidéo en HTML 5 par Dailymotion ne fonctionne que sous Firefox Beta. On peut ajouter un skin autour, mettre la vidéo en flou, ajouter un “edge effect” par dessus… Ca rame sur mon netbook mais c’est sympa.

Avec le sortie de JetPack, on peut imaginer un bel avenir pour le combo JS + HTML 5.

Palm

Michael Abbot, le Senior Vice President de Palm, en charge des applications et des services, mise aussi sur le HTML 5 sur le WebOS de Palm :

You as a developer don’t need to leave your prior knowledge at the door to develop for the phone.

Pour faire des applis iPhone, il faut s’y connaître en Objective-C. Pour faire des applis Palm, il faudra s’y connaître en HTML 5 et JS. Je ne sais pas à quel point ça pourra rivaliser en termes de qualité d’applications, mais je veux bien voir.

Apple

Je viens de voir sur la Worldwide Developers Conference 2009 que Safari Mobile supportait le HTML 5. C’est pas un détail anodin. Après le succès des app iPhone, celui des app web mobiles sur iPhone ?

Les développeurs web ?

Je ne suis pas développeur web mais j’imagine que je pourrais m’y intéresser si les possibilités sont importantes tout en gardant des technologies simples d’accès et performantes. Un avis de développeur JS sur la question ?

Comment implémenter du HTML 5 aujourd’hui

Ok, c’est bien beau toutes ces nouvelles balises, mais je fais comment pour l’utiliser aujourd’hui ?

Applications Web : oui mais…
Pour les balises axées “applications web” (canvas, geolocation, video, appcache…), quelques navigateurs en version beta offrent la possiblité d’utiliser ces nouvelles balises. Avec du JS, c’est déjà possible d’en tirer profit.

Structure : OK
En ce qui concerne les balises de “structure” (header, section, article…), il est d’ores et déjà possible de les utiliser. En fait, si les navigateurs ne comprennent pas forcément ces balises “inconnues” mais ne renvoient pas d’erreur. C’est juste que ces balises ne sont pas stylées et qu’elles sont considérées comme “inline”. Un display:block fait l’affaire.
Pour IE6, il faut rajouter un script pour que le style s’applique à ces nouvelles balises.

1. <script>
2. document.createElement(‘header’);
3. document.createElement(‘footer’);
4. document.createElement(‘section’);
5. document.createElement(‘aside’);
6. document.createElement(‘nav’);
7. document.createElement(‘article’);
8. </script>

La concurrence : Flash, XHTML 2 et… Windows ?

Je pense que le HTML 5 va surtout concurrencer les plugins de navigateur, et notamment Flash/Silverlight. En fait, l’intérêt de ces deux derniers est avant tout de palier à un manque, surtout au niveau de la gestion du multimédia dans le web (la vidéo en premier). Le HTML 5 peut sans doute gérer ça de manière plus légère, plus sémantique et plus accessible. C’est plutôt le combo HTML 5 + JS qui sera intéressant.

En parallèle du développement du HTML 5, il y aussi celui du XHTML 2. Actuellement, je mets toutes mes Doctype en XHTML 1.0 Strict, parce que j’ai peu de problème de compatibilité avec (Quirks Mode sous IE6 notamment). Après, j’ai pas trop suivi l’avancée du XHTML 2. Peut-être qu’on arrivera à “merger” les deux à un moment donné ?

Enfin, est-ce que le HTML 5 peut rivaliser avec Windows (et plus généralement les OS) ? Haha, ça a l’air très marrant comme supposition, mais certains y croient vraiment. Depuis des années, Google se positionne sur ça : faire du web l’outil de travail principal.
Google Docs + Chrome + Calendar + Notebook + Picasa + Mail + Talk = Web Desktop ?
Le problème des applis web par rapport aux applis de bureau sont principalement :

1. la rapidité d’exécution
2. les fonctionnalités
3. la nécessité d’être connecté pour travailler

Le HTML 5 va aider à résoudre le 3ème point, avec la possiblité de sauvegarder des informations en local (voir AppCache plus haut).
Pour le 2nd point, j’utilise rarement les fonctionnalités avancées de Word, et sur ce point, Google Docs me sufflit largement.
Pour le 1er point, un outil aussi basique qu’un tableur ou qu’un traitement de texte nécessite relativement peu de ressources.

Etant très souvent connecté, j’utilise uniquement Google Docs et plus du tout Microsoft Word/Excel. Avec le HTML 5, j’aurais sans doute même plus besoin d’être connecté.

J’imagine un OS qui sera uniquement un navigateur web. Peut-être pour la Crunchpad ?

Conclusion

Le HTML 5 est résolument axé “application web”. Couplé avec du JS, les résultats sont très intéressants. Ca me fait penser à du Jetpack pour un site (et non pas un navigateur). Il est surtout intéressant pour les développeurs du web de s’y pencher plutôt qu’un web designer comme moi. Parce qu’au final, les balises de structure (header, section…), ça facilite légèrement l’intégration et ça ajoute de la sémantique mais c’est pas révolutionnaire, alors que la video/audio, la géo localisation, le appcache… ont énormément de potentiel.

Le problème actuel est qu’il faut encore attendre 2010 avant de profiter vraiment du HTML 5. Mais en réalité, les développeurs n’attendent pas. Comme le dit Dave Clark :

The technology is here even if the standards committees haven’t caught up

We reject: kings, presidents, and voting. We believe in: rough consensus and running code.

Le mot d’ordre serait donc d’être pragmatique. Ne pas attendre les standards mais s’amuser à utiliser ce qu’on peut déjà utiliser pour avoir de l’avance et faire avancer la standardisation justement.

Le plus gros acteur du web, Google, s’y intéresse. Il y a donc forcément du potentiel dans le HTML 5…

Le débat

Il existe un débat assez récurrent sur l’élément de la page qui portera le h1. Que ce soit dans un post ou deux, ou dans des commentaires, la question reste ouverte. Il y a 2 écoles :

• h1 pour le logo
  Etant donné que le logo porte le nom du site, c’est l’élément le plus important. Il doit donc être dans un <h1>, sur toutes les pages.
  Exemple : http://wordpress.org/
• h1 différent par page, un lien pour le logo
  Le h1 doit représenter le contenu de la page. Ce dernier étant différent pour chaque page, il faut que le h1 change aussi.
  Exemple : http://simplebits.com/

Cas particulier : il arrive d’avoir un h1 pour le logo uniquement sur la page d’accueil, les autres pages ayant un h1 différent. Je classe ces sites dans la deuxième catégorie.

Le h1, le plus important et l’unique (?)

C’est quoi un h1 d’abord ? Selon le W3C, ça donne :

A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.

Le h1 est le titre de premier niveau et doit introduire la section qui le suit.

Paradoxal le h1 ?

Si le h1 est sur le logo, alors il est tout en haut. Il doit donc décrire tout ce qui le suit, c’est à dire, le reste de la page. Il ne faut pas le mettre sur le logo alors ?

Title et h1 : amis intimes

Le titre de la page (balise <title>) est défini ainsi par le W3C :

The TITLE element is not considered part of the flow of text. It should be displayed, for example as the page header or window title. Exactly one title is required per document.

Le titre est unique et doit décrire le contenu de la page. C’est à peu près de cette façon que j’utilise mon h1 : il est unique et décrit la page. Il est pour moi différent pour chaque page, comme l’est le titre.

Par contre, le titre doit être davantage fourni que le h1. L’idéal pour ce post serait :

• <title>Un h1 pour le logo ou pas ? < Blog < bbxdesign</title>
• <h1>Un h1 pour le logo ou pas ?</h1>

Mon titre décrit le contenu du document et d’où il provient.
Mon h1 décrit la section qu’il introduit : mon post.

Les deux sont complémentaires parce que l’un fait partie du flux du document, l’autre non. Ils ont donc un rôle légèrement différent.

Un h1 est-il unique ?

Je viens de remarquer que Digg et A List Apart ont deux h1 dans la même page (lorsque l’on va dans les commentaires ou sur un article). Ca m’a surpris parce que j’ai toujours cru que le h1 était unique, comme l’est la balise title. Le W3C ne spécifie rien sur l’unicité des headings (h1,h2,h3…) mais étant donné qu’elle préconise d’utiliser une partie de la balise title pour son contenu, je présume qu’il faut que le h1 soit unique.

La solution optimale : un h1 différent par page, un lien pour le logo

Si je résume, le h1 :

• décrit la section qui le suit
• reprend une partie du title, qui lui-même décrit la page
• est unique (selon moi)

Cette équation a une seule solution : il y a un h1 différent par page, un lien pour le logo (à part éventuellement pour la page d’accueil, qui est un cas particulier).

Si le h1 doit décrire ce qui le suit et que je le mets sur le logo “bbxdesign” sur toutes les pages (il l’est actuellement uniquement sur ma page d’accueil), alors toutes mes pages auront comme contenu “bbxdesign” ? C’est très léger comme description de ma page, et très redondant, surtout pour les moteurs de recherche. Toutes mes pages ne parlent pas de “bbxdesign”. C’est juste le nom du site (qui est par ailleurs dans l’url). Mes pages ont toutes un contenu différent et je veux que mon h1 reflète ceci. C’est pour ça que ma page d’accueil a le logo comme h1, mais tous mes posts ont leur titre comme h1 (et le logo devient h2).

Le logo décrit le site, pas la page que l’on consulte actuellement. Après, il est possible de mettre deux h1, un pour le logo, un pour le titre du post par exemple. Mais cela voudrait dire que le premier h1 (celui du logo) affiche “bbxdesign”, et l’autre affiche “Un h1 pour le logo ou pas ?”. Pourquoi pas, mais je trouve que le second a davantage de poids et de légitimité que le premier. Et étant donné que l’on jusqu’à 6 niveaux hiérarchiques, pourquoi ne pas en tirer profit ?

Les titres : une question d’ordre ou de poids ?

Si le h1 n’est pas le logo, il se peut (et c’est mon cas) que le h1 ne soit pas le premier élément de la page, mais arrive après le header et la navigation. Est-ce que c’est problématique ? Je ne pense pas. Le W3C ne précise rien à ce sujet. Il faudrait plutôt se poser la question si les titres (h1,h2,h3…) sont davantage une question d’ordre ou de poids ?

A première vue, c’est surtout une question d’ordre. On a d’abord un h1, puis un h2, puis un ou plusieurs h3, puis peut-être un autre h2 suivi d’autres h3… A ce propos, il est interdit de “sauter” un niveau hiérarchique. On ne passe pas d’un h1 à un h3 sans avoir de h2. Il faut voir les h1-h6 comme des chapitres d’un livre.

Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not “skip” levels (e.g., H1 directly to H3).

Pour le W3C c’est une question d’ordre. Mais il m’arrive de ne pas suivre cette règle à la lettre. Par exemple, dans une sidebar structurée, je mets des <h3> et des <ul> parce que c’est le poids que je leur donne par rapport au contenu de la page. Et mon post a lui aussi des h3-h6. Par conséquent, l’ordre de mes titres dans mon code peut passer du h6 au h3. Et ce n’est pas spécifique à la sidebar. Ca peut arriver lorsqu’il y a plusieurs zones dans la page avec un contenu différent.

Les titres h1-h6 restent des éléments assez mal utilisés (par moi d’abord), sans doute par manque de précisions de la part du W3C. En même temps, c’est peut-être têtu de s’obstiner autant. Parce qu’en ayant d’un côté le W3C (avec les soucis de standardisation et d’accessibilité) et de l’autre les moteurs de recherche (qui analysent minitieusement notre code), couplés à un flou autour de la définition de l’utilisation des titres, on se demande parfois si la solution est unique.

HTML : vers davantage de modularité

Je code toujours en XHTML 1.0 Strict, et ça m’a évité pas mal de problème de Quirksmode je me rends compte. J’utilise au maximum les balises sémantiques <p>,<ul>,<label>,<hn>,<strong>… mais je suis de moins en moins réticent à multiplier les <div> et <span>. D’un côté, c’est cool d’éviter la divite, c’est joli, c’est léger. Mais en pratique, et surtout pour les gros sites, il faut être très spécifique quant aux styles à appliquer à certains éléments. Donc je rajoute une ou deux div par ci par là pour améliorer ma productivité et surtout la flexibilité du code. Ca facilite grandement la différenciation. Et ça permet surtout de prévoir d’eventuelles évolutions de fonctionnalités, et avoir une approche plus modulaire.

A force de prôner la séparation HTML (contenu) / CSS (mise en page), on a peur de modifier le HTML, comme si c’était devenu interdit voire impossible. Je me dis que les développeurs ne sont pas bien méchants et que l’on peut leur demander des modifs HTML, avoir plusieurs classes sur un même élément au lieu de répéter son code CSS pour pas grand chose (voir plus bas).

CSS : une seule css, un reset et de moins en moins de contextualisation

C’est évidemment très lié au HTML utilisé. Depuis quelques temps, je me suis fait un fichier reset.css qui utilise le Reset CSS de Yahoo! . Par contre, ce n’est pas un fichier que j’importe à chaque fois mais un code que je copie-colle en créant ma CSS. Parce que oui, je préfère garder une seule CSS pour tout le site. Niveau lisibilité, je n’ai pas trop de problème à utiliser un seul fichier parce que j’écris chaque sélecteur CSS sur une seule ligne. Niveau productivité, répartir des propriétés sur plusieurs CSS c’est passer beaucoup de temps de l’une à l’autre, trouver où se trouve ce sélecteur, éviter les conflits… J’évite. Et le seul vrai avantage d’avoir plusieurs CSS, c’est d’en appeler certaines dans certains cas, et d’autres dans les autres cas. Je préfère mettre une class au body pour différencier les pages, c’est beaucoup mieux.

Les exceptions pour utiliser plusieurs CSS sont : un fichier pour ie6, un fichier par couleur (si il y a des thèmes par couleur) et un fichier pour le print.

Je fais encore pas mal de contextualisation (ex: .bloc table tbody td.direction ) parce que ça permet d’éviter les conflits. + de contextualisation = – de classes à créer

Appliquer le même style à des éléments HTML différents

Il y aussi le cas où vous voulez que plusieurs éléments HTML aient les mêmes propriétés CSS Dans ce cas, il y 3 choix :

• copier-coller les mêmes propriétés pour la nouvelle classe (bouh, pas bien!)
  .maclasse { propriétés identiques }
  .monautrelement { propriétés identiques }
  .montroisieme { propriétés identiques }
• mettre les éléments qui ont les mêmes propriétés à la suite
  .maclasse, .monautreelement, .montroisieme { propriétés identiques }
• créer une nouvelle classe et rajouter cette classe dans le HTML
  .manouvelleclasse { propriétés identiques }

La première méthode est à éviter : si on veut changer une propriété (ex: la couleur d’une bordure), il faut le changer autant de fois que l’on a copié-collé.
La deuxième méthode est la plus propre : le HTML reste relativement léger (= non alourdi de classes) mais la CSS est plus longue à maintenir. C’est ce que je faisais avant.
La troisième méthode est plus “modulaire” je dirais. Un élément HTML aura par exemple : class=”.maclasse .manouvelleclasse”. On rajoute donc une classe aux éléments qui ont le même style. Mmmh. Est-ce que c’est bien ? Est-ce que l’on sépare bien la mise en page du contenu ? Plus ou moins je dirais. En fait, dans le HTML, on ajoute la classe à tous les éléments qui doivent appraître de la même façon. Et si on veut plus qu’un élément n’aie plus ces propriétés ? Il faut supprimer la classe dans le code HTML. Ah. C’est pas bien. On ne devrait plus avoir à toucher au code HTML. En théorie, c’est vrai. Mais en pratique, c’est, d’une part, très rare de vouloir changer le style d’un seul élément, et d’autre part, pourquoi n’aurait pas-t-on le droit de modifier le HTML ? Une fois livré, on ne peut plus rien faire (voir § sur le HTML) ?

Je dois préciser une chose importante : cette méthode modulaire, je l’utilise surtout pour les blocs et les gros éléments, pour les éléments qui structurent et divisent l’affichage. Il faudrait que j’envisage de faire un article avec des exemples plus éloquents.

IE6 : 40% de perte de temps

J’ai déjà parlé de ce que l’on pourrait faire si IE6 n’existait plus. En fait, rendre un site compatible IE6, c’est du débuggage pur et simple. On doit utiliser des overflow:hidden, position:relative, display:inline… pour aucune raison valable si ce n’est faire plaisir aux internautes du siècle dernier (ou presque). Sans compter tout ce que l’on est privé de faire. Bref, une calamité.

Nommer les class/id

Dans mon souci d’avoir un code lisible, pour moi et ceux qui retoucheront aux CSS, j’essaye d’avoir des noms de class/id simples mais efficaces. Simple, ça veut dire court. Avec 4 lettres, on peut faire pas mal de choses : .bloc, .nav, .main, .side… J’ai par exemple remplacé .pagination par .page. Ou mettre .srv au lieu de .service. C’est pas très méchant et ça permet d’avoir une CSS bien plus lisible (surtout si l’on contextualise ET que l’on met tout sur une ligne).

Et si je passe autant de temps, c’est aussi pour éviter d’appeler un élément “grillade” par exemple (alors que ça n’a rien à voir avec un barbecue). J’ai vérifié, elle y est encore.

Découper les images

Dernier point : découper le PSD. On voit directement si un PSD est fait par quelqu’un qui sait intégrer ou pas. J’ai de la chance, c’est souvent le cas. Mais lorsque ça ne l’est pas, il faut voir les effets de dégradés, les superpositions, les ombres qui dépassent… qui n’ont l’air de rien graphiquement, mais qui sont une calamité à intégrer. D’ailleurs, c’est une calamité à cause d’IE6! Parce que pour IE6, il faut tout aplatir! L’ombre doit aller avec l’élement qui la fait ET avec l’élément où elle se projette. N’est-ce pas logique ? Et bien non. Vive les PNG. C’est tout.

Conclusion

J’ai essayé de faire un rapide panorama de ce que doit faire un intégrateur. On se rend compte que le grand ennemi reste IE6. Les 40% cités correspondent au temps de débuggage, mais je suis sûr qu’on peut gagner du temps dans les autres domaines (découpage, css, html) si il n’y avait pas IE6. J’ai peut-être oublié des éléments, je ne sais pas. Vous avez des idées ? Des remarques ? Des critiques ?