jd_

Je te remercie pour ta question Je vais reprendre mon exemple du livre - quand bien même il est sujet à critique, ce sera plus simple pour exposer l'idée. Quand je prend un livre dans ma bibliothèque, j'en observe d'abord l'allure générale, soit pour faire vite, la couverture. Au minimum (exceptions rares mises à part), elle comporte le titre du livre, pour pouvoir l'identifier (oublions les considérations de tranche, recto, verso). C'est ce qui me semble être le "niveau le plus haut" pour un document de type livre - le premier contact en sorte, qui donne un renseignement nécessairement et volontairement étiolé, mais crucial. Ensuite, j'ouvre le livre. Dans la majorité des cas (encore une fois, hors exceptions rares et propres au support du livre), j'ai successivement et au minimum : un rappel du titre mentionné sur la couverture (parfois précisé d'un sous-titre), puis se déroule à mes yeux l'ensemble du contenu du livre avec des séparations en chapitres, sous-chapitres, (...), paragraphes. Le titre (title) d'un document web me semble jouer le même rôle que le titre inscrit sur la couverture du livre : il fait partie d'un ensemble de méta-donnée (encore que le terme ne soit pas exact, mais il est parlant). C'est aussi ce titre-là que je souhaiterais pouvoir rappeler (ou non, pour un aspect pratique propre au web) dans le contenu du document (ie. les pages du livre), au même niveau que le reste du "plan didactique" (entendre par là la "structure" qui permet de s'y retrouver une fois entré dans le livre/le document). Une objection : le titre inscrit sur la couverture n'est-il pas déjà un élément du livre, du contenu ? Bien sûr que si, mais tout de même : ce titre de couverture n'en est pas moins à part, et physiquement (il n'est pas inscrit dedans, mais dehors), et de part sa fonction (ce qu'il dit caractérise le livre). Evidement, cette approche est assujettie aux réserves déjà soulignées, et surtout celle-ci : un document web ne permet pas aisément de distinguer ce qui serait "titre en tant que métadonnée" et "titre rappelé en tant que contenu" - parce que le premier title apparaît en même temps que le contenu, notament ! En fait, on a la tentation de considérer le premier title au même rang que ce qui sert à "baliser" (mettre des marques visibles) le contenu du document, parce que c'est pratique. A mon avis, c'est lui faire un grand déshonneur Utiliser un h1 en ce sens, peut être une bonne initiative, donc - mais souvent, elle ne l'est pas car elle vient comme une information caractéristique par défaut. Pour le problème de la redondance des h1, je pense qu'on a fait le tour. Enfin, un autre problème : on remarque que pour un livre, il y a nette séparation entre le titre de la couverture, le titre rappelé dans les pages, et un éventuel identifiant générique du livre (ISBN...). Pour un document web, c'est beaucoup plus complexe : les deux premières informations (de nature différente) viennent en même temps, un identifiant n'est pas toujours requis (quoique l'url en joue le rôle, et s'y ajoute alors la confusion en identifiant et nom du document !). Tout ça est un peu tiré par les cheveux, mais on voit comment un problème technique peut cacher un vrai problème de définition de ce qu'est un document virtuel En tout cas, ça me semble être dans la logique "séparation contenu/présentation", avec présentation ici qui rime avec information edit: je n'ai pas répondu à la deuxième question. En fait, je n'en sais rien. Actuellement il n'y a aucun moyen de faire la distinction entre les deux niveaux d'abstraction, si je puis dire, du document. A vrai dire, je crois qu'il n'y aura jamais aucun moyen de le faire parce que ça n'a pas de sens. Pourtant, ce pourrait être pratique, par exemple pour une impression d'un document, ou son envoi par mail... La voie à suivre, tu l'as indiqué en disant ça C'est un problème vraiment complet et complexe, parce que ça ne concerne pas que le document en tant que bidule figé...

Mes excuses, par "spécification dans son ensemble", je parlais de la partie concernant les éléments hx (ayant tronqué ma citation). Nous sommes d'accord sur ce point. Je suis bien d'accord aussi sur la nuance déterminante entre recommandation appliquable et appliquée (convention). Mais quant à choisir de parler selon telle ou telle convention, je ne sais pas si c'est exactement un choix : les limitations techniques réduisent ce qu'il pourrait y avoir de subjectif. Je m'explique : Pour le problème qui nous intéresse, on se rend compte qu'il y a grosso modo deux approches : * non-confusion entre le document dans son ensemble et ses parties * confusion entre le document et ses parties (parce qu'il n'y en a pas d'explicites, par exemple) (La solution que tu proposais (faire s'afficher le 'title' comme titre du document, dans le document) ne fonctionnera pas non plus partout.) Mais en-dehors de cet aspect technique, je pense qu'utiliser h1 avec la même idée que title (titre du document), c'est tout aussi subjectif que de ne pas le faire C'est également une liberté prise avec la spécification (et plus généralement avec la description d'un Document), en considérant qu'un document organisé en une section unique revient à parler d'un document sans section - alors qu'en définitive, il y a d'abord ce qu'est le document, puis ce qu'a le document. On ne fait pas l'amalgame pour un livre papier, on est parfois obligé de le faire pour un document virtuel. Je ne dis pas qu'il faudrait qu'un document virtuel soit "comme" un document papier, non, mais sur ce plan-là, ..oui, car la description d'un document, quelque soit sa nature, ne change pas. Le must serait - selon moi - de pouvoir choisir simplement si on souhaite rappeller le titre du document, dans le corps du document, avant de passer à un/des éventuel(s) titre de section(s). C'est pour ça que je dis qu'il ne faudrait pas faire l'amalgame entre titre du document et titre de section, quand bien même ce serait l'ensemble du contenu du document : je parle au conditionnel, en pensant à une meilleure implémentation de la norme... et en n'oubliant pas que c'est difficile pour le moment Donc je pense à ça comme un problème qui concerne le contenu du document et pas ce qu'on en voit au final. C'est un point important de la description des documents, non ?

La lecture des recommandations donne toujours matière à discussions Comme tu l'as dis, nous nous "rabattons" sur une utilisation mutatis mutandis de l'élément h1 : si rien n'interdit de l'utiliser plusieurs fois, alors il est possible de l'utiliser une seule fois en lieu et place du titre de la page, pour combler une lacune (quoique ça dépende des points de vue) d'implémentation. Je suis de l'avis d'utiliser plusieurs H1 par page si le besoin s'en fait sentir. En effet : La spécification dans son ensemble parle de titre de rubriques ou sections, et pas de titre de (la) page. Les éléments hx devraient servir à baliser la structure "didactique" du document (en faire un plan), sans déborder en son niveau le plus haut sur la nature du document lui-même (c'est le rôle du titre d'indiquer ce dont parle, globalement, le document). Seulement, pour le moment ce n'est pas très pratique...

Investir dans l'apprentissage de SVG est certainement une bonne chose, si tu as le temps, car ce n'est pas particulièrement difficile : tout est XML. Cet avantage est double, puisque ça induit que tu peux intégrer des media-SVG très facilement dans tes documents web, pour peu qu'ils soient organisés dans une architecture du type XHTML ou tout XML. A l'heure actuelle, SVG est mature techniquement parlant (peut-être pas encore au niveau de ses fonctionnalités..), mais sa diffusion à court terme restera très difficile, d'une part à cause de l'absence d'outil d'édition/création, et aussi de non prise en charge en standard du format par les navigateurs. Autant le plugin Flash est entré dans les moeurs, autant la visionneuse d'Adobe (ou autre module)... Quelqu'un saurait-il si du coté de Mozilla (où on aime le XML ), on s'intéresse à la promotion de SVG via mozilla/firefox (la version 1.0PR de Firefox a inauguré le plugin flash installé automatiquement, pourquoi pas un truc similaire pour SVG ?)

ligne 12 : clause IF fausse (paranthèse fermante et ouvrante en plein milieu).

yamo, ce n'est pas que je veuille être désagréable, mais une (fausse) question me taraude : es-tu certain de vouloir te lancer dans une aventure comme celle-la sans avoir les compétences requises pour même simplement mener à bien un brouillon du projet ?

Pour commencer en PHP, je suggèrerais d'abord de se familiariser avec le vocabulaire. Enormément de gens commencent à taper du code en imitant (copiant..) des lignes ou morceaux de code trouvés par-ci par-là sans pouvoir mettre un nom sur ce qu'ils font, et par là suite ils s'étonnent de ne pas progresser. Ensuite, c'est comme pour tout : il faut un peu d'imitation (ne pas réinventer la roue...), un peu d'imagination (la "prise de risque" si difficile à entamer), et de la patience (beaucoup). Personnellement, le premier bidule que j'ai créé en PHP fût un livre d'or (avec MySQL comme base de donnée), et après coup je me dis que ce n'était pas mal d'avoir commencé par ça - c'est simple mais assez complet, et il existe tellement de bons livres d'or sur le net qu'on peut très vite, soit s'aider de ce qui existe, soit comparer son bidule et les autres scripts. Quelque soit ta méthode, prends bien le temps de fixer les connaissances de bases, pour comprendre ce que tu vas faire, non pas chercher à comprendre ce que tu as recopié. Pour ça... il faut se faire violence et ingurgiter les connaissances minimum

Ce mec est un génie ! Bienvenue copain (et encore un pompeur, c'est fou), je suis sûr que tu vas pouvoir nous aider en cassant les mauvaises habitudes

Héhé, en relisant un peu tes modifs je vois que j'avais laissé passé quelques trucs - hargneux, moi ? meuh non J'ai commencé, je finis. Page 1 "qui rentreront" > qui entreront (entrer en com, pas rentrer en com). "si le sujet les intéressent" > les intéresse (reformulation : si le sujet intéresse ces gens). Page 2 "et recevera" > recevra. "des éventuels erreurs" > éventuelles. "Les informations envoyés" > envoyées. "seront envoyés par l'intermediaire" > envoyés par l'intermédiaire. toujours "stoquer" > stocker "pas obligatoire" > obligatoires. "celle demandé" > demandée. Question : "N'encodez pas le caractère de séparation avec votre fonction, sinon, il ne sera pas détecter la différence entre le nom de l'argument et sa valeur." > Pas bien compris : je suppose que c'est la fonction qui ne saura pas détecter la différence, hum ? (en l'état, ça fait référence au caractère, mais avec une faute d'accord ;p). "ou manquant" > manquants. " (ou un autre serveur distant de..." > oubli d'une ) : distant) de... " tel que le format" > telle que (fait référence à une information parmi celles envoyées). "déstinés au" > destinés. "la reception" > réception. Page 3 "par l'intermediaire" > intermédiaire. "la verification" > vérification. Page 4 "les modifications nécessaire" > nécessaires. "va donc récuperer" > récupérer. "erreurs sont détéctées" > détectées. "une zone récéption" > réception. "Pour ceux qui n'aurait pas suivit" > n'auraient pas suivi (sans t). toujours "servira de" > servira à Sans vouloir être désagréable : faut absolument revoir tes règles d'accord hein d'accord ? (haha... hum je *sors*). Sinon à la seconde lecture brute, j'ai mieux compris le code source (mais mieux n'est pas parfait... j'ai encore du chemin à faire pour l'OO coule de source)

De rien. Merci pour le lien volontaire (sauf qu'il n'y a rien à voir - mais plus pour très longtemps).

Notre ami belge S.F., aka Steve, aka Nudrema, a publié un billet/article sur Tainted Words qui ne manquera pas d'intéresser tous ceux qui s'intéressent aux charsets, sans trop savoir de quoi il s'agit. Egalement, une mise au point sur les éditeurs textes. Lire "Jeux de caractère : c'est quoi ?"

Rapidement : Page 1 "Les trackbacks ont été crées" > créés. "des informations sont échangés" > échangées. "en communications" > en communication. "Les trackbacks ont pour idée de relier" > L'idée des trackbacks est de... (je doute que les trackbacks soient dotés d'une IA ). "les interessent" > intéressent. "s'averer" > s'avérer. "très répendu" > répandus. "Les exemples, ne manquent donc pas" > pas de virgule. "l'utilitée" > l'utilité. (Note : je trouve ce passage pas très clair). Page 2 "La méthode GET a été supprimé de la spécification depuis GET janvier 2003." > ...depuis Janvier 2003. Tu soulignes l'expression Requête HTTP : c'est mâl Utilise une autre manière pour mettre le terme en avant. Dans la même veine, tu veux insister sur le mot-clé "url" ensuite, mais tu utilises l'italique - utilise plutôt l'élément strong. Faute d'orthographe : "extremement" > extrêmement. "balises title" > le terme "homologué" est élément . "stoquer le texte " > stocker. "mis si dessus" > mis ci-dessus. "Le code se démarque en 3 grandes parties :" > se démarque ne convient pas (est structuré, peut être scindé en...). "Les sockets, avec php, sont ouvert" > ouverts. "la taille de ses paramètres déstinées" > destinés. "Vous verez que" > verrez. Page 3 "les informations envoyés" > envoyées. "aux requêtes envoyés" > envoyées. "Au niveau principe" > ça ne se dit pas (donc ne s'écrit pas). "Les données seront analysés" > analysées. "elle renvera" > retournera (pareil en-dessous). "cette partie là" > cette partie-là. "la zone register_globals" > c'est une variable . "du fichier qui envoi" > envoit. "Si vous avez bien ceci" > cela (référence à des termes énoncés auparavant). "de ce que peut representer" > représenter, pareil pour "verification", 2x). "dela" > de la (espace). "penchons nous" > penchons-nous. Page 4 "N'étant pas nécessaire de rappeller ce qu'est l'XML" > Bancale . "le fichier xml générer" > généré "Un regex" > Une regex, non ? (quoiqu'il existe bien un crapaux qui change sexe dans la forêt Amazonienne, incroyable d'ailleurs..) "le fichier qui vous servira de" > servira à. En bref, vérifie ton orthographe (j'en ai peut-être manqué), utilise l'élément code pour les noms de fonctions et variables (ce serait plus clair pendant la lecture, plutôt que l'emphase). Sinon, l'article est bien Cela dit, je n'utilise pas les trackbacks donc je ne peux formuler aucun avis technique, héhé...

Il y également ChuWiki, qui repose sur la syntaxe WikiRenderer. Il est plus simple que Wikini, mais fais très bien son boulot aussi. Un ami l'utilise même comme bloc-note

Un page de synthèse d'information sur Ogg Vorbis.

Je plusse pour le sentiment euphorique Cela dit, je doute que ce soit aussi idylique en entreprise, compte-tenu des contraintes qui s'opposent à un parcours d'apprentissage perso plus lent. Comme tu le dis, French Dead, il faut créer l'euphorie par un autre biais (production).

Contrairement à ce qui se dit dans les cercles de détracteurs, le passage au feuilles de style ne m'a pas entravé question créativité. J'ai continué à faire les mêmes interfaces complexes dans mon logiciel graphique, et j'ai réussi sans grandes peines (mais avec de la volonté et de l'enthousiasme) à les intégrer, pour sortir des pages valides. Le fait de réfléchir en blocs et non en tables m'a en fait apporté deux grands bénéfices, dont je ne pourrai plus me passer : d'abord le fait de pouvoir "superposer" (implicitement) facilement des éléments (pour gérer des courbes, par exemple); ensuite de pouvoir évacuer tout texte inutile de mes interfaces, si je ne prévois pas d'y appliquer des effets complexes nécessitant l'utilisation d'images (effets que seul un logiciel graphique sait faire, bien sûr). Au final, la souplesse est double : contenu/mise en forme, mais aussi mise en forme/mise en page. On ne peut pas faire plus de choses, mais on peut les faire plus simplement, plus rapidement (pour ma part, j'estime le gain entre 50 et 60% de temps en moins, de la création dans le logiciel graphique jusqu'à la validation des pages finales), pour un code pus clairs et bulletproof. N'étant pas dans un processus payant, je ne sais pas ce que ça vaudrait en terme de chiffres, mais Keith Robinson a écrit un billet sur le retour sur investissement des standarts du web pour démontrer la solidité de la chose.

Webdesigner, en bon anglais. Cela étant dit... dis en "un peu" plus ! (je ne suis pas intéressé, mais si tu ne dis rien de précis sur ton "projet", tu ne risques pas d'avoir des retours).

Bienvenue Alfred ! L'accessibilité, une histoire de famille ?

Monique => Si, si, mais j'évite de révéler son plan d'invasion du HUB au grand jour (notez la diversion habile menée par l'appel amical sur <C² /> !) Enfin là... ça commence à se voir *(n'importe quoi...)*

Soho, Denis faisait référence à la syntaxe à suivre. Récapitulatif : Les attributs dans le code (X)HTML : <balise attribut="valeur"> exemple : <p style="font-size: 1.5em;"> Les attributs dans une feuille de style : balise { attribut: valeur; } exemple : p { font-size: 1.5em; } Les guillemets droits sont obligatoires dans le code (X)HTML, c'est en fait une règle syntaxique qui tient du XML. Un oubli de guillement dans le code -> document mal formé & non valide. Par contre, tu gagnerais en effet à gérer les attributs de ta balise background (et des autres ) dans une feuille de style (et là, les guillemets ne font pas partie de la syntaxe, comme tu peux le voir).

Salut "collègue" ! C'est le "gang" Pompage.net qui se forme, là ! Je suis sûr que tes "quelques compétences" vont beaucoup nous aider, héhé

Bienvenue giangcui ! C'est vraiment formidable de voir que le HUB aide des webmasters par-delà les frontières, en-dehors du duo France-Québec !

En attendant que quelqu'un retrouve les posts en question, un indice : l'idée qui prévaut c'est de travailler avec Gecko (moteur de rendu du Mozilla, notament), car il est celui qui respecte le mieux les recommendations W3C, et ensuite d'aller tester dans les autres navigateurs (dont IE) et de régler les conflits au cas-par-cas. Et non l'inverse (qui est perte de temps et prise de tête assurée) Sinon, bah bienvenue !

Sympa - sobriété de rigueur. Les onglets dénote un peu par leur effet de relief un peu appuyé, par rapport au reste. Si tu pouvais améliorer la transition entre le rideau rouge (qui comporte un motif) et le prolongement continu, ce serait vraiment chouette .

Tu parles de ce genre de chose ? <p style="page-break-before: always;"> Note : aucune idée de la validité de ce truc, pas le temps de regarder, mais j'ai remarqué ça dans le source d'un dossier d'inscription que je devais imprimer, le résultat est bien évidement qu'à chaque balise, l'imprimante démarre la suite sur une nouvelle page.