Pas de tableaux du tout ?

(reprise du message précédent)

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
Modifié par fredmac (04 Mar 2006 - 14:34)

Ah... Il faut relire le message de Jean-Pierre, et son rappel sur la distinction entre contenu, structure et présentation.

La sémantique au sens linguistique (message de fredmac), c'est celle du contenu, qui dérive rapidement vers celle de sa présentation (et généralement uniquement dans le media graphique dominant), et qui saute souvent par-dessus la question de la structure. S'interroger sur le sens du contenu pour l'utilisateur est bien-sûr nécessaire, mais cela ne m'aidera pas à choisir par exemple entre :

<div>
1. un item<br />
2. un autre item<br />
3. encore un autre item
</div>

et :

<ol>
<li>un item</li>
<li>un autre item</li>
<li>encore un autre item</li>
</ol>

La sémantique au sens HTML (mon message ci-dessus), c'est celle de la structure. C'est en posant la question de l'exploitation éventuelle du <ol> par opposition au <div> par des machines (indifféremment du rendu utilisateur) que je vais être amené à faire un choix structurel.

Ces deux approches ne répondent pas aux mêmes besoins. Le problème est qu'en les confondant, on tente souvent de répondre aux problèmes de structure avec le mauvais outil

(Pour rendre cet exemple plus concret: dans un outil en ligne de travail collaboratif, je peux être dans un cas où il s'agit de listes d'opérations à réaliser par ordre de priorité. Et je peux avoir un script qui va parcourir une collection de cas, et extraire ceux où telle opération (en supposant un vocabulaire normalisé) est en première position, afin de les attribuer à la personne responsable de cette opération spécifique...)
Modifié par Laurent Denis (04 Mar 2006 - 15:22)

jpv a écrit :
@ 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.

Effectivement, une fois les couples id et for=id établis, l'information sémantique est présente. Elle pourra – potentiellement – être exploitée par un automatisme logiciel, et tant mieux. C'est d'ailleurs le cas, dans une certaine mesure, avec un navigateur récent : en cliquant sur mon label doté d'un for="monid", le pointeur va automatiquement à mon élément porteur de l'identifiant "monid", et c'est bien.

Voilà pour la sémantique. Vu ce que je me suis pris dans la gueule, je n'aurais pas dû utiliser ce terme, et je me range à ta définition, partagée par Laurent Denis ou Raphaël à ce que je vois. D'autant plus que je n'ai pas envie de sortir un dictionnaire, qui ne font jamais autorité, dont les définitions ne sont pas toujours pertinentes ou applicables, et qui me vaudraient surtout les foudres de Laurent Denis. Nous sommes dans une problématique technique, et donc on utilisera le terme sémantique dans son sens technique.

Je ne vais pas revenir indéfiniment en détail sur l'exemple que je donnais. Je reste convaincu que ma "démonstration" a un certain intérêt, et qu'elle apporte une réponse intéressante à l'équation suivante :
- premièrement : je veux obtenir une présentation graphique pour plusieurs raisons, dont la volonté de transmettre via la présentation graphique une information qualifiante sur les objets que j'affiche. Ici, je veux un alignement à la fois horizontal et vertical des objets afin de mettre en valeur une double relation. La présentation graphique utilise un code visuel (structuration en lignes et colonnes) faisant appel à un code culturel. Le but étant de faciliter et d'accélérer la compréhension du statut de chaque objet.
- deuxièmement : je souhaite que cette présentation visuelle repose sur un code reflétant cette information structurelle et organisationnelle. Dans l'idéal, ce code pourra comporter des informations sémantiques permettant à des outils logiciels de reconnaître et d'exploiter (de diverses manières) cette information.

L'exemple que je donnais permettait de répondre complètement au premier problème, et partiellement au deuxième. Il me semble donc avoir un certain intérêt.

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

Je pense que je viens de contester ce jugement. Effectivement, c'est aussi de la mécanique. Mais le but poursuivi, c'est de transmettre une information, si possible aussi bien visuellement (code graphique) que sémantiquement (utilisation d'un code spécifique permettant à des outils techniques de reconstituer les liens logiques...). Je n'en dirai pas plus, vu que je ne connais pas précisément ce que tu entends par mécanique

Allez hop, première fois que j'arrive à lancer un troll sur un sujet de ce genre.
Si quelqu'un lance un « les tableaux, c'est de la technique de nazi », on aura aussi droit à notre point Godwin

Laurent Denis a écrit :
Ces deux approches ne répondent pas aux mêmes besoins. Le problème est qu'en les confondant, on tente souvent de répondre aux problèmes de structure avec le mauvais outil .

Oui, tout à fait. Néanmoins on utilise pas des concepts en les mettants à sa sauce... au mieux on se doit d'en inventer (d'en proposer) de nouveaux (par exemple, "structuration en vue d'un traitement informatique" et non pas "sémantique HTML"). Ce faisant on désambiguïse son discour. Mais je suis conscient que cela est plus facile à dire (à écrire) qu'a faire

Laurent Denis a écrit :
La sémantique au sens HTML (mon message ci-dessus), c'est celle de la structure. C'est en posant la question de l'exploitation éventuelle du <ol> par opposition au <div> par des machines (indifféremment du rendu utilisateur) que je vais être amené à faire un choix structurel.

L'absence de visibilité sur d'éventuels traitements informatique (qui sait ce qu'il sera possible de faire demain ?) est un puissant frein à ce type de réflexion. Cela s'apparente plus à de la prospective.

Je ne peux choisir entre ol et div que si je connais le comportement de la machine à un moment T. Si aujourd'hui la machine ne distingue pas (au sens ou tu le souhaiterais), cette question doit-elle se poser ? Néanmoins, rien n'interdit d'y réfléchir
Modifié par fredmac (04 Mar 2006 - 16:37)

Par contre, je pense avoir retenu ceci de l'intervention de Laurent Denis sur l'exemple des listes :

La structure

<div>
1. un item<br />
2. un autre item<br />
3. encore un autre item
</div>

Permet de faire passer l'information "liste avec plusieurs éléments" via les agents utilisateur graphiques (et dans une certaine mesure avec un lecteur d'écran, même si le fait que les items ne seront pas annoncés comme tels peut ralentir la compréhension de l'information).

Par contre, la structure

<ol>
<li>un item</li>
<li>un autre item</li>
<li>encore un autre item</li>
</ol>

si elle permet de faire passer la même information via un agent utilisateur graphique ou un lecteur d'écran, permet également à des logiciels ou scripts de parser le code pour en extraire le contenu et l'information structurelle, indépendamment du rendu graphique ou audio.

J'ai bon ?
Modifié par mpop (04 Mar 2006 - 16:37)

Laurent Denis a écrit :
C'est en posant la question de l'exploitation éventuelle du <ol> par opposition au <div> par des machines (indifféremment du rendu utilisateur) que je vais être amené à faire un choix structurel.

Ba je dirais tout aussi bien que c'est en prenant la mesure de la structuration voulue par l'auteur (Une série d'opérations déterminées et devant être exécutées dans un certain ordre) que la discrimination s'effectuera pour choisir la balise la plus pertinente et adéquate (au passage la question du rendu visuel au moment où ce choix s'effectue n'a rien à voir dans l'affaire).

Cela dit je comprend bien qu'il y a un vrai saut conceptuel entre balisage pertinent et adéquat et la notion de sémantique web (et bien évidemment le deuxième terme je ne l'emploie pour ma part jamais pour parler de la première situation).

clb56 a écrit :
Cela dit je comprend bien qu'il y a un vrai saut conceptuel entre balisage pertinent et adéquat et la notion de sémantique web (et bien évidemment le deuxième terme je ne l'emploie pour ma part jamais pour parler de la première situation).

Ah c'est pour ça alors que je me fais taper dessus
Modifié par mpop (04 Mar 2006 - 19:45)

fredmac a écrit :
(par exemple, "structuration en vue d'un traitement informatique" et non pas "sémantique HTML"). Ce faisant on désambiguïse son discour.

L'expression historique "Semantic Web" et sa traduction littérale en français ne sont en effet pas dénuées d'ambiguïtés. Les hasards du vocubulaire ont leur part de responsabilité dans les difficultés rencontrées.

fredmac a écrit :
Je ne peux choisir entre ol et div que si je connais le comportement de la machine à un moment T. Si aujourd'hui la machine ne distingue pas (au sens ou tu le souhaiterais), cette question doit-elle se poser ?

C'est là où la conformité aux standards Web joue pleinement son rôle : HTML4.01 s'adresse à la fois aux agents utilisateurs et aux auteurs de documents. Et d'autres normes comme les UAAG ( User Agent Accessibility Guidelines) vont compléter HTML4.01 en précisant certaines exploitations de la sémantique HTML par les agents utilisateurs... La sémantique HTML n'a de sens que dans un univers normé

<edit>Vous aviez rectifié de vous-mêmes: il fallait évidemment lire UAAG et non ATAG </>
Modifié par Laurent Denis (04 Mar 2006 - 19:32)

clb56 a écrit :


Ba je dirais tout aussi bien que c'est en prenant la mesure de la structuration voulue par l'auteur (Une série d'opérations déterminées et devant être exécutées dans un certain ordre) que la discrimination s'effectuera pour choisir la balise la plus pertinente et adéquate (au passage la question du rendu visuel au moment où ce choix s'effectue n'a rien à voir dans l'affaire).

Hum... Si ce n'est que le rédacteur de contenu ayant à se poser la question du balisage structurel, c'est une situation temporaire et anormale. Et que les rédacteurs ne devraient en fait jamais tomber sur la moindre ligne de (X)HTML. C'est le travail des agents de production de contenu (éditeurs wysiwyg, CMS surtout), encore balbutiant, mais en pleine mutation.

Là, on touche un problème de fond : d'une certaine manière, le Web sémantique est destiné à s'auto-produire. Pas à être écrit par les utilisateurs...

<edit>C'est d'ailleurs une des problèmes caractéristiques des micro-formats tentant d'étendre la sémantique HTML : contrairement à ce qu'affirment souvent les inventeurs de ces formats, ça n'est pas du tout plus sympa à écrire à la main que du RDF </>
Modifié par Laurent Denis (04 Mar 2006 - 19:41)

bonsoir,

a écrit :
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...

Je suppose que tu parles des tableaux de mise en forme, là aussi les mots ont de l'importance : il n'y à pas de discours contre les tableaux, il y à essentiellement un discours contre les méthodes de développement fondées sur des tableaux de mise en forme et elles seules.

Là aussi il faut lever un malentendu : Les tableaux de mise en forme ne sont pas interdis par les spécifications, ce n'est pas une technique "non-standard" :

a écrit :
Le modèle de la table de HTML permet aux auteurs d'arranger des données (texte, texte préformaté, images, liens, formulaires, champs de formulaires, autres tables, etc.) en rangées et colonnes de cellules.
11.1 La spécification HTML 4.01 - Introduction aux tables

En revanche, les tables de mise en forme ont deux soucis :

Le premier est technique :

a écrit :
Les tables ne devraient pas représenter simplement un moyen de disposer le contenu d'un document car cela peut entraîner des problèmes de restitution sur les médias non-visuels. Afin de minimiser ces problèmes, les auteurs devraient employer des feuilles de style pour le contrôle de la disposition plutôt que des tables.
11.1 La spécification HTML 4.01 - Introduction aux tables

Le second concerne les méthodes de développement associées à cette technologie qui sont exclusivement tournées vers la représentation graphique ce qui pose des problèmes en terme de conception, d'interopérabilité et d'accessibilité.

Et donc de proposer une technologie plus convaincante, plus pérenne et plus efficace, au coeur de laquelle nous avons ce concept de séparation contenu, structure, présentation.

Le levier majeur de cette technologie, qui est la clé de voûte de tout le reste, c'est qu'elle rends la structure très exigeante et éloigne la conception web de la seule restitution graphique.

Et plus on reporte la représentation graphique sur CSS, et donc moins on utilise de tables de mise en forme, plus le contenu exigera d'être fortement structuré, plus il sera accessible à d'autre restitution.

Alors que dans une conception traditionnelle on à tendance à structurer le contenu autour d'un design et d'une "sémantique visuelle" pour reprendre l'expression de mpop qui dans ce contexte est appropriée

Le soucis c'est qu'elle est très dépendante des conditions, ce qui la rends "éphémère" et qu'elle sera perdue sur d'autres formes de restitution.

C'est la raison pour laquelle, et je m'en excuse encore, j'ai réagis brutalement au discours de mpop parce que je voyais ressurgir cette manière de faire qui va de la présentation graphique vers la structure et que ça c'est le mal...

Par rapport au contenu, à sa structure, à la logique du propos et à ses objectifs de restitution, la présentation graphique n'est pas la bonne méthode pour guider le travail sur la structure : sur ce sujet c'est la moins efficace, la moins exigeante, la moins convaincante.

La restitution vocale par exemple est infiniment plus efficace pour lever un doute sur la structure.

Jean-pierre

@ jpv :
Merci pour ces précisions

Bonjour,

a écrit :
Ici, je veux un alignement à la fois horizontal et vertical des objets afin de mettre en valeur une double relation.
...
- deuxièmement : je souhaite que cette présentation visuelle repose sur un code reflétant cette information structurelle et organisationnelle.

C'est la définition d'une table de donnée, donc d'une table dotée d'un titre, d'un résumé et d'une relation croisée lignes/colonne.

a écrit :

... dont la volonté de transmettre via la présentation graphique une information qualifiante sur les objets que j'affiche.
...
La présentation graphique utilise un code visuel (structuration en lignes et colonnes) faisant appel à un code culturel. Le but étant de faciliter et d'accélérer la compréhension du statut de chaque objet.

Si ce que tu décris là, et c'est le coeur du problème, n'est qu'un code visuel (lignes et colonnes) à des fins d'ergonomie (faciliter la compréhension) il ne doit pas peser sur la structure du contenu.

En revanche si ce n'est pas ça et que les éléments en cause ont pour nature d'être présentés de la sorte alors le problème est mal posé, ce n'est pas à la présentation graphique de le déterminer.

Reporté à ton exemple : un formulaire, le choix de la table de données ne semble pas pertinent car le formulaire dispose de tous les éléments nécessaire pour décrire sa structure (legend, fieldset, label, tabindex).

D'ailleurs tu le dit toi-même : information qualifiante "via la présentation graphique", cela ne concerne pas la nature des éléments affichés mais la manière de les présenter.

La réponse c'est donc ni la liste de définition, ni la table de données mais un mécanisme de présentation.

Ce peut-être un mécanisme CSS (le meilleur) ou la table de mise en forme (l'astuce) mais dans les deux cas ils n'auront "rien à dire" sur les relations entre les éléments, juste à les présenter de la meilleure façon possible.

Jean-pierre

jpv a écrit :
bonsoir,

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...

Je suppose que tu parles des tableaux de mise en forme, là aussi les mots ont de l'importance : il n'y à pas de discours contre les tableaux, il y à essentiellement un discours contre les méthodes de développement fondées sur des tableaux de mise en forme et elles seules.


Et c'est même encore plus compliqué que ça puisque le fond de l'argumentaire contre la mise en page par tableau tient surtout sur les problèmes posés par l'imbrication ad infinitum de ceux ci (considérable poids inutile d'un codage inutile et en plus à la gestion non optimisable, difficultés abyssales concernant l'accessibilité, total manque de pertinence des descripteurs par rapport aux types de contenu à décrire ou pour le dire autrement à la structuration intrinsèque dont ledit contenu est déjà porteur).

Mais dans dans mon propos je ne parlais pas de ça je ne parlais que de formules, slogans, professions de foi plus ou moins explicites par rapport auxquels il s'agit pour nous de penser.

Personellement il m'a fallu quelques mois pour me rendre compte que 90% des termes dont on m'abreuvait n'avaient aucune consistance intellectuelle ou théorique (forme, contenu, mise en page, présentation...) et donc j'ai la dent dure là dessus. Au passage je confirme que le triptyque que tu as donné (contenu, structure, présentation) me parait aussi peu déterminé qu'il est séducteur (un nouveau paradigme lapidaire qui risque d'être aussi confortable qu'il sera peu pensé).

Pour le reste même si je ne pense pas que le propos s'adressait à moi je dirai que tu prêches un coinvaincu. Je suis depuis presque deux ans un afficionado quasi extravagant du travail nostyle en développement web, je peux même pousser le bouchon jusqu'à tester du développement sans le moindre <div> juste comme ça pour voir jusqu'où on peut pousser l'épure du document html et que néanmoins le "css media=screen addict" en sorte néanmoins quelque chose.

Au passage, mon point de vue sur les css (je parle toujours du media=screen) n'est pas qu'elles servent à faire de la mise en page "too much hype marketing design" mais que dans une telle démarche au moins l'intégrité du document html lui même est préservée.

Bonjour,

Sur ce point, clb56, puis-je me permettre de donner le regard d'un "évangéliste" de longue date ?

<edit>En fait de regard, c'est un authentique coup de gueule maison </>

Oui, il y a des simplifications dans l'évangélisme standard. Dans le cas qui nous occupe, c'est notamment vrai pour le contenu actuel d'OpenWeb, à la source de beaucoup de discours qui a leur tour ont opéré leur propres simplifications (notament Alsa). C'est le cas également d'autres contenus "initiateurs", ceux du WASP, de CSSdiscuss, de W3Québec, de DevMO, etc. Pour ceux qui cherchent du contenu sans simplification... voir le travail de Richard Ishida sur l'i18n du W3C, qui est une mine de trésors... que personne ne lit et dont personne ne se sert, malgré sa formidable qualité : il est superbe, mais compliqué.

Les gens veulent à la fois une technologie dont les innovations répondent à leur besoin, technologie qu'on est en train d'élaborer... et un mode d'emploi niveau balai bissell . Problème...

Lorsque nous avons lancé OpenWeb et bâti le contenu initial du site, qui a été par la suite repris un peu partout comme nous utilisions nous-mêmes le travail du WASP, d'alistApart ou de NetscapeDevEdge (c'était le but du jeu commun), nous avons:
- dû faire des simplifications. On ne vend pas une technologie en plongeant d'emblée dans ses concepts les plus fouillés. Et ce n'est pas un problème quand cette simplification ne l'empêche pas d'être immédiatement opérationnelle. Ne pas oublier que le contexte était beaucoup plus idéologique qu'aujourd'hui. Et qu'aucune de ces simplifications n'est problématique sur le fond.
- fait avec le peu de recul disponible alors faute justement d'implémentations, de travail de terrain et de retours. Beaucoup de problématiques se sont manifestées ou affirmées depuis. Le regard n'est plus le même, et c'est le sens de mes interventions sur ce forum, et leur principale motivation.

Dire que:

clb56 a écrit :
90% des termes dont on m'abreuvait n'avaient aucune consistance intellectuelle ou théorique (forme, contenu, mise en page, présentation...)

... est faux. Totalement. Et passablement inacceptable au regard du travail accompli et des résultats obtenus

On peut voir cela de deux manières :
- savoir d'où l'on vient, où on en était il y a 5 ans, et mesurer ce qui s'accomplit actuellement.
- ou débarquer <censured /> et râler. C'est le cas de peu de gens heureusement, mais c'est toujours assez pénible. Nous sommes en train de construire. Pas de livrer du tout cuit.

Je suis très sec et sans concession. Mais j'ai de très bonnes raisons de l'être, devant ce qui me rappelle les pires trolls passés sur l'évangélisme standard, ALA "W3C go home"

<edit>En prolongement, un excellent billet de Molly Holzschlag à méditer : How to Sniff Out a Rotten Standardista. Il faudrait ajouter un 4e portrait à sa galerie : le râleur impénitent

Ah, aussi: relire Why specs matter (traduction partielle en français), sous-titré Morons and Assholes

</>
Modifié par Laurent Denis (05 Mar 2006 - 10:14)

mpop a écrit :
Si quelqu'un lance un « les tableaux, c'est de la technique de nazi », on aura aussi droit à notre point Godwin

OK, je me dévoue : les tableaux, c'est de la technique de nazi puisqu'Hitler était peintre.

djfeat a écrit :


les tableaux, c'est de la technique de nazi

Ah, si seulement Adobe était à la place de Microsoft : on ne parlerait pas de standards W3C, et nous ferions tous de beaux PDF sans états d'âmes, avec de belles grilles de layout façon tablô
Modifié par Laurent Denis (05 Mar 2006 - 11:07)

Pour le prix « Trophée Godwin du meilleur artiste trolleur de l'année » dans la catégorie « Point Godwin sur sollicitation du public », les vainqueurs sont :

N°1 – djfeat, mention spéciale Humour et Élégance
N°2 – Laurent Denis, mention spéciale Mise en perspective et Décalage

Houlàlà, vous faites fort.
a part ça ce topic j'y suis complètement largué.

Je suis le maillon faible, au-revoir.