Bonjour votre avis svp merci !

Bonjour à tous

après avoir lu et travaillé le html et css, je vous soumet la 1ere partie du site.

Alors, je vous donne le lien direct de la 1ere page car l'index n'est pas réalisé. Je m'explique, j'herbergais un site pour mes élèves avant, ils avaient donc l'adresse !
Et comme là, je raconte mes vacances, j'ai pas trop envie qu'ils y aillent. Donc, en index, j'ai mis "le site n'exite plus" avec un lien caché. Je vous fais grace de la recherche

voilou..... donc je veux bien lire vos critiques sur ce début de site .
En tout cas, merci à tous ceux et celles qui prendront un petit peu de leur temps pour m'aider

Le site : http://olivier.moulin18.club.fr/pagecr/lerecit.htm

merci beaucoup a bientot

hélly

En vrac quelques détails. Je n'ai pas plongé en profondeur.

- Déjà, évites le Comic Sans MS comme la peste. Pour certains habitués du net (dont moi-même), celle-ci a tendance à provoquer d'irrépressibles crises d'urticaire....

- Evite de même le bleu souligné pour quelque chose qui n'est pas un lien. Sur internet, « bleu souligné » et « lien hypertexte » sont devenus synonymes, et contrevenir à cette convention a tendance à désorienter les visiteurs.

- <span class="gras"> : non, ce n'est pas du gras. Un titre (<hx>), une emphase (<em> ou <strong>), à toi de voir, mais du « bête » gras, sûrement pas...

- <span class="couleur">lancha</span> : <em> ?

- <a class="info" href="#">soda La Parada<span> : Ce n'est pas un lien, vu que ça provoque juste l'apparition d'une infobulle. Un <a> avec la petite main, ça donne envie de cliquer, et ensuite de se demander pourquoi rien ne se passe. Niveau esthétique, je conseillerais plutôt le curseur d'aide (la flèche avec le point d'interrogation, comme sur les <abbr>). Niveau marquage, là tu peux mettre un <span>

L'explication sur la home-page est une bonne initiative, mais en pratique personne ne la lit, alors autant faire en sorte que cela soit le plus intuitif possible...

- pour les images, tu devrais plutôt mettre, à mon sens, une image flottante à gauche qu'un tableau. En effet, il s'agit là d'un artifice de présentation et le tableau est loin de s'imposer (il est même plutôt déconseillé, en fait)

- <li> > </li> : d'un point de vue sémantique c'est pas joli joli non plus

- je verrais bien un menu quelque part avec tous les jours accessibles en un clic, parce que là c'est assez pénible à parcourir.

Salut et merci pour cette analyse qui m'aide beaucoup.

- alors, j'ai changé effectivement cette couleur bleue qui s'apparente à des liens (j'y avais meme pas pensé). Par contre, je ne vois pas trop le pblm du comic .... ?

- j'ai mis un <strong> pour le gras
- pour le couleur, par contre le em ne me semblait pas suffisant....
- pour les bulles, j'ai bien compris ton avis. Mais comment fait on pour avoir l'autre curseur et est ce que l'effet de boite sera le meme ?
- Pour les images , j'avais mis un float au début mais mon pblm (d'ailleurs , il reste un clear both ds mon css) c'est d'aligner la photo avecle paragraphe qui peut etre de differente taille !!! Peux tu me dire comment faire ?
- enfin, pour les <li>, je comprend plus car on m'a dit que c'etait mieux semantiquement que d'ecrire ds un <p> ou un <div> ... ?

-enfin, pour le menu, tu parle d'un menu qui serait present ds toutes les pages ?

merci en tout cas, ca me fait du boulot mais c'est cool

si tu as le temps de me tenir au courant
hélly

helly a écrit :
Par contre, je ne vois pas trop le pblm du comic .... ?

Bonjour helly,

Ci-dessous une bonne ressource pour les polices de caractère

http://edu.ca.edu/article67.html

Bonjour,
Pour le comic sans S.F. devait penser à ce comité: Ban comic sans
http://bancomicsans.com/image/bunnypunch.png

helly a écrit :
enfin, pour les <li>, je comprend plus car on m'a dit que c'etait mieux semantiquement que d'ecrire ds un <p> ou un <div> ... ?

S.F. a tout à fait raison. Et toi, tu as effectivement de quoi ne plus rien y comprendre.

<attention, coup de gueule>

Une petite astuce préalable : les gens qui ont la bouche pleine de Sémantique (avec une grosse majuscule) et de pas bien sémantiquement, sont en règle générale très sympathiques, bien intentionnés... et complètement ignorants sur ce sujet.

La "sémantique" HTML est trop souvent vue comme une somme de principes absolus, éthiques, que chacun peut d'ailleurs inventer à plaisir puisqu'ils ne sont écrits nulle part noir sur blanc. Cela permet d'asséner des péremptoires C'est pas sémantique, ça au pauvre gars qui cherche simplement à obtenir tel résultat, avec pour seul conséquence de lui compliquer la vie. C'est très valorisant pour le sémantiseur.

Mais la "sémantique Web" n'a rien d'éthique. Ce n'est pas une religion, une philosophie, une sorte de principe vague et éthéré pour les purs. Elle n'est surtout pas destiné à définir ce qu'un code doit ou ne doit pas être dans l'absolu, pour... pour quoi au fait ? Pour faire joli, se faire plaisir ou se gargariser ?

C'est bête, la sémantique. Très bête. Et très concret. D'où la question à poser systématiquement au sémantiseur pour le faire taire à coup sûr : Oui... Mais ça va servir à quoi, concrètement, ton truc ?

<exemple entre parenthèses>

C'est la vieille histoire des sémantiseurs qui vous disent de mettre vos citations dans des <q>. Comme ça, pour le principe. Parce que <q>, c'est sémantique, na!.

Ce qui ne sert strictement à rien, en l'absence du principal apport de l'élément <q>, qui est son attribut cite servant à indiquer l'URI de la source de la citation. L'attribut, lui, est exploitable (sauf que nos navigateurs actuels ne savent pas le faire ). Le <q>, en lui-même, n'aura comme conséquence éventuelle qu'une différence de présentation (des guillemets, un changement de voix) parfaitement possibles avec d'autres balisages. En d'autres termes, <q> n'est pas spécialement sémantique. Ce qui est sémantique, c'est son attribut cite et la métadonnée qu'il permet d'exploiter. Mais le sémantiseur est ignare. Il ignore en général tout de l'attribut cite. Il met juste ses citation entre deux <q> et il est content.

</exemple>

Alors, sémantique, c'est quoi ? Tout simplement "Comment faire en sorte que ceci puisse être compris de telle manière par telle machine afin qu'elle puisse l'exploiter et en faire quelque-chose d'utile pour l'utilisateur" (sic).

Ce "quelque-chose" est très souvent, au plus simple, un rendu affiché dans un navigateur, puisque nous en sommes à peine aux premiers vagissements du Web sémantique (on ne peut encore même pas parler de balbutiements). Avec plus d'ambition, il s'agit d'autres types de traitement du contenu (indexation, réutilisation, traduction, extraction d'une catégorie donnée d'infos, etc.)


Revenons à nos moutons et à ces liens. Ici, quel est le traitement attendu ? Grosso modo, produire un menu linéaire ressemblant à un fil d'ariane. Les aspects concrets sont :
- les liens doivent s'afficher en ligne
- un séparateur > doit apparaître entre chaque lien
- cela doit être également bien rendu dans d'autres medias que le media screen, en particulier quand la page est lue par une synthèse vocale.

Pour le reste de la pseudo-sémantique :
- que ce soit un <ul>, un <p>, une <div> ou des cacahuètes ne changera rien, puisque sémantiquement la notion de menu n'existe pas en HTML. Pour le plaisir illusoire d'être "sémantique", on pourrait mettre un élément <map> (quoi que, sur le fond, ça se discute ici...), mais cela n'a aucun intérêt étant donné l'implémentation nulle de cet élément, et son absence d'avenir dans les implémentations prévues.
- Que le séparateur > soit inséré ou non dans le contenu, soit généré ou non par CSS... n'a rien de sémantique ou de pas sémantique. C'est un choix à faire sur le degré d'abstraction du code HTML, c'est tout. Et ce choix est fonction de l'interopérabilité recherchée. Pour que ce séparateur passe dans le plus grand nombre de navigateurs possibles, il faut qu'il soit dans le contenu. Dans l'idéal, il faudrait pouvoir l'abstraire du rendu vocal de la page, car il est désagréable à entendre, mais ce n'est pas vital.

Donc, on a, sémantiquement :
- trois liens
- deux >
- une ligne.

<p>
 <a href="...">Accueil du costa</a>
 &gt;
 <a href="...">Le récit</a>
 &gt;
 <a href="...">Aller à la page 1</a>
</p>

Simple, direct, et basta !

Déçus ? Vous attendiez la révélation sémantique du siècle sur les fils d'ariane ? Ben non. C'est tout con, la sémantique, on vous dit.

Allez, quand même : remplacez <p> par <div> si ça vous gratouille, ça ne fera pas un pet de différence sémantique, mais ça ne coûtera rien et si ça vous fait plaisir, c'est très bien.

Mais le gugusse qui t'a convaincu d'utiliser une liste qu'il faut linéariser en CSS, qui aura des rendus grotesque hors CSS ou hors media visuel, et qui t'a compliqué la vie pour ça... j'aimerais bien l'avoir sous la main, tiens
Modifié par Laurent Denis (28 Mar 2005 - 10:57)

helly a écrit :
Par contre, je ne vois pas trop le pblm du comic .... ?

Dans le même genre que la précédente, vous en voulez une sur les typographes qui nous cassent les pieds avec leur fontes à eux qu'ils aiment et celles qu'ils n'aiment pas ?

Tant que tu spécifies une série de polices avec font-family, conclue par une police générique (serif ou sans-serif), tout va bien et tu as tout à fait le droit imprescriptible d'utiliser du Comic :les allergiques au Comic l'auront (s'ils ne sont pas idiots) désinstallée de leur machine, et auront donc ta page dans le second choix de police indiqué. Et tout le monde sera content sans avoir à inventer je ne sais quelle règle non standard.
Modifié par Laurent Denis (28 Mar 2005 - 09:10)

S.F. a écrit :

- <span class="gras"> : non, ce n'est pas du gras. Un titre (<hx>), une emphase (<em> ou <strong>), à toi de voir, mais du « bête » gras, sûrement pas...

- <span class="couleur">lancha</span> : <em> ?

Steve (S.F.) est très loin d'être un de ces sémanticiens sur lequels je m'époumonnais ci-dessus. Mais là, je ne suis pas d'accord :

<span class="gras"> n'est pas du gras ? Ben si. Justement. Mais ce n'est pas parce qu'on veut obtenir un affichage en gras qu'on veut aussi mettre une emphase. Cette confusion est tout le problème de <em> et de <strong>, qui devraient en fait être supprimés du XHTML (ce sera le cas de strong pour XHTML2.0).

Il faut se poser la question au cas par cas :
- est-ce que je veux juste mettre en gras ? (Et éventuellement produire un effet similaire en rendu vocal)
- est-ce que je veux mettre une emphase sur ce mot ? Et c'est là que ça déraille : emphase, c'est quoi ? Un mot clé à retenir lorsqu'on fait une synthèse du document ? Lorsqu'on indexe le document ? Autre-chose ? C'est inutilisable, car <em> a été défini de manière beaucoup trop vague. En fait, cet élément n'est resté dans les specs qu'en raison de l'éternel compromis entre HTML de structure et HTML de présentation. Et c'est un tort :
- <em> est trop mal défini pour avoir une sémantique exploitable
- <em> est, quoi qu'on en dise, un élément de présentation tel qu'il est employé dans la plupart des cas, à commencer par les sites "sémantiques". Qu'est-ce que les navigateurs font du <em> ? Ils lui appliquent de l'italique dans leurs styles par défaut. C'est tout. C'est purement présentatif. Qu'est-ce que les autre machines font du <em> ? Rien de particulier, parce que ce n'est pas une balise fiable.

Donc :
- évitez <b> et <i>, les éléments dépréciés qui posent des problèmes de compatibilité si vous souhaitez réutiliser votre code avec un minimum d'efforts sous une autre DTD (XHTML basic pour les mobiles, par exemple)
- vive le <span="gras"> pour ceux qui veulent être stricts
- vive le <em> pour ceux qui veulent croire être sémantique. C'est totalement inoffensif. <strong> vous embêtera le jour où vous voudrez passer au XHTML2.0

De toutes façons, les principaux intéressés à l'heure actuelle, c'est à dire les moteurs de recherche, exploitent le Web réel, et se servent aussi bien de <b>, de <span> et de <strong> pour repérer un mot-clé (voir google:define et son algorythme sémantiquement aberrant, mais concrètement très efficace).

Maintenant : <span class="couleur">lancha</span> : <em> ? Pourquoi diable la mise en couleur, seul résultat recherché, devrait-il passer par une emphase ? C'est très bien, <span class="couleur">lancha</span> !

Enfin, les info-bulles :

<a class="info" href="#">Ristaurante Mixto 
  v&eacute;g&eacute;tariano<span>1400 colones soit 3 euros</span></a>

Le seul problème est celui de l'interopérabilité et de l'accessibilité. Dans sa forme actuelle, l'information supplémentaire sera accessible dans tous les dispositifs de rendus, puisqu'elle est dans le texte. Elle ne sera pas agréablement rendue dans certains cas :
- Mettre au moins les espaces requis entre les mots pour que les synthèses vocales s'y retrouvent (tariano<span>1400)
- Mettre entre parenthèses le contenu du span pour que ça garde un sens d'incise quand le rendu se fait sans javascript (navigateur texte, navigateur graphique avec javascript désacrivé, lecteur d'écran...)

Plus simplement, quel est l'intérêt de cette information qui nécessite que l'utilisateur fasse l'effort de bouger sa souris ? alors qu'elle pourrait plus naturellement être incluse dans le texte, entre parenthèses, et ainsi accessible immédiatement ?

Je sais, c'est fun quand c'est dynamique. C'est surtout inutile.

Et mettre un <span lang="..."> à chaque fois que le texte n'est pas en français serait franchement plus utile
Modifié par Laurent Denis (28 Mar 2005 - 09:26)

Laurent a écrit :
Alors, sémantique, c'est quoi ? Tout simplement "Comment faire en sorte que ceci puisse être compris de telle manière par telle machine afin qu'elle puisse l'exploiter et en faire quelque-chose d'utile pour l'utilisateur" (sic).

Je prefère rester terre-à-terre est me contenter d'une définition qui serait d'utiliser chaque balise selon le rôle qui lui a été donné. Ensuite, aux agents utilisateurs de suivre les consignes également ou non. Si eux ne respectent pas les standards, je ne peux pas le faire pour eux.

Au sujet de la sémantique, j'avoue que je dois être un peu idiot puisque je me contente d'employer les balises telles qu'elles ont été définies :
- <q> pour des citations en ligne, puisque c'est sa fonction
- <li> pour des items de liste (par exemple des items de liste dans un menu)

C'est peut-être très bête, mais si le sens de <q> est de structurer une citation, pourquoi ne pas l'utiliser à cet effet ?

a écrit :
Mais le gugusse qui t'a convaincu d'utiliser une liste qu'il faut linéariser en CSS, qui aura des rendus grotesque hors CSS ou hors media visuel, et qui t'a compliqué la vie pour ça... j'aimerais bien l'avoir sous la main, tiens

Ben là aussi c'est de la bête application des consignes. Le gugusse c'est le W3C
http://www.la-grange.net/w3c/html4.01/struct/lists.html#h-10.4

W3C a écrit :
L'élément DIR était conçu pour la création de listes de répertoires multicolonnes. L'élément MENU était conçu pour les listes de menu sur une seule colonne. Les deux éléments ont la même structure que l'élément UL, seule leur restitution diffère. En pratique, l'agent utilisateur restituera une liste DIR, ou MENU, exactement comme une liste UL.

Nous recommandons fortement d'utiliser l'élément UL à leur place.

Et pour XHTML2 : http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-list.html#sec_11.2.

Je crois comprendre le message que tu veux transmettre : ne pas suivre les specs à la lettre. Mais si maintenant, on n'est plus obligé de lire les specs, où va-t-on ?

Non, Raphael, ça n'est pas du tout ça. Il s'agit au contraire de bien lire les spécifications, d'en comprendre la portée, et de s'en tenir à ce qu'elles déterminent, sans leur prêter ce qu'elles ne disent pas et qu'on voudrait y trouver parce que la vie serait ainsi plus belle. En un mot, arrêtons de fantasmer sur HTML4.01 / XHTML1.x.

Il faut comprendre que HTML (et avec lui XHTML1.x) n'est pas un langage universel, où chacun trouvera son compte. C'est un format aux capacités limitées et non extensibles, à la sémantique générique et floue. (comparez avec les formats appuyés sur RDF, tels que RSS1.0, FOAF, etc. Comparez avec XHTML modulaire, avec XHTML2.0, etc.)

Et qui souffre en outre de multiples incohérences historiques (pourquoi <b>, <tt>, <i> et pas <u> ? Pourquoi seuls <ins> et <del> sont-ils dotés d'un attribut datetime ? Pourquoi ne peut-on pas définir la langue d'un attribut indépendamment de celle du contenu de l'élément ? Comment la langue de traitement d'un document, nécessairement unique, pourrait-elle être déterminée en prorité à partir d'un entête HTTP Content-Langage qui, par définition peut contenir plusieurs indications de langues ? J'ai une liste de questions de ce type qui doit faire trois pages, je vous l'épargne.)

Finalement, HTML et XHTML1.X sont naturellement frustrants, parce que ce sont des formats de compromis, qui n'ont plus d'errata (pour HTML) et donc des outils très mal fichus et très en deça des possibilités du Web sémantique. En son temps, HTML3.0 (qui n'a jamais vu le jour), allait peut-être plus loin qu'HTML4.01. Mais ce chemin-là n'a pas pu être suivi, inutile de le regretter. Inutile surtout de s'y croire encore.

A partir de là:
- ou on se berce d'illusions en se disant qu'on va faire sémantique à tout va parce qu'on fait du XHTML1.0 conforme en inventant la moitié des règles de conformité en question,
- ou on fait avec l'existant, en sachant que ça a une portée très limitée, qu'il y a souvent plusieurs solutions dans le même format, et que le Web sémantique reposera sur d'autres formats en émergence (zut, une nouvelle révolution culturelle à assumer !)

Ainsi, la notion de menu n'existe pas en HTML. C'est agaçant, mais c'est comme ça. On aura beau tortiller la spec dans tous les sens, on ne lui en fera pas dire plus, et on en sera toujours réduit à se débrouiller avec son bon sens.

Le fait que la spec mentionne l'ex-élément <menu> dans le contexte des listes ne signifie pas qu'un menu [i]doit être toujours rendu à l'aide d'une liste. Il veut simplement dire que lorsqu'il y a une raison de rendre un menu sous forme de liste, l'élément générique de liste <ul> fait très bien l'affaire., et qu'un élément <menu> est donc superflu, et dès lors suprimé de la spec.[/b]

"Lorsqu'on a une raison de rendre un menu sous forme de liste". Tout est là. Voilà le bon sens qui pointe le bout de son nez. Zut, il faut réfléchir.

Ici, y a-t-il la moindre raison de rendre ce menu sous forme de liste ? Les questions sont:
- Qu'est-ce que cela va apporter comme bénéfice exploitable ?
- Qu'est-ce que cela apporter comme contrainte à gérer ?

Du point de vue de l'exploitable, qu'attend-on de ce menu ?
- qu'il s'affiche, se lise, se touche (en braille)... bien. A cet égard, <ul>, <div> et <p> sont de bénéfice équivalent en général. Mais ici, <ul> ne fait que produire un résultat qui se dégrade affreusement lorsque seul le HTML brut est rendu (faites l'expérience d'écouter un <li> > </li> et de généraliser ça à un usage régulier !)
- que chaque item puisse être isolé et extrait : que le conteneur soit un <ul> ou un <p> n'y change rien, puisque chaque item est défini par un <a>.
- que chaque lien puisse être exploité : là encore, <a> se suffit très bien à lui-même, quelque-soit son conteneur.

Du point de vue des contraintes :
- entre un élément ne nécessitant aucune mesure particulière en CSS et rendant bien sans CSS, d'une part,
- et une liste exigeant qu'on la bidouille en CSS pour la linéariser et qui, je le répète, aura un rendu grotesque ou amoindri sans CSS d'autre part...
...Le choix est immédiat, non ?

Mais attention : je retiens la solution du <p> pour un menu précis (celui de cette page, avec son contenu précis). Pas pour "les menus" en général. Puisque <menu> n'existe pas, il faut l'oublier et juger au cas par cas, sans généralité abusive.

Un trait caractéristique des sémanticiens ci-dessus est justement d'énoncer des Vérités Absolues et Intangibles, au lieu de réfléchir au contenu à structurer et de reconnaître que c'est problématique et que nous n'avons pas toujours, actuellement, les moyens de bien faire. "La Vérité", ça aide souvent à économiser la dépense en neurones (Zut, j'avais pourtant décidé d'arrêter les sarcasmes).

Pour les citations : la spec ne dit pas "on doit" utiliser <q> pour les citations. Elle dit "on peut", si on veut pouvoir faire ce que permet <q cite="...">.

Alors, effectivement, utiliser <q> pour baliser des citations, c'est bien, pour le principe. Mais ça ne sert à rien si on ne s'en sert pas pour la seule raison concrète de le faire : <q> a un attribut permettant de lui associer une metadonnée (cite).

En d'autres termes, mettre des <q>, oui, c'est avoir la satisfaction de ne pas faire de bêtise gênante. Mais on ne fait pas avancer le Web sémantique d'un orteil. Mettre des <q cite="http://example.org">, c'est déjà plus utile.

Et quand il n'y a pas de cite ? Reconnaître honnêtement que n'importe quel balisage permettant de générer les guillemets reviendra exactement au même que le <q> tout seul. Un <span class="citation">, par exemple.
Modifié par Laurent Denis (28 Mar 2005 - 12:50)

oulala, c'est compliqué tout ça. Moi qui pensait que c'était une science exacte...

Ben, du coup, je retravaille dessus donc si vous avez encore des conseils ou des remarques, n'hésitez pas (c'est comme ca qu'on progresse)

sinon, je voualis savoir si quelqu'un savait comment faire une bannière avec photofiltre ? Est ce que ce logiciel est bien pour faire une bannière ou non ?

merci d'avance

Hélly

http://olivier.moulin18.club.fr/pagecr/indcosta.htm : la nouvelle mouture toujous en construction

helly a écrit :
oulala, c'est compliqué tout ça. Moi qui pensait que c'était une science exacte...

Ben... non, justement, et c'était là l'enjeu
Merveileux mot de la fin pour cette parenthèse, que tu nous pardonneras, j'espère

a écrit :
Et quand il n'y a pas de cite ? Reconnaître honnêtement que n'importe quel balisage permettant de générer les guillemets reviendra exactement au même que le <q> tout seul. Un <span class="citation">, par exemple.

Sur un navigateur graphique utilisant les CSS, il n'y aurait visuellement pas de différence.
Mais n'est-ce pas un peu trop restrictif ? Un span "citation" n'aura aucune structure dans un agent utilisateur non graphique; ni d'apparence dans un navigateur sans CSS.

Pourquoi ne pas utiliser <q> (sans cite) parce que c'est ... son rôle ?!
Bien sûr qu'il ne s'agit que d'une proposition ("il pourrait..."), mais toutes les specs ne sont que des propositions.

Désolé, mais j'ai beaucoup de mal à accepter que "cela puisse revenir au même". Utiliser une balise pour une autre me gêne énormément.

Ou plutôt, j'ai du mal à cerner la limite de ton raisonnement : utiliser un <p font-size 15> "reviendrait aussi au même" qu'un <h1> ?
Plus loin : peut-on faire un document intégralement (et uniquement) composé de <div> et <span> ?


EDIT : désolé helly de rester hors-sujet, mais la discussion est intéressante
Modifié par Raphael (28 Mar 2005 - 13:34)

Pas grave, ca m'interesse un peu aussi

et sinon, vous avez d'autes idées pour améliorer ?

la je travaille sur le design de la 1ere page.... je mettrais le lien tout a l'heure

hélly

EDIT : nouvelle mouture du moment !
http://olivier.moulin18.club.fr/pagecr/costarica.htm

Modifié par helly (28 Mar 2005 - 16:35)

Avant tout, ce par quoi il aurait peut-être fallu commencer : le Web sémantique ne s'adresse pas à l'utilisateur, ni aux outils qui ne font que lui présenter du contenu. Il s'adresse aux machines (je n'aime pas ce terme, mais c'est celui de TBL, et je n'en vois pas d'autres). Aux machines à qui on va demander de traiter ce contenu pour en faire autre-chose, en réponse à une demande de l'utilisateur.

Concrètement, par exemple : "Donne-moi toutes les citations du blog de Raphael Goetter dans le Web francophone sur le sujet des brocolis"

Ce qui donne comme cible : <q cite="http://blog.alsacreations.com/...">... brocolis...</q>

A quoi sert un <q>... brocolis...</q>, même si le contexte indique que c'est extrait de ton blog ? A rien de plus qu'un <span class="citation">... brocolis...</span>. Visuellement, ces trois codes pourront avoir un rendu équivalent, y compris dans des agents non CSS. Mais sémantiquement, seul le premier est pertinent, et les deux derniers sont équivalents, c'est à dire tout aussi inutilisables l'un que l'autre.

Maintenant, si on parle de rendu utilisateur de ce code, ce qui est totalement différent : oui, tu as en partie raison (en partie, car beaucoup d'éléments HTML n'ont pas de rendu spécifique en dehors des navigateurs graphiques), mais cela n'a rien à voir avec la sémantique.

En effet, lorsque tu recommandes d'utiliser des balisages spécifiques selon leur définition W3C, c'est tout simplement parce qu'ils auront, dans une large palette d'UA, de fortes chances d'avoir un rendu par défaut qui facilite leur compréhension par l'utilisateur. Concrètement, le <q>...brocolis...</q> aura de fortes chances d'avoir des guillemets par défaut, ou d'être en italique, ou d'avoir une voix différente. Toutes choses qui aideront effectivement l'humain à délimiter la citation. C'est bien, et c'est en effet recommandable. Mais cela ne servira pas aux machines sémantiques. Et cela ne reposera en HTML (et donc en XHTML1.0) que sur un coup de bol : en effet, rien ne définit le rendu par défaut d'un élément HTML (ce ne sera peut-être pas le cas en XHTML2.0).

Alors, utiliser <q> sans cite juste parce que c'est son rôle... Oui, cela facilite les choses. Mais sans prétendre que c'est sémantique. Et en sachant que ça ne l'est pas, en fait. Que ça tient uniquement à des questions de présentation par défaut. Que ça ne fait pas avancer le Web sémantique Et surtout, qu'il peut y avoir, au cas par cas, des raisons tout à fait valables de ne pas le faire.

Raphael a écrit :

j'ai du mal à cerner la limite de ton raisonnement : utiliser un <p font-size 15> "reviendrait aussi au même" qu'un <h1> ?

Non, bien-sûr : contrairement à <q>, <h1> se suffit à lui-même pour s'identifier comme titre (signalant un contenu traitable comme tel) et plus précisément de tel niveau (exploitable dans une hiérarchisation).

La limite de mon raisonnement, c'est celle de la sémantique du HTML : celui-ci comporte quelques éléments à la sémantique immédiate et exploitable (<div> et <span> (!), <h1>...<h6>, <a>, <p> peut-être, quoique personne ou presque ne sache ce qu'est un paragraphe), et beaucoup à la sémantique illusoire car floue (<dl>, <address>, <samp>, <var>, <code>), inconsistante (<em>, <strong>), inexistante (<b>, <i>, <tt>, <pre>, <abbr>, <acronym>, <sup>), ou mal comprise (<q>, <blockquote>, <cite>, <dfn>).

Donc, l'objet de mon coup de gueule est : dites que ça se présentera en général mieux si on fait comme ça. Mais n'en faites pas des règles absolues, car ce n'est le plus souvent qu'une question de présentation.

Raphael a écrit :

Plus loin : peut-on faire un document intégralement (et uniquement) composé de <div> et <span> ?

Evidemment non. Il faudrait réinventer, en moins bien, et à coup d'attributs class restant à normaliser, la sémantique HTML

En revanche, on peut faire un document sémantique en XML, à coup de <div class="citation" source="..." auteur="..." ISBN="..."> et autres <div class="paragraphe">, <div class="titre">, <span type="code/php">, etc.

La pratique montre juste que des éléments spécifiques sont beaucoup plus pratiques qu'un élément générique raffiné par ses attributs. Donc on fera des <token role="..."> et on inventera Docbook

helly a écrit :

EDIT : nouvelle mouture du moment !
http://olivier.moulin18.club.fr/pagecr/costarica.htm

Bon, pour la peine, et puisqu'on squatte un peu ton fil :

- les changements sont conséquents
- le menu sera présent sur toutes les pages du récit, n'est-ce pas ?
- garde une hiérarchie de titre cohérente: après un <h1>, mets un <h2>, pas un <h3> : la hiérarchie des titres n'est pas obligatoire en HTML, mais elle sert pour certains outils, et particulièrement les lecteurs d'écrans qui permettent de "naviguer" dans ta page à partir de tes titres.
- Par pitié, remplace ce XHTML1.1 par un honnête XHTML1.0 ! En bref, XHTML1.1 ne s'utilise pas du tout comme cela, et ne t'apportera rien.

Si je veux garder c menu à toutes les pages, cela veut dire que les pages récit doivent etre diminuées de largeur ?

et comment je fais pour que ce menu + header apparaissent a chq fois
sur chq page ?

merci hélly

Très joli, ta première réponse, Laurent, tu devrais t'en inspirer pour faire une humeur Openweb .

Bon, je vais donner quelques petites explications sur mes remarques précédentes, que j'ai données "comme telles" parce que je n'avais pas trop le temps (j'ai répondu en vitesse).

- Pour ce qui est de mon "c'est pas sémantique", chez moi ça se limite à ce postulat :

a écrit :
Qu'est-ce que ça donne si je masque la feuille de style ?

En l'occurrence, autant je peux comprendre qu'une liste soit un menu, autant une ligne ">" dans cette liste, ça me paraissait assez déplacé. À vrai dire, personne n'a jamais dit (à ma connaissance) qu'il fallait impérativement une liste pour faire un menu ! (d'autant plus qu'ici, c'est discutable : sur trois ou quatre liens, seuls deux me semblent corrélés)

- Pour le Comic Sans MS, je l'ai dit : c'est un avis personnel, j'abhorre vraiment cette police. C'est très subjectif, j'en conviens, mais bon, on me demandait mon avis, après tout Mais bon, installer/désinstaller une police, c'est assez chiant, et puis bon, idiot ou pas, si on la désinstalle, on peut plus râler, c'est vrai quoi !

- Pour le <span class="gras">, je propse le titre parce que pour moi, ce qui est en gras est le titre du paragraphe. Et ensuite le <strong> parce que celui-ci fait souvent figure de "mini-titre", à l'échelle d'un paragraphe (plus que d'emphase forte, je trouve aussi que ce qualificatif ne veut rien dire). C'est pas forcément très joli pour un puriste, mais bon, on ne met alors pas le <strong> gratuitement, et c'est plus facile d'obtenir ce résultat avec un <strong> qu'avec un titre positionné savamment, toute polémique à part.

Le <em> conseillé un peu plus loin pour les mots en bleu, idem, c'est parce que l'impression que j'avais était que ces mots étaient en bleu dans le but de ressortir (et effectivement, ils ressortent, et bien). Ce qui est grosso-modo la définition d'une emphase. Un <em> avec un style approprié le ferait tout à fait, non ? Si c'est effectivement un effet esthétique, ma foi, un <span> le fait bien, mais ici, les mots bleus m'ont quand même l'air assez ciblés...

Mais ceux qui me connaissent savent que j'ai passé le stade de l'extrémisme stérile pour passer à un stade plus pragmatique, sans rater une occasion de râler, évidemment ! Et d'un point de vue pragmatique, justement, utiliser une balise pour son emploi théorique (exemple de <q>) ça a un avantage : ça simplifie diablement la création de CSS. Et la CSS est plus claire qu'avec une floppée de <span>. Et ça allège le code HTML. Et... Mais bon, je ne suis plus à une entorse au "règlement" près, quand il s'agit de faire un truc précis... Le tout est que cette entorse soit justifiée (une décision sans justification est une mauvaise décision, susceptible de provoquer des ennuis par la suite). La « sémantique » est loin d'être une science exacte !

Sinon, un truc dingue, c'est qu'ici les contributeurs ont la capacité intellectuelle de faire de grands textes sans fautes mais horriblement pénibles à lire, en fin de compte (je ne fais pas exception). Faudrait qu'on ait des cours de journalisme, histoire d'apprendre la concision

Raphaël, on peut avoir les lignes horizontales <hr /> dans le forum, ou un autre moyen sympa de segmenter nos réponses ? (titres, que sais-je encore ?) Merci !

helly a écrit :

Si je veux garder c menu à toutes les pages, cela veut dire que les pages récit doivent etre diminuées de largeur ?

et comment je fais pour que ce menu + header apparaissent a chq fois
sur chq page ?

merci hélly

haha ! C'est tout ton sujet qui est parti en aparté

Est-ce que tu peux élaborer un peu plus tes questions parce que je ne comprend pas très bien
Modifié par Stephan (29 Mar 2005 - 03:20)

S.F. a écrit :
Raphaël, on peut avoir les lignes horizontales <hr /> dans le forum, ou un autre moyen sympa de segmenter nos réponses ? (titres, que sais-je encore ?) Merci !

Le HTML n'est pas interprêté et je ne pense pas qu'n aille jusqu'à proposer du code wiki élaboré.
Pour tes séparations, tu peux peut-être utiliser la touche "_" ?

-> ________________________________________

(bon, j'avoue que sur un navigateur non graphique, ce ne sera pas la joie )
Modifié par Raphael (29 Mar 2005 - 06:12)