LaurentDenis

Ouh la la... je suis fatigué, moi : Je ne sais plus lire, en effet

Oubliez ça

En ce qui concerne les moteurs, ce sont des sites à part entière, sans aucune relation si tu n'as pas de liens entre les deux (ce qui ne serait pas une bonne idée )

Là, j'ai du mal à te suivre : permettre à l'utilisateur de passer d'une version linguistique à une autre est au contraire nécessaire. Si j'arrive sur la version anglaise (via un moteur, ou un lien dans un autre site, par exemple), je serais heureux de trouver sur la page anglaise un lien vers son équivalent français

cela dit, sans doute voulais-tu dire "pas une bonne idée du point de vue référencement" ? Auquel cas... c'est effectivement problématique

Le problème d'encodage ne doit pas être réglé dans le fichier lui-même. Celui était encodé en iso-8859-1 apparemment. Il faut donc d'abord rétablir le <?xml version="1.0" encoding="iso-8859-1"?>.

Ensuite, pour résoudre le problème signalé par le validateur, il faut intervenir au niveau serveur, pour modifier l'en-tête HTTP Content-Type qui renvoit actuellement la valeur US-ASCII et qui devra indiquer l'encodage réel du fichier, c'est à dire iso-8859-1.

Au plus simple, passer par php et ajouter :

header('Content-Type: text/xml; charset=iso-8859-1');

Vous mélangez tout ! Pourquoi utiliser un charset US-ASCII ? Y a-t-il une raison qui justifie cela ?

un coup vous utilisez des caracteres accentues (=> charset a utiliser : UTF-8), un coup vous utilisez les equivalents iso (=> charset a utiliser : iso-8859-1).

Vous devriez choisir un format d'encodage et vous y tenir. A moins que vous ne teniez a donner le tournis aux lecteurs RSS

Meme chose pour le reste du site. Si vous definisez vos pages HTML avec un charset iso-8859-1, alors vous ne devriez pas avoir de caracteres accentues (é, ê, è...) dans votre code HTML. La non plus ce n'est pas coherent

<{POST_SNAPBACK}>

Aïe Aïe Aïe ! Non !

ça n'est pas du tout ça, un encodage !

Le fait qu'un document soit en utf-8 ou en iso-8859-1 ne change rien. Les caractères accentués peuvent aussi bien être:

- directement présents : é

- présents sous forme d'entités caractères: & eacute;

- présents sous forme d'entités numériques: & #233;

Ce n'est que lorsque l'on utilise un caractère absent d'un encodage qu'il est nécessaire de passer par l'entité caractère ou numérique, celle-ci étant indépendante de l'encodage. Autrement dit, la lettre grec alpha dans un document en iso-8859-1 doit être encodé & Alpha; ou & #913;

Ici, ce n'est absolument pas nécessaire, et tant que nizouille se contentera de mettre des caractères accentués, il peut très bien les écrire littéralement, dans la mesure où son éditeur HTML gère l'iso-8859-1. Il peut aussi les encoder, ce qui ne sert à rien, mais ne pose absolument aucun problème.

L'image peut être placée en position absolue en CSS. Voir Initiation au positionnement CSS : 3. position absolue et fixe

Approximativement :

en HTML:
<div id="logo"><img src="..."></div>


Dans la feuille de style CSS:
#logo {
position: absolute;
left: 10px; /* à modifier selon les besoins */
top: 10px; /* à modifier selon les besoins */
}

Du danger des simplifications... Ce que dit le HTML 4.0 Block-Level Elements du WDG est un beau racourci... qui crée effectivement une certaine confusion.

<script> n'est pas alternativement un élément %inline et un élément %bloc. C'est un élément %inline uniquement.

En effet, la DTD HTML4.01 stricte déclare:

<!-- %inline; covers inline or "text-level" elements -->
<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">

Où est <script> là-dedans ? Tout simplement dans %special :

<!ENTITY % special
   "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">

En d'autres termes, <script> appartient à la catégorie %special, laquelle appartient elle-même à la catégorie %inline.

En revanche, <script> n'est pas un élément %block :

<!ENTITY % block
     "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
      BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

... là, pas de SCRIPT directement ou indirectement mentionné. (En revanche, on y trouve bien <noscript>)

Alors... Comment fait <script> pour pouvoir se mettre directement dans <head> et dans <body>, qui n'admettent pas d'éléments enfants %inline ? Tout simplement en vertu d'un cas d'exception :

<!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body -->

<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements -->
<!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- document head -->

Autrement dit, <script> bénéficie ici d'un privilège qui l'autorise à figurer dans <body> et dans <head>.

En HTML4.01 transitional, il en est de même, si ce n'est que <script> peut être mis directement dans <body> puisque l'une des particularités de transitional est d'y autoriser la présence d'un élément %inline. En revanche, on trouve la même règle d'exception pour <head>

On est donc dans un cas très différents de <ins> et <del> qui eux, sont explicitement des éléments alternativement %inline et %block, selon les DTD.

Maintenant, le problème reste entier : un <script> étant %inline... peut-il comporter des éléments %block ? Là, le WDG simplifie maladroitement : en effet, un <script> ne contient aucun élément HTML. La question ne se pose simplement pas.

En revanche, il peut générer un élément HTML %block... qui n'invalidera pas le document, mais qui n'en sera pas moins problématique.

C'est une des limites du HTML. XHTML résoud le problème, par exemple en faisant en sorte que document.write ne marche pas dans un script lorsque XHTML est traité comme du XML...

Dans le même ordre d'idées, <script> peut permettre de générer la balise de fermeture d'un élément ouvert hors du script. Si javascript est désactivé... l'élément n'est plus fermé Là encore, ce n'est plus possible en "vrai" XHTML.

Et puis, au fond, on le sait : javascript est intrinsèquement démoniaque

Ah... Pas simple, HTML4.01, sur ce coup là. Résumons:

L'élément <script> est un élément de type%inline. Pour cette raison (et d'autres, mais passons sur les détails des DTD), il peut se placer, en HTML transitional comme en strict:

- directement dans l'élément <body>

- dans l'élément <head>

- dans un élément %bloc

- dans un élément %inline

L'élément <noscript>, lui, est un élément de type %block. Il ne peut donc se placer (toujours en précisant qu'il y a d'autres raisons liés à des détails des DTD), que:

- directement dans l'élément <body>

- dans l'élément <head>

- dans un élément %bloc

La question est donc: pourquoi diable <noscript> est-il un élément %block et non %inline comme <script> ?

A cause de leur contenu, qui est fondamentalement différent. En effet:

- un <script> ne contient aucun élément HTML, mais ... du langage de script, c'est à dire d'une certaine manière du texte brut (en fait, c'est plus compliqué, car la présence d'un balisage HTML dans un script provoque un comportement spécifique du moteur HTML... mais passons. L'idée générale que c'est du texte est suffisante ici).

- un <noscript>, lui, n'est pas destiné à contenir du texte brut, mais du balisage HTML qui devra être interprété directement par le navigateur comme n'importe quel autre balisage. Et ce balisage ne peut pas être restreint à des éléments %inline : il faut que <noscript> puisse comporter des éléments %block pour permettre d'afficher des titres, des paragraphes, des tableaux, des listes, etc.

La plus grande permissivité du HTML4.01 transitional permet de placer dans <noscript> aussi bien du texte brut, des éléments %inline et des éléments %block. Ce n'est plus le cas en HTML4.01 strict, où il n'admet plus que des éléments %block.

Mais l'important est là: dès lors que <noscript> contient des éléments %block... il ne peut pas être placé dans un élément %inline. Logique imparable, non ?

Si l'accessibilité est une de tes préoccupations, ce type de redirection est très problématique : certains de tes visiteurs n'auront pas le "temps" de consulter le contenu de la page d'avertissement (dans un lecteur d'écran par exemple, ou tout autre circonstance ralentissant leur lecture) et se retrouveront à leur point de départ sans comprendre pourquoi le lien suivi ne marche pas.

Dans ma version initiale (celle de ma signature), le menu est aussi en include mais il est en bas de page et je le fais remonté en le mettant en position absolu comme dit plus haut.

Ce n'est qu'en le mettant en float et avec le clear:both que je mets l'include en haut de page pour le menu.

Est-ce que cela pourrait être la cause du délai d'affichage ?

Et si oui, comme garder le float et le clear:both tout en positionnant le <include du menu> après le contenu (donc en bas de page dans le code) ?

<{POST_SNAPBACK}>

Il est en effet probable que, sur une machine un peu lente, le traitement de la page soit suffisamment long pour qu'un affichage progressif de ce genre se produise.

Si tu souhaites inverser l'ordre de ton contenu pour obtenir <contenu> puis <menu>, tu peux conserver ton positionnement en float:

- float:right sur le <contenu> avec une largeur en %

- menu en flux de largeur donc variable selon les résolutions.

Mais en fait:

- si je ne me trompe pas, ton pied de page n'occupe pas toute la largeur d'affichage ? Auquel cas, la solution du menu en positionnement absolu est bien plus évidente.

- et finalement, ce petit problème de rendu progressif est-il vraiment essentiel au point de revoir ta mise en page ?

Hem... Il doit y avoir, au bas mot et à vu de nez, plus d'une trentaine de raisons potentielles pour que des images d'arrière-plan CSS ne s'affichent pas.

Comme on ne va peut-être pas toutes te les passer en revue, essayons un truc plus simple :

- l'url de ta page web ?

- ou au moins le code HTML et CSS concerné ?

Lafleur, en ce qui me concerne, et à la lecture de ton dernier message, le troll s'arrête là.

(Et je suis très tenté de fermer ce sujet si tu continues à l'alimenter de cette manière).

Pour être clair, inventaire des trolls :

Je ne vois pas en quoi le fait que le marquage d'une page soit correct ou non la rend plus similaire ou plus populaire

Encore une fois, il n'y a pas besoin de faire d'analyse très poussée pour se rendre compte que les buts du W3C reflètent une vision parfaitement américaine du monde et de la façon dont les gens doivent penser.

normal qu'un moteur propose des résultats censés plaire à la majorité de ses utilisateurs. Je ne vois pas bien en quoi il est intéressant qu'une thèse le plus souvent imbitable prenne la place d'une information vulgarisée sur le domaine, même si cette dernière est payante.

n'importe qui peut, au prix d'un moindre effort, produire un document qui, même codé de travers, peut être lu et compris par n'importe qui d'autre sur un ordinateur.

vous pouvez même ricaner entre vous à la lecture de pages bancales montées par d'autres moins velus que vous en la matière, mais quand vous avez l'air de déplorer le fait que vos mérites ne sont pas suffisamment reconnus par les moteurs, là, je trouve que vous exagérez un peu

L'un des mérites à mon avis de l'article d'Arno est de mettre en évidence le malaise et l'incompréhension mutuelle qui imprègne aujourd'hui tout débat sur les standards, celui-ci y compris.

Tout en renvoyant à mon tour au billet d'Eric ( http://blog.dreams4net.com/FudTrollEtUzine ) qui démontait parfaitement les erreurs à la base du discours d'Arno, je dois dire, contrairement à Denis, que ce "W3C Go Home" était aussi très pertinent, malgré son côté démagogique : il y a un Web de l'écran immédiat, indifférent à des problématiques plus complexes, qui a acquis une indéniable légitimité.

C'est ce Web du Wysiwyg, du SPIP historique, de monsieur tout le monde, mais aussi de nombreux "pros" jugés conservateurs, qui s'exprimait dans cet article. Je ne crois pas qu'on puisse réduire sa résistance à de la paresse, à de l'incompétence ou au confort de l'habitude. Elle exprime un besoin plus profond.

Ce besoin ne disparaîtrait d'ailleurs pas avec de nouveaux langages, quels qu'ils soient. Hixon demandait: "People obviously think they want a page layout language. How do we make them realise they have a page layout language (CSS), but that for the Good of the People they should work with semantics at the lowest level instead of working with formatting?" La réponse qu'on ne pourra pas, car ils n'ont pas vraiment besoin de différencier structuration et présentation. Ils n'ont surtout pas besoin d'un niveau d'abstraction élevé, mais uniquement d'un système concret de présentation à l'écran.

XHTML ou tout autre évolution n'y changera sans doute rien : il suffit de voir aujourd'hui le code des skyblogs : du XHTML1.1 (sic) - CSS purement présentatif sans aucun rapport avec les exigences qualitatives de ce format. Les skyblogs en XHTML, c'est une énorme aberation. Pas en raison de leur contenu, mais parce que les objectifs poursuivis ne sont pas ceux du XHTML.

Personnellement, je pense comme l'ont déjà dit Laurent et Kimberlyclarko qu'il ne faut pas enterrer le Html, et que les développeurs ont intérêt à rassurer "Mr tout le monde" sur ce point.

HTML restera non seulement nécessaire, mais surtout inévitable en tant que format graphique. Oui, ce n'est pas ce qu'il est supposé être. Mais c'est ce que son histoire en a fait, et c'est ce qu'entérine HTML4.01 transitional. Je préfère de loin qu'on invite à se servir intelligemment du HTML en ce sens, plutôt que de susciter le rejet de la notion même de standard.

Or, les moteurs majeurs influencent bien plus l'évolution du web que ne peut le faire actuellement le W3C. On aura l'occasion ces prochaines semaines je pense de le vérifier grandeur nature suite à l'initiative du rel="nofollow"

Heureux de te l'entendre dire On s'est un peu trop focalisé, à mon sens, uniquement sur le rôle des navigateurs. Il me semble que les moteurs vont occuper à présent de plus en plus visiblement le devant de la scène, et le "nofollow" vendu sous son emballage "sémantique" n'est sans doute qu'un premier pas.

Que se passerait-il si un acteur majeur du marché (au hasard Google) décidait du jour au lendemain de ne plus prendre en compte les H1 pour leur préférer les <font size="x"> sous le prétexte que ce serait une balise plus "moderne" ou plus massivement utilisée ?

Un simple constat : il existe aujourd'hui des navigateurs "conformes". Il n'existe aucun moteur "conforme". Et je ne vois aucun mouvement en ce sens chez les moteurs dominants du marché. Tout comme un navigateur en mode quirks, ils traitent de l'existant, dans l'immédiat, et avec toute liberté de modifier leurs pratiques au jugé.

Pour ton exemple XFN en revanche, je n'ai pas compris sur quoi tu te bases pour affirmer que le standard développé par le W3C ne se limite pas à une vision occidentale. Rien que la page "en 7 points" dont j'ai mis le lien est un condensé d'un idéal américain. Il est par exemple question de "libre arbitre". On essaie de compter les cultures dans lesquelles cette notion n'existe tout simplement pas ?

<{POST_SNAPBACK}>

La différence entre FOAF et XFN est que, dans le cas de FOAF, son extensibilité via les espaces de noms permet de d'étendre le langage afin de décrire autant de modes de relations sociales ou familiales qu'on le souhaiterait... Cette extensibilité n'est possible que parce qu'il s'agit d'un standard.

Autre exemple, peut-être plus accessible: revenons au XHTML. Si le mode de structuration actuel du XHTML ne répond pas à tes besoins, tu as la possibilité de créer tes propres structures additionnelles, toujours par le biais des espaces de noms (C'est le XHTML modulaire). Et ceci, là encore, n'est possible que parce qu'il s'agit d'un standard : faute de quoi, tes éléments structurels personnels seront dénués de sens pour tout autre personne (et dans n'importe quel navigateur).

Mais surtout, je pense que la solution est que les éditeurs de navigateurs continuent de faire des logiciels permissifs.

La démarche d'Opera, par exemple, qui version après version accepte quelques balises propriétaires de plus va dans le bon sens, même si je me doute que cela doit faire hurler les puristes.

<{POST_SNAPBACK}>

La permissivité des navigateurs proprement dite n'a qu'un impact limité, en fait.

En quoi consiste-t-elle ?

- les éléments HTML propriétaires ? Il n'en existe pas tant que cela (à titre indicatif, audioscope, bgsound, blackface, blink, bq, comment, embed, fn, ilayer, keygen,

layer, limittext, listing, marquee, multicol, nobr, noembed, nolayer, nosmartquotes,

plaintext, server, shadow, sidebar, spacer, wbr, xmp). Tous les navigateurs alternatifs en supportent quelques-uns parmi les plus courants, comme le célèbre marquee (Opera n'en supporte pas spécialement plus que les autres navigateurs).

- les éléments HTML dépréciés par les spécifications (X)HTML strictes, comme applet ? Leur support n'a aucune chance d'être modifié, puisqu'ils font partie des normes transitional.

- les extensions CSS propriétaires sont en forte augmentation... sous une forme à présent normalisée via CSS2.1 qui leur réserve une syntaxe spéciale (l'extension -o- pour opera, -moz- pour mozilla, etc)

- le javascript propriétaire : peu de changement à prévoir de ce côté depuis l'adoption par Mozilla du support du document.all indétectable, il me semble.

- le maintien de deux modes de rendu alternatifs: un mode de respect strict des standards, et un mode de rendu quirks assurant la compatibilité avec le comportement d'anciennes versions de ces navigateurs. On imagine mal sa disparition.

Ce qui compte davantage, je crois, c'est le fait qu'HTML ne dictant aucun processus de gestion d'erreur, chaque navigateur recours à ses propres modes de récupération. Et là, effectivement, la question se pose : faut-il "coller" comme c'est souvent le cas au mode de récupération d'erreur du navigateur dominant, autrement dit IE, afin de limiter la casse dans le rendu des pages conçues spécifiquement pour celui-ci ?

Le problème est que ce n'est pas toujours possible ni souhaitable. Opera, récemment, semble avoir plutôt revu légèrement à la baisse sa compatibilité avec le modèle IE. Par exemple, dans le traitement des dimensions attribuées abusivement à un élément en ligne non remplacé : la reproduction du comportement d'IE entraînait des erreurs ingérables par ailleurs...

Enfin, par le biais des types de contenu, les navigateurs récents peuvent s'ouvrir au support de nouvelles normes (XHTML modulaire par exemple) sans renoncer à la compatibilité avec la "soupe de balise" traditionnelle.

Et pour conclure, un constat : "monsieur tout le monde" (raccourci évidemment abusif) n'éprouve aucun besoin de faire des sites "sémantiques" (sic), "indépendants du média", "accessibles" ou autres qualités visées par les standards. Il cherche le plus souvent à faire un site essentiellement visuel.

Il faudrait peut-être en tirer la leçon et accepter l'inévitable, c'est à dire une utilisation du HTML (il n'y a pas de X, et c'est volontaire) en tant que format résolument concret, par opposition aux nouveaux formats plus abstraits. J'avoue que quand je vois un éditeur WYSIWYG prometteur comme Nvu se tourner vers la production de XHTML strict... je n'en vois pas l'intérêt. Ne vaudrait-il pas mieux favoriser l'accès de 'monsieur tout le monde" à un HTML sans doute moins ambitieux, mais pour lequel les éditeurs sont plus aisés à mettre en oeuvre ?

Tiens, sur ce coup, c'est moi qui vais faire hurler les puristes

Tu dis aussi : "Ce n'est pas le W3C qui édicte, qui choisit. Chaque organisme et même chaque personne intervenant sur le Web peuvent s'y associer." C'est certainement vrai (encore que, je cause pas le britiche, je peux aller causer avec eux ?), mais dans les faits, chaque organisme et chaque intervenant ne s'y associe pas.

J'ai du mal à voir la validité de ce raisonnement, qui consiste à dire: Il existe un processus de consensus... Je choisis de ne pas y participer pour y faire entendre mon point de vue... Ma non participation volontaire rend ce consensus discutable

Une seule langue, c'est l'absence de la richesses qu'apportent les autres langues ! C'est l'impossibilité de se confronter à des pensées structurellement  différentes !

Coïncidence, j'étais en train de relire une critique adressée à un format développé hors du processus W3C, justement. Il s'agit de XFN, qui vise à exprimer les relations sociales à travers les hyperliens. L'un des points de la critique faite à XFN est justement que ce format, lorsqu'il s'agit de décrire les relations de type familiales :

- reflète uniquement des modèles occidentaux,

- et se limite, dans cette vision occidentale, à une définition très "bien pensante" des relations de couple.

Limitations qu'on ne retrouve pas dans FOAF, autre format servant le même propos, mais dans une approche "normalisée W3C"...

Je cite cet exemple pour montrer simplement que la recherche d'un "format standard" n'a rien de réducteur en matière culturelle, et que pour être un "standard", il doit justement éviter de tomber dans ce travers...

Ils sont permis mais il faut les écrire en minuscule (comme tous les attributs en XHTML) , donc en écrivant "onmouseout" tu ne devrai plus avoir de problèmes de validation

<{POST_SNAPBACK}>

Une remarque : les spécifications, les "standards" si vous préférez, n'ont pas vraiment pour rôle premier de vous renseigner sur ce genre de choses. Ils ont plutôt pour but de permette l'élaboration et donc l'utilisation d'outils gérant cela à votre place.

Ce qui est amusant, là, c'est que très peu de gens, avant de poser ce type de questions, passent simplement leur code à travers un outil comme "Tidy", dont le rôle est justement de gérer cela, en passant automatiquement les noms d'attributs et d'éléments en minuscules

AMHA, avant de se poser une question sur la non-validation d'une page Web, on devrait d'abord voir ce que donne la même page après passage dans un outil tel Tidy. Par exépience, le gain de temps est considérable.

1/ j'ai fait un formulaire qui contient plusieurs pages, chacune d'entre elle contient un bouton submit. Cependant,pour passer d'une page a une autre sans cliquer sur le submit, j'ai insere des liens (banal!) <A HREF="mapage2.htm">page2</A>....<A HREF="mapage9.htm">page9</A>et je veux qu'en cliquant sur un de ces liens ca m'enregistre les donnees du formulaire comme si j'avais clique sur le bouton submit de la page avant de passer a la page desiree. Comment faire pour associer a chacun des liens une focntion de submit?

<{POST_SNAPBACK}>

Juste une question, avant de commencer à produire des hacks et des bidouilles en série: pourquoi diable vouloir "passer d'une page à l'autre" sans recourir au mécanisme normal de soumission de formulaire ?

- Qu'est-ce que tu y gagnes ?

- Qu'est-ce que l'utilisateur y gagne ?

Je suppose qu'il doit y avoir de bonnes réponses à ces questions.

Disons plutôt que le gain serait nul :

- le problème reste entier lorsque le navigateur applique la CSS par défaut si celle-ci dégrade l'affichage dans la résolution du visiteur

- tu peux de toutes façons créer une mise page CSS qui s'adapte à la résolution d'écran sans avoir à passer par javascript (ceci est vrai pour les résolutions desktop. Le problème est plus complexe pour les très petits écrans de mobiles ou le web-tv. Mais dans ce cas, c'est le navigateur qui procède aux adaptations nécessaires, s'il est bon).

L'idée majeure est créer une mise en page "fluide", et non pas figée dans des dimensions rigides.

Reconnaissons aussi que la conformité au W3C n'est pas une condition suffisante, ni même nécessaire d'accessibilité. En tant que daltonien, je remarque par exemple que la même proportion (si ce n'est plus) de sites valides W3C me sont inaccessibles ou difficiles d'accès.

<{POST_SNAPBACK}>

Pourquoi faut-il toujours boucler sur les mêmes questions ?

La validité (X)HTML n'a jamais été supposée rendre un site accessible (Elle ne le rend même pas "conforme" à la norme (X)HTML visée, en fait). La validité n'est qu'un critère de l'accessibilité, parmi plusieurs dizaines beaucoup plus spécifiques, notament ceux visant la manière dont l'information est véhiculée par les couleurs, ou la façon dont celles-ci contrastent.

Et l'accessibilité elle-même se décline en plusieurs niveaux.

Et l'accessibilité ne peut faire l'objet d'aucune validation mécanique.

Autrement dit un site "valide W3C", s'il prétend être ispo facto accessible, ne dit rien d'autre qu'une énorme sottise.

Cela ne t'empêche pas de mettre un lien dans <h1>  [j'espère que je ne vais pas faire hurler Monique et Laurent]

<{POST_SNAPBACK}>

Tu sais bien que je ne hurle que sur les mécréants. Or ton <a> dans un <h1> est parfaitement canonique, et sanctifié par les plus hauts textes sacrés, comme suit :

<!ELEMENT (%heading;)  - - (%inline;)* -- heading -->

<!ATTLIST (%heading;)

  %attrs;                              -- %coreattrs, %i18n, %events --

  >

(Ce qui en langage profane signifie bêtement que les éléments %inline, dont le <a>, peuvent être mis dans les éléments %heading, c'est à dire <h1>...<h6> )

Ces considérations de bistrot pour dire que si je trouve légitime le respect des standards, je trouve tout aussi légitime de détourner les balises aux fins que l'on juge utiles ou amusantes. Le W3C met à notre portée des outils. C'est très gentil à lui. Mais nous sommes encore libre d'en user à notre sauce, tout de même ?

<{POST_SNAPBACK}>

Ha, la vieux malentendu sur le rôle du W3C et des standards dont il permet la définition : cet organisme et ces standards n'ont aucune valeur ni aucune autorité, ni aucune légitimité en eux-mêmes. Et aucun auteur de page Web n'a d'autres obligations envers les standards que celles qu'il choisit d'adopter.

Promoteurs et adversaires des "standards" oublient souvent:

- que W3C ne fait que permettre une élaboration "sociale", collective, de ces normes qui font l'objet d'un processus (souvent jugé trop long) de critique, de tests, d'amendements, etc. Ce n'est pas le W3C qui édicte, qui choisit. Chaque organisme et même chaque personne intervenant sur le Web peuvent s'y associer.

- que ces standards n'ont pas d'intérêt en dehors des objectifs explicites qu'ils ont reçu. Parmi ceux-ci figurent par exemple des notions comme l'interopérabilité, l'accessibilité, l'indépendance envers le media, la réutilisabilité du contenu, etc. Si, dans un projet donné, tu as d'autres priorités que ces objectifs, alors tu n'as en effet pas à te préoccuper des standards : ceux-ci sont totalement hors-sujet en ce qui te concerne.

La "dissociation forme fond" en donne d'ailleurs un très bon exemple : revoir simplement la justification qu'en donne le W3C dans .

Architecture of the World Wide Web :

L'expérience montre que la séparation du contenu, de la présentation et de l'interaction favorise la réutilisation du contenu et son indépendance à l'égard du dispositif de rendu ;

Si tu ne te préoccupe pas particulièrement de réutilisation du contenu ni d'indépendance envers le media de rendu.... ma foi, fort heureusement, comme tu dis, libre à toi d'user du Web à ta sauce

J'ai un petit problème avec les <h1>    ...

Lorsque j'utilise cette balise (pour le référencement), cela provoque un saut de ligne.

<{POST_SNAPBACK}>

Je suis pris d'un doute affreux. Tu ne ferais pas quelque-chose comme :

<div>Blabla bla blabla, <h1>mot clé</h1> blabla... <h1>Autre mot clé</h1>...</div>

Par hasard ?

Voir HTML4.01: ( http://www.w3.org/TR/html401/struct/links.html#adef-rel )

rel = link-types [CI]

This attribute describes the relationship from the current document to the anchor specified by the href attribute. The value of this attribute is a space-separated list of link types.

On écrit donc simplement :

<a href="document.html" rel="external nofollow">external link</a>

Mais bien-sûr, rien, ni personne, ni surtout les inventeurs du "nofollow"... ne peut dire actuellement si "nofollow" sera pris en compte lorsqu'il n'est pas la seule valeur d'attribut.

Il y a diverses autres incertitudes de cette ordre... Mais je suppose que c'est ce qui fait le charme des pseudo-spécifications inventées unilatéralement et de manière purement propriétaire

Moi j'aime bien Opera. Dommage que la pub soit si imposante... :/

<{POST_SNAPBACK}>

Dommage que l'ouverture du porte-monnaie soit devenue aussi difficile chez les utilisateurs du Web.

(Précision: je ne parle pas de sortir son carnet de chèque en ayant au préalable discuté d'un emprunt avec son banquier, ce que nécessitent certaines autres applications parfois indispensables pour l'accessibilité, mais à la fourchette de prix nettement différente).

Opera vocal est actuellement en version bêta :ce n'est pas la version finale, mais une version de test. La version finale est annoncée par Opera... pour "le début de l'année"

Pour la lecture en français, il faudra attendre qu'IBM adapte ses librairies vocales, puisque cette partie du navigateur repose sur la technologie d'IBM. Ni Opera ni IBM n'ont donné la moindre information sur la date d'une future version française.

Je ne suis pas allé très loin dans le site : parcours de la page d'accueil, de la page "Navigation au clavier", et dela page "Cinema" avec IBM HPR. Quelques remarques rapides, en vrac :

- ton menu étant placé en tête de contenu, fournir un lien d'évitement de la navigation donnant accès directement au contenu. Et racourcir le "L'actualité de la ville de Cholet conforme aux recommandations du w3c sur l'accessibilité du web aux handicapés ", prodigieusement agaçant et inutile.

- revoir le choix des accesskeys, inopérants dans de nombreuses applications. Tu as manifestement lu http://openweb.eu.org/articles/accesskey_e...non_transforme/ puisque tu en cites un extrait, me semble-t-il

- écrire "cinéma dans le menu, avec son accent. j'ai eu du mal à comprendre ce que voulait dire le "sinnma" que j'entendais

- écrire en toutes lettres les noms des jours dans le tableau des horaires de cinéma : "mer" est un peu déroutant.