5568 sujets

Sémantique web et HTML

Pages :
Bonjour Smiley langue

Je me suis mis depuis peu de temps à la conception de pages web en xHTML pour ne pas utiliser les tableaux pour la mise en page etc... mais est ce qu'il faut vraiment les utiliser UNIQUEMENT pour les données tabulaires et de stats ? je veux dire par exemple si je me met à coder un forum, est ce que je dois imbriquer des div ou l'utilisation d'un tableau est tout de même correct... En gros c'est pas de tableaux du TOUT ou pas de tableaux pour la mise en page globale du site ?

merci d'avance Smiley smile Smiley biggol
Administrateur
Bonjour,

phedio (ce forum (c) dew) utilise un tableau pour ce qui représente des données tabulaires (ça sort tout droit d'une base de données d'ailleurs)
auteur date heure éditer
avatar TEXTE
pm mail www
auteur date heure éditer
avatar TEXTE
pm mail www
auteur date heure éditer
avatar TEXTE
pm mail www
auteur date heure éditer
avatar TEXTE
pm mail www
...

mais pas pour le menu, le bas de page ou le fil d'Ariane ...

Par contre pour un forum tel que Vanilla, il y avait des div jusqu'à maintenant (pas très riche sémantiquement) et quelque chose de mieux pour la v1.0 qui approche, sans tableau. Les données sont tout autant tabulaires mais leur simplicité (pas de fioritures, pas de jj/mm/aaaa hh:mm:ss par exemple) fait qu'une autre représentation convient tout aussi bien.
Modifié par Felipe (02 Mar 2006 - 17:28)
Je trouve que les listes de définition vont très bien aussi pour cet usage... genre :


<dl>
<dt>Auteur - Date - éditer/citer/...</dt>
<dd>Texte du post</dd>
...
</dl>
QuentinC a écrit :
Je trouve que les listes de définition vont très bien aussi pour cet usage... genre :


<dl>
<dt>Auteur - Date - éditer/citer/...</dt>
<dd>Texte du post</dd>
...
</dl>


Je ne suis pas du tout d'accord. Le texte d'un post n'est pas, à mon avis, une définition de Auteur-Date-éditer/citer.

Une liste de définitions est une liste de définitions, ce n'est pas parce que son rendu visuel par défaut convient que c'est une bonne raison de la choisir.
Palleas a écrit :
En gros c'est pas de tableaux du TOUT ou pas de tableaux pour la mise en page globale du site ?

Il n'y a pas de règle absolut, mais de manière général, si ton tableau à pour but de donner une informations sur la nature de tes données, il est justifié. Si ton tableau n'a pour but que de gérer une mise en forme, c'est qu'il est possible de s'en passer.

La seul règle vraiment valable, c'est la séparation fond et forme : Si le tableau n'est la que pour la forme, il est inutile, sinon il est justifié.


Smiley smile
Bonjour,

Si je peux risquer le bout du petit doigt entre le marteau et l'enclume... ? Smiley cligne

Il me semble qu'il a évidemment forum et forum. Que le problème majeur est plutôt de trouver la structure qui rendra le plus "maniable" possible le choix de fonctionnalités précisément retenu pour le forum concerné. Un forum minaliste pourra peut-être se trouver plus utilisable (dans les outils d'aides notament) sans tableau. Il ne souffrira pas non plus (ni pour l'accessibilité ni pour l'utilisabilité) d'un tableau bien géré.

A l'autre bout du problème, malgré leur complexité, les tableaux bien utilisés conviennent très bien aux forums à l'interface plus "lourd". Les quelques essais de forums usine-à-gaz mais sans tableau que j'ai vu étaient tous catastrophiques dans un lecteur d'écran, et nettement en dessous des forums classiques dans des navigateurs textes, en termes d'utilisabilité.

Il ne faut pas oublier que les tableaux sont à la fois l'un des problèmes les plus lourds pour l'accessibilité, et l'un des domaines dans lesquels le développement des outils d'aide a été le plus poussé Smiley cligne

Pour la liste de définition, maintenant, je butte personnellement toujours sur ce problème : l'absence de titrage (pas de <hn><dt>...</dt></hn> possible), qui prive d'un mécanisme de navigation et de synthèse du contenu largement répandu et très efficace. C'est ce qui me semble plus important que de tenter de déterminer ce que seraient supposées faire les listes de définition qui de toutes façons sont un maillon faible des structures HTML...

Bon, je vais mettre un pansement préventif Smiley cligne
Modifié par Laurent Denis (03 Mar 2006 - 10:21)
Nan paske en fait j'ai peur que ce soit trop chaud pour moi de faire un forum qu'avec des div :s quoique nan en fait... mais ca fait plein de blocs imbrqués... Smiley eek
Ahem. Un autre critère de choix d'utilisation de tableaux (encore une fois avec attention sur leur accessibilité, etc.) est justement le temps passé à réaliser une solution CSS sans tableau qui soit fiable et de même niveau d'utilisabilité...

Là, on va dire "tablô". Et découvrir qu'on peut faire des tableaux accessibles Smiley cligne
Jep a écrit :
La seule règle vraiment valable, c'est la séparation fond et forme : Si le tableau n'est la que pour la forme, il est inutile, sinon il est justifié. Smiley smile


Comme le sait tout étudiant en littérature (salut à ceux qui passeront par là !), la forme, c'est aussi un contenu Smiley cligne

Tout ça pour dire que l'opposition technique entre forme et contenu, aussi pratique soit-elle (et nécessaire, en termes d'accessibilité), est toute relative.
Modifié par mpop (03 Mar 2006 - 11:37)
Bah, non.

Parce que la séparation contenu présentation n'a rien de philosophique ou de littéraire dans le cas qui nous occupe. Ces't un bête problème mécanique : quoi faire pour obtenir quel affichage ou quelle lecture.

Une chose qui m'échappe souvent (ne m'en veuillez pas) : je n'ai jamais compris cette obstination fréquente à ignorer le fait qu'on parlait d'un média bien précis, de sa technique, et non de la littérature ou de l'existence en général. Et de problèmes beaucoup plus terre à terre que les exercices de philos du bac. Bref, la forme et le contenu en littérature, c'est vrai, c'est essentiel, c'est intéressant, mais n'est-ce pas un peu hors sujet ? Smiley cligne

Dans le même ordre d'idée, il y a la tentation d'empoigner son Larousse ou son Petit Robert pour définir sémantiquement les <abbr> et les <acronym>, de relire Platon pour savoir à parti de combien d'items commence une liste, ou de demander une définition opérationnelle de l'élément cite en invoquant les coutumes typograhiques... Inutile de prendre son dictionnaire "culturel" pour répondre à une question de convention technique, ce n'est pas là qu'est la réponse utile.

<edit>Tiens, au fait: la séparation de la structure et de la présentation en HTML n'a effectivement rien d'évident. Mais là, il ne s'agit toujours pas de philosophie, mais simplement de l'histoire (courte et récente) de ce format, toute entière ancrée dans un media visuel uniquement, puis forcé via XHTML1.0 à produire des contenus réutilisables indépendament du media. De simples contingences historiques... C'est parfois très terre à terre, ça, l'histoire d'un format technique Smiley cligne
</>
Modifié par Laurent Denis (03 Mar 2006 - 12:33)
Laurent Denis a écrit :
Bah, non.

Parce que la séparation contenu présentation n'a rien de philosophique ou de littéraire dans le cas qui nous occupe. Ces't un bête problème mécanique : quoi faire pour obtenir quel affichage ou quelle lecture.

Une chose qui m'échappe souvent (ne m'en veuillez pas) : je n'ai jamais compris cette obstination fréquente à ignorer le fait qu'on parlait d'un média bien précis, de sa technique, et non de la littérature ou de l'existence en général. Et de problèmes beaucoup plus terre à terre que les exercices de philos du bac. Bref, la forme et le contenu en littérature, c'est vrai, c'est essentiel, c'est intéressant, mais n'est-ce pas un peu hors sujet ? Smiley cligne

Si, d'ailleurs c'était carrément fait exprès Smiley lol

Je précise que je me suis formé aux technologies web (enfin juste une partie) directement avec XHTML et CSS, et que la première fois que j'ai lu dans un tutoriel « Nous allons séparer dans deux fichiers différents le contenu et la présentation », je me suis dit : « Bon sang mais c'est bien sûr ! »

Il reste, sans partir dans une discussion philosophique pas forcément pertinente, que (X)HTML est très pauvre d'un point de vue sémantique. Certes, on pourra dire qu'il est "épuré" ou "généraliste", mais le peu d'éléments disponibles oblige parfois à des contorsions assez pénible. Pour ma part, je n'ai jamais trouvé comment marquer sémantiquement le titre d'une œuvre ou d'une référence bibliographique. Après avoir relu trois fois les specs et malgré ma relative maîtrise de l'anglais, je n'ai toujours pas compris si cite s'appliquer à une citation (ça me semble étrange, on a déjà q et blockquote !) ou à la source d'une citation, ou à autre chose encore. Bah...

Pour revenir à quelque chose de plus proche de la demande de départ, on peut souligner le fait que "données tabulaires" peut avoir une définition fluctuante. Une donnée tabulaire est-elle une donnée de type technique, scientifique, statistique, ou bien plutôt toute donnée qui prend sens grâce à une relation horizontale ET une relation verticale ?

Un exemple que j'aime bien, c'est celui des formulaires avec éléments input et label associés. On peut bien entendu faire une série de paragraphe, ou même une liste non ordonnée (pourquoi pas ?), mais j'aime bien l'utilisation du tableau simple à deux colonnes, une colonne pour les label et une autre pour les champs de saisie. On a bien une classification verticale par type d'objet, et un rapport direct entre les objets d'une même ligne. Pour le coup, un tableau me semble aussi pertinent (si ce n'est plus) dans ce cas qu'une série de paragraphes. Et on gagne un avantage techniquer pour la réalisation d'une mise en page avec alignement des champs de saisie.
On pourra d'ailleurs rappeler que la motivation pour obtenir cet alignement n'est pas forcément 100% esthétique, mais aussi, partiellement, sémantique : l'alignement permet une reconnaissance bien plus rapide du "statut" différencié des éléments (information sur le champ de saisie d'une part, et champ de saisie lui-même d'autre part).

D'ailleurs, si l'on voulait à tout prix aligner ces champs de saisie entre eux, n'était-ce pas aussi parce que l'on voulait obtenir cette identification rapide. C'est à dire : parce que l'on voulait transmettre, via une présentation visuelle, une information ? Arrêtez-moi si je me trompe, mais on touche au cœur de la sémantique, là Smiley cligne
Modifié par mpop (03 Mar 2006 - 23:19)
Laurent Denis a écrit :
Mais là, il ne s'agit toujours pas de philosophie, mais simplement de l'histoire (courte et récente) de ce format, toute entière ancrée dans un media visuel uniquement, puis forcé via XHTML1.0 à produire des contenus réutilisables indépendament du media. De simples contingences historiques... C'est parfois très terre à terre, ça, l'histoire d'un format technique


<humour>
Enfin un vrai troll avec des racines profondes et anciennes !

La vieille Europe et ses considérations intellectualistes, idéalistes et philosophiques contre le monde anglo-saxon, et son illustre et magnifique rejeton étatsunien, avec son point de vue empirique, pragmatique et au passage tout autant philosophique.

miam miam
</humour>
Je me rend compte que lorsque je parle de double relation logique (que je qualifie de verticale et d'horizontale par analogie avec la présentation classique d'un tableau), on rejoint la proposition de QuentinC, que je me permet d'appliquer à mon exemple :

<dl>
	<dt><label /></dt>
	<dd><input /></dd>

	<dt><label /></dt>
	<dd><input /></dd>

	<dt><label /></dt>
	<dd><input /></dd>
</dl>

On retrouve :
1 – une relation "horizontale", qui lie plusieurs objets ayant un lien direct dans un couple dt + dd ;
2 – une relation "verticale", qui groupe des objets en fonction de leur type.

Différences :
1 – ici, la relation "verticale" est inférée par l'utilisation de balises spécifiques à chaque type d'objet, tandis qu'avec un tableau c'est la place de l'objet par rapport aux autres objets qui crée l'association de type ;
2 – un tableau est plus neutre, car il ne qualifie par le lien logique entre objets d'une même ligne, mais se contente de les associer... tandis que le couple dt + dd qualifie la relation entre les deux objets, en précisant le type (ou le statut) de chaque objet.

Un tableau est donc plus neutre, du moins dans la définition que j'en donne. Si les implications sémantiques d'une liste de définition ne sont pas adaptées au contenu que l'on veut afficher dans chaque "objet", mieux vaut utiliser un tableau.

Par contre, la définition du tableau que j'utilise n'est pas adaptable aux forums dont chaque message s'étend sur plus d'une ligne de tableau. Mais à la rigueur, on s'en fout. Je me suis bien amusé à développer un modèle sémantique du tableau, mais ce n'est pas comme si c'était particulièrement important non plus Smiley biggrin

Juste une dernière pour Laurent Denis :
L'opposition problème technique / réflexion philosophie c'est bien joli, mais c'est juste un poil réducteur. Quand le problème technique en question n'est pas purement "mathématique" mais touche au codage visuel (ici, spatial) d'une information pour en permettre, faciliter ou accélérer la compréhension – en référence à certains codes visuels d'une culture –, il me semble légitime de s'interroger sur le "sens" des objets utilisés :
- sont-ils porteurs d'une qualification, via un balisage spécifique ?
- cette qualification est-elle adaptée à l'information que l'on veut communiquer ?

Ensuite, comme personne ne lit le code directement, il faut s'interroger sur les agents médiateurs (graphiques ou non) et la manière dont ils rendent (ou pas), accentuent ou atténuent, ou encore déforment la qualification initialement souhaitée.
Mais je ne vois pas pourquoi cette indispensable réflexion pragmatique interdirait toute réflexion en amont.
Modifié par mpop (03 Mar 2006 - 23:20)
Bonsoir,

a écrit :
L'opposition problème technique / réflexion philosophie c'est bien joli, mais c'est juste un poil réducteur.


Mais alors juste un poil, parce que Laurent à absolument raison la demande de Palleas au départ ne concerne effectivement qu'un
a écrit :
bête problème mécanique : quoi faire pour obtenir quel affichage ou quelle lecture.


C'est après que le fil est devenu "philosophique" dés lors que l'on commence à parler de la séparation du fond de la forme, heu... du contenu de la présentation, heu... de la structure de la présentation.... Smiley lol

Vous remarquerez que si on est tous d'accord sur l'idée (on sépare) en revanche sur le fait de savoir ce qu'on doit séparer c'est pas gagné :

a écrit :
Tiens, au fait: la séparation de la structure et de la présentation en HTML n'a effectivement rien d'évident.


Et il y à une raison à ça : c'est qu'on ne sépare pas deux choses mais trois : le contenu, la structure, la présentation.

Le contenu c'est ce qui est dit au travers du langage, des images, des animations, des vidéos.
La structure c'est la manière dont le contenu est logiquement organisé par l'intermédiaire du balisage Html et de la sémantique qui y est associée.
La présentation c'est la manière dont on va rendre le contenu au travers des médias de restitution.

a écrit :
The content of a document refers to what it says to the user through natural language, images, sounds, movies, animations, etc
The structure of a document is how it is organized logically (e.g., by chapter, with an introduction and table of contents, etc.).
An element (e.g., P, STRONG, BLOCKQUOTE in HTML) that specifies document structure is called a structural element.
The presentation of a document is how the document is rendered.
WAI (Printable) Glossary


L'expression "séparation du contenu de sa présentation" est un faux-semblant et là encore je suis absolument d'accord avec Laurent :
a écrit :
je n'ai jamais compris cette obstination fréquente à ignorer le fait qu'on parlait d'un média bien précis


C'est bien la dictature du navigateur graphique qui nous fait faire à tort ce raccourcis et fusionner deux choses différentes : la structure et le contenu.

@ mpop : Je vais te sembler très brutal et je m'en excuse par avance mais ta démonstration liste de définition Vs tableau de mise en forme ça n'à aucun sens.

On s'en fout complètement de la manière dont, du point de vue de la présentation graphique, les labels et les inputs sont alignés si tant est que la structure soit correcte.

Hors tu n'à besoin de rien pour établir une relation entre un label et son champs associé, ces deux éléments sont déjà structurellement relié par la sémantique for=id.

Du coup tout ce que tu va faire pour les aligner c'est juste de la mécanique, rien d'autre.

a écrit :
D'ailleurs, si l'on voulait à tout prix aligner ces champs de saisie entre eux, n'était-ce pas aussi parce que l'on voulait obtenir cette identification rapide. C'est à dire : parce que l'on voulait transmettre, via une présentation visuelle, une information ? Arrêtez-moi si je me trompe, mais on touche au cœur de la sémantique, là


Je suis obligé de t'arrêter : Le fait qu'ils le soient, ou pas, ou selon, n'à aucune valeur sémantique, c'est de l'ergonomie, de la signalétique, du design tout ce que tu veux mais surtout pas de la sémantique.

C'est pareil pour un tableau de mise en forme : tu n'établis aucune relation ou classification de type de rien du tout avec un tableau de mise en forme : tu t'évites juste d'utiliser du positionnement CSS, c'est son seul rôle.

Il faut faire très attention à ca : La sémantique pour HTML c'est les éléments qui constituent la structure et les métadonnées et c'est tout.

Ce n'est ni le contenu ni sa représentation.

Jean-pierre
Modifié par jpv (04 Mar 2006 - 03:55)
Gilles a écrit :

Je ne suis pas du tout d'accord. Le texte d'un post n'est pas, à mon avis, une définition de Auteur-Date-éditer/citer.

Une liste de définitions est une liste de définitions, ce n'est pas parce que son rendu visuel par défaut convient que c'est une bonne raison de la choisir.

Moi non plus je ne suis pas d'accord. Je choisis une liste de définition parce que ça me semble beaucoup plus pratique à utiliser dans un lecteur d'écran. Je m'en fous de l'aspect visuel pour l'instant.
Pour moi, une structure style :

auteur - date - citer/éditer/...
post
auteur - date - citer/éditer/...
post

n'est pas plus une donnée tabulaire qu'une définition. Enfin si, car <dt> se lie logiquement à <dd>, ce qui est très bien, car un auteur est lié à son post. IL y a une relation directe entre l'auteur d'un post et celui-ci. Ce qui n'est à mon sens pas forcément le cas entre deux <td> voisins.

Pour moi, dès le moment où il y a tableau et donc donnée tabulaire, c'est dès qu'on peut mettre un titre aux colonnes et/ou aux lignes. Pour un forum, c'est pas possible, du moins pas complètement je trouve.
Bonjour,

Une simple piqure de rappel pour compléter l'intervention de jpv: la sémantique ne vise pas à transmettre une signification à l'utilisateur. Elle ignore totalement l'utilisateur. Elle vise les machines uniquement.

(Que ces machines soient côté client, côté serveur ou ailleurs, qu'elles travaillent directement pour l'utilisateur ou non, peu importe : elles peuvent être aussi bien l'une des extensions de navigateur mentionnées dans les exemple ci-dessous qu'un CMS, un robot d'indexation ou un proxy...)

Ce qui vise l'utilisateur, c'est la présentation. Les éléments HTML ont, dans tous les medias, une présentation par défaut, c'est à dire des styles CSS par défaut (ou leur équivalent). On confond très souvent ces styles de l'user agent avec de la sémantique, alors qu'ils n'ont rien à voir avec celle-ci : le fait qu'un paragraphe p s'affiche par défaut sous forme d'un bloc de texte, ou que des cellules de tableaux s'affichent les unes à côté des autres... n'est pas de la sémantique. C'est la couche de présentation par défaut de l'UA, qui est d'ailleurs modifiable librement, alors que la sémantique, elle, ne l'est pas.

Pour donner quelques exemples de sémantique réelle et de son exploitation :
- La sémantique de label, c'est effectivement le for= et l'id du contrôle qui sont exploitables par exemple par le navigateur graphique lors d'un clic sur le contenu de l'élément label.
- La sémantique de q et de blockquote, ce n'est pas de dire à l'utilisateur "ceci est une citation". C'est leur attribut cite qui permet par exemple à un script d'exploiter l'url de la source pour générer un lien vers celle-ci.
- La sémantique de dt-dd et celle de dfn : permettre à google:define par exemple d'extraire les couples terme/définition et d'agréger en une seule page Web les définitions d'un même terme recherchée sur le Web. Sémantique floue, d'ailleurs, puisque rien ne définit l'élément englobant la définition dans le cas de dfn. Sémantique très mal exploitée également par Google:define et surtout par les sites eux-mêmes puisque c'est finalement l'élément de présentation <b> qui est le plus exploité par ce script !
- La sémantique de cite, c'est effectivement de renseigner la source de la citation. De manière très floue encore, car rien ne permet de différencier auteur et éditeur dans <cite>Jules Dupont</cite>, <cite>Editions Eyrolles</cite>, de manière à rendre ces informations exploitables pour générer un index des auteurs cités, par exemple (il faut recourir à des class="author... comme le proposait Karl Dubost, et surtout s'entendre sur un vocabulaire normalisé, créer ce qu'on appelle un micro-format, c'est à dire étendre HTML en lui ajoutant la sémantique manquante)
- La sémantique des h1, h2... : permettre à un script d'extraire la table des matières d'un document (éventuellement navigable). Sémantique approximative d'ailleurs, puisque le respect de l'ordre hiérarchique des titres n'est pas imposé par la norme HTML (il faudra attendre WCAG2.0 pour cela, c'est à dire à nouveau une norme bouchant les trous sémantique du HTML).
- la sémantique HTML, ce sont encore les liens relatifs permettant la navigation dans une collection de ressources.
- Et bien-sûr, les éléments meta avec l'exemple des métadonnées DC (ignorées par 99% du Web publique, mais très utilisées dans des traitements internes de documents)

On s'aperçoit rapidement :
- que cette sémantique HTML est assez pauvre, très imparfaite, et beaucoup d'éléments n'ont en fait pas de véritable sémantique exploitable (les paragraphes, les listes) ou n'ont qu'une sémantique minimale qui ne suffit pas aux besoins (les hyperliens, exemple de la métadonnée nofollow créée unilatéralement par Google). Ce n'est pas tout à fait pour rien que le W3C s'est engagé dans quelque-chose de totalement différent du HTML avec le web semantique (voir cet exemple fonctionnel), ou qu'on a vu apparaître d'autres démarches parallèles ou concurrentes: micro-formats et HTML5 Smiley cligne
- que ce peu de sémantique HTML est généralement ignoré et non implémenté par les navigateurs Web modernes, qui sont essentiellement des machines à afficher (pas de fonctionnalité de génération de TOC par défaut, attribut cite ignoré, pas d'exploitation des link rel de navigation dans une collection de documents, pratiquement aucune exploitation des éléments meta etc.). Il faut recourir à des extensions Firefox, des UserJS Opera, etc. pour réaliser les implémentations.

C'est un cercle vicieux : la sémantique HTML bien que limitée,pouvait se développer et pourrait être beaucoup plus exploitée qu'actuellement, mais:
- les navigateurs ont été conçus historiquement avant pour présenter le contenu sans tenir compte de la "couche" de données sémantiques.
- Du coup, la sémantique HTML est restée largement ignorée par les auteurs de sites Web...
- Ce qui n'incite pas les navigateurs, les moteurs de recherche, les traducteurs, les CMS etc. à en tenir compte. Un exemple amusant: même un CMS aussi bien conçu que DotClear propose un bouton ajoutant au billet un blockquote... sans attribut cite ni boîte de dialogue permettant la saisie de celui-ci... Smiley cligne
Modifié par Laurent Denis (04 Mar 2006 - 10:10)
jpv a écrit :

L'expression "séparation du contenu de sa présentation" est un faux-semblant


Pour quelqu'un qui à l'heur de s'intéresser un peu sérieusement au développement web, c'est surtout un pré donné particulièrement maladroit, peu précis et non explicité.

Ta phrase est très juste mais elle aurait du s'adresser à ceux qui ont lancé ce genre de formule comme étendard du discours pour les standards, du discours contre les tableaux...

Maintenant d'une certaine manière c'est trop tard, et c'est donc les nouveaux venus qui partant d'une formulation dont ils ne sont pas l'auteur pour essayer de réfléchir là dessus qui se font envoyer sur les roses pour leur naîveté et leur incompréhension.

jpv a écrit :
c'est qu'on ne sépare pas deux choses mais trois : le contenu, la structure, la présentation.

Le contenu c'est ce qui est dit au travers du langage, des images, des animations, des vidéos.
La structure c'est la manière dont le contenu est logiquement organisé par l'intermédiaire du balisage Html et de la sémantique qui y est associée.
La présentation c'est la manière dont on va rendre le contenu au travers des médias de restitution.



Ah bon, c'était si simple que ça, on ne voyait que deux choses où il y en a trois ?
Et bien non je ne suis pas d'accord, on est encore dans quelque chose de trop sommaire. A commencer par le fait que le html ne structure pas du tout le contenu, ce qui structure le contenu c'est son auteur lui même.

Ce que le html structure c'est le document lui même par l'utilisation de descripteurs pertinents pour rendre compte de la structuration du contenu voulue par l'auteur.

Exemple naïf.
si pour présenter une recette de cuisine on a :


<h1>La tarte tatin</h1>
<h2>Les étapes de la réalisation</h2>
<ol>
<li>Etape 1</li>
<li>Etape 2</li>
etc...
</ol>

<h2>Les ingrédients</h2>
<ul>
<li>Un ingrédient</li>
<li>Un autre</li>
etc...
</ul>


Alors on a bien je pense un balisage pertinent et une structuration du document effective. L'auteur reste néanmoins avec un gros problème quant à la structuration de son contenu.
Modifié par clb56 (04 Mar 2006 - 11:01)
Laurent Denis a écrit :
...
Une simple piqure de rappel pour compléter l'intervention de jpv: la sémantique ne vise pas à transmettre une signification à l'utilisateur. Elle ignore totalement l'utilisateur. Elle vise les machines uniquement.


Bonjour,
J'ai le sentiment d'être largué... je suis surpris de l'usage que tu fais du terme "sémantique". La sémantique ne vise t-elle pas l'étude du sens (en tant qu'objet) ? et contrairement à ce que tu affirmes, la sémantique tient compte du binôme émetteur/recepteur. Iil n'existe pas de sens absolue, mais re-contextualisé...

Pour reprendre ton propos "elle vise les machines" ; les dites machines sont programmées par les hommes, donc le code est en lui même porteur de sens.

Le balisage est compris et perçus différamment par les personnes qui l'utilisent, pour la simple est bonne raison qu'il se réfère à un construction anglo-saxonne du rapport entre la forme et le contenu... Pour les latins, les choses diffèrents. Une structure n'est jamais universelle, c'est toujours une modalité d'imposition de sa vision du monde. Dire que le balisage est anglo saxon n'est pas neutre...

Et c'est probablement pourquoi il nous interroge... le fait que nous discutions du sens des balises nous rappelle que ce sens n'est visiblement pas universel Smiley sweatdrop
Modifié par fredmac (04 Mar 2006 - 13:45)
Administrateur
fredmac a écrit :
et contrairement à ce que tu affirmes, la sémantique tient compte du binôme émetteur/recepteur.

Le récepteur d'un document web est bel est bien une machine (un navigateur, ou plus largement un agent utilisateur)... qui va traiter le document pour le transmettre au visiteur.
Raphael a écrit :

Le récepteur d'un document web est bel est bien une machine (un navigateur, ou plus largement un agent utilisateur)... qui va traiter le document pour le transmettre au visiteur.


Oui d'un point de vue technologique. Mais l'ordinateur (ou le navigateur) est un medium ; la page web "transite" par l'ordinateur. On envoi pas un mail pour qu'il reste sur le disque dur d'un ordinateur, mais pour qu'il soit lu, idem pour une page web. Le destinataire final est l'internaute-lecteur.

Raphael, je crois que nous parlons de la même chose, mais différament Smiley murf Smiley cligne
Modifié par fredmac (04 Mar 2006 - 14:34)
Pages :