Ça y est, décembre est lancé. Et avec les premières neiges on a envie de rester au chaud et de lire des bons articles qui parlent du Web, n’est ce pas ?

4 calendriers avec des perles à découvrir chaque jour de décembre :

• 24ways remets ça pour la sixième année : des articles de haute qualité qu’on attends toute l’année. Ils contribuent à rendre l’hiver moins dur.
• HTML5 Advent : des démos HTML5 pour en avoir plein les yeux.
• Adfont Calendar : mateurs de typographie, sous chaque case se cache une police d’écriture proposée par FontDec.k
• Performance Calendar : et oui, même les performances Web ont leur calendrier.

Typographie, HTML5 et performances : les sujets chaud du Web de cette année sont là pour se tenir au chaud cet hiver jusqu’à Noël.

Dans l’article ever- thought about using font face for icons? ils expliquent comment faire une page où toutes les images seraient contenues dans un fichier de police. En appliquant chaque icône à une lettre, on a des images dans la police d’écriture

Cela donne des images :

• qui s’agrandissent sans perte de qualité ;
• très faciles à colorer, agrandir, souligner en CSS ;
• rapides à charger car cela ne fait qu’une requête HTTP pour tout le paquet d’icônes.

Mais cette technique souffre de serieux points faibles. En plus d’être plus difficile à maintenir, il faut choisir entre un HTML qui n’a aucun sens comme <span class="phone-icon">a</span> ou une feuille de style CSS imbitable qui ne fonctionne pas sous IE :

.phone-number:before {
  content: 'a';
  font-family: "Mes Icônes"
}

La solution serait de ne remplacer que les quelques caractères Unicode qui représentent déjà des icônes. Ainsi on garde du sens à l’HTML et on peut profiter de la cascade des polices d’écriture disponibles.

<li>☎ +33-666-42-42-50</li>

Le dix-huitième Apéro Ruby organisé par Ruby France était tourné autour de GitHub. Étaient présents les géniaux Scott Chacon et PJ Hyett de GitHub.

Schacon a présenté ShowOff, son application Ruby pour faire des présentations. Pas aussi bien qu’HTML5 Slides, mais je ne suis pas très objectif sur le sujet. Sinon c’est Sinatra, markdown, HTML, JS, que du bon et plein de bonnes idées pour la suite. Ses slides sont même un fork sur GitHub. Miam.

S’en sont suivi plein de questions sur GitHub. Plein de bonnes choses de prévues comme pouvoir utiliser SVN avec n’importe quel dépôt GitHub, ou auxquelles ils réfléchissent sérieusement comme les tickets et le wiki dans une branche du dépôt. Ils m’ont même assuré que l’internationalisation arrivait d’ici une semaine ou deux. \o/

Oh et c’était open bar. Thanks GitHub!

L’édition 2009 des conférences Paris Web est terminée. Une fois de plus la grande qualité des conférences et le bon esprit qui règne étaient là. J’ai a-do-ré.

Quelques citations :

Après tout ça j’ai des milliers de nouvelles idées et de choses à faire. Par exemple il faut que je me renseigne sur l’HTTP « bis » qui est en cours de discution au w3c, que je lise cette documentation sur le cache, que j’installe phpsecinfo, que je lise à propos des méthodes agiles de Jeff Patton, que j’utilise les favelets de Stéphane Deschamps, que je regarde de plus près les CSS media queries, que je me remette à jour dans mes sauvegardes, que je retrouve la proposition de Daniel Glazman sur les règles CSS qui permettent de cibler la disponibilité de certaines propriétés dans les navigateurs, que j’implémente Foaf+SSL quelque part, que je mette la main à la pâte sur La Distribution, …

Merci Paris Web !

La page blanche. Puis viens ce moment pur où, dôté de la maquette du site, il ne reste plus qu’à faire la page la plus propre possible. À nous le choix d’XHTML ou d’HTML, d’utiliser ou pas tt, address, … De créer de jolies listes, des titres à plusieurs niveaux. De choisir avec soin le nom des ids et des classes et de saupoudrer le tout de microformats. Le tout propre et bien indenté.

J’aime ce moment où on peut s’approcher le plus possible des idéaux de l’HTML sémantique… jusqu’à ce que CMS et CSS, bourreaux des cœurs, nous imposent de souiller la pureté de nos documents.

Google Mobwrite est une petite application web qui sert à synchroniser des champs de formulaires en temps réel.

Avec un brin de JavaScript, n’importe quel champ texte devient un éditeur de texte temps-réel comme SubEthaEdit en appliquant les changements chez tout le monde en même temps.

La synchronisation, la fusion et la résolution des conflits entre différents utilisateurs est un problème compliqué dont Google Mobwrite se charge. Votre application finale aura simplement à conserver en mémoire le dernier formulaire envoyé.

Exemple

Installation

Si vous avez une toute petite application, il vous suffit d’avoir des identifiants uniques sur vos champs de formulaires et d’ajouter ces quelques lignes de JavaScript :

<script type="text/javascript" src="http://mobwrite3.appspot.com/static/compressed_form.js"></script>
<script type="text/javascript">
mobwrite.syncGateway='http://mobwrite3.appspot.com/scripts/q.py';
mobwrite.share('identifiant-du-champ', 'identifiant-du-2eme-champ', ...);
</script>

Si vous comptez utiliser ce service un peu plus vous êtes invités à héberger votre propre application ou de la créer gratuitement sur Google AppEngine (se fait en 5 minutes).

Edith

J’ai implémenté Google Mobwrite sur Edith (edit.sunfox.org) en me créant un compte Google AppEngine très rapidement. Depuis, plus de problème d’écrasement de données si plusieurs personnes ont une page ouverte en même temps.

En HTML le nombre de classes et le nom des classes est libre. Néanmoins il est bon d’utiliser des classes sémantiques, décrivant la fonction de la balise plutôt que son style.

Exemples

Pourquoi faire ?

De cette façon en utilisant des feuilles de style CSS l’on peut décider de changer les couleurs et l’affichage des pages sans avoir à changer l’HTML ou d’avoir des styles illogiques tels que .red { color:pink; }. D’autre part votre site peut avoir plusieurs feuilles de style (impression, mobile, slide, …), où vous pouvez décider par exemple que la classe large-column serait dans ce format… ni large, ni en colonne.

Ce n’est pas très grave si quelques-unes de vos classes décrivent l’apparence finale plutôt que la fonction de votre texte. Néanmoins c’est important dans une démarche qualité globale et cela augmente la réutilisabilité de votre code.

Tout ça pour en venir aux frameworks actuels

Les frameworks CSS qui foisonnent ces derniers temps tels que Blueprint CSS et YUI Grids CSS imposent sciemment l’utilisation de classes telles que <div class="column span-15">. C’est dommage. C’est pourquoi je les évite.

J’attends que les implémentations de CSS dynamiques telles que CleverCSS intègrent les fonctionnalités appréciables de ces frameworks. Mais je n’ai encore vu personne avancer cette idée. Ils pourraient pourtant par exemple avoir des propriétés magiques de type colspan: 15 qui se transformeraient en code nécessaire à la création d’une colonne à la bonne taille… Lazyweb te sens-tu le courage ?

En HTML sémantique il faut utiliser les balises ayant un sens et pas seulement un effet de style. C’est pour cela que la balise <b> qui signifie gras est dépréciée en faveur de <strong> qui signifie fort.

De même pour la balise italique <i> que l’on remplace par <em> qui signifie emphase. Cette nouvelle balise s’utilise quand on mets l’accent sur un mot et plus juste pour faire de l’italique.

Mais en français les règles typographiques veulent que certaines parties de textes soient en italique, comme par exemple les titres de livres ou encore les formules de latin. Si ces textes doivent être en italique on ne mets pas forcément l’accent dessus dans la phrase.

Il ne faut donc pas oublier la balise <i> aussi rapidement. Il faut l’utiliser quand elle s’applique à une règle typographique et utiliser <em> quand vraiment il s’agit d’une emphase.

(Oh et dans le même genre il y a aussi la pauvre balise big.)

Les images nous cachent des choses

Sur une image l’utilisateur ne sait pas au premier coup d’oeil que c’est un lien, rien de souligné ou de couleur differente du texte comme on peut le faire avec le texte. Rien ne différencie une image avec un lien d’une image sans.

Il faut donc attendre que l’utilisateur survole l’image et voie son curseur se transformer pour qu’il sache que c’est un lien ou bien utiliser des codes visuels (boutons, etc.) pour qu’il sache que c’est un lien.

Les images nous cachent aussi les différents etats d’un lien. Un lien hypertexte a aussi une couleur ou une présentation différente quand survolé, quand cliqué et quand déjà visité. Il est donc souvent impossible à l’utilisateur de voir rapidement quels liens il a déjà visité si le lien est une image !

Les Grandes Exceptions

Les images en haut à gauche des pages comme la grosse banière ici sur Sunfox ou le logo Google ont interêt à avoir un lien vers la page principale car c’est à ça que s’attend l’utilisateur. Et c’est de moindre importance ici de savoir si elle a déjà été visitée ou non.

Ne pas faire

On ne voit ici aucune différence entre les deux images, on serait passé à côté du lien si on ne le survolait pas de la souris. Et comme le web n’est pas un jeu du chat et de la… souris, on ne va pas s’amuser à survoler tout ce qui se trouve sur l’écran…

Mais faire

Ici l’on sait tout de suite que ces images nous amènent vers une autre page :

Ces deux dernières images ont également l’avantage de rester dans les mêmes couleurs des autres liens, et surtout de pouvoir changer de couleur de lien quand survolé et une fois le lien déjà visité !

Je suis un peu coupable

L’image sur mes gouttes est un exemple de graphique entre les deux où on pourrait s’attendre à un lien mais qui ne serait pas obligatoire.

Enfin, rappellons qu’il est beaucoup moins frustrant de rater un lien que de survoler une image en s’attendant à ce que ce soit un lien…

Chez Dualnet mon dernier projet a été de construire de A à z le site du DVD du Roi Arthur le film, pour Disney. C’est la première fois que je fais ce genre de site, et j’ai dû le faire entièrement tout seul.

Je suis assez fier du résultat, surtout en ce qui concerne l’html valide, léger et sémantique et le sacré usage des feuilles de style.

Croyez moi, ce respect des standards et cette accessibilité est une révolution dans ce genre de sites. Les sites commerciaux, de films, de DVDs et plus largement de publicité sont tous sauvagement crées pour ne fonctionner que chez la grosse partie des utilisateurs, en oubliant le reste.

C’est sans doute le seul site de film qui puisse être visité proprement à partir d’un PDA. Ou bien encore visité par un téléphone portable, un moteur de recherche ou encore un aveugle. (Si si, les aveugles aussi ont le droit de tout savoir sur le DVD du Roi Arthur… :p)

Les balises dépréciées en faveur de styles CSS sont donc <b>, <i> italique, <u> souligné, <strike> barré, <center>, <big>, <small>, …

Quoique… Les balises big et small sont des styles de texte certes, mais elles ont aussi un sens !

<big> a une dimension de hauteur, de mise au premier plan. Il se distingue de strong par son importance plus élevée, sa hauteur. C’est comme un header mais sans hiérarchie. Un lecteur vocal pourait, par exemple, le parler plus fort.

De même pour <small>. Il n’y a d’ailleurs aucune autre balise que celle-ci pour qualifier un texte qui est moins important que le reste !

Alors faut-il utiliser big et small ou utiliser des strong et des span stylés en CSS à la place ? Je pense que cette dernière solution serait une erreur, et qu’il faut utiliser ces deux balises oubliées pour leur donner le sens qu’elles aimeraient tant porter.

Simplement :

• il ne peut y avoir qu’un seul id dans un document
• un élément ne peut avoir qu’un seul id

L’on peut donc avoir

<div class="robert"></div>
<div class="robert"></div>

<div class="robert pouet"></div>

Mais PAS :

<div id="robert"></div>
<div id="robert"></div>

<div id="robert pouet"></div>

Quel est alors l’avantage d’utiliser l’id s’il est si restrictif ?

1. Utiliser du Javascript.

   En javascript on utilise l’id pour désigner tel ou tel élément par getElementById (prendre élément par son id). C’est une méthode très rapide pour pointer sur un élément.

2. Ancres.

   Grâce à l’id on peut faire un lien sur une partie de la page en utilisant un lien de type :

   <a href="#robert">lien</a>

   Lien qui pointera sur l’élément de la page ayant un id tel que :

   <strong id="robert">contenu</strong>

   Autre exemple :

   <body id="top">
   <a href="#top">haut de la page</a>

3. L’aspect sémantique de la chose.

   L’id a une valeur d’unicité et de chose à laquelle on peut se réferrer ou vers laquelle on peut faire un lien, on ne doit donc utiliser l’id que pour les éléments stables d’une page comme pour les grandes sections d’une page. Donner un id à un élément lui donne une autre dimension : il en devient plus important et unique.

Il manque à mon propre site quelques points dans le niveau 3, mais dans l’ensemble je m’en sort rudement bien :]

Voir aussi un petit post à propos du lancement d’Oquast sur escalope par notre bon vieux docLegi et Opquast.org.