<C²: webløg />

Courriel - email address

Avatar Paginus

vendredi 09 juillet 2004
par Normand Lamoureux

Le HTML, facile ?

La déconstruction d'un mythe

On sous-entend trop souvent et on concède trop rapidement que le HTML est facile ; qu'il ne demande que peu ou pas de connaissances techniques ; qu'il est aisé à manier et relativement rapide à apprendre. C'est faire l'économie des contradictions qui sommeillent en lui. C'est occulter les aléas de son histoire et les difficultés qu'il recèle. Bref, c'est aller un peu vite en besogne. Aussi vais-je tenter de mettre en évidence la relative complexité qui se cache derrière cette apparente simplicité.

Le HTML est tellement facile, serais-je tenté d'objecter, que les personnes avisées ne s'entendent pas toutes sur la différence à faire entre <abbr> et <acronym>. Et encore moins sur l'opportunité de maintenir une distinction si subtile au sein de ce qui se veut la langue commune du Web.

Tellement facile, qu'on rencontre encore des développeurs professionnels se demander l'intérêt qu'il peut y avoir à remplacer <b> par <strong>, vu l'allongement du code que cela représente, ou <i> par <em>, étant donné que l'un comme l'autre aura pour effet d'afficher le texte en italique. Dans la plupart des navigateurs, du moins.

Tellement facile, que des auteurs sérieux ne sont pas loin de penser que des éléments aussi peu utilisés que var, address, samp, dfn ou tt n'ont de raison d'être que celle qui sied au poids du passé et qu'on gagnerait en simplicité en les éliminant. Comme si une spécification pouvait se permettre de changer aussi souvent que les versions d'un produit, et comme si c'était la fréquence d'emploi d'un élément qui était garant de sa valeur pérenne.

Tellement facile enfin, que la plupart des agents-utilisateurs sont expressément conçus pour tolérer les erreurs HTML les plus fréquentes. Une solution de facilité que certains voient d'un bon oeil par souci d'ouverture et d'universalité, mais qui fait craindre à d'autres que le Web ne s'écroule sur lui-même d'ici quelques années, faute de rigueur et de consistance.

La maîtrise du HTML est si triviale en fait, qu'on n'en finit plus de compter les tutoriels, foires aux questions, forums et autres ressources mises de l'avant pour venir en aide aux débutants et pour en expliquer les subtilités aux codeurs plus expérimentés qui se croyaient parvenus. Inventaire au sein duquel se trouve toute une constellation de blogues où on s'emploie tantôt à dénoncer les mauvais usages du HTML, tantôt à en promouvoir les bonnes pratiques. C'est dire l'état du Web... et le capharnaüm auquel l'illusion de la facilité peut conduire. Si le HTML était facile, on n'aurait besoin d'y revenir ou d'en corriger si souvent l'usage.

Le HTML est à ce point sympathique et facile à maîtriser, que certaines firmes se sont empressées de créer des outils pour en contourner les difficultés et permettre à quiconque de publier rapidement sans avoir à se soucier de la moindre ligne de code, donc sans avoir à l'apprendre. Pareille entreprise n'a de sens, on s'en doute, que parce que le HTML n'est ni simple ni intuitif. Si le HTML est si trivial qu'on le dit, comment expliquer alors que plus de 94 % des sites Web analysés dans le cadre d'une étude sur leur accessibilité ne passent même pas le test du validateur ? En fait de facilité, on peut rêver mieux.

En réalité, le HTML rebute et fait peur. De plus, il faut comprendre l'anglais pour s'y sentir à l'aise. Et ce, que l'on soit japonais, arabe ou inuit. Allez, soyez honnêtes, qui d'entre vous songerait un seul instant à rédiger une lettre ou une carte postale en commençant par dire, en anglais, que le texte sera écrit en français, suivant un alignement de gauche à droite, et que le jeu de caractères utilisé sera l'alphabet latin étendu tel que défini dans la norme ISO 8859-1 ?

Facile, le HTML ? Le petit nombre d'éléments dont il se compose et la simplicité des règles qui en régissent la syntaxe pourraient le laisser croire, mais il n'en est rien. Car l'un et l'autre varient en fonction de la version qu'on utilise.

Tenez. Êtes-vous en HTML 4.01 ? Vous pouvez marquer vos paragraphes avec une balise ouvrante <p> sans avoir à vous soucier de la refermer ensuite, car c'est facultatif. Aucun navigateur ne vous en tiendra rigueur. Aucun validateur non plus. Êtes-vous en XHTML 1.0 ou 1.1 ? Il vous faudra impérativement les refermer, car c'est devenu obligatoire. Bien plus, il vous faudra même penser à écrire différemment la finale des balises pour lesquelles il n'existe pas de balise fermante, tel img, br, hr, link ou meta. Il se peut que les navigateurs ne vous en tiennent pas rigueur si vous passez outre, et que votre page s'affiche tout de même comme prévu, mais le validateur, lui, ne manquera pas de vous signifier la présence d'erreurs dans votre code.

Il y a relativement peu d'éléments en HTML. Mais il faut connaître les possibilités et les limites de chacun pour se servir du lot d'une manière adéquate. Ce qui suppose que l'on connaisse tout l'attirail des attributs dont on peut les affecter, ainsi que le genre de valeur qu'on peut y mettre, mais aussi et surtout de savoir réfléchir. Car une chose est de composer un document, une autre de savoir en marquer la structure avec un jeu de balises approprié.

Un florilège, par exemple, est bien un recueil de citations, n'est-ce pas ? Or il n'y a pas d'élément HTML qui soit spécifiquement conçu pour baliser pareille chose. Normal, puisque le HTML n'entend pas tout prévoir. Il faut donc inventer quelque chose à partir de ce qui existe. En y réfléchissant on pourrait penser que la solution consiste à encadrer chaque citation d'abord avec <q> et ensuite avec <li>, de façon à ce que l'ensemble forme une liste... heu... à moins que ce ne soit mieux de les encadrer d'abord toutes avec <p> et d'encadrer le tout avec <blockquote> ? ...ou chacune avec <p> et <blockquote>, puis l'ensemble avec <div> ? Trivial, n'est-ce pas ?

Le dernier cas est un peu exceptionnel, j'en conviens. N'empêche que rien que pour écrire un document HTML d'une phrase avec une image, un lien hypertexte et un lien courriel, il faut recourir à URI, HTTP et au système d'adressage propre au courriel ; soit trois protocoles différents. Et à cela, il n'y a rien d'exceptionnel. Derrière son apparente simplicité donc, le HTML suppose un ensemble de connaissances et de savoir-faire dont la complexité finit pas passer inaperçue aux habitués, mais qui ne manque pas d'être source de difficultés pour les nouveaux-venus.

Conclusion

En un sens, le HTML n'est pas difficile. Car à bien y penser, la puissance de pénétration intellectuelle requise pour en comprendre les éléments n'a rien d'exceptionnel. Et de ce point de vue, le HTML reste - fort heureusement - relativement facile.

Mais en un autre sens, le HTML se montre difficile. Car dans la pratique, il faut connaître beaucoup de choses pour se tirer d'embarras, éviter les erreurs et se servir de tout cet arsenal d'outils d'une manière adéquate. D'où la relative complexité du HTML.

Difficile, donc, le HTML. Pas au sens d'« inaccessible », mais au sens de « complexe ». Voilà ce que j'ai voulu montrer. Et j'ai voulu le faire essentiellement pour deux raisons.

D'abord pour mettre en évidence la prodigieuse souplesse de ce merveilleux langage. Car on ne s'étonne pas assez, me semble-t-il, de ce que le HTML permet d'intégrer en un seul et même document des choses aussi disparates que du texte, du son, des métadonnées, des animations, des images, des liens, des scripts et des formulaires.

Mais aussi pour bien faire sentir qu'on ne peut pas maîtriser cette merveilleuse boîte à outils sans un minimum de compréhension de ce que l'on fait. Or cette compréhension, il faut l'acquérir. Et cela prend du temps. Aussi est-ce pourquoi je me méfie de tout ce qui a tendance à laisser croire qu'on peut apprendre le HTML en une heure, une journée, voire une semaine. Car à tout prendre, l'art du HTML ne réside pas dans ses outils, mais dans l'usage qu'on en fait. Et c'est l'art qui est difficile.

Normand Lamoureux | 2004.07.09 @ 22:11

Alors, qu'en pensez-vous ?

Voici ce que vous aviez à en dire... vos impressions, recueillies à vif.

2004.07.10 @ 12:51 par Vchahun

Il est assez facile de faire une page web de base, avec des <h*>, des <p>, quelques <b> et 2-3 <i>, et ça suffit pour présenter un texte.
Quand il s'agit d'ajouter de la couleur, on opte pour la solution <font> et puis on rajoute quelques images par-ci par-là ...
Et après, on se rend bien compte que on a beau apprendre toute la liste des autres balises, on ne peut rien faire qui soit beau ! Alors, on plonge dans son éditeur WYSIWYG et on ne se casse pas la tête.
Le HTML est donc difficile dès qu'il s'agit de faire de la mise en forme, mais on peut oublier les balises comme <abbr> si on veut faire un truc simple. Et la tendance du recours aux éditeurs visuels va prendre de l'ampleur dans les prochaines années quand XHTML 2, XForms, XFrames etc vont devenir les langages de référence: pour comprende un truc comme ça, il faut lire un livre - et encore !
Et pourtant, le but du W3 est de simplifier les choses en supprimant des balises, en mettant d'un côté le style et de l'autre le code html ...
A vrai dire, le html 'sale' ne vas sans doute pas laisser place au xhtml avant un grand nombre d'années, mais ça risque de faire des dégats, en particulier chez les jeunes (comme moi) qui n'en ont encore moins rien à faire des standarts !
Finalement, c'est pas si simple, le html :p

Haut retour au début de la page

2004.07.11 @ 01:57 par Laurent Denis

Le premier mythe à déconstruire pour servir le propos sur la nécessité d'un apprentissage du HTML et du souci de son bon usage... aurait été celui selon lequel 'le HTML, ça sert à présenter un document' :

- <abbr>, <acronym>: la différence est une question de présentation orale. Un seul élément suffit donc.

- <em> et <strong>, <b> et <i> : il n'a jamais été question de substituer les uns aux autres, mais de remplacer <b> et <i> (présentatifs) par une règle CSS, et d'utiliser <em> et <strong> uniquement quand il s'agit d'ajouter à la structure du document l'information 'mise en exergue'. Ce dont on peut ne pas avoir besoin (voir la fin de ce commentaire).

- <tt> est un élément de présentation ('éléments de style de police')... Ne pas utiliser, remplacer par CSS.

Hum... il me semble que j'ai déjà gagné en facilité, là.

Autre mythe : la complexité supposé accrue du respect strict des normes XHTML. Il faudrait d'abord bien différencier HTML et XHTML, et replacer chacun dans leur perpective historique :
- HTML4.01 Transitional me permet de conserver l'utilisation du balisage présentatif à titre temporaire, par exemple tant que mon outil de production ne me laisse pas d'autres possibilité.
- HTML4.01 Strict 'épure' (insuffisamment) le HTML4 et m'apporte un gain de facilité avec la disparition des éléments de présentation.
- XHTML1.0 strict reformule HTML4.01 avec la rigueur syntaxique du XML : nouveau gain de facilité avec une syntaxe qui ne me propose plus autant d'options touffues. Exemple, je n'ai plus à me demander si je ferme ou non mes <p> : je ferme **tout**. Là encore, je gagne en facilité.

Les navigateurs sont tolérants, pas les validateurs ? Je sers du XHTML Strict en tant que XML (application/xhtml+xml)... et je m'aperçois immédiatement que mon navigateur (pas IE) ne tolère plus mes erreurs. Je le fais personnellement, et cela me simplifie aussi la vie.

Enfin, qu'est-ce que le 'bon usage' du (X)HTML? Celui qui est valide et qui répond à mes besoins :
- La norme HTML4.01 n'est pas assez détaillée sur <dfn>, en effet, pour des raisons historiques (le 'gel' de cette norme au sein du W3C, alors qu'elle contient encore beaucoup d'erreurs et d'imprécisions). Il en est de même pour <samp> et <var>. En tout état de cause, elle ne fait que dire que ces balises sont valides et ne me donne pas vraiment les moyens de bien en saisir l'utilisation.
- Mais si j'estime ne pas en avoir l'usage... je me contente de ne pas m'en servir, ce qui n'ôte rien à la validité et à la qualité de mon document.

Tiens, c'est amusant : je n'ai pas cessé de me faciliter la vie;) Je ne crois pas que l'art soit si difficile. Je crois plutôt qu'il est particulièrement obscurci par son histoire.

Haut retour au début de la page

2004.07.11 @ 03:46 par ElMoustiko

De part mon expérience personnelle, je peux dire que le Xhtml est assez simple d'apprentissage, en effet le nombre de balise etant assez limité (du moins pour les balises les plus courantes, classiques ou utilisées comme hN, p par exemple) il reste assez simple de créer une page web (assez simple il est vrai) sans pour autant se plonger dans la litterature pas toujours tres passionnante. Par contre pour ce qui est du html disons 'classique' là c'est autre chose, car la multitude de balises de mise en forme (meme si l'on est pas forcé de les utiliser) ajoute en complexité, et selon moi n'aporte finalement pas grand chose à une page simple pour par exemple présenter quelque chose, les couleurs ne sont pas indispensable à la bonne compréhension d'un document, les tailles de textes non plus. Ainsi je remarque que le xhtml est plus 'facile' à apprendre que le html dans la mesure ou toutes les balises de mise en forme sont exclues, nous n'avons donc pas a nous en préoccuper, savoir qu'elles existent peut etre interessant ... lorsque l'on est historien du web ! Ensuite là où ça se corse c'est lorsque l'on veut mettre le tout en forme pour apporter un 'plus', n'etant pas indispensable mais ne gachant rien ! Et c'est là qu'entre la difficulté selon moi, la mise en place des css, pas si difficile (une fois qu'on les connais un peu :) ) mais souvent assez deroutant au depart et pas si evident à utiliser pour un débutant surtout si celui ci utilisait auparavant un editeur du type WYSIWYG (What You See Is What You Get). Puisque j'en suis au editeur WYSIWYG (vade retro satanas ! ), parlons en, certes si l'on ne veut pas connaitre le html et ses possibilité, c'est simple de faire une page web, mais dès que l'on veut approfondir, ça se corse dans la mesure où ce genre d'editeur de page web utilisent un nombre important de balises bien souvent inutiles (les table pour la structure de la page par exemple), et bien pour moi, c'est là et uniquement là que se trouve la difficulté du html, comprendre un code mal formulé !

Voila desolé pour la longueur du roman !
++

Haut retour au début de la page

2004.07.11 @ 06:49 par Normand Lamoureux

> Laurent Denis
J'ai beau me relire, je ne vois nulle part un endroit où j'aurais dit que le XHTML était plus difficile que le HTML. Désolé, Laurent, mais ce n'est pas dans le texte... ni dans le propos du texte.

Dans le passage où il est question de XHTML, tout ce que je dis, c'est que les choses se passent d'une manière différente comparativement au HTML 4.0. Différente. Pas forcément plus difficile.

En un sens, tu as raison de dire que la première chose à laquelle s'en prendre aurait dû être le détournement du HTML pour des fins de présentation et de mise en page (sujet dont je parlerai dans une suite à paraître).

Mais j'y ai réfléchi, et je croyais justifiable de parler du HTML en son état (à savoir complexe), avant de commencer à expliquer pourquoi il est dans cet état. Le constat avant l'explication.

Haut retour au début de la page

2004.07.11 @ 07:16 par Laurent Denis

>Normand, ma laborieuse compréhension de cet article montre, AMHA, qu'on crée de la confusion en soulignant ces différences entre HTML et XHTML (strict) sans en expliquer les raisons, et particulièrement le fait que le XHTML vise à résoudre une partie des difficultés rencontrées en HTML ;)
J'ai donc très sincèrement hâte de lire cette suite!

Haut retour au début de la page

2004.07.12 @ 08:47 par [ Adrien Leygues ]

Salut,

merci pour cet article, HTML est un langage méconnu et sous estimé et cela se ressent sur le prix de vente à la journée, 1pt pour un intégrateur équivaut à 1,5 pt...

Haut retour au début de la page

2004.07.12 @ 08:47 par [ Adrien Leygues ]

pour un développeur...

Haut retour au début de la page

2004.07.12 @ 10:54 par Olivier

Dans le contexte informatique, je trouve que HTML est un format, non pas un langage. En tant que format, c'est plutôt simple comparé à Flash, .doc ou .pdf par exemple., mais plutòt compliqué comparé à .txt. Et c'est la moindre des choses à mon avis qu'un développeur gagne beaucoup plus qu'un intégrateur.

Haut retour au début de la page

2004.07.12 @ 10:59 par [ Adrien Leygues ]

'Après la philosophie XHTML il faut la pratique de l'XHTML.'

Est-ce que moi qui fait une confusion concernant sémantique et xhtml?

Pour moi XHTML amène simplement une normalisation sur l'écriture des balises en concordance avec XML (attributs en minus, guillements, fermeture des balises...) et enlève les attributs de présentation (valign, border...) mais HTML 4 offre déjà toute les possibilité en matière d'écriture sémantique non?

Haut retour au début de la page

2004.07.12 @ 11:01 par [ Adrien Leygues ]

'Et c'est la moindre des choses à mon avis qu'un développeur gagne beaucoup plus qu'un intégrateur.'

Pour quelles raisons?

Haut retour au début de la page

2004.07.12 @ 11:52 par Bobe

'Allez, soyez honnêtes, qui d'entre vous songerait un seul instant à rédiger une lettre ou une carte postale en commençant par dire, en anglais, que le texte sera écrit en français, suivant un alignement de gauche à droite, et que le jeu de caractères utilisé sera l'alphabet latin étendu tel que défini dans la norme ISO 8859-1 ?'

Tu compares un support fixe à un support descriptif, souple et malléable ?
Est ce que ça ne choque que moi ou bien ?

Haut retour au début de la page

2004.07.12 @ 16:49 par Normand Lamoureux

>Adrien
Quoiqu'on en dise, le HTML est effectivement méconnu et sous-estimé. Je suis heureux d'en entendre un autre que moi le dire.

>Olivier
Et si on s'entendait pour dire que le HTML est un langage de balisage, mais pas un langage de programmation?

>Bobe
Je fais effectivement la comparaison dont tu parles. Et si je la fais, c'est pour montrer qu'on ne peut procéder de la même façon dans les deux cas. Où est le problème?

Haut retour au début de la page

2004.07.13 @ 03:53 par [ Adrien Leygues ]

Normand,

d'où t'es venu l'idée de faire ce constat?

Haut retour au début de la page

2004.07.13 @ 07:17 par Normand Lamoureux

> Adrien
Excellente question! C'est au moment où je me suis mis à expliquer comment faire une page Web à ma grand-mère que j'ai réalisé à quel point ce qui me semblait simple et facile était loin d'être évident.

Tient, tant qu'à y être, je serais curieux de savoir combien parmi vous se sont déjà risqués à pareille aventure.

Haut retour au début de la page

2004.07.13 @ 18:15 par Gloom

'...il vous faudra même penser à écrire différemment la finale des balises pour lesquelles il n'existe pas de balise fermante, tel img, br, hr, link ou meta.'

Faux ! On peut très bien fermer ces balises (juste après leurs ouverture): <img src='example.png' width='125' height='125' alt='Exemple'></img> est correcte.

Haut retour au début de la page

2004.07.13 @ 20:58 par Normand Lamoureux

Désolé, Gloom, mais la syntaxe dont tu parles ne valide pas.

De plus, à propos de l'élément IMG, le paragraphe 13.2 de la spécification HTML 4.01 dit explicitement: «Balise ouvrante: obligatoire, balise fermante: interdite.»
(Cf. http://www.la-grange.net/...)

Haut retour au début de la page

2004.07.13 @ 22:21 par Denis

Pour répondre simplement à ta question Normand, je crois qu'on pourrait dire que l'absence quasi-complète de didacticiels sur HTML présentant la technologie dans un contexte privilégiant la sémantique est un indicatif clair que bien expliquer HTML est une chose difficile... :\

Haut retour au début de la page

2004.07.13 @ 23:51 par Laurent Denis

Sans même aborder le pas sémantique qui reste à franchir, une très large partie du Web s'est développée dans une optique purement 'visuelle' et non 'structurante', oubliant que le code s'adressait d'abord à des machines destinées à l'exploiter au profit de l'utilisateur, et non directement à l'internaute et à son navigateur.

Ce n'est qu'en envisageant cette évolution sémantique qu'on a commencé à se rendre compte de cette erreur, qui bloque le Web à l'état de sous-produit multimédia tout aussi pauvre qu'un CD-Rom interactif.

Au passage, nous en avions parlé ailleurs il y a peu Denis et moi-même, mais c'est l'occasion de souligner l'excellence de ce tutoriel réalisé par les élèves de l'ENS (un institut d'enseignement supérieur français): http://www.tuteurs.ens.fr...

ça commence par: 'Le principe de base du HTML est qu'il se préoccupe du contenu et non du rendu visuel.'
j'aime bien cette manière d'attaquer la question :)

Haut retour au début de la page

2004.07.14 @ 00:54 par Laurent Denis

Normand > 'C'est au moment où je me suis mis à expliquer comment faire une page Web à ma grand-mère que j'ai réalisé à quel point ce qui me semblait simple et facile était loin d'être évident. Tient, tant qu'à y être, je serais curieux de savoir combien parmi vous se sont déjà risqués à pareille aventure.'

Je m'y suis risqué entre-autres avec:
- beaucoup de précautions
- des élèves de cours primaire (10-12 ans).

Précision importante dans ce cadre : je ne fais pas partie des gens qui considère béatement que les 'jeunes' maîtrisent spontanément et magiquement mieux les outils informatiques que les adultes. Ils ont simplement moins d'inhibitions que les adultes et n'hésitent pas à 'y aller', voilà tout.

Autre précision: vu le public, mes constats ont forcément quelque-chose d'assez naïf ;)

Premier acquis de ces expériences: il est nécessaire de poser clairement quelques données de base:
- le document Web n'est pas ce qu'on voit dans son navigateur, mais cette fameuse 'source' dont on s'aperçoit immédiatement qu'elle n'a aucun sens dans notre langage.
- en effet, le document Web n'est pas fait pour être lu par un être humain.
- en le créant, nous nous adressons à des machines dans leur langage à elles.
- le rôle de ce langage est d'ajouter des informations qui sont pour nous évidentes (ceci est un titre), mais qu'elles sont trop stupides pour comprendre (d'où la nécessité du <h1>...</h1))
- En faisant cet effort de nous adresser aux machines dans le langage que nous avons créé pour elles, nous leur permettons de travailler à notre service, et de nous retourner un document plus intéressant, c'est à dire avec lequel nous pouvons faire plus de choses.

Quelques autres constats tirés d'approches variées et successives :
- l'approche wysiwyg mène rapidement à la confusion la plus totale. L'élève apprend certes à se servir de l'éditeur, mais pas du langage. Il n'apprend pas à structurer son contenu, ni à maîtriser à son niveau les mécanismes de lien, d'image, etc.
- l'approche 'codons le contenu' en HTML permissif mène au même résultat.
- l'approche 'codons en XHTML strict' limitée pour cette tranche d'âge aux éléments de base du texte permet de travailler des notions de base de l'expression, telles le titrage, le plan du discours, l'incise, l'emphase...

Bref, j'en ai tiré le sentiment qu'un langage de structuration de texte tel qu'XHTML est une grammaire dont la pratique est tout aussi formatrice que celle de la grammaire syntaxique classique. Un meta-langage, amenant à réfléchir sur son usage personnel du langage, dans un cadre dont les contraintes sont formatrices.

Haut retour au début de la page

2004.07.14 @ 01:32 par Laurent Denis

>Normand ' Désolé, Gloom, mais la syntaxe dont tu parles ne valide pas. De plus, à propos de l'élément IMG, le paragraphe 13.2 de la spécification HTML 4.01 dit explicitement: «Balise ouvrante: obligatoire, balise fermante: interdite.» (Cf. http://www.la-grange.net/...)'

C'est un peu plus compliqué que ça ;)
- La syntaxe de Gloom est parfaitement valide... en XML, c'est à dire si la page est servie avec un type mime application application/xhtml+xml. Exemple : http://www.blog-and-blues...

Mais en HTML (lorsque la page est servie avec un type mime text/html), les navigateurs font de drôle de choses avec cette syntaxe. Exemple: http://www.blog-and-blues...

Pourquoi ? Relire la specification XHTML ;)

'C.2 Eléments vides

Inclure un espacement avant le / et >de fin des éléments vides, par exemple <br />, <hr /> et <img src='karen.jpg' alt='Karen' />. Utilisez également une syntaxe minale pour les éléments vides, par exemple <br />, comme syntaxe alternative de <br></br> qui est autorisé par XML, car cela donne des résultats inattendus dans certains agents utilisateurs.'
(Règles de Compatilité HTML, http://www.la-grange.net/...)

Haut retour au début de la page

2004.07.14 @ 01:39 par Laurent Denis

Désolé de rajouter un 4e commentaire, mais j'ai cliqué un peu vite avant d'avoir complété mon texte :
Ci-dessus, la syntaxe de Gloom est effectivement invalide avec une DTD HTML. Les deux exemples que je donne sont du XHTML, l'un traité comme du xml et l'autre comme du HTML... et même dans ce cas, cette syntaxe est à proscrire actuellement.

Haut retour au début de la page

2004.07.14 @ 07:45 par Anne F.

Je dirais que la majorité des difficultés rencontrées en (X)HTML tiennent à un manque de logique. Ouvrir et fermer une balise, imbriquer correctement les éléments, utiliser la balise appropriée à un type de contenu... Fondamentalement, il s'agit simplement d'apprendre quelques règles simples et de les appliquer systématiquement. Ca, ça s'apprend en une heure, à condition d'accepter de ne pas faire tout de suite la page extrêmement complexe dont on rêvait.

Combien de personnes refusent d'en passer par là et préfèrent un éditeur WYSIWYG parce qu'il permet immédiatement d'accéder à un design élaboré ? Et parmi les gens qui s'essaient à coder directement, combien se sentent réellement incapables d'appliquer la logique inhérente à un langage structuré ?

J'ai imbriqué correctement les balises avant de lire que c'était important, parce que ça me paraissait *naturel* et logique de structurer ainsi mes pages ; mais certaines personnes doivent faire un effort de réflexion considérable pour arriver au même résultat. Ca me rappelle les cours de maths au collège : quoi de plus simple que de résoudre une équation : il suffit d'appliquer les règles apprises ; et pourtant, combien de personnes ni bêtes ni feignantes n'y arrivent jamais ?

Alors le (X)HTML facile ou difficile, je crois que c'est essentiellement une question de prédisposition à la logique ou non.

Haut retour au début de la page

2004.07.14 @ 10:56 par ElMoustiko

La logique, ca me parait un peu facile, certe il en faut, certe elle prend une part importante, mais il y a aussi la volonté de bien faire, sur l'un des forums auquel je participe (plus pour longtemps, un peu marre de la mentalité, voir ce qui va suivre), j'ai reussi tant bien que mal a faire creer une section sur les standards web, ou ceux qui le peuvent aident les autres membres en ce qui concerne le xhtml, les css, et autres regles de sémantique web. Et bien c'est un bide, la mentalité de la plupart des membres (moyenne d'age selon moi autour de 16-17 ans) c'est de faire un 'Zolie Site' en 2 temps 3 mouvement avec leur outil favoris, dreamweaver... peu un porte de la maniere tant que le resultat fait 'style' avec plein de flash partout... J'ai beau expliquer que leur methode n'est pas viable, ni meme correcte, rien n'y fait ils se contre fichent de la bonne facon de creer des pages web, les arguments vont du 'on peut rien faire de creatif avec les standards, c'est tout carré' au 'j'ai pas que ca a faire de tapoter mes balises a la main' en passant par des 'les autres sites le font bien, pourquoi pas moi'... Finalement je pense que la méconnaissance du langage html et de ce qui tourne autour est beaucoup du a un manque de volonté de bien faire flagrant, dynamisé par des outils, certes pratique, mais de facilité comme les editeurs WYSIWYG. Il faudrait commencer par former les 'webmasters' avant de savoir si le html est vraiment si difficile.

Haut retour au début de la page

2004.07.14 @ 11:51 par Xethorn

J'ai adoré le texte, j'ai aussi adoré les commentaires :) Vous cherchez vraiment trop loin, pourquoi ne pas simplement prendre comme exemple la langue d'un pays. Vous avez tourné pour la plupart autour de ce sujet, mais comparez :

Pour définir un texte en gras, on le définit par deux balises <strong> ou <b>, à dire vrai peu-importe puisque l'on peut même utilisé <span> avec une propriété CSS. Au final, nous aurons : <strong>Votre texte</strong>, les balises définissent donc le texte en gras. Elles définissent.

Pour définir un objet comme possédé, on utilise des articles : 'mon', 'ma', 'mes' ... on les emplois en fonction des resultats que l'on souhaitent. Mais dans tout les cas, nous aurons le même resultat : article possessif suivit du nom de l'objet possédé.

Bon, maintenant, revenons à l'article : il dit que le HTML est facile et que le HTML est difficile. IL est facile pour sa structure mais est difficile par son utilisation. Pourquoi ne pas avoir parlé de philosophie HTML ?

Par ailleurs, nous avons toujours des petits clans qui s'allignent comme des têtes d'épingles, on retient dans plusieurs cas : ceux qui utilisent des logiciels WYSIWYG (prononcé Ouizi Ouigue)pour faire l'interface graphique en même temps que le contenu, et les autres qui s'amusent à lire les spécifications ou qui demandent de l'aide ou apprenent les langages normalisés en autodidactes (les techniques sont nombreuses : analyses de codes sources ...).

Voilà, j'en arrive à un petit commmentaire, qui au final est un peu inutile, je tourne une fois de plus autour du pot. J'en fini donc sur : le html est un langage compréhensible par la majorité des gens. Il faut avoir une capacité d'abstraction suffisante (bien qu'elle n'est pas très énorme).

C'est pourquoi, dire que le html est un langage difficile ou simple est impossible.

<mode comique>Il existe, c'est déjà une bonne chose que l'on en ai la preuve :)</mode> après, il faut en comprendre le sens ;)

Bon Zen.

Haut retour au début de la page

2004.07.14 @ 13:01 par Normand Lamoureux

Après les préoccupations historiques de Laurent Denis, voilà que Anne F. et ElMoustiko parlent de logique et de philosophie HTML. Non mais, dites-donc, vous vous amusez à deviner les prochains développements de cet article ou quoi? ;-)

Et en passant, Xethorn, merci pour l'appréciation. Ça fait chaud au coeur!

Haut retour au début de la page

2004.07.14 @ 14:02 par Olivier

Je pense pas qu'on doive comparer HTML à la 'langue d'un pays', mais plutôt à la façon de publier un texte dans la langue d'un pays. C'est une façon de présenter et d'échanger des informations, un format, pas une langue. Mais la comparaison peut être amusante : doit-on davantage s'offusquer des fautes de français (qui abondent sur cybercodeur.net) ou des fautes d'HTML ? Le cerveau s'accomode des fautes de français, un peu comme les navigateurs des fautes d'HTML...

Haut retour au début de la page

2004.07.14 @ 14:36 par Anne F.

> ElMoustiko : 'J'ai beau expliquer que leur methode n'est pas viable, ni meme correcte, rien n'y fait ils se contre fichent de la bonne facon de creer des pages web'

Je compatis... mais effectivement, dans ce cas, mieux vaut laisser tomber. On n'apprendra jamais rien à quelqu'un qui ne veut pas apprendre. Il n'est de pire sourd que celui qui ne veut pas entendre...

Haut retour au début de la page

2004.07.14 @ 14:43 par Laurent Denis

Xethorn > 'Pour définir un texte en gras, on le définit par deux balises <strong> ou <b>, à dire vrai peu-importe puisque l'on peut même utilisé <span> avec une propriété CSS.'

L'équivalent grammatical que tu donnes ne correspond pas à ces alternatives: 'mon', 'ma', 'mes' ont tous la même **fonction** (pronom possessif...).

ce n'est pas le cas de <strong>, <b> et <span>+CSS : les deux derniers ont une fonction strictement présentative à l'écran et à l'impression, le premier a une fonction sémantique.

L'équivalent serait plutôt de dire que 'le' et 'mon' ont la même fonction. Ce qui s'avère immédiatement faux ;)

Haut retour au début de la page

2004.07.14 @ 14:46 par Denis

Anne F. >

C'est certain... en fait, il y a suffisamment de gens ayant soif d'apprendre pour ne pas user notre salive pour ceux qui n'entendent rien à rien. De toutes façons, à force de trainer de plus en plus derrière, ils finiront (peut-être) par comprendre l'intérêt de voir le choses différemment... :)

Haut retour au début de la page

2004.07.14 @ 16:05 par ElMoustiko

>Olivier : 'Mais la comparaison peut être amusante : doit-on davantage s'offusquer des fautes de français (qui abondent sur cybercodeur.net) ou des fautes d'HTML ?'

J'ai bien aimé cette phrase... c'est vrai qu'avant de se preoccuper de faire du html 'gramaticalement' correct, nous pourrions aussi bien nous occuper d'ecrire et de s'exprimer correctement ... (moi le premier, vous vous en rendez compte) et en tapant ces qeulques lignes (bourrées de fautes), je me rend compte du pourquoi du comment ! J'ecris un peu a la va vite laissant mes doigts pianoter un peu de facon automatique pour taper du texte, et les touches accentuées etant situées plus haut que les autres, je ne les tapes qu'une fois sur 3 (dans le meilleur des cas)... Et bien c'est pareil pour le html, les gens qui je critiquai tout a l'heure qui utilisent dreamweaver & cie a tout va, et bien j'en fais partie... en ce qui concerne le francais, et c'est bien plus grave. Voilà qui me remet à ma place, je n'ai plus qu'à coder mes pages n'importe comment ! Les automatismes sont ils trop enracinés pour que je puisse réapprendre à parler et à écrire français correctement ? En est-il de même pour les pseudo-webmestres qui utilisent les éditeurs WYSIWYG pour créer leurs pages web ? Voilà qui serait une bonne étude comportementale pour les comportementalistes présents parmi nous s'il y en a.

Haut retour au début de la page

2004.07.14 @ 16:09 par Denis

Olivier... Ai-je besoin de t'expliquer pourquoi tu es blacklisté sur certains sites comme Constellationw3 ou tu es assez grand pour en comprendre les raisons tout seul ? :(

Haut retour au début de la page

2004.07.15 @ 02:15 par Xethorn

> Laurent
'ce n'est pas le cas de <strong>, <b> et <span>+CSS : les deux derniers ont une fonction strictement présentative à l'écran et à l'impression, le premier a une fonction sémantique.'
Non, absolument pas :) Là tu fais des erreurs grammaticales et tu n'obtiens absolument pas le resultat voulu. Desactive le CSS tu n'auras qu'un texte ordinaire. C'est pareil avec le 'La' et le 'mon'. Ce sont tout les deux des pronoms dont les fonctions sont totalement différentes. Il en est de même en HTML. Je m'explique :

On peut diviser en deux catégories les balises cités : celles qui défissent le texte comme gras, directement dans le code html : <strong> & <b> et ceux qui servent à donner une apparence graphique : <span>.

Cependant, je crois qu'il ne faut pas mélanger les notions de CSS avec l'HTML, sinon, nous courront à la catastrophe. Parce que l'HTML peut-être lu par un lecteur d'écran, mais le CSS également (par les outils : voice) - dans ce cas, autant parler de javascript ...

> Normand Lamoureux
En fait, ton texte est bien, il comprend de nombreux exemples, et les commentaires lui ajoute une note de verité : on se casse la tête sur un sujet qui est l'HTML :) On cherche des arguments pour dire qu'est ce qui fait que l'HTML est facile, et qu'est ce qui fait que l'HTML est compliqué.

Ma fois, après la lecture de tout les commentaires, on peut déjà en conclure que écrire de l'HTML est facile mais que choisir la bonne balise parmis un ensemble de balise peut s'averer compliqué : le HTML est trop diversifié.

En somme, le travail du W3C est loin d'être inutile ;)
// long commentaire pour pas grand chose finalement//

Ps : certains font des sites avec des éditeurs WYSIWIG uniquement pour avoir la colorisation syntaxique : pour voir s'ils font des erreurs quelque part. Je crois même qu'actuellement un editeur de site web permet de faire des sites conformes (Dreamweaver ?). Mais bon, il faut aussi arrêter de s'attaquer à ses webmaster qui la plupart du temps ne font que lire des articles présents dans des journaux qui expliquent comment faire son site avec FrontPage ... donc je ne pense pas qu'il soit nécessaire de polémiquer sur les sites non conformes ... de toute évidence, TOUT les sites du net, sans exception, on surement une faute quelque part ...

Ps2 : au final, je plains les participants du W3C ... ils ont du se poser ses questions bien avant nous :)

Haut retour au début de la page

2004.07.15 @ 03:13 par [ Adrien Leygues ]

Salut,

'Ps2 : au final, je plains les participants du W3C ... ils ont du se poser ses questions bien avant nous :)'

Oui, et justement ce que je trouve difficile en ce moment c'est de devoir expliquer, 'aux ptits jeunes' que celà a toujours été prévu comme ça finalement, et que prendre en compte les bonnes règles de codage n'est pas un plus, ni un moins, mais fait partie des fonctionnements de base. D'où l'importance d'une bonne éducation :)

Haut retour au début de la page

2004.07.15 @ 06:28 par Laurent Denis

> Xethorn
Bon, plutôt que de divaguer, lisons simplement la norme ;)
'Les éléments de phrase ajoutent une information structurelle à des portions du texte... STRONG :indique une mise en exergue plus forte... '
(http://www.la-grange.net/...)

'La restitution des éléments de style de police dépend de l'agent utilisateur... B : restitué sous la forme d'un texte en caractères gras.'
(http://www.la-grange.net/...)

Les deux éléments sont susceptibles d'être restitué par du gras, mais dans le cas de <strong>, ce n'est pas spécifiquement son rôle.

Amusante démonstration d'une des difficultés du HTML : il y a un texte normatif à lire et à connaître :)

Haut retour au début de la page

2004.07.15 @ 10:35 par Olivier

Quelque chose peut être facile, mais il peut être difficile de faire quelque chose de bien avec. Exemple : VisualBasic ;-) Autre exemple : HTML ?

Haut retour au début de la page

2004.07.15 @ 11:05 par Olivier

Le mieux d'après moi, c'est d'avoir quelque chose de difficile, et qui permette de faire facilement des choses bien quand on le maitrise. Le contraire de la philosophie Microsoft.

Haut retour au début de la page

2004.07.15 @ 12:37 par Olivier

Note à Normand : la page d'accueil www.paginus.com a un petit problème, on y voit les coordonnées d'un certain Claude Gendron de Ste-Marthe-sur-le-Lac, des liens et une image qui ne fonctionnent pas. Probablement une erreur de drag & drop de index.html avec ftp dans le mauvais site. Ca m'est arrivé aussi une fois.

Haut retour au début de la page

2004.07.15 @ 15:05 par Normand Lamoureux

Au sujet des coordonnées visibles, je vais voir à ça de ce pas. Merci!

Haut retour au début de la page

2004.07.15 @ 15:53 par Olivier

Note à Bleizig : il y a un petit bug sur la fonction qui fabrique un lien http dans les commentaires, ça prend un espace de trop au début. Exemple : www.itunes.com

Haut retour au début de la page

2004.07.22 @ 09:03 par arnaud

Je pensais connaitre pas trop mal le HTML, mais en parcourant ce site, aslacreations et d'autres j'ai vraiment honte des sites que j'ai pu faire.

Depuis quelques temps j'essaye de me mettre à la norme, faire mes sites en utilisant le mieux possibles les meilleures balises tout en continuant à en découvrir des nouvelles balises du genre <dd> <dt> sans encore en comprendre l'utilité.

Je faisais partie des gens qui sous-estimaient le HTML.
Par contre je n'ai jamais utilisé d'éditeur html, je n'y ai jamais rien compris et je m'y perds trop facilement.

@Xethorn: si les WYSIWIG sont les éditeurs comme dreamveaver, frontpage, cutehtml, etc... Sache que de nombreux éditeurs de texte ont aussi la coloration syntaxique comme UltraEdit par exemple et plein d'autres.

Haut retour au début de la page

2004.07.23 @ 04:36 par Xethorn

Je suis au courant :) Pour ma part, j'utilise kwrite qui semble utiliser la colorisation syntaxique provenant de Quanta+.

Les éditeurs WYSIWIG qui sont (celon moi à proscrire) sont ceux qui permettent la modification de la page directement par l'affichage et non le code source. D'ailleurs, mettez simplement dans google 'Document sans nom', vous serez surpris du nombre de personnes qui ne savent pas utiliser ses logiciels :)

Haut retour au début de la page

2004.07.25 @ 19:41 par termitor

hum editeur de code html correct pour etre fait de plusieurs onglet avec les divers aspect du html !
genre :
* source (html colorisé)
* semantique ( mise en forme structurelle pour bien voir ce que l'on choisit comme 'Sémantique' )
* css1 ( ca veut dire la on definie fonte - taille - couleur ... , mais sans les modele de boite css2 )
* css2 avec des aides importante pour la 'mise en boites', mais c clairement la partie la plus complexe du couple html/css
*rendu final

et si l'html integre correctement Xframe on pourrais aller beaucoup plus loin avec un systeme de composition de site par morceau ! et une interface d'integration finale ! ca serais quand meme pas mal mieux !

Haut retour au début de la page

2004.07.30 @ 03:25 par zerchove

Laurent Denis, vous dites :

<quote>
<abbr>, <acronym>: la différence est une question de présentation orale. Un seul élément suffit donc.
</quote>

Je ne suis pas d'accord. Sémantiquement ce sont deux choses différentes non ? une abbréviation et un acronyme. On aurait meme pu avoir 'sigle' non ?

Quelle importance qu'il y ait un peu 'trop' de balises ? C'est quelque chose qui me parait au contraire très important, cette richesse de balises, pour faire comprendre aux gens le 'web sémantique', enfin la séparation fond/forme quoi.

Enfin bon... ptet que j'ai pas compris votre propos...

Haut retour au début de la page

2004.07.31 @ 06:19 par Normand Lamoureux

Je suis d'accord avec le point de vue de zerchove.

Par définition, un acronyme est une abréviation syllabiquement prononcée (alors que les autres abréviations sont soit épelées, comme W3C ou HTML, soit à remplacer par le mot complet qu'elles abrègent, comme M. ou Mme).

Puisque c'est par définition, on touche à la nature des choses. Le fait qu'un acronyme soit prononcé n'a donc rien d'accessoire ou de *présentationnel*. C'est pourquoi je milite en faveur du maintien de l'élément acronym... et de son usage.

Haut retour au début de la page

2004.08.02 @ 01:43 par Laurent Denis

Je retente ma réponse, puisqu'hier les deux précédentes tentatives ont échoué à poster ce commentaire (Bleizig !????) ;)

Remplaçons 'présentation' par 'restitution', puisque le premier terme semble induire une nuance péjorative signifiant 'c'est accessoire'.

Serons-nous d'accord pour dire que la différence essentielle entre abbr et acronym réside dans leur **restitution** orale ?

Dans ce cas, CSS aural est justement conçu pour gérer ce type de données, en les extrayant du document (X)HTML. Ce qui permet de ramener le vocabulaire de celui-ci à un seul élément.

Plus important : dans quels cas, hors la restitution orale, a-t-on vraiment besoin de différencier sémantiquement abréviations et acronymes avec autre chose que <abbr class='normal'> et <abbr class='acronym'> par exemple ? Quels scénarios de traitement de ceux-ci justifieraient un tel investissement ?

Haut retour au début de la page

2004.08.03 @ 10:28 par Normand Lamoureux

<blockquote><p>Serons-nous d'accord pour dire que la différence essentielle entre abbr et acronym réside dans leur **restitution** orale ?</p></blockquote>

Non, Laurent, mon point est que la prononciation syllabique d'une abréviation en fait automatiquement un acronyme. Et ce, *indépendamment* de son éventuelle restitution orale.

<blockquote><p>Dans quels cas, hors la restitution orale, a-t-on vraiment besoin de différencier sémantiquement abréviations et acronymes [...] ? Quels scénarios de traitement de ceux-ci justifieraient un tel investissement ?</blockquote></p>

À ces deux questions je réponds: aucun. Puisque la différence essentielle entre une abréviation et un acronyme réside justement dans le fait de devoir être syllabiquement prononcé pour l'un et pas pour l'autre.

Et à la question de savoir pourquoi on aurait besoin de différencier sémantiquement une abréviation d'un acronyme <q>avec autre chose que <abbr class='normal'> et <abbr class='acronym'></q>, je répondrai laconiquement: pour la même raison qu'on devrait baliser un titre de niveau 1 avec <h1> plutôt qu'avec <p class='titre-1'>.

Haut retour au début de la page

2004.08.03 @ 19:26 par Olivier

<blockquote><p>Dans quels cas, hors la restitution orale, a-t-on vraiment besoin de différencier sémantiquement abréviations et acronymes [...] ? Quels scénarios de traitement de ceux-ci justifieraient un tel investissement ?</blockquote></p>

Attention à l'imbrication des tags. Ca marche certes sur tous les browsers mais les puristes vont bondir.

Plus sérieusement, vaut mieux <blockquote><p>...</p></blockquote> ou <p><blockquote>...</blockquote></p>. L'un est-il meilleur sémantiquement ?

Haut retour au début de la page

2004.08.03 @ 19:35 par Normand Lamoureux

Tu as tout à fait raison, Olivier. J'ai fait un copié-collé trop rapide et j'ai simplement ajouté la barre oblique... en oubliant d'inverser les balises.

Honte à moi.

Haut retour au début de la page

2004.08.03 @ 22:22 par Laurent Denis

@Normand : Désolé, mais il y a là une logique qui m'échappe : 'Non, Laurent, mon point est que la prononciation syllabique d'une abréviation en fait automatiquement un acronyme. Et ce, *indépendamment* de son éventuelle restitution orale.' ;)

@Olivier : aucun des deux n'y meilleur sémantiquement, mais l'un des deux est totalement invalide.

Haut retour au début de la page

2004.08.04 @ 06:09 par Normand Lamoureux

@ Laurent
Je tente l'explication suivante.

Grammaticalement parlant, un acronyme est une abréviation qui se prononce comme un mot.

L'éventuelle restitution d'un mot dans un navigateur vocal ne change pas la nature de ce mot.

Un acronyme reste donc un acronyme. Qu'il soit mécaniquement restitué ou pas.

Haut retour au début de la page

2005.09.04 @ 13:28 par lol

<cool ton article></cool ton article>

Haut retour au début de la page

2005.10.09 @ 11:18 par aba

Le HTML est un langage de description, ni simple ni difficile à utiliser. C'est une boite à outil avec laquelle ont peut entreprendre des réalisations + ou - complexe et pour lesquelles la maitrise du concepteur donnera toute sa dimension.

Haut retour au début de la page

2005.10.22 @ 08:33 par HPz

Je viens de lire ce très long commentaire concernant l'HTML.
Moi, ce que j'aimerais bien trouvé, c'est un didacticiel qui m'expliquerait par le détail comment les 'lignes' et 'balises' sont traitées au fur et à mesure de leurs lectures par ce que j'appellerais 'l'interpréteur'. Lit-t-il dans un premier temps la totalité de la page en construisant des 'tables indexées' avec les différente 'éléments', 'id', 'name', etc... ? Si c'est le cas qu'en fait-il ensuite?
Exemple: où, quand et comment, une fonction onLoad() est-elle exécutée?
Exemple: où, quand et comment une fonction window.onload() est-elle exécutée?
Il n'était pas difficile de trouver comment fonctionnait 'l'assembleur' et, en fait ici, je suis en train de faire la même démarche.

Haut retour au début de la page

Les commentaires et trackbacks sont désormais fermés. Pour toute remarque, vous pouvez toujours nous contacter.

Pisteur (Trackback)

Carnet: Déconstruction trop hâtive d'un mythe (la facilité du HTML)
Extrait: Le HTML est un langage destiné à simplifier une problématiqu...
Weblog: Blog &amp; Blues
Traqué le: 2004.07.10 @ 03:11
Carnet: 10/07/2004 - Chinoiseries HTML
Extrait: Tellement facile, qu'on rencontre encore des développeurs pr...
Weblog: Embruns &gt; Journal de bord
Traqué le: 2004.07.10 @ 01:24