Discussions actives
CSS, formulaire et labels multilignes (2)CSS, XHTML et formulaire (12)
Espresso : étapes de construction des CSS (7)
Images de fond, boites rondes (13)
Images d'arrière plan (8)
Je vois des listes partout !
L'abus de programmation en LISP me fait voir des listes partout. Et si une page Web etait simplement une liste de listes ? Ne serait-il pas plus semantiquement correct de d'utiliser des <ul>...</ul> imbriques pour representer ces pages Web ? C'est une idee qui m'est venue en discutant avec Emmanuel Clement avec qui je discute ferme de CSS et de semantique (voir egalement aujourd'hui les superbes calendriers d'Emmanuel). Sur Niutopia, les "oneliners" sont dans une liste. Emmanuel prefererait des paragraphes. Voici mon point de vue.
Pour moi, les oneliners (les breves, les blablas, la tribune etc. on cherche un meilleur nom) sont des elements d'une liste... de oneliners justement. Ils sont les uns a la suite des autres, et il n'y a pas d'element autre au milieu. Alors que si c'est simplement une suite de paragraphes, on ne sait pas trop ou ca commence et ou ca finit, il pourrait y avoir un titre au milieu, ou une table ou n'importe quel autre element.
Imaginons un navigateur qui ressemble plus a un outliner : d'un clic sur un petit [+] ou un petit [-], on pourrait collapser ou decollapser (de quoi herisser bien des cheveux roux :-) en un clic les oneliners. Imaginons un non-voyant qui ecoute les deux premiers oneliners "Salut Bob, ca va ?" et "Ouais ca va et toi ?" et qui se dit que ca n'a aucun interet : un petit raccourci clavier, et hop, on passe a la fin de la liste. Pratique non ?
Dans la meme idee, qu'est ce qu'un joueb, si ce n'est une liste d'articles ? Ne faudrait il pas enlister tous ces articles ? On obtiendrait ainsi une page plus structuree. Plus facile a parser. Plus interessante pour les navigateurs du futur. J'ai plein d'idees pour les navigateurs du futur, je vous en parlerai un de ces jours. :-)
Pour moi, les oneliners (les breves, les blablas, la tribune etc. on cherche un meilleur nom) sont des elements d'une liste... de oneliners justement. Ils sont les uns a la suite des autres, et il n'y a pas d'element autre au milieu. Alors que si c'est simplement une suite de paragraphes, on ne sait pas trop ou ca commence et ou ca finit, il pourrait y avoir un titre au milieu, ou une table ou n'importe quel autre element.
Imaginons un navigateur qui ressemble plus a un outliner : d'un clic sur un petit [+] ou un petit [-], on pourrait collapser ou decollapser (de quoi herisser bien des cheveux roux :-) en un clic les oneliners. Imaginons un non-voyant qui ecoute les deux premiers oneliners "Salut Bob, ca va ?" et "Ouais ca va et toi ?" et qui se dit que ca n'a aucun interet : un petit raccourci clavier, et hop, on passe a la fin de la liste. Pratique non ?
Dans la meme idee, qu'est ce qu'un joueb, si ce n'est une liste d'articles ? Ne faudrait il pas enlister tous ces articles ? On obtiendrait ainsi une page plus structuree. Plus facile a parser. Plus interessante pour les navigateurs du futur. J'ai plein d'idees pour les navigateurs du futur, je vous en parlerai un de ces jours. :-)
Ecrit par Biz, le Mardi 17 Décembre 2002, 20:55 dans la rubrique "Premiers Pas".
Commentaires :
Anonyme
19-12-02
à 11:06
une liste, un arbre? une citation, un paragraphe, un commentaire ?
Si je comprends bien, tu vois un truc genre l'Active Renderer pour les "onelines" couplé avec les raccourcis clavier du Google Keyboard.
Mais sémantiquement, les "oneliners" c'est une suite de paragraphes, pas une liste (qui est une visualisation, et possiblement la façon dont ton algorithme les stocke et manipule). Même plus, y'a certains "onelines" qui sont des répliquesm uniquement compréhensibles en lisant les précédentes messages. Alors que dans une liste (genre PQcéréalescapotessavonhuile d'olive), chaque élément est indépendant du précédent et sans ordre (pour cela, y'a les OL).
Idem pour le contenu d'un joueb. Y'a un certain ordre chronologique,(pas dans tous certes, mais ca existe). La représentation visuelle se rapproche plus d'un arbre, avec en plus des liens invisibles (les catégories, les références à de précédentes chroniques par exemple) que l'hypertexte permet plus ou moins de matérialiser/utiliser. L'outline est effectivement une façon hiérarchique de répresenter le tout (et de l'écrire aussi, mais c'est un autre outil)
Sémantiquement, sur un joueb, tu trouves le coeur, l'article et les commentaires (qu'ils soient sur site, ou bien distants et matérialisés par TB, ou traitement manuel et automatique des introducteur (le BackLink de Niutopia)): première différence, première séparation sémantique.L'article lui-même comprend au moins un paragraphe, possiblement des citations, surement quelques mots mis en exergue. Et des liens, des listes, du multimédia peut-être. Dans les commentaires, les mêmes constituants se retrouvent avec en plus la notion d'"enfilade" et une plus forte fréquence des citations.
Bref, l'utilisation des balises va apporter plus de richesse, traduite (ou non) visuellement d'ailleurs. Plus d'information sémantique qu'avec un simple UL, en tout cas.
Et ensuite y'a les méta-informations, mais j'y comprends pas grand chose (et surtout je vois pas comment l'automatiser cette extraction de meta-information). Par contre, son usage commence à devenir concret et intéressant, à mon goût
Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
Hello,
Je reprend ce que dis "Anonyme" :
sémantiquement, les "oneliners" c'est une suite de paragraphes, pas une liste (...)
Alors que dans une liste, chaque élément est indépendant du précédent et sans ordre.
C'est pour cette raison, Biz, que je souhaitais différencier les listes des oneliners.
La suite logique des dialogues ou textes du oneliner n'a rien à voir avec la logique d'une liste dans laquelle l'ordre des items peut être changé sans que la compréhension soit affectée
Je comprend ta logique mais c'est une question de terminologie : tu parles du terme "liste" mais je pense que tu penses "entité nommable" (chai pas si je suis bien clair)
Cela me fait également penser à un travail de première année aux Beaux-Arts (ha, c'était bien ce temps-là !) :
Travail photographique sur la série et la séquence.
Une série de photos de fleurs peut avoir n'importe quel ordre.
Une séquence sur une fleur qui éclot c'est différent, l'ordre importe.
Série = liste
Séquence = oneliner
Je reprend ce que dis "Anonyme" :
sémantiquement, les "oneliners" c'est une suite de paragraphes, pas une liste (...)
Alors que dans une liste, chaque élément est indépendant du précédent et sans ordre.
C'est pour cette raison, Biz, que je souhaitais différencier les listes des oneliners.
La suite logique des dialogues ou textes du oneliner n'a rien à voir avec la logique d'une liste dans laquelle l'ordre des items peut être changé sans que la compréhension soit affectée
Je comprend ta logique mais c'est une question de terminologie : tu parles du terme "liste" mais je pense que tu penses "entité nommable" (chai pas si je suis bien clair)
Cela me fait également penser à un travail de première année aux Beaux-Arts (ha, c'était bien ce temps-là !) :
Travail photographique sur la série et la séquence.
Une série de photos de fleurs peut avoir n'importe quel ordre.
Une séquence sur une fleur qui éclot c'est différent, l'ordre importe.
Série = liste
Séquence = oneliner
Re: Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
Interessant. Si effectivement, ul = serie et ol = sequence (je n'en suis pas convaincu), alors on pourrait mettre les oneliners en ol. C'est une information semantique en plus de savoir que les oneliners sont des elements d'une meme serie.
Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
>Mais sémantiquement, les "oneliners" c'est une suite de paragraphes, pas une liste (qui est une visualisation, et possiblement la façon dont ton algorithme les stocke et manipule). Même plus, y'a certains "onelines" qui sont des répliquesm uniquement compréhensibles en lisant les précédentes messages. Alors que dans une liste (genre
PQcéréalescapotessavonhuile d'olive), chaque élément est indépendant du précédent et sans ordre (pour cela, y'a les OL).
Oui et non. Tout ce que la spec dit, c'est : ul = bullet-style, et ol = number-style. D'ailleurs a mon avis, ul et ol sont mal nommees. ;-) Ca devrait etre liste numerotee et liste non-numerotee. Les listes sont toujours ordonnees. A ma connaissance, aucun navigateur ne melange les elements d'une liste non ordonnee. Ou il faudrait reecrire la spec en expliquant clairement l'intention derriere ul et ol.
>Idem pour le contenu d'un joueb. Y'a un certain ordre chronologique,(pas dans tous certes, mais ca existe). La représentation visuelle se rapproche plus d'un arbre, avec en plus des liens invisibles
Qu'est ce qu'un arbre si ce n'est une liste de listes ? :-)
>Bref, l'utilisation des balises va apporter plus de richesse, traduite (ou non) visuellement d'ailleurs. Plus d'information sémantique qu'avec un simple UL, en tout cas.
Mais rien ne t'empeche de mettre toutes tes informations semantiques a l'interieur de ton element li, non ?
PQcéréalescapotessavonhuile d'olive), chaque élément est indépendant du précédent et sans ordre (pour cela, y'a les OL).
Oui et non. Tout ce que la spec dit, c'est : ul = bullet-style, et ol = number-style. D'ailleurs a mon avis, ul et ol sont mal nommees. ;-) Ca devrait etre liste numerotee et liste non-numerotee. Les listes sont toujours ordonnees. A ma connaissance, aucun navigateur ne melange les elements d'une liste non ordonnee. Ou il faudrait reecrire la spec en expliquant clairement l'intention derriere ul et ol.
>Idem pour le contenu d'un joueb. Y'a un certain ordre chronologique,(pas dans tous certes, mais ca existe). La représentation visuelle se rapproche plus d'un arbre, avec en plus des liens invisibles
Qu'est ce qu'un arbre si ce n'est une liste de listes ? :-)
>Bref, l'utilisation des balises va apporter plus de richesse, traduite (ou non) visuellement d'ailleurs. Plus d'information sémantique qu'avec un simple UL, en tout cas.
Mais rien ne t'empeche de mettre toutes tes informations semantiques a l'interieur de ton element li, non ?
Re: Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
Désolé pour la fausse manoeuvre ci-dessus.
>Et si une page Web etait simplement une liste de listes ? Ne serait-il pas plus semantiquement correct de d'utiliser des <ul>...</ul> imbriques pour representer ces pages Web ?
Honnêtement, lorsque j'ai ces lignes, j'ai sursauté et je me suis dit que c'était absurde: un document html ainsi structuré ne serait qu'une énumération sans hiérarchie...
Et puis, à la réflexion, et à la lecture de:
>Mais rien ne t'empeche de mettre toutes tes informations semantiques a l'interieur de ton element li, non ?
Je crois en effet que l'idée mérite d'être creusée.
Pour une page de weblog avec liens de navigation du site et liens vers d'autres blogs, on aboutirait par exemple à quelque-chose comme:
<ul>
<li><h1>Titre de Page</h1>
<p>... bandeau d'en-tête ... </p>
</li>
<li><h2>Weblog</h2>
<ul>
<li><h3>Titre d'un post</h3>
<p>... texte du post ...</p>
</li>
</li>
<li><h2>Navigation</h2>
<ul>
<li><h3>Navigation interne</h3>
<ul>
<li><a href...>lien</a></li>
...
</ul>
</li>
<li><h3>Navigation externe</h3>
<ul>
<li><a href...>lien</a></li>
...
</ul>
</li>
</ul>
</ul>
(La hiérarchie des titres ci-dessus est sans doute à revoir)
J'aurai cru a priori qu'un tel imbriquement de listes et de titres serait invalide, mais ce n'est pas le cas.
En fait, et c'est le plus intéressant, ceci ressemble beaucoup à ce que le HTML 2 permettra de faire avec l'élément section, si celui-ci est retenu au final...
Voir http://www.w3.org/TR/xhtml2/mod-text.html#sec_8.15.
L'idée est donc plutôt novatrice et mérite d'être creusée.
>Et si une page Web etait simplement une liste de listes ? Ne serait-il pas plus semantiquement correct de d'utiliser des <ul>...</ul> imbriques pour representer ces pages Web ?
Honnêtement, lorsque j'ai ces lignes, j'ai sursauté et je me suis dit que c'était absurde: un document html ainsi structuré ne serait qu'une énumération sans hiérarchie...
Et puis, à la réflexion, et à la lecture de:
>Mais rien ne t'empeche de mettre toutes tes informations semantiques a l'interieur de ton element li, non ?
Je crois en effet que l'idée mérite d'être creusée.
Pour une page de weblog avec liens de navigation du site et liens vers d'autres blogs, on aboutirait par exemple à quelque-chose comme:
<ul>
<li><h1>Titre de Page</h1>
<p>... bandeau d'en-tête ... </p>
</li>
<li><h2>Weblog</h2>
<ul>
<li><h3>Titre d'un post</h3>
<p>... texte du post ...</p>
</li>
</li>
<li><h2>Navigation</h2>
<ul>
<li><h3>Navigation interne</h3>
<ul>
<li><a href...>lien</a></li>
...
</ul>
</li>
<li><h3>Navigation externe</h3>
<ul>
<li><a href...>lien</a></li>
...
</ul>
</li>
</ul>
</ul>
(La hiérarchie des titres ci-dessus est sans doute à revoir)
J'aurai cru a priori qu'un tel imbriquement de listes et de titres serait invalide, mais ce n'est pas le cas.
En fait, et c'est le plus intéressant, ceci ressemble beaucoup à ce que le HTML 2 permettra de faire avec l'élément section, si celui-ci est retenu au final...
Voir http://www.w3.org/TR/xhtml2/mod-text.html#sec_8.15.
L'idée est donc plutôt novatrice et mérite d'être creusée.
Re: Re: Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
Hum... pas très clair, mon exemple, et invalide pour cause de fautes de frappes.
Celui-ci est plus clair et valide:
http://www.blogblues.com/standards/test/listeblog.asp
Celui-ci est plus clair et valide:
http://www.blogblues.com/standards/test/listeblog.asp
Re: Re: Re: Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
Ton exemple est tres parlant. :-)
A propos de ton commentaire : "Enfin, le petit essai que j'ai fait, un peu poussé peut-être, a un défaut immédiat: un code à peu près aussi lisible et simple à manier que celui d'un layout à tableaux :-(... "
A mon avis, tu dis ca parce que tu l'as ecrit a la main. Mais comme l'a devine anonyme plus haut, a un moment donne, dans mon outil, les articles (ou les commentaires) sont dans une liste (un tableau a une dimension). Pour un outil de generation de joueb, c'est donc tres simple a manier.
Pour un navigateur, c'est toujours aussi simple a manier, et savoir que les articles sont :
a) des elements semblables,
b) les uns a la suite des autres sans rien d'etranger au milieu,
permettrait de faire des choses intelligentes, comme l'expansion ou l'inverse en un clic de souris. (comme l'explorateur de Windows le fait avec les repertoires, qui sont des listes de fichiers et d'autres repertoires).
C'est la meme philosophie que les CSS etc. : a la base, il y a tres souvent des informations tres semantiques (bases de donnees, systemes divers et varies), et on essaie de garder ces informations semantiques le plus longtemps possible, de les pousser jusqu'au client, pour que ca soit l'utilisateur et non le webmaster qui decide comment les informations peuvent etre traitees.
> "ul et ol ne sont pas neutres côté présentation induite"
C'est vrai. Plus j'y reflechi, et plus je trouve que ul et ol sont mal nommees. Ce sont toutes les deux des listes ordonnees, et la seule difference est visuelle, ol est numerotee.
Tout ca pour dire que pour moi, ca me parait toujours aussi sense de mettre les oneliners dans une liste ul. :-)
A propos de ton commentaire : "Enfin, le petit essai que j'ai fait, un peu poussé peut-être, a un défaut immédiat: un code à peu près aussi lisible et simple à manier que celui d'un layout à tableaux :-(... "
A mon avis, tu dis ca parce que tu l'as ecrit a la main. Mais comme l'a devine anonyme plus haut, a un moment donne, dans mon outil, les articles (ou les commentaires) sont dans une liste (un tableau a une dimension). Pour un outil de generation de joueb, c'est donc tres simple a manier.
Pour un navigateur, c'est toujours aussi simple a manier, et savoir que les articles sont :
a) des elements semblables,
b) les uns a la suite des autres sans rien d'etranger au milieu,
permettrait de faire des choses intelligentes, comme l'expansion ou l'inverse en un clic de souris. (comme l'explorateur de Windows le fait avec les repertoires, qui sont des listes de fichiers et d'autres repertoires).
C'est la meme philosophie que les CSS etc. : a la base, il y a tres souvent des informations tres semantiques (bases de donnees, systemes divers et varies), et on essaie de garder ces informations semantiques le plus longtemps possible, de les pousser jusqu'au client, pour que ca soit l'utilisateur et non le webmaster qui decide comment les informations peuvent etre traitees.
> "ul et ol ne sont pas neutres côté présentation induite"
C'est vrai. Plus j'y reflechi, et plus je trouve que ul et ol sont mal nommees. Ce sont toutes les deux des listes ordonnees, et la seule difference est visuelle, ol est numerotee.
Tout ca pour dire que pour moi, ca me parait toujours aussi sense de mettre les oneliners dans une liste ul. :-)
Re: Re: Re: Re: Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
"C'est vrai. Plus j'y reflechi, et plus je trouve que ul et ol sont mal nommees. Ce sont toutes les deux des listes ordonnees, et la seule difference est visuelle, ol est numerotee."
??
Je ne comprend pas ce qui te faire dire cela Biz.
OL (Ordered List) est sensé représenter une liste ordonnée si l'on considère que la liste est numérotée à l'affichage (par défaut) d'un navigateur,
mais UL (Unordered List) n'est pas ordonné
Dans le code d'ailleurs, rien n'ordonne les éléments sous UL et OL. Je trouve même que ces deux types de listes ne sont pas ordonnées.
Pour remonter plus haut dans la discussion ("ul = serie et ol = sequence"), je ne pensais aucunement cela.
Je rapproche UL et OL de la série, et symboliserais la séquence par une suite de "P".
Enfin, je trouve l'exemple de Laurent très intéressant, surtout le rapprochement avec les specs Xhtml 2.0 et l'élément "section". Cependant je trouve, que cet exemple commence à "plier" le html/xhtml pour l'obliger à faire ce à quoi il n'est pas destiné mais qui le sera avec l'élément "section" de la prochaine spec.
Je comprend les démarches présentées mais je pense que l'emploi de UL/OL reste à un niveau "simple" en html3.2/html4/xhtml1 (liste de mes courses, de mes adresses mail... mais pas de mes dialogues oneliners)
??
Je ne comprend pas ce qui te faire dire cela Biz.
OL (Ordered List) est sensé représenter une liste ordonnée si l'on considère que la liste est numérotée à l'affichage (par défaut) d'un navigateur,
mais UL (Unordered List) n'est pas ordonné
Dans le code d'ailleurs, rien n'ordonne les éléments sous UL et OL. Je trouve même que ces deux types de listes ne sont pas ordonnées.
Pour remonter plus haut dans la discussion ("ul = serie et ol = sequence"), je ne pensais aucunement cela.
Je rapproche UL et OL de la série, et symboliserais la séquence par une suite de "P".
Enfin, je trouve l'exemple de Laurent très intéressant, surtout le rapprochement avec les specs Xhtml 2.0 et l'élément "section". Cependant je trouve, que cet exemple commence à "plier" le html/xhtml pour l'obliger à faire ce à quoi il n'est pas destiné mais qui le sera avec l'élément "section" de la prochaine spec.
Je comprend les démarches présentées mais je pense que l'emploi de UL/OL reste à un niveau "simple" en html3.2/html4/xhtml1 (liste de mes courses, de mes adresses mail... mais pas de mes dialogues oneliners)
Re: Re: Re: Re: Re: Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
Oups, je me reprends à propos de :
"Dans le code d'ailleurs, rien n'ordonne les éléments sous UL et OL. Je trouve même que ces deux types de listes ne sont pas ordonnées."
Je veux dire que la liste ordonnée l'est bel et bien mais que, dans le code, si ce n'est la précision par l'élément OL, chaque élément de la liste ne comprend rien de distinctif pour dire "premier élément", "second", etc.
"Dans le code d'ailleurs, rien n'ordonne les éléments sous UL et OL. Je trouve même que ces deux types de listes ne sont pas ordonnées."
Je veux dire que la liste ordonnée l'est bel et bien mais que, dans le code, si ce n'est la précision par l'élément OL, chaque élément de la liste ne comprend rien de distinctif pour dire "premier élément", "second", etc.
Re: Re: Re: Re: Re: Re: Re: une liste, un arbre? une citation, un paragraphe, un commentaire ?
Pour moi, les deux listes sont ordonnees, parce que les elements sont affiches dans l'ordre ou ils sont ecrits dans le code. Une liste non ordonnee, pour moi, c'est une liste d'elements dont l'ordre pourrait tres bien etre inverse par des programmes : un editeur lit le fichier xml, stocke les elements de la liste dans une structure pas forcement ordonnee (hachage par exemple), et resauve le fichier xml avec les elements pas forcement dans le meme ordre. Et ca serait pareil visuellement : le navigateur pourrait placer les elements dans l'ordre qu'il le souhaite, par exemple si ca facilite la mise en page (moins de retours a la ligne, de traits d'union pour couper des mots etc.). Ou dans l'ordre que l'utilisateur souhaite : alphabetique en suivant les conventions de tel ou tel pays pour les caracteres un peu speciaux.
Je ne suis pas le W3C, mais moi j'aurais fais une seule liste, ordonnee, et j'aurais considere que la numerotation ou non, c'est une question de presentation : a mettre dans les CSS. Au meme titre que la numerotation des titres par exemple, je ne sais pas si c'est prevu ou si ca existe deja, mais pouvoir numeroter automatiquement les titres, ca serait chouette. :-)
Je ne suis pas le W3C, mais moi j'aurais fais une seule liste, ordonnee, et j'aurais considere que la numerotation ou non, c'est une question de presentation : a mettre dans les CSS. Au meme titre que la numerotation des titres par exemple, je ne sais pas si c'est prevu ou si ca existe deja, mais pouvoir numeroter automatiquement les titres, ca serait chouette. :-)
Numéroration des titres
>Au meme titre que la numerotation des titres par exemple, je ne sais pas si c'est prevu ou si ca existe deja, mais pouvoir numeroter automatiquement les titres, ca serait chouette. :-)
On peut le faire aisément avec le contenu généré en css, qui inclut des compteurs. Voir:
http://www.yoyodesign.org/doc/w3c/css2/generate.html#counters
Par exemple, pour numéroter les titres h2 en ramenant le compteur à zéro après chaque titre h1:
h2:before {
content: counter(titre2) ". ";
counter-increment: titre2;
}
h1 {
counter-reset: titre2;
}
Le hic: à part Opera, très peu de navigateurs supportent les compteurs générés en css (évidemment pas IE windows, quant à Mozilla... peut-être le tout dernier, je n'ai pas vérifié)
Je m'en suis servi pour indiquer les sections et sous-sections dans le petit exemple d'utilisation des listes.
On peut le faire aisément avec le contenu généré en css, qui inclut des compteurs. Voir:
http://www.yoyodesign.org/doc/w3c/css2/generate.html#counters
Par exemple, pour numéroter les titres h2 en ramenant le compteur à zéro après chaque titre h1:
h2:before {
content: counter(titre2) ". ";
counter-increment: titre2;
}
h1 {
counter-reset: titre2;
}
Le hic: à part Opera, très peu de navigateurs supportent les compteurs générés en css (évidemment pas IE windows, quant à Mozilla... peut-être le tout dernier, je n'ai pas vérifié)
Je m'en suis servi pour indiquer les sections et sous-sections dans le petit exemple d'utilisation des listes.
Version XML
- Cette page est peut-être encore valide XHTML1.1 et CSS sans tableaux.
Thème inspiré par Bryan Bell.
Thème inspiré par Bryan Bell.
Dans la meme idee...