Varia

Mot-clé -

Fil des billets

16 septembre 2003

Les polices

Vu du travail, avec Internet Explorer, mon sommaire est illisible, parce que la taille des polices est trop petite. J'avais trouvé une page expliquant et comparant les différentes présentations possibles des navigateurs en fonction des tailles de polices définies, mais je ne trouve plus ma source. Toujours est-il que mes pourcentages ne marche pas ou alors je n'ai pas tout compris.

Mon but est très simple : je veux que le sommaire se différencie du corps de la page. J'ai défini pour cela deux familles de polices dans ma feuille de style, une pour l'ensemble de la page

body { 

font-family: Times, serif;

}

et une autre pour le sommaire

#sommaire { 

font-family: Lucida, Verdana, Helvetica, Arial, sans-serif;

}

Le nom des polices correspond aux polices éventuellement disponibles sur le poste du lecteur. Si aucune police n'est disponible, l'agent utilisateur se rabat sur la famille générique. Ainsi, si vous n'avez pas de police nommée Times, le navigateur utilisera le nom de famille générique serif pour fournir un équivalent (par exemple Times New Roman).

Pour accentuer cette différence, je veux que la taille du sommaire soit inférieure à la taille du corps de la page. Pour cela, je peux soit définir des tailles absolues (en centimètre ou en point par exemple), inutilisable pour le média écran mais utile pour l'impression, soit définir des tailles relatives (en pixel ou en carré typographique par exemple). Ce sont ces dernières que je vais utiliser. Mais quelles unités relatives choisir ? Il suffit de respecter le choix de l'utilisateur.

Ainsi, les valeurs en pixel dépendent de la résolution de l'écran du lecteur. Si le lecteur a fixé la taille de la police à 16 pixels, on peut supposer qu'il a ses raisons (son confort de lecture par exemple). Pourquoi vouloir alors lui infliger une taille de 12 pixels ? On va supposer que le lecteur est intelligent et utiliser des valeurs en carré typographique. En rajoutant dans la feuille de style une propriété font-size, pour toute la page

body { 

font-family: Times, serif;
font-size: 1em;
}

et pour le sommaire

#sommaire * {
font-size: .9em;
}

je définis une taille de police relative au choix de l'utilisateur. Avec 1em, ce choix est respecté quelle que soit la taille définie en pixel (16 pixels dans mon exemple). Avec .9em, j'indique au navigateur une taille de police plus petite, toujours relativement à la taille choisie au départ, mais je laisse le navigateur faire le calcul. J'arrive ainsi au but voulu.

Il existe d'autres possibilités, comme smaller ou larger, mais elles n'ont pas l'air de fonctionner correctement.

Ma feuille de style est maintenant stabilisée. Il me reste toutefois à styler des balises que j'ai employé récemment, comme del et ins, et d'autres dont l'affichage ne me plaît pas comme dt et dd.

15 septembre 2003

Lenteur

Je me demande si, finalement, la forme d'un weblog est adaptée à ce que j'écris.

Ou inversement.

Je ne pensais pas que la publication quotidienne d'un simple article me prendrait autant de temps, même si l'exercice reste intéressant. Mais une semaine de retard, est-ce si important ?

Il est vrai que je fais tout à la main. On ne peut pas dire que ça aide. Mais je ne peux pas dire non plus que je sois aidé. Mon problème avec tous ces outils de publication, c'est qu'aucun ne propose de mode statique ou disons non-connecté. Je m'explique.

Premièrement, je veux pouvoir écrire mes trucs dans l'éditeur que j'aurais choisi, en l'occurence ici, Vim, évidemment, et non pas dans un formulaire de navigateur. Il me faut de la place pour écrire. Le programme vellum contourne cette exigence grâce à son système d'importation basé sur les modules Gendoc.

Mais, et c'est le deuxième point, les pages sont généralement crées dynamiquement. Le programme pyblosxom fonctionne aussi de cette manière : vous créez des fichiers textes dans un répertoire sur lesquels vous venez appliquer des gabarits pour générer vos pages. Mais il n'y aucun moyen de faire cette manipulation automatiquement : il manque un bouton ÉcritmoitoutsurledisquedurMerci!. Je dois donc, au minimum, installer un serveur HTTP, voire, dans le pire des cas, une base de données. Tout ça pour publier trois trucs ? Euh, non merci.

Alors, je fais avec les moyens du bord :

  • j'écris avec mon éditeur fétiche.
  • j'applique le correcteur orthographique Aspell sur chacun des articles.
  • les pages du journal sont rangées sous le répertoire /journal/AAAA/MM/JJ-titre_de_l'article.html : AAAA correspond à l'année, MM au mois et JJ au jour. L'adresse de l'article actuel sera ainsi /journal/2003/09/15-lenteur.html. Je me suis appuyé sur un article du blog de Neokraft, Cool URIs for my blog et sur la traduction française de Cool URIs don't change, Les URLs sympas ne changent pas.
  • toutes les pages sont ensuite générées par le programme MMyW et vérifier par Tidy.
  • Enfin, elles sont publiées par FTP.

Ce qu'il me faudrait, c'est quelque chose dans le genre de charm (oui, oui, je sais encore un programme écrit en python).

Et il y a encore tout le reste en suspend :

  • la mise en ligne des articles de l'année 2003.
  • redéfinir les catégories, que ce soit pour les articles ou pour les liens ;
  • le copyright ;
  • la compréhension des rétroliens ;

3 septembre 2003

Sémantique et petits rongeurs

Quelques notes suite à la lecture de l'article Won't somebody please think of the gerbils? de Mark Pilgrim, article dans lequel il revient sur le XHTML, la validation, les CSS, le balisage sémantique et l'accessibilité.

Si je peux comprendre ces réticences concernant le XHTML, le fait que mes documents soient servis comme du HTML ne me gênent pas, parce que dans la norme XHTML 1.0, le nommage MIME général recommandé pour les applications n'a pas encore été résolu. Le problème se posera si je passe en 1.1. Il faudrait alors que je vérifie que mon FAI (puisque cela se passe côté serveur) serve mes pages en xhtml+xml. Pourquoi utiliser du XHTML 1.0 strict alors ? Parce que comme l'écrivait Tristan Nitot, j'ai de la chance d'être un débutant :

C'est pour cela que les débutants ont une chance inouïe : ils peuvent décider, pour peu qu'on les informe, de débuter directement au niveau XHTML 1.0 strict, sémantique et accessible.

Débuter à ce niveau permet à des néophytes comme moi de bien rédiger ses pages. La principale règle d'écriture tient en une seule phrase : un document bien formé est un document dont chaque élément possède une balise d'ouverture, un contenu et une balise de clôture. Cela me semblait contraignant au départ, mais finalement on s'y habitue vite.

Un document bien formé n'est pas encore un document valide, bien que pour qu'un document soit valide, il doive être bien formé. C'est une condition nécessaire mais pas suffisante. Il faut encore qu'il obéisse à la structure de la DTD dans laquelle les éléments et les attributs sont définis. La validité elle-même ne me dit rien sur la sémantique ou l'accessibilité de mon document. À la limite, elle ne me sert qu'à déboguer mes pages, mais le programme Tidy le fait aussi bien. Quel est l'intérêt alors de laisser une rubrique « Validation » dans mon sommaire ? Pour faire comme tout le monde ?

Les feuilles de style en cascade (CSS) me permettent de séparer la structure de mon document de sa présentation physique (écran de moniteur ou de portable, papier, synthèse vocale, etc.). Elles n'ont rien à voir avec la conformité de mes pages : une page peut être valide sans utiliser de feuilles de styles ou l'inverse.

Le balisage sémantique est lié à la signification des marqueurs. Certains éléments renvoient à un type de contenu (textuel comme p ou non comme img) ou à une construction logique (comme h1). Mais h1 est lui-même de type textuel, non ? C'est le point le moins clair pour moi : lire l'annexe B des directives pour l'accessibilité aux contenus Web pour plus de précisions.

L'accessibilité signifie que le contenu est accessible indépendament de l'agent utilisateur. D'après Mark Pilgrim, deux points importants sont à retenir : l'attribut alt pour les éléments images et la navigation au clavier grâce à l'attribut accesskey. J'y rajouterais un troisième point, écrire des liens explicites qui ont encore un sens en dehors de leurs contextes. Si le premier point est règlé et que je fais attention au troisième, je n'ai défini par contre aucune navigation au clavier. Il va falloir que je me penche là-dessus et que j'écrive une page expliquant ma politique d'accessibilité.

6 août 2003

blockquote, q et cite (2)

Problème : référencer chaque citation. Solution : donner à chaque élément q un attribut title, dans lequel on précise l'auteur, le titre et la page de la référence. Au cas où la référence pointée par l'attribut cite de l'élément blockquote ne se trouve pas en ligne, la remplacer par une URN indiquant l' ISBN de la source. Ce mécanisme est expliqué dans la RFC 3187.

13 juillet 2003

blockquote, q et cite

Selon la norme, cite indique un extrait ou une référence vers une autre source, blockquote indique une citation longue de type bloc (avec saut de paragraphe) et q une citation courte de type en-ligne (sans saut de paragraphe).

Ces trois éléments peuvent prendre les attributs lang et title et les éléments blockquote et q peuvent prendre en plus l'attribut cite qui fournit les indications sur l'origine de la source. Pour chacune de mes citations, j'ai besoin du titre du livre et de la page de la citation.

En m'appuyant sur l'Art d'utiliser le cite de Karl Dubost, je me rends compte que si l'exemple qu'il donne est tout à fait valable pour les citations longues, elle pose un problème pour les citations dans le corps du texte. Exemple :

<blockquote cite="Recherches logiques" lang="fr">
<p>
<q lang="fr">Une très longue citation de Husserl</q>
</p>
<cite title="Auteur">Husserl, E.</cite>
<cite title="Titre" lang="fr">Recherches logiques</cite>
<cite title="Année">1901</cite>:
<cite title="Page">223</cite>
</blockquote>

On remarque au passage que pour le type de citation longue, il n'y a plus besoin de faire un renvoi puisque nous avons toutes les informations nécessaires. Mais le problème reste entier pour les citations en-ligne : je ne peux pas utiliser ce système. Je peux peut-être créer une classe sur l'élément blockquote pour les citations en ligne, cela gênerait moins la lecture, mais ça la gênerait quand même (et c'est pour ça que je ne suis pas satisfait). Un autre point mineur concerne les abbréviations qui courent à travers le document.

- page 6 de 7 -