Forums Zebulon.fr: Passer du HTML sauvage à XHTML et CSS - Forums Zebulon.fr

Les premiers développements de pages web ont été réalisés dans une relative anarchie, essentiellement due à l'absence de standards suffisamment forts pour s'imposer aux concepteurs des navigateurs. Lesquels d'ailleurs nageaient souvent à contre-courant, pour tenter de s'imposer en se distinguant de leurs concurrents.

Les travaux du W3C (World Wide Web Consortium) ont peu à peu emporté l'adhésion et assis sa notoriété. Récemment, l'apparition de navigateurs respectant de plus en plus strictement ses recommandations ont taillé des croupières aux tenants du marché, et l'on ne peut que souhaiter longue vie à des petits nouveaux prometteurs, comme Mozilla Firefox.

C'est dans cette ligne d'évolution qu'émerge la rigueur. Peu à peu. Le principe de la feuille de style existe en effet depuis fort longtemps, et XHTML a déjà fêté son second anniversaire...

Et pourtant, le respect des standards n'est pas encore jugé fondamental, et la mise en forme sauvage d'une page HTML reste très répandue, y compris hélas dans les générateurs graphiques. On rencontre fréquemment l'utilisation détournée de tableaux pour effectuer de la mise en page, ou des attributs de style noyés directement dans le corps du texte, comme par exemple un balisage du genre <font face=Arial size=4><b>BIGTITLE</b></font>. Pourquoi s'en priver, tant que c'est toléré ?

L'idée qui préside à l'utilisation systématique de feuilles de styles est celle de la séparation entre le contenu d'un message et sa présentation,

• la page HTML ne doit contenir que le message lui-même, ce qui permet de faciliter le contrôle de sa structuration sémantique,
  
• la feuille de style CSS décrit la façon de présenter le message, en fonction de sa structure signifiante (les blocs de texte, les paragraphes, les niveaux de titres, etc).

L'externalisation de la feuille de style dans un fichier séparé permet de faire bénéficier plusieurs pages (et, pourquoi pas, tout un site) d'un aspect visuel homogène. Alors, quelle économie de moyens lorsqu'on veut changer le look du site : il suffit de modifier la feuille de style, sans toucher aux pages HTML elles-mêmes... enfin, presque !

__________

Au programme,

• Pompage, collecteur d'incitations au respect des standards,
  
• CSSzenGarden, preuve ludique de l'efficacité des feuilles de style,
  
• SELFHTML, documentation de référence pour la programmation web,
  
• HTML, une approche intuitive,
  
• CSS, la mise en oeuvre d'une feuille de style,
  
• Validator, l'impitoyable maître d'école,
  
• XHTML, la convergence...,
  
• XHTML, mais en vrai, cette fois !,
  
• CSS, pour la cohérence d'un style et le confort visuel

Ce message a été modifié par dylav - 31 mars 2008 - 07:47 .

Pompage.net, collecteur d'incitations au respect des standards

Ce petit post pour vous signaler l'existence d'un site sympathique et sérieux, Pompage.net *, qui s'est spécialisé depuis 2001 dans la collecte et la traduction d'articles concernant la normalisation de l'écriture HTML (puis XHTML), en particulier au travers de l'utilisation de feuilles de style (CSS).

C'est le principe de la séparation systématique de la description du contenu (en HTML), de celle de sa forme (en CSS).

Les articles choisis sont limpides et, pour une large majorité, peuvent être compris sans difficulté par un développeur moyen. Ils sont sans prétention (pas de guru, ici, quoique...), et bien utiles pour clarifier ses idées et adopter une rigueur payante dans sa démarche créative.

Quelques exemples de sujets,

• une saga en 15 épisodes sur les bases de la mise en oeuvre de CSS,
  
• le combat entre mises en page par tables ou par CSS pur,
  
• la mise en oeuvre multimédia, n'oubliant pas les problèmes spécifiques aux malvoyants, aux non-voyants, aux impressions, aux accès par téléphone portable, ...
  
• etc.

Enfin, Pompage.net référence des traductions effectuées sur d'autres sites, ainsi que divers sites, forums et tutoriels.

Les seuls reproches que je pourrais lui faire seraient que,

• parfois un article me laisse sur ma faim,
  
• il ne paraît de nouveautés, au mieux, qu'une fois par mois...

On ronge son frein ! Mais qui suis-je, moi, pour les critiquer ?
______

* je ne suis lié en aucune manière à ce site, et n'en suis qu'un visiteur régulier.

Ce message a été modifié par dylav - 24 mars 2006 - 09:40 .

CSSzenGarden, preuve ludique de l'efficacité des feuilles de style

Ce petit post pour introduire une expérience atypique destinée à faire la preuve, par l'exemple, de l'efficacité des feuilles de style.

Le principe de CSSzenGarden est de mettre à disposition de tout un chacun* une page HTML brute structurée, c'est-à-dire bien balisée en blocs (<div>, <span>) et paragraphes <p>, munis d'étiquettes distinctives permettant de les qualifier dans une feuille de style, séparément (attribut id) ou par groupe (attribut class). La seule modification autorisée est celle du nom de la feuille de style externe à lui appliquer.

L'exercice a beaucoup plu de par le monde, car on compte plus de 150 présentations en ligne, pour la plupart radicalement différentes les unes des autres. Si vous avez quelques minutes d'émerveillement à y consacrer, visualisez plusieurs de ces oeuvres, en vous souvenant bien que le contenu de la page HTML est toujours rigoureusement le même et que seule change la feuille de style CSS !

Il existe une traduction française de CSSzenGarden, qui répertorie plus d'une cinquantaine de contributions.

Pour ma part, l'intérêt fondamental que je trouve à cette expérience réside dans le côté sémantique de la démonstration : la page HTML ne contient que du texte structuré, donc très facile à maintenir. C'est bien alors le fond du sujet traité qui y est privilégié. Mais rien n'empêche, par ailleurs, de le présenter élégamment, grâce à une feuille de style, pour retenir le visiteur dans la lecture du message véhiculé.

______

* chacun peut jouer avec, il suffit de télécharger le code source de la page HTML et de laisser courir son imagination. Mais CSSzenGarden sollicite surtout les graphistes professionnels, et se réserve le droit de mettre ou non en ligne les résultats de leurs travaux.

Ce message a été modifié par dylav - 24 mars 2006 - 09:48 .

SELFHTML, documentation de référence pour la programmation web

En matière de référence pour la programmation web, il est clair que l'organisme officiel et incontournable est le W3C (World Wide Web Consortium), qui s'efforce d'édicter des standards pour le web, en spécifiant des recommandations, que devraient respecter tous les navigateurs.

Le W3C est la référence, mais ses documents, étant des préconisations, sont plutôt des méta documents destinés aux concepteurs des navigateurs, donc pas toujours aisés à appréhender par le commun des développeurs.

C'est probablement ce qui a créé un besoin de documentations plus abordables, comblé en particulier par le site SELFHTML (allemand), dont je vous invite à visiter la traduction française.

De présentation un peu austère mais très efficace, ce site est extrêmement précieux, avec des chapitres de référence pour les professionnels, mais également des chapitres d'initiation pour débutants.

SELFHTML référence et documente,

• HTML, XHTML, DHTML,
  
• CSS,
  
• JavaScript,
  
• CGI / Perl,
  
• PHP.

Ce site est bien entendu l'une de mes sources de référence préférées*.
______

* je précise, pour éviter tout malentendu, que je ne lui suis lié en aucune sorte.

Ce message a été modifié par dylav - 24 mars 2006 - 09:48 .

HTML, une approche intuitive

Je suis venu tard à la micro-informatique, poussé par ma fille qui voulait pouvoir appliquer à la maison tout ce qu’on lui enseignait de façon dégrossivo-intuitive à l’école primaire. De métier informaticien concepteur et développeur sur gros système, je n’étais pas très pressé d’entrer dans un monde approximatif où, Bill Gates en tête, on est satisfait quand ça fonctionne à peu près. Et puis elle en savait déjà plus que moi lorsque, en 1999, j’ai enfin décidé d’acquérir mon premier PC.

Pour me démarquer de sa supériorité dans le maniement de WORD et EXCEL, j’ai décidé de tenter un gros coup en bâtissant un mini-site pour décrire ma cassettothèque. Une page-menu qui liste par ordre alphabétique tous les films enregistrés, chaque ligne débranchant par lien hypertexte vers la fiche du film (titre, année, acteurs, résumé, si possible une photo et, bien entendu, numéro de cassette, position, durée).



Le générateur de code

Mais j’ignorais tout du HTML, le langage avec lequel on construisait des pages web. Et c’est WORD 97 qui m’a mis le pied à l’étrier… avec sa sortie Fichier / Enregistrer au format HTML. Vite une page WORD, une photo en haut à gauche (option texte rapproché), à côté un titre puis du texte et, en bas, ne pas oublier d’identifier la cassette concernée. Enregistrement au format HTML.

Flûte, le texte se retrouve sous la photo, et tout a été verticalisé. Renseignements pris, c’est en enfermant ses données dans des cases de tableau qu’on réussit à maintenir après traduction HTML une présentation à peu près voulue. Vite fait, bien fait, un tableau une ligne deux colonnes, et hop… c’était presque ça.

Le décryptage du code généré

Mais moi qui me targue d’esthétisme, je n’étais pas vraiment satisfait. Et puis il restait à écrire le menu. Alors, un langage de plus, un langage de moins, je n’avais plus qu’à assimiler HTML pour analyser le code généré, et voir ce qu’on pourrait en faire. Ayant trouvé au bureau un didacticiel et un doc de référence très chouettes (je les ai depuis perdus tous deux, hélas), j’ai tenté de déchiffrer mon code HTML issu de WORD. Une horreur… plus de 30% du code était totalement inutile.

Après épuration, ce code restait un véritable salmigondis, qui ne respectait même pas la syntaxe HTML. Alors pourquoi la page réussissait-elle à s’afficher sous Internet Explorer (sur mainframe, c’est incontournable, lorsqu’on commet une erreur de programmation, le logiciel plante, et il est nécessaire de corriger) ? La permissivité, bien sûr…

Mais quand va-t-il nous parler de CSS ?

Oups ! Si je vous fais part de tous les avatars de ma démarche d’approche du web, il y en a qui risquent de s’endormir en route… Ce que je voudrais ajouter avant d’entrer dans le vif du sujet, c’est qu’il existe des générateurs de pages HTML beaucoup plus sophistiqués que WORD, bien sûr, mais je n’en ai finalement jamais pratiqué, n’ayant pas eu envie de m’investir dans cette voie : la programmation en HTML natif est passionnante, bien que confinant à l’artisanat…

Quant à mon code épuré, le voilà, nécessaire et suffisant, et syntaxiquement correct. Il est cependant bourré de défauts, ne faisant en particulier pas appel à une feuille de style. C’est ce que nous analyserons dans une prochaine étape…

<HTML><HEAD>
<META HTTP-EQUIV="Content-Type"
	  CONTENT="text/html; charset=windows-1252">
<TITLE>ORATIO IN L. CATILINAM PRIMA</TITLE>
</HEAD>
<BODY><CENTER>
<TABLE WIDTH="625"><TR><TD>
<SPAN STYLE="float:left;margin-right:5">
<IMG SRC="Ciceron.jpg"></SPAN>
<FONT SIZE="4" FACE="Verdana">
<B>ORATIO IN L. CATILINAM PRIMA</B>
<FONT SIZE="2"><CENTER>(Cicero, 08-11-0063)</CENTER>
cum Janus Paulus Belmondus, Sofia Marcia, Maria Foresta,
Catarina Danova atque Lino Ventura
<HR SIZE="1" COLOR="#000000">
Quo usque tandem abutere, Catilina, patientia nostra ?
quam diu etiam furor iste tuus nos eludet ?
quem ad finem sese effrenata iactabit audacia ?
Nihilne te nocturnum praesidium Palati, nihil urbis vigiliae,
nihil timor populi, nihil concursus bonorum omnium,
nihil hic munitissimus habendi senatus locus,
nihil horum ora voltusque moverunt ?
Patere tua consilia non sentis,
constrictam iam horum omnium scientia teneri
coniurationem tuam non vides ?
Quid proxima, quid superiore nocte egeris, ubi fueris,
quos convocaveris, quid consilii ceperis,
quem nostrum ignorare arbitraris ?
O tempora, o mores ! Senatus haec intellegit.
consul videt; hic tamen vivit. Vivit ?
immo vero etiam in senatum venit, fit publici consilii particeps,
notat et designat oculis ad caedem unum quemque nostrum.
<HR SIZE="1" COLOR="#000000">
cassette #<B>54</B>, début à 4h08, durée 1h54
</FONT></FONT>
</TD></TR></TABLE></CENTER>
</BODY></HTML>

Ce message a été modifié par tangui - 05 juin 2006 - 10:27 .

CSS : la mise en œuvre d’une feuille de style

L’idée principale qui sous-tend l’utilisation de feuilles de style en cascade (CSS, pour Cascading Style Sheets) réside, rappelons-le, dans la volonté de clarifier les rôles : à la page HTML celui du contenu, à la feuille CSS celui de sa présentation.

Je ne vais pas développer ici un cours CSS, j’ai déjà cité plus haut des références de sites et/ou articles qui traitent la question avec pertinence, auxquels je vous invite à vous reporter (et il en existe bien d'autres). Je me contenterai de vous montrer la démarche de normalisation sur l’exemple simplissime de ma pseudo-fiche cinéma.

Rappelons le code source, dont j’ai numéroté ci-dessous les lignes à gauche pour les identifier plus facilement dans mes explications (j’ai sauté les lignes [17] à [31], sans intérêt pour la démonstration, dans la mesure où elles ne contiennent que du texte).

[01] <HTML><HEAD>
[02] <META HTTP-EQUIV="Content-Type"
[03]	   CONTENT="text/html; charset=windows-1252">
[04] <TITLE>ORATIO IN L. CATILINAM PRIMA</TITLE>
[05] </HEAD>
[06] <BODY><CENTER>
[07] <TABLE WIDTH="625"><TR><TD>
[08] <SPAN STYLE="float:left;margin-right:5">
[09] <IMG SRC="Ciceron.jpg"></SPAN>
[10] <FONT SIZE="4" FACE="Verdana">
[11] <B>ORATIO IN L. CATILINAM PRIMA</B>
[12] <FONT SIZE="2"><CENTER>(Cicero, 08-11-0063)</CENTER>
[13] cum Janus Paulus Belmondus, Sofia Marcia, Maria Foresta,
[14] Catarina Danova atque Lino Ventura
[15] <HR SIZE="1" COLOR="#000000">
[16] Quo usque tandem abutere, Catilina, patientia nostra ?   [...] 
[32] notat et designat oculis ad caedem unum quemque nostrum.
[33] <HR SIZE="1" COLOR="#000000">
[34] cassette #<B>54</B>, début à 4h08, durée 1h54
[35] </FONT></FONT>
[36] </TD></TR></TABLE></CENTER>
[37] </BODY></HTML>

Tout d’abord, la ligne [06] contient la balise <BODY>, drapeau de début du corps de texte, suivie d’une balise <CENTER> qui demande de centrer sur l’écran tout ce qui se situe ensuite, en l’occurrence toute la page (cf. </CENTER> ligne [36], et </BODY> ligne [37]). Il s’agit d’un élément de présentation. Il nous faut donc l’enlever de là, et créer une feuille de style où l’insérer.

[04b]<STYLE TYPE="text/css">
[04c]BODY {text-align:center}
[04z]</STYLE>

La ligne [04b] est le drapeau de début de la feuille de style, qui précise qu’elle contient du texte CSS, et la ligne [04z] en représente le drapeau de fin. Quant à la ligne [04c], elle indique que, dans la page, tous les éléments englobants devront être centrés horizontalement sur l’écran.

La ligne [07] introduit une table <TABLE>, avec une ligne <TR> et une colonne <TD>. Outre le fait qu’il est préférable, pour faciliter la relecture, d’écrire une seule balise par ligne, la balise <TABLE> est affublée d’un attribut de largeur : présentation, donc => direction feuille de style.

[04d]TABLE {width:625}

Attention, si l’on avait plusieurs tables dans la page, elles se retrouveraient toutes affectées de cette largeur. Il faudrait alors identifier cette table, pour limiter la portée de la mesure à elle seule.

[07] <TABLE ID="corps"><TR><TD>
[04d]#corps {width:625}

Si la page était encore plus complexe, et qu’on veuille affecter cette largeur à un groupe d’entre elles, on spécifierait par exemple, pour chacune des tables concernées,

[07] <TABLE CLASS="larg"><TR><TD>
[04d].larg {width:625}

La ligne [08] décrit un bloc incorporé flottant dans la cellule de table, qui doit être positionné à gauche et dégager à droite une marge. Mise en page ? Feuille de style !

[08] <SPAN CLASS="spim">
[04e].spim {float:left;margin-right:5}

On remarquera ici que les éléments de style étaient directement codés en tant que tels dans la balise <SPAN>.

La ligne [10] exprime typiquement, elle aussi, des instructions de présentation : elle demande qu’on utilise, dans la cellule concernée, la police Verdana, en taille 4 pour la ligne-titre en gras qui suit (puis, ligne [12], en taille 2). On va donc reporter tout ça dans la feuille de style, en décrivant d’une part les modalités pour la cellule (ligne [04f]), puis celles du titre, qu’on traitera en tant que titre de plus haut niveau (balise <H1> aux caractéristiques décrites en ligne [04g]).

[07] <TABLE ID="corps"><TR><TD ID="fiche">
[10] ...disparaît...
[11] <H1>ORATIO IN L. CATILINAM PRIMA</H1>
[12] <CENTER>(Cicero, 08-11-0063)</CENTER>
[04f]#fiche {font-family:Verdana;font-size:13px}
[04g]H1 {font-size:18px;font-weight:bold}

Et c’est là qu’on découvre un niveau de difficulté supplémentaire : HTML et CSS ne disent pas les mêmes choses de la même façon… et un langage de plus ! En bref, la police est identifiée respectivement par FACE= et font-family:, et sa taille par SIZE= et font-size: (avec en outre des unités de mesure différentes). Quant au titre, il est respectivement mis en gras par la balise <B> et l’attribut font-weight:.

On va temporairement garder la ligne [12] dans son [nouvel] état actuel. En effet, remplacer <CENTER> … </CENTER> par quelque chose comme <SPAN class="center"> … </SPAN> ne me semble pas faire avancer la question de l’épuration du HTML… (il faudra cependant y revenir plus tard, lorsque nous parlerons de XHTML).

Pour les lignes [15] et [33], on reconnaît le travail à faire (avec pour spécifier l’épaisseur du trait l’attribut SIZE= devenant height:),

[04h]HR {height:1;color:#000000}
[15] <HR>
[33] <HR>

Et la ligne [35] disparaît, puisque les drapeaux de début d’application de police ont été retirés en lignes [10] et [12].

D’où le nouveau code source suivant, rationalisé par une présentation indentée (c’est juste pour la vue, pas pour l’odeur oups, le fonctionnel) :

<HTML>
  <HEAD>
	<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
	<TITLE>ORATIO IN L. CATILINAM PRIMA</TITLE>
	<STYLE TYPE="text/css">
	   BODY   {text-align:center}
	   H1	 {font-size:18px;font-weight:bold}
	   HR	 {height:1;color:#000000}
	   .spim  {float:left;margin-right:5}
	   #corps {width:625}
	   #fiche {font-family:Verdana;font-size:13px}
	</STYLE>
  </HEAD>
  <BODY>
	<TABLE ID="corps">
	  <TR>
		<TD ID="fiche">
		  <SPAN CLASS="spim">
			<IMG SRC="Ciceron.jpg">
		  </SPAN>
		  <H1>ORATIO IN L. CATILINAM PRIMA</H1>
		  <CENTER>(Cicero, 08-11-0063)</CENTER>
			cum Janus Paulus Belmondus, Sofia Marcia, Maria Foresta,
			Catarina Danova atque Lino Ventura
		  <HR>
			Quo usque tandem abutere, Catilina, patientia nostra ?
[...]
			notat et designat oculis ad caedem unum quemque nostrum.
		  <HR>
			cassette #<B>54</B>, début à 4h08, durée 1h54
		</TD>
	  </TR>
	</TABLE>
  </BODY>
</HTML>

Ouf ! J'ai bien fait de partir d'une page rudimentaire, sinon on y serait encore cette nuit...

Et voilà du code nettoyé, où les balises qui restent dans le <BODY> peuvent être considérées comme signifiantes de l’importance de ce qu’elles bornent plus que de la présentation qui en sera faite (reportée, elle, dans la feuille de style).

Si la différence ne semble pas flagrante, c’est que le code source d’origine était à la fois extrêmement simple et syntaxiquement correct. Ce qui n’est hélas pas toujours le cas en sortie de générateur, ou lorsque l’on rédige sa page HTML à la main : l’erreur est humaine...

Dans la prochaine étape, nous passerons le code au filtre d’un validateur, pour nous assurer que cette écriture est parfaitement correcte.

Validator, l'impitoyable maître d'école

Dans l'étape précédente, nous avons pris soin de relire notre dictée, afin de nous assurer que nous n'avions pas laissé traîner de fautes de grammaire ou d'orthographe. Vous avez de plus, j'en suis persuadé, copié/collé le code sous un nom du genre Fiche.html, que vous avez bien entendu eu la curiosité de lancer en double-cliquant dessus. Désolé, il manquait l'URL de l'image... Je vous suggère donc de remplacer la 19ème ligne par

<IMG SRC="http://www.eleves.ens.fr/home/mlnguyen/divers/rome/images/ciceron_phb.jpg">

pour constater qu'on obtient effectivement toujours le résultat attendu en dépit de la création d'une feuille de style.

C'est alors sûrs de notre coup que nous soumettons notre page au validateur officiel du W3C. Pour cela, nous lui indiquons le chemin de notre Fiche.html dans la case Local File, avant d'enfoncer le bouton Check avec tout de même un rien d'appréhension :
This page is not Valid (no Doctype found)!

Pas d'affolement... le validateur nous indique tout simplement que nous avons omis de lui préciser quelle langue nous parlons, et qu'avec la meilleure volonté du monde, il aura du mal à trouver le barème à appliquer. Renseignons-nous, par exemple chez Pompage.net (oui, ils fournissent ça aussi !).

Pour commencer, nous sommes en HTML 4.01 (puisque je vous le dis). Ensuite, on a le choix entre les DTD (Document Type Declaration, ou DOCTYPE) frameset (ce n'est pas notre cas), transitionnelle (encore un peu permissive), et stricte (pure et dure, façon ayatollah). Moi, je suis humble, je vais commencer par la DTD transitionnelle, en ajoutant en tête de fichier la ligne

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

Je soumets à nouveau au validateur... caramba, encore raté !
This page is not Valid HTML 4.01 Transitional!
Cette fois, c'est la balise IMG (affichant une image) qui requiert impérativement un attribut ALT (texte à faire apparaître à la place de l'image tant qu'elle n'est pas affichée, ou en bulle attachée au pointeur quand on la survole).

On remplace :

<IMG SRC="http://www.eleves.ens.fr/home/mlnguyen/divers/rome/images/ciceron_phb.jpg" ALT="Cicero">

et on recommence :
This Page Is Valid HTML 4.01 Transitional!

Foin de triomphalisme, encore un effort, passons à la grammaire "stricte", en changeant de DTD en tête de fichier source,

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Arrgh ! Encore une faute !
This page is not Valid HTML 4.01 Strict!

Eh bien oui, je l'avais prévu (mais pas si tôt !), la balise <CENTER> est tombée en disgrâce, et nous serions dans l'obligation de mettre en oeuvre le centrage de la façon filandreuse dont je parlais l'autre fois, avec une classe ".center" dans la feuille de style, sollicitée en attribut d'une balise <SPAN CLASS="center"> en lieu et place de la balise <CENTER>. Ce n'est pas un progrès sémantique, et le mieux sera d'oublier le centrage...
This Page Is Valid HTML 4.01 Strict!

On souffle un coup... et on repart ! Il nous reste en effet à extraire la feuille de style de notre source HTML, afin d'en faire un fichier source CSS à part entière, que nous allons par exemple nommer Style.css (seul le nom est au choix, .css étant obligatoirement l'extension à affecter à une feuille de style) :

BODY   {text-align:center}
H1	 {font-size:18px;font-weight:bold;margin-bottom:0}
HR	 {height:1;color:#000000}
.spim  {float:left;margin-right:5}
#corps {width:625}
#fiche {font-family:Verdana;font-size:13px}

et que notre fiche-ciné va solliciter ainsi (à supposer que les deux fichiers soient, ici, rangés dans le même répertoire) :

<LINK type="text/css" rel=stylesheet href="Style.css">

Il nous reste à soumettre la feuille de style au validateur CSS. Eh oui, le W3C a tout prévu pour nous éviter de commettre des écarts impardonnables ! Allez, essayez, je vous ai même trouvé une version française (enfin, presque) du validateur...

Catastrophe ! Pour 6 lignes, 3 erreurs et 5 avertissements (warnings). Il s'agit de 3 fois la même erreur (lignes 3, 4 et 5), d'une mesure dont on ne donne pas l'unité (bizarre, tout de même, que les navigateurs aient implicitement compris qu'il s'agissait de pixels !).

Pour les warnings,
- on va ignorer celui de la ligne 1,
- ligne 3, assurons le contraste entre fond (blanc) et "police" (noir),
- ligne 6, ça bégaie, avec deux fois la recommandation d'ajouter une alternative générique à la police choisie.

Je propose une nouvelle version

BODY   {text-align:center}
H1	 {font-size:18px;font-weight:bold;margin-bottom:0}
HR	 {height:1px;color:#000000;background-color:#FFFFFF}
.spim  {float:left;margin-right:5px}
#corps {width:625px}
#fiche {font-family:Verdana, sans-serif;font-size:13px;text-align:left}

dont j'ai décidé qu'elle me satisferait et là, tiens tiens !, tout warning a disparu...
Aucune erreur ou avertissement

Cette feuille de style externe est donc à adjoindre à la page HTML épurée :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<HTML>
  <HEAD>
	<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
	<TITLE>ORATIO IN L. CATILINAM PRIMA</TITLE>
	<LINK type="text/css" rel=stylesheet href="Style.css">
  </HEAD>
  <BODY>
	<TABLE ID="corps">
	  <TR>
		<TD ID="fiche">
		  <SPAN CLASS="spim">
			<IMG SRC="http://www.eleves.ens.fr/home/mlnguyen/divers/rome/images/ciceron_phb.jpg" ALT="Cicero">
		  </SPAN>
		  <H1>ORATIO IN L. CATILINAM PRIMA</H1>
			(Cicero, 08-11-0063)
		  <BR>
			cum Janus Paulus Belmondus, Sofia Marcia, Maria Foresta,
			Catarina Danova atque Lino Ventura
		  <HR>
			Quo usque tandem abutere, Catilina, patientia nostra ?
			quam diu etiam furor iste tuus nos eludet ?
			quem ad finem sese effrenata iactabit audacia ?
			Nihilne te nocturnum praesidium Palati, nihil urbis vigiliae,
			nihil timor populi, nihil concursus bonorum omnium,
			nihil hic munitissimus habendi senatus locus,
			nihil horum ora voltusque moverunt ?
			Patere tua consilia non sentis,
			constrictam iam horum omnium scientia teneri
			coniurationem tuam non vides ?
			Quid proxima, quid superiore nocte egeris, ubi fueris,
			quos convocaveris, quid consilii ceperis,
			quem nostrum ignorare arbitraris ?
			O tempora, o mores ! Senatus haec intellegit.
			consul videt; hic tamen vivit. Vivit ?
			immo vero etiam in senatum venit, fit publici consilii particeps,
			notat et designat oculis ad caedem unum quemque nostrum.
		  <HR>
			cassette #<B>54</B>, début à 4h08, durée 1h54
		</TD>
	  </TR>
	</TABLE>
  </BODY>
</HTML>

Au fait, on en a réalisés, des chamboulements, dans notre pseudo-fiche-ciné ! Si on vérifiait qu'elle donne toujours les résultats attendus ? Oh, non ! Ne voilà-t-il pas que l'option de centrage du BODY s'applique maintenant même à l'intérieur du conteneur <TD>. Aussi surpris que vous, j'ai cependant lâchement triché en complétant le style #fiche avec l'attribut text-align:left, qui rétablit la situation...

Plutôt content, je retourne par curiosité dans les spécifications HTML du W3C pour constater, ô horreur, que les dernières recommandations, HTML 4.01, datent du 24-12-1999 ? Est-il possible qu'ils se soient à ce point endormis sur leur notoriété ?

Evidemment non, puisqu'est apparu le XHTML 1.0 le 26-01-2000, suivi du XHTML 1.1 le 31-05-2001, et, tout nouveau tout beau, de l'annonce du XHTML 2.0 le 27-01-2006.

Ce message a été modifié par dylav - 23 avril 2006 - 07:30 .

XHTML, la convergence...

D'abord un [tout petit] peu d'histoire. En 1986 apparut le metalangage SGML(1), qui permet de définir des langages de balisage à l'aide de DTD(2). Une DTD est en quelque sorte la grammaire d'un langage de balisage.

SGML s'avérant assez sophistiqué (comprenez totalement ésotérique pour le commun des mortels), on créa la variante simplifiée XML(3), que nous connaissons bien dans le domaine de la formalisation de flux de données, mais qui lui aussi permet de définir des langages de balisage à l'aide de DTD.

HTML(4) a été défini à l'aide de SGML au début des années 90, et c'est encore le cas aujourd'hui avec HTML 4 (non, ce n'est pas une redite, l'autre 4, c'était le nota, celui-ci, c'est le numéro de version !). Mais l'importance croissante que prend XML a conduit à la décision de lui faire supplanter SGML dans la définition de HTML. Et, pour éviter toute confusion, ce nouvel HTML fut rebaptisé XHTML(5).

XHTML 1.0 parut donc en janvier 2000. Je passe sur les détails techniques(6), il s'agissait de converger vers une compatibilité totale entre langages standard XML.
_____

(1) ISO 8879 SGML = Standard Generalized Markup Language
(2) DTD = Document Type Definitions
(3) XML = eXtensible Markup Language
(4) HTML = HyperText Markup Language
(5) XHTML = eXtensible HyperText Markup Language
(6) voir par exemple le site SELFHTML, cité plus haut

Mais sur un plan pratique ?

Au premier abord, pas grand-chose de nouveau. J'en veux pour preuve que les recommandations XHTML du W3C sont particulièrement brèves. Elles se contentent d'indiquer les rares différences de syntaxe, pour la plupart de convergence XML. Ainsi,

• les balises à contenu doivent impérativement avoir un drapeau de début et un drapeau de fin (terminé la tolérance <P> sans </P>, par exemple),
  
• les balises sans contenu doivent être autofermées, en ajoutant un espace et un "/" juste avant le ">" de fin (exemple, <BR />),
  
• les valeurs affectées aux attributs doivent impérativement être encadrées de guillemets, même s'il s'agit de valeurs numériques,
  
• les noms des balises et des attributs doivent être indiqués en minuscules (exactement le contraire du standard strict HTML !),
  
• des balises tombent en disgrâce,
  
• des attributs de balises tombent en disgrâce,
  
• le mécanisme de frames est fortement déconseillé, avec une mort annoncée,
  
• etc. (mais c'est un petit etc).

Pour plus de précisions, voir les Recommandations XHTML 1.0 du W3C (traduction française de Karl Dubost).

Retroussons les manches

Reprenons maintenant notre pseudo-fiche cinéma. Tout d'abord, il nous faut changer de DTD.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Ensuite, nous allons appliquer les transformations évoquées ci-dessus. Je vous épargne la litanie des opérations, en voici le résultat :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
		"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
	<meta http-equiv="Content-Type" content="text/html; charset=windows-1252" />
	<title>ORATIO IN L. CATILINAM PRIMA</title>
	<link type="text/css" rel="stylesheet" href="Style.css" />
  </head>
  <body>
	<table id="corps">
	  <tr>
		<td id="fiche">
		  <span class="spim">
			<img src="http://www.eleves.ens.fr/home/mlnguyen/divers/rome/images/ciceron_phb.jpg" alt="Cicero" />
		  </span>
		  <h1>ORATIO IN L. CATILINAM PRIMA</h1>
			(Cicero, 08-11-0063)
		  <br />
			cum Janus Paulus Belmondus, Sofia Marcia, Maria Foresta,
			Catarina Danova atque Lino Ventura
		  <hr />
			Quo usque tandem abutere, Catilina, patientia nostra ?
			quam diu etiam furor iste tuus nos eludet ?
			quem ad finem sese effrenata iactabit audacia ?
			Nihilne te nocturnum praesidium Palati, nihil urbis vigiliae,
			nihil timor populi, nihil concursus bonorum omnium,
			nihil hic munitissimus habendi senatus locus,
			nihil horum ora voltusque moverunt ?
			Patere tua consilia non sentis,
			constrictam iam horum omnium scientia teneri
			coniurationem tuam non vides ?
			Quid proxima, quid superiore nocte egeris, ubi fueris,
			quos convocaveris, quid consilii ceperis,
			quem nostrum ignorare arbitraris ?
			O tempora, o mores ! Senatus haec intellegit.
			consul videt; hic tamen vivit. Vivit ?
			immo vero etiam in senatum venit, fit publici consilii particeps,
			notat et designat oculis ad caedem unum quemque nostrum.
		  <hr />
			cassette #<b>54</b>, début à 4h08, durée 1h54
		</td>
	  </tr>
	</table>
  </body>
</html>

Allez zou, comme l'on dit dans le midi, un petit coup de validateur et...
This Page Is Valid XHTML 1.0 Strict!

Mais est-ce suffisant ?

Quand on se souvient des difficultés rencontrées avec les précédentes validations (remontez voir plus haut !), on est surpris de réussir du premier coup, et en strict, s'il vous plaît ! Ceci prouve que la transco semble simple, voilà tout.

Néanmoins, si vous avez un peu parcouru quelques sites sur le sujet, ne serait-ce que ceux que je vous ai indiqués plus haut, vous aurez raison de prétendre que cette page XHTML est plutôt médiocre. Pas grammaticalement, puisqu'elle a passé l'épreuve de la validation. Mais,

• la balise <html> n'est pas qualifiée,
  
• la balise <table> a été détournée de sa fonction énumérative,
  
• les paragraphes ne sont pas formalisés,
  
• les balises <b> et <i> sont déconseillées, ainsi que <br>.

Et, pour revenir au titre de ce dossier, j'ajouterai que la feuille de style CSS présente elle aussi plusieurs défauts non négligeables, ne serait-ce que dans le domaine du confort visuel.

Encore, me direz-vous ? Jamais content ? Il ne s'agit pas de se complaire dans la théorie, mais de créer des pages web solides, qui puissent bénéficier des plus larges capacités de diffusion, et des plus grandes facilités d'évolution. Au fond, n'est-ce pas notre but, lorsque nous construisons un site ?

Ce message a été modifié par dylav - 23 avril 2006 - 07:37 .

XHTML, mais en vrai, cette fois !

Tout d'abord, un petit coup de déstabilisateur ! Dans l'article de Tommy Olsson Doctype Declarations and Content-Type Headers, traduit en mars dernier par Philippe Janvier pour pompage.net, nous apprenons avec surprise que la déclaration d'un DOCTYPE n'est requise que pour la validation (c'était bien la peine de s'appliquer...), et que c'est dans l'entête Content-Type du protocole de transfert HTTP qu'on spécifie le langage utilisé.

Si alors je veux parler XHTML, je dois donc le dire, donc être compatible XML, donc préciser tout cela en tête de mon fichier

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=iso-8859-1" />
...

et, pour que le navigateur ne cherche aucun faux-fuyant, j'enfonce le clou en imposant l'extension .xhtml au nom de ma page. Je n'insiste pas plus, vous pourrez trouver plus de détails par exemple ici sur SELHTML.org.

Je double-clique sur mon fichier, et Windows est tout désorienté, ne connaissant pas cette extension. Il me suffit de lui indiquer que je veux l'ouvrir avec FireFox et... la page s'affiche ! Il faut dire qu'avec une page aussi basique, je n'ai pas grand mérite. Quoique, à la lecture de la fin de l'article de Tommy Olsson...

Et au fait, et I.E.? Oui, je sais, je suis sur Zébulon, mais quand même ! Eh bien, si je demande l'ouverture de ma page avec I.E., je vois apparaître mon code source dans une représentation XML classique... Déception, si si ! Soit I.E. ne sait pas transformer mon flux XHTML, soit il refuse d'afficher la page parce qu'elle n'est pas parfaitement conforme XML. Comme je ne suis pas présomptueux, je pencherais plutôt pour la seconde hypothèse.

Mais cela signifierait-il, a contrario, que le fameux navigateur FireFox se permettrait d'être moins strict que Bilou ? En tout cas, j'ai perdu une partie de ma mise en forme, et en suis quelque peu chagrin... Me référant une fois encore à Tommy Olsson, je vais donc transiger, et réduire mes ambitions à l'entête suivante

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
...

dans l'attente de précisions qui ne manqueront pas de se faire jour !

Et avec la balise <table>, qu'est-ce qui ne va pas ?

Roger Johansson, dans son article Bring on the tables (dont on trouvera dans pompage.net la traduction de Pierre Equoy), explique qu'il ne faut pas honnir les tableaux, mais les réserver à leur véritable emploi, à savoir l'énumération de données tabulaires. Et il ajoute que c'est pour ce type de fonctionnement que lui ont été ajoutés des éléments descriptifs, qu'un dispositif de traduction vocale peut analyser pour présenter ce tableau à un aveugle. Eh oui, un aveugle aussi doit pouvoir surfer sur le Net !

Je me dois donc de remplacer mon bloc de présentation <table> par un bloc <div>, effectivement prévu à cet effet.

Prenons garde à cette conversion qui semble toute bête. Nous n'avions ici qu'une table mono-cellulaire. Mais je vous laisse imaginer les difficultés soulevées par l'abandon d'une table de la nature suivante (un de mes squelettes de fiche-cinéma) !



Et les paragraphes ?

Dans un livre, tout texte est composé de paragraphes, dont par exemple la première ligne peut être indentée, et qui sont la plupart du temps séparés par un interligne un peu plus important.

Eh bien, en XHTML, pour respecter cette sémantique de découpage d'un texte en unités logiques, on formalise les paragraphes en les bornant par les balises englobantes <p> et </p>.

L'italique, le gras ?

Bien que les balises <i> et <b> soient encore tolérées, il est conseillé d'oublier leur côté typographique pour privilégier la notion de mise en valeur, avec <em> pour marquer une intonation, et <strong> pour marquer une forte intonation. Ici, le mot intonation n'est pas innocent : les aveugles en bénéficieront, et les autres verront respectivement l'italique et le gras.

D'où une nouvelle version de la page,

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr">
  <head>
	<title>ORATIO IN L. CATILINAM PRIMA</title>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
	<link type="text/css" rel="stylesheet" href="Style.css" />
  </head>
  <body>
	<div id="fiche">
	  <span class="spim">
		<img src="http://www.eleves.ens.fr/home/mlnguyen/divers/rome/images/ciceron_phb.jpg" alt="Cicero" />
	  </span>
	  <h1>ORATIO IN L. CATILINAM PRIMA</h1>
	  <p>
		(Cicero, 08-11-0063)
	  </p>
	  <p>
		cum Janus Paulus Belmondus, Sofia Marcia, Maria Foresta,
		Catarina Danova atque Lino Ventura
		  </p>
		  <hr />
		  <p>
		Quo usque tandem abutere, Catilina, patientia nostra ?
		[...]
		notat et designat oculis ad caedem unum quemque nostrum.
	  </p>
	  <hr />
	  <p>
		cassette #<strong>54</strong>, début à 4h08, durée 1h54
	  </p>
	</div>
  </body>
</html>

à laquelle il faut associer la feuille de style légèrement modifiée (fusion des id #corps et #fiche)

body   {text-align:center}
h1	 {font-size:18px;font-weight:bold;margin-bottom:0}
hr	 {height:1px;color:#000000;background-color:#FFFFFF}
p		{margin:0}
.spim  {float:left;margin-right:5px}
#fiche {width:625px;font-family:Verdana, sans-serif;font-size:13px;text-align:left}

Et notre prochaine étape va s'intéresser à cette feuille de style, pour lui permettre d'apporter du confort aux déficients visuels (bien plus nombreux, cette fois, que les aveugles), et aussi adapter la présentation de notre page à la définition de l'écran client.

Ce message a été modifié par dylav - 02 mai 2006 - 10:56 .

CSS, pour la cohérence d'un style et le confort visuel

Rappelons la feuille de style sur laquelle nous devons travailler.

body   {text-align:center}
h1	 {font-size:18px;font-weight:bold;margin-bottom:0}
hr	 {height:1px;color:#000000;background-color:#FFFFFF}
p		{margin:0}
.spim  {float:left;margin-right:5px}
#fiche {width:625px;font-family:Verdana, sans-serif;font-size:13px;text-align:left}

S'adapter au contexte du visiteur

Tout d'abord, n'oublions pas, lorsque nous construisons une page HTML, que notre visiteur utilisera pour la consulter un navigateur, qui va interpréter notre code pour la lui présenter. Si aujourd'hui les navigateurs on tendance à respecter de mieux en mieux les standards, et donc à converger vers des représentations similaires, il persiste encore de légères différences de mise en forme. Surtout pour les dernières avancées CSS2. Ne tentons donc pas des ajustements complexes au pixel près, nous risquerions d'être déçus par le rendu.

Notre visiteur s'est doté d'un écran à la mesure des ses désirs et/ou de ses moyens, dont la diagonale peut aller de 14 pouces (vieux matos, ou au contraire ultra-portable) à 20 ou plus. Dans certaines limites, il peut en outre choisir la définition de son écran (640*480, 800*600, 1024*768, 1280*1024, etc). Pour respecter le confort de lecture en définition minimale, allons-nous présenter un timbre-poste en grande définition ? C'est un choix.

Inversement, on peut envisager de récupérer à la volée les caractéristiques de l'écran client pour calculer une présentation sur mesure, soit en associant un script JavaScript à une page statique, soit en programmant carrément la génération d'une page dynamique.

Entre ces deux extrêmes, j'aurais tendance à me contenter de travailler en relatif. Il s'agit d'exprimer les dimensions d'un bloc en pourcentage des dimensions de l'écran. Ceci évite de se préoccuper desdites dimensions, et présente en outre l'avantage de faire l'économie de fastidieuses mises au point de programmations pas toujours évidentes.

Concrètement, j'ai conçu ma fiche-film dans une définition 1024*768. Pour qu'elle reste, quelle que soit la définition de l'écran de mon visiteur, la même apparente fenêtre dans la fenêtre de l'écran, je définis la largeur du bloc à 61% (675/1024).

De la même façon, les marges peuvent (doivent) s'exprimer en relatif (par exemple ici, 0.5% pour la marge à droite de l'image). En revanche, esthétiquement, je garderai l'épaisseur du trait <hr> fixe à 1 pixel. Vous noterez au passage que j'ai forcé à zéro l'espacement qui suit un titre, ainsi que les espacements qui précèdent et qui suivent les blocs paragraphes. Pour gagner de la place, ce qui n'est pas toujours judicieux.

Ce qui nous donne :

body {text-align:center}
h1 {font-size:18px;font-weight:bold;margin-bottom:0}
hr {height:1px;color:#000000;background-color:#FFFFFF}
p {margin:0}
.spim {float:left;margin-right:0.5%}
#fiche {width:61%;font-family:Verdana, sans-serif;font-size:13px;text-align:left}

Très bien, cette appropriation de la taille de l'écran mais, me direz-vous, pour que l'homothétie fonctionne, il faut que l'image suive, sinon la présentation ne sera plus la même d'une taille d'écran à l'autre. C'est vrai. Et là, le choix est douloureux. Si techniquement il est possible de déclarer les dimensions de l'image en relatif, le résultat visuel peut être médiocre, voire déplorable.

LA police, pour une homogénéité visuelle

On va parler aussi de déclaration de taille de police. Mais je voudrais auparavant aborder un point purement esthétique. De même qu'un livre utilise de bout en bout une seule [gamme de] police de caractères, pour le texte comme pour les titres, il est souhaitable de n'utiliser qu'une police pour assurer un style homogène et cohérent, non seulement à une page HTML, mais même à tout un site.

Certains documents techniques utilisent éventuellement une autre police pour un usage précis. Par exemple, sur Zébulon, la police Courier New pour les extraits de CODE. On en comprend l'intérêt. Mais on sent bien que cette mise en valeur spécialisée perdrait de son intérêt visuel si elle était noyée au milieu d'un texte utilisant de multiples polices.

Le choix de LA police, c'est déjà l'un des éléments primordiaux du look de votre page (de votre site). Mais n'oublions pas que le visiteur ne disposera peut-être pas de cette police, et proposons au moins une alternative par défaut. Les plus répandues sont serif et sans-serif, selon le cas (une police avec serif ajoute de petites barres aux extrémités des lettres, comme Courrier ou Times. Inversement, Arial ou Verdana sont des polices sans sérif).

Alors, une seule police (et sa remplaçante) dans la page, cela signifie qu'on les fixe au niveau global du BODY (au lieu du niveau de détail #fiche), et tous les niveaux inférieurs en bénéficieront implicitement par héritage.

Ce qui nous donne :

body {font-family:Verdana,sans-serif;text-align:center}
h1 {font-size:18px;font-weight:bold;margin-bottom:0}
hr {height:1px;color:#000000;background-color:#FFFFFF}
p {margin:0}
.spim {float:left;margin-right:0.5%}
#fiche {width:61%;font-size:13px;text-align:left}

La taille de la police, pour le confort visuel

Chacun, en tout cas chez les moins jeunes, a vécu au moins une fois un moment de fatigue visuelle, lui faisant juger trop petite l'écriture sur l'écran. Pour d'autres hélas, c'est un problème permanent. Tous les bons navigateurs permettent de palier cela, en proposant par exemple un CTRL+ qui agrandit la taille des caractères (et un CTRL- pour redescendre).

Dans le passé, la définition des tailles de polices directement dans le BODY (oh!) était assurée par l'attribut size de la balise <font>, qui pouvait prendre les valeurs 1 à 7 (avec la valeur 3 par défaut), dans une unité relative non précisée (en rapport avec la définition de l'écran).

Quand nous avons voulu séparer contenu et présentation, cette définition est remontée dans la feuille de style. C'est pourquoi j'ai précisé

#fiche {font-size:13px}

pour le corps de ma fiche. Seulement, le problème, c'est que l'effet loupe ne fonctionne plus. Nous avons effectivement exprimé la taille de la police dans une unité absolue, le pixel. Sachez qu'on trouve malheureusement encore beaucoup de sites dans ce cas (bonjour les myopes !), et qui de plus utilisent parfois de toutes petites tailles de caractères pour en mettre plus sur l'écran.

La solution, c'est l'unité relative em, où la taille standard est de 1em. Par relative, on entend relative à l'écran, de sorte que cette valeur par défaut ne donnera pas la même taille réelle d'un écran à l'autre.

Mais attention, la proportionnalité s'entend, à chaque niveau hiérarchique, par rapport au niveau directement supérieur. Imaginons un écran où la taille de police est définie, dans le <body>, à 1.1em, contenant un bloc <div> où l'on redéfinit la taille à 0.9em : on obtient une taille réelle de 0.99 (= 1.1 * 0.9). De même, si ce bloc <div> en contient un autre où l'on précise une taille de 0.9em, on aura une taille réelle à 0.89 (= 0.99 * 0.9).

Pour une définition 1024*768, on peut prétendre que 1em vaut environ 15px. D'où des tailles de 0.85em dans le <div>, et 1.2em pour les titres <h1>.

Ce qui nous donne :

body {font-family:Verdana,sans-serif;text-align:center}
h1 {font-size:1.2em;font-weight:bold;margin-bottom:0}
hr {height:1px;color:#000000;background-color:#FFFFFF}
p {margin:0}
.spim {float:left;margin-right:0.5%}
#fiche {width:61%;font-size:0.85em;text-align:left}

Bon, si l'effet recherché n'est pas tout à fait atteint, c'est que la solution ne passe pas vraiment par les mathématiques, mais plutôt par les approximations successives ! Ainsi, j'obtiens à peu près ce que je voulais avec la feuille de style ci-dessous, que je présente sous une forme plus orthodoxe que la mienne, mais qui bouffe plus de place !

body {
	font-family:Verdana,sans-serif;
}
h1 {
	font-size:1.2em;
	font-weight:bold;
	margin-bottom:0;
}
hr {
	height:1px;
	color:#000000;
	background-color:#FFFFFF;
}
p {
	margin:0;
}
.spim {
	float:left;
	margin-right:1%;
}
#fiche {
	width:62%;
	font-size:0.8em;
}

Je dis à peu près, parce que persistent de petites différences entre les affichages IE et FF. Il faut savoir s'en contenter...

Et ensuite ?

Eh bien, ensuite, bonne chance ! J'espère, avec cet exemple simple, avoir su vous convaincre que travailler proprement avec les standards n'est pas seulement un exercice intellectuel, mais aussi une assurance de confort pour vos visiteurs, et de pérennité de votre site... deux pas vers le succès !

Il reste des milliers de pistes à explorer, à commencer, sur pompage.net (qui sait allier démythification et rigueur), par les articles (tous traduits en français) :

• Partir du bon pied avec les standards (Steve Smith), pour démarrer en douceur,
  
• CSS : on reprend tout à zéro ! (Joe Gillespie), véritable tutoriel très didactique,
  
• Gros, rigide, trapu ? gagnez en souplesse ! (Joe Clark), pour être navigable jusque sur PDA,
  
• Création d’une mise en page fluide à l’aide des marges négatives (Ryan Brill), qui prouve de façon élégante que l'on peut se passer de <table> pour réaliser une mise en page sophistiquée,

et plein d'autres aussi passionnants les uns que les autres. Vraiment que du bonheur !

Et moi, il me reste à convertir 1623 pages HTML plus ou moins anarchiques... (j'ai honte)

Epilogue : la conjuration de Catilina

Et à vous, les non latinistes (et même à moi qui l'ai été, mais qui n'y comprends vraiment plus rien en direct live), il faut bien que je livre une traduction de ce début de la diatribe qu'adressa, le 8 novembre de l'an 63 devant le Sénat, le fameux sénateur romain Cicéron au dictateur Catilina :

Citation

On peut dire qu'il n'avait pas froid aux yeux, le sénateur Cicéron !
Ne nous en manquerait-il pas des comme ça, de nos jours ?

Bonus : la souris folle

Fameux bonus que cette Souris Folle ! Une page certes pleine d'humour, mais ce n'est pas pour cela que j'attire votre attention sur ce petit rongeur. Une page réalisée par une sommité de Zébulon, mais ce n'est pas pour cela que je voulais l'évoquer dans ce dossier.

Non ! Ce que cette page a de remarquable, c'est la pureté de l'écriture et l'élégance de la solution.

La pureté de l'écriture ? Eh bien oui, on peut lire le source XHTML, on y voit le plan du discours en 3 parties, on y lit directement le texte. Il n'y manque que la mise en forme.

L'élégance, c'est la mise en oeuvre de trois colonnes avec une simple classe, décrite par seulement 3 attributs. Et c'est [presque] tout !

Et que voit-on en bas à droite ? Les certificats des validateurs XHTML et CSS... et ils ne sont pas volés !

N'hésitez pas à étudier les deux documents,
- "Affichage > Source" pour la page XHTML,
- et là, la feuille de style.

Dernière minute : L'accessibilité en marche

Pour conclure à la fois sur le caractère stratégique de la prise en compte des handicaps, et sur l'intérêt des feuilles de style, vous pourrez également étudier le site Ipédis, qui développe le sujet L'accessibilité en marche.

Sur le plan du contenu, il est en particulier rappelé que, dans le secteur public, l'accès aux handicapés est une obligation légale depuis un an déjà. Et par handicapé, il faut aussi entendre daltonien, myope, arthritique, etc.

Sur le plan technique, c'est du pur XHTML/CSS, avec une présentation en trois blocs colonnes en sandwich entre une entête et un pied de page (le cas d'école, vraiment), mais aussi la mise en oeuvre de feuilles de style spécialisées, l'une pour la présentation sur écran, l'autre pour la restitution sur papier (eh oui, on peut moduler la mise en page).

Ce message a été modifié par dylav - 11 mai 2006 - 07:46 .