Ganf

Commit : DW n'est pas forcément un mauvais outil s'il est bien utilisé. ImageReady en est un, oui. Par contre je me rend compte que je n'aurai pas du parler de mauvais outils mais de mauvais procédés. C'est le principe du découpage de la page par cellules de tableau avec espaceurs et images de fond qui est à revoir. Maintenant je suis d'accord avec toi sur le fait que peu de graphistes ont appris à utiliser les bonnes méthodes. C'est dommage d'ailleurs. Mais quelqu'un de motivé et de sensibilisé se doit à mon avis de se remettre en cause là dessus. En tout cas c'est tout son intérêt s'il veut toujours avoir son boulot dans le Web dans quelques années je pense. Bonne question. Je ne connais pas d'outil entièrement graphiste qui utilise les bons procédés. Tu peux le faire via DW ou d'autres mais justement en utilisant des interfaces peu graphiques. Ce que j'appelle les bons procédés en graphisme Web c'est (pour faire une grosse aproximation méchante) passer par les CSS. Il y a des intermédiaires, où tu choisis tes propriétés CSS via des jolis interfaces. Par contre effectivement ça n'est pas du "je glisse et je coche sur un bouton à partir du rendu visuel", c'est en deux étapes "j'ouvre la boite de dialogue de propriétés, je change les propriétés, je constate le résultat". Effectivement "ça marche" : le rendu dans le type de client HTML que tu utilise est bon. Maintenant en Web il y a bien d'autres problématiques que le simple "rendu graphique dans mon navigateur". Là il faut voir ce que tu considère comme étant ton métier. Si ton métier c'est uniquement le rendu, tu n'es pas graphiste Web mais graphiste tout court. Tu donnes une joli image avec les calques non fusionnés à l'intégrateur et lui se chargera de mettre ça sous HTML/CSS, c'est son métier. Par contre du coup ne vas pas générer ces tableaux HTML, tu sors de ton métier et de ta sphère d'expertise Si par contre tu considères que ton métier c'est (aussi) le Web alors il va falloir chercher plus loin que le simple "ça marche parce que ça ressemble à mon image" parce que ça ne répond pas à la problématique. Et si en plus tu travailles pour d'autres (qui font le code applicatif) alors ton inadéquation risque de les pénaliser eux. Je comprend tout à fait vu que c'est comme ça que quasi tout le monde a appris. Du coup on peut difficilement le reprocher. Maintenant je te suggère de jeter un coup d'oeil avancé aux CSS (même si effectivement il y a un palier d'aprentissage à franchir). C'est d'autant plus important qu'à mon avis un graphiste Web qui fonctionne encore en découpage par tableau risque d'avoir des problèmes d'obsolescence dans quelques années. C'est d'autant plus vrai si tu travailles avec des développeurs ou intégrateurs parce que pour eux la différence entre les CSS et tes procédés est énorme au niveau simplicité, maintenance, évolutivité et emmerdement pour coder.

Désolé si j'ai pu paraitre agressif, ce n'était pas le but. C'était plutot montrer une (mauvaise) surprise et bien affirmer que addslashes n'est pas la solution, pas taper sur qui que ce soit. Certes, mais pour le coup le problème soumis ici vient uniquement du manque d'échappement. Dans le code en question ce qu'il manque ce n'est pas un addslashes (qui ne résoudra rien si $Nom contient des apostraphes et/ou guillemets) mais bien un htmlspecialchars(). Ah ben si, tout de même : la ligne en question c'est un envoi de valeur vers un formulaire HTML. L'utilisation c'est "envoyer du HTML" pour la donnée en question, justement. et ... c'est bien pour ça que je me permet de réintervenir : ce n'est pas une solution au problème. Pour exemple si dans ta solution code j'ai $Nom1 qui contient des apostrophes echo "<td>Nom: <input name='Aut1_Nom' type='text' id='Nom' size='31' maxlength='30' value='".addslashes($Nom1)."'></td>"; Dans sa page HTML ça va donner : <td>Nom: <input name='Aut1_Nom' type='text' id='Nom' size='31' maxlength='30' value='voici l\'exemple'></td> Le navigateur n'interprête pas le \ et le considère comme du texte brut, il arrêtera le contenu de l'attribut value à l'apparition du premier délimiteur (l'apostrophe juste après \) et la valeur sera toujours coupée au milieu. A la limite on peut faire comme dit Commmint (changer le délimiteur) et on évite le problème avec l'apostrophe mais il apparaittra si au lieu de contenir une apostrophe la valeur contient un guillemet double. Ca n'est donc pas une solution non plus. Donc oui, même mis à part la sécurité, l'unique bonne solution c'est bien un htmlspecialchars() ou un htmlspecialentities(). Et même mis à part la sécurité, une sortie sur HTML (c'est le cas ici puisque c'est un echo d'un <input>) doit toujours être échappée sinon ça cassera toujours le rendu HTML (et ce cas est un bon exemple). Addslashes c'est soit pour échapper quand on fait une sortie vers un langage qui prend cette convention d'échappement (le SQL en est un), soit pour composer avec les délimiteurs de PHP lui même dans les chaînes statiques. Jamais pour échapper un contenu vers HTML.

Dites, on parle bien de la même chose ? Quand on envoie une chaîne de texte vers une sortie on doit *toujours* faire l'échappement adapté. Là il n'y a rien, c'est au mieux un truc qui marche pas dans certains cas, plus probablement une faille de sécurité potentielle (XSS dans ce cas là). En SQL l'échappement ça peut être addslashes, mysql_real_escape_string(), str_replace("'", "''", ...) et plein d'autres suivant ta base. En HTML (ton cas) c'est htmlspecialchars(...., ENT_QUOTES) ou htmlentities() si tu préfères. Je suis effaré de voir que pour tout le monde c'est un addslashes. Ca veut dire que: - vous ne comprenez pas ce que vous manipulez - vous ne faites pas habituellement vos échappement pour les envois de texte vers le HTML donc vos codes sont potentiellement aussi troués que ma passoire. [EDIT: désolé si ça a été pris en agressif, ce dernier paragraphe n'était pas l'intention. Pour moi dire que quelqu'un n'a pas compris n'est pas forcément ni mauvais ni agressif, ni même vraiment critique]

Désolé lafleur, je me suis mal exprimé. Je ne dénature nullement l'idée de choisir une police ou de ce qu'on veut y mettre. Ce que je veux dire c'est que si une part non majoritaire des gens ne voient pas la bonne police et voient à la place une police par défaut, ça ne le gênera pas. Du coup, et contrairement à plein d'autres sujets, on peut sans trop de mal sélectionner deux ou trois polices (une courantes sous windows, une courante sous mac et une pas trop rare sous linux) et se dire que si ça ne concerne pas 100% des gens on peut tout de même continuer. Bref, on peut mettre ce qu'on veut sans que ça porte à conséquence. C'est rare sur le média Web, profitez en. Je crois que la seule exception à ce principe pour les polices c'est une des polices MS qui "apparait" plus grosses que les autres (donc qui "rend" le texte de taille différente si on ne l'a pas).

bon, je suis décu de ne pas avoir eu plus de réponses. Merci à ceux qui ont joué le jeu en tout cas.

est tu prêt à télécharger une police chez toi juste pour lire un site ? je pense que tu répondra non (en tous cas c'est la réponse que feront la plupart des gens) Pourquoi ? pas besoin de site alternatif, on peut déjà faire des demandes de type "une Tahoma, sinon une Helvetica, sinon un sans serif générique" et le navigateur sélectionnera tout seul celle qu'il a suivant l'ordre de préférence. Pas besoin de plusieurs sites.

Je ne suis pas d'accord. C'est impossible pour un graphiste qui a appris à utiliser les mauvais outils avec un découpage des images. Ce n'est pas impossible pour quelqu'un qui a appris à utiliser d'autres outils et d'autres méthodes. Il ne faut pas mélanger les outils et les possibilités. Le graphiste actuel il a déjà du apprendre des outils et des méthodes. C'est juste dommage que beaucoup de graphistes Web n'ont pas appris les bons outils.

Bah, ça va effectivement mieux quand on me dit que c'est une suite d'une autre discussion, qu'on y met un lien et qu'en plus on pose les questions dont on attend les réponses Pour répondre plus avant : je ne trouve pas qu'on est limité. Effectivement tout le monde n'a pas les mêmes polices, et alors ? vous pouvez mettre une liste par préférences. Et celui qui n'aura aucune de la liste verra sa police par défaut, ce n'est pas bien dramatique. Est ce que la police que verra le visiteur est vraiment l'important ? si ceux qui ont des config moins courantes ont leur police par défaut ils ne s'en rendront probablement même pas compte, il y en a même qui préféreront. Elle n'est pas figée mais elle est fixée (taille non proportionnelle). Et je peux vous dire que pour ceux qui ne lisent pas parfaitemet sur écran, la possibilité de zoomer est vraiment un paliatif, pas une solution.

Mouais, tu utilises deux noms de police propres à MS Windows que certains ne pourront pas voir, tu définis des tailles en pixels suivant tes propres choix, tu nous donnes des polices serif pour de l'écran ... Bref, je vois mal à quel problématique tu cherches répondre en fournissant ce tableau ou au moins ce que tu cherches à apporter via ce biais. Quel est la problématique de base à laquelle tu souhaites répondre ou sur laquelle tu souhaites discuter ? Que cherches tu à apporter en donnant ce tableau ? Ce n'est pas clair, ou tout du moins je ne comprend pas.

Le spam étant plus ou moins aveugle que personnellement tu mettes no-follow ou pas n'y change rien. Ca n'empêche pas le spam, c'est sensé simplement diminuer son intérêt. Maintenant par contre si ton outil est mis à jour pour gérer nativement les nofollow sur sa prochaine version ET que les noms des champs ou l'interface pour poster un commentaire/trackback change ... il faudra au spammeur mettre son outil à jour, ce qu'il ne fera pas puisqu'il n'a aucune utilité de perdre du temps à spammer des sites insensibles. Oui, mais tu sembles prendre pour certain que ça vient des nofollow. Personnellement je dirai qu'il y a 99% de chances pour que ça n'ai rien à voir et qu'on aurait eu cette augmentation de toutes façons.

Et bien non Monique, pour moi ce n'est pas inconcevable. Ca ne veut pas dire que je ne me sens pas concerné, que je ne rale pas quand je vois un idiot à grosse voiture se garer sur la place handicapé, mais je n'irai pas voir le gérant d'un cinéma pour lui expliquer que son escalier est innaccessible. Ce n'est simplement pas mon métier. J'ai un métier avec une expertise, je connais les tenants et aboutissants dans ce domaine, je sais ce que ça implique au niveau cout, au niveau humain, je sais ce que ça rapporte aux gens concernés, ... dans d'autres domaines ce n'est pas du tout le cas et je serai bien à mal de faire autre chose qu'une critique gratuite qui ne fait rien avancer, ou même dire des choses fausses. Du coup je m'abstiens.

_AT_Lurch: Si ils ont le droit de faire un lien sans te demander ton avis, ils ont aussi le droit de le le laisser si tu n'es pas d'accord. En quoi atteingent-ils tes droits ? de quelles lois parles tu ?

Je vais compléter Dan : * Si tu es un sombre geek, que tu t'y connais en administration (non, savoir taper 3 commandes linux ne suffit pas) le VDS t'ouvre beaucoup de portes. Ca convient très bien à des gens qui veulent peu de ressources mais qui veulent une très grande liberté (installer ce qu'ils veulent, des appli pas standard, un accès shell, installer un serveur à eux ..) Tu peux trouver des VDS intéressant avec beaucoup de bande passante à partir de 10euro/mois. Ca reste très abordable. Coté partage des ressources ca reste du mutalisé mais en général tu as pas mal de disque et plus de ram dispo reservée pour toi que sur un mutualisé (mais ça reste pas des masses, généralement entre 64 et 128 pour les bas prix). Il faut voir aussi que coté partage ce sont des partages "imposés". Le voisin ne peut pas prendre toutes les ressources dispo et te faire ramer comme sur un mutualisé classique (et inversement tu ne peux pas toi non plus prendre toutes les ressources dispo) * Si tu es un débutant ou un professionnel classique passe ton chemin. Soit ça te demandera trop d'admin, soit ça aura des ressources trop faibles Quoi que j'ai vu passer un hébergeur de VDS qui gère des fusions de disque : il y a un disque système accessible en lecture pour tout le monde, il contient un système à jour et avec les correctifs (donc maintenu sans que tu n'aies rien à faire) et un disque vide à toi. Les deux sont fusionnés, quand tu écris tu écris toujours sur le tien, quand tu modifies un fichier partagé ça l'écrit sur ton disque. Quand tu veux lire un fichier ça le lit d'abord chez toi, et s'il n'existe pas ça le lit sur le disque global. Le truc c'est que du coup tu peux revenir à la config par défaut mise à jour simplement en effacant tes trucs à toi. Les softs sont automatiquement mis à jour, sauf si tu les as modifié ou réinstallé dans ton disque perso. C'est totalement transparent et pas idiot pour alléger la charge d'admin. * Si tu es un professionnel avec des contraintes fortes le VDS peut être intéressant car il s'agit de machines virtuelles, donc qui peuvent avoir toute la redondance qu'on veut. Maintenant on ne parle plus là des mêmes prix et ce n'est probablement pas ça que tu cherches.

Oui, mais ce sont des liens profond faits à la main (donc pas de pb avec les bdd), vers des sources diverses, à partir de textes de commentaires ou critique (donc ça se rapproche de la citation et de la référence), ça n'a pas pour but de tromper le visiteur sur le propriétaire du contenu, ça ne fait pas de inlining, c'est généralement du texte donc on repère le site destination, (donc pas de risques de confusion ou d'appropriation) ... Bref, pour une fois les blogs c'est probablement le type de lien qui pose le moins de problèmes. Ce qui en pose plus ce sont les sites type keljob (qui peuvent parasiter la section DRH d'un site de société ou d'un autre site de recherche de boulot), les sites d'actu qui repompent systématiquement et sans accord les liens d'un autre site d'actu ou qui font des liens auto vers chacun des articles, les sites qui référencent directement des images vidéo ou sons ... C'est surtout pour ce genre de choses que le lien peut poser problème. à peu près la même date que tes documents, l'histoire de keljob, à l'époque beaucoup de monde en parlait et je m'étais un peu renseigné. Certes, mais si ton site a exactement la même activité que Webmaster-hub ça peut être tendancieux. Même chose si tu fais un lien systématique ou sans activité rédactionnelle vers chacun de leurs articles. Bref, un lien c'est technique, ça n'est ni explicitement autorisé ni interdit, ça dépend de ce que tu en fais.

J'avais parlé de la chose avec un professionnel et après pas mal d'échange voilà ce que j'ai retenu (c'etait il y a pas mal de temps donc je ne garantie rien): La problématique générale * Rien ne légifère le lien en lui-même donc il est par principe autorisé s'il ne contrevient pas à une législation tierce * Rien ne peut empêcher un lien unique vers un document si le lien, la destination et le rapport entre la source et la destination sont explicite. L'indication d'une adresse ou la citation ne peuvent pas être restreints. Activité parasite : * on fait des liens vers des documents "profonds" de façon à se remplacer aux pages habituelles du site cible. Ca peut être vu comme du parasitage, ce qui est interdit * même chose si le site source et le site destination ont la même activité, il ne faut pas que le site source puisse être vu comme un moyen de profiter du contenu ciblé à la place du site cible, c'est à dire qu'il soit un remplacement. * globalement, si le fait de permettre l'accès au contenu est une des raisons d'être du site source *et* du site cible, on prend un risque car ça revient à paraster le site cible Droit des bases de données : * Il est interdit de faire des liens de manière systématique ou automatique vers tous les contenus (ou tous ceux qui correspondent à un certain critère donné). Ca pourrait être vu comme un pillage de base de donnée (il y aurait une loi contre ça), même si les données récupérées sont publiques/libres. Par contre si la récupération met en oeuvre l'intervention manuelle d'un rédacteur ou une activité de rédaction, il n'y aurait pas de problèmes de ce coté Diffamation : * Si le but du lien est de porter atteinte à la personne auteur du contenu ciblé ou concernée par le contenu ciblé, on risque de tomber dans les cas d'injure ou diffamation. C'est valable autant pour les liens de type google bomb avec un texte dégradant (député libericide par ex) qu'un simple lien pour dire "je parle de...". Le lien peut etre soit porteur de la diffamation (premier cas), soit constituer le nommage et l'identification de la personne diffamer (donc faire parti du délit) Droit d'auteur et endossement * Le lien peut être contesté si l'auteur ou le propriétaire du lien ciblé n'est pas clair. C'est particulièrement vrai dans le cas de lien en frames ou contenus inline. Si le visiteur est induit en erreur sur "à qui appatient le contenu", on peut rentrer dans des problèmes de droit d'auteur. * De même si le lien induit dans l'esprit du visiteur une notion d'endossement ou de relation entre la cible et la source, on peut avoir un problème Contrefaçon : * Certains voient la mise en frame (ou contenus inline) comme un copie du contenu, donc une contrefaçon. C'est à mon vis exagéré et faux mais c'est au moins argumentable, donc à éviter si vous ne voulez pas risquer un procès. De ce que j'ai compris rien n'autorise quelqu'un à mettre des conditions sur les liens qu'on peut ou pas faire vers lui en dehors de ce type de poblèmes (qui ne sont finalement pas liés au lien lui-même). Pour pouvoir imposer des restrictions il faudrait avoir un monopole d'exploitation des liens or rien dans la loi n'interdit de faire référence ou de pointer vers un contenu sous droit d'auteur (seul le contenu lui même est protégé). Rien n'oblige non plus à prevenir l'auteur ou à faire une quelconque démarche. Par contre: si le fait que ce soit ou pas la base du Web et l'usage peut éventuellement diminer la gravité, ça ne peut pas être une justification au lien d'un point de vue légal.

Certes, mais ont-ils diffusé ou copié ton contenu ? Ils ne font que doner l'adresse. D'ailleurs même si ils donnaient un extrait/résumé ça tombe dans le droit de citation vu qu'il est là avec la référence et dans le but d'inciter à consulter l'oeuvre (pas en remplacement). De meme que personne ne peut t'empêcher de donner l'adresse de ton voisin ou le n° ISBN + titre du dernier livre à la mode, personne ne peut empecherde donner l'adresse d'un contenu Web si le but est bien uniquement de fournir un adresse/reference (et dans un annuaire c'est incontestable). (je parle là au point de vue légal. Au point de vue humain je comprend mal les raisons d'un annuaire manuel et non exhaustif de ne pas retirer les liens sur demande du proprio.)

Disons que le but est d'en enlever, pas d'en rajouter en fait. Un index par thème est déjà prévu mais il se retrouvera sur page dédiée, donc me pose moins de cas de conscience. Pour donner un apperçu, ce que je compte mettre sur la page d'accueil : - titre du site avec logo visuel, le tout avec un lien vers la page d'accueil - desciption du site (ce qu'il est et à quoi il sert), avec un lien en bas de la description "plusde détail sur ce site" qui mène vers la page qui liste l'auteur, la licence, les déclarations d'intention (respect de la vie privée, accessibilité), l'aide, le formulaire de contact, ... - une boite "selection", qui liste les liens/titre (éventuellement courtedescr) des quelques textes qui se semblent les plus utiles/importants/intéressants. Le titre de la boite est un lien qui permet d'accéder à la page dédiée aux sélections (archive chronologique des sélections, lien vers le feed RSS, etc) - une boite similaire mais pour les derniers textes publiés (actualité) - un mini mini menu flottant avec : la case de recherche, 4 liens vers les thématiques principales, un lien vers la page d'archive par date Ceci dit la page va dépendre de ce qu'on me répondra sur les questions et pour le moment pas grand monde ne s'est lancé.

Je n'ai pas trouvé de forum spécifique à l'ergonomie, j'ai pris celui concernant l'accessibilité car il me semble le mieux correspondre. Que les modérateurs n'hésitent pas à rediriger le cas échéant. Je suis en train de revoir au niveau ergonomie ce que je vais placer dans mon site et où. Un de mes buts est la simplification de l'interface par l'élimination de ce qui est inutile ou le déplacement sur une seconde page dédiée de ce qui est peu utile. Ma première question concerne les navigations par date. Presque tous les blogs mettent en première page (voire sur chaque page) une liste des années et mois pour pouvoir sauter directement. Certains mettent même des calendriers pour visualiser directement les articles à une date donnée. Le site concerné est un intermédiaire entre le recueil d'article et le blog. Il y aura un remplissage très irrégulier et qui ne sera certainement pas quotidien. Voici les questions : 1- Dans ce que vous utilisez (je parle bien de ce que *vous* utilisez *concrêtement*, même si c'est peu pratique ou que vous voudriez autre chose à la place) a- est -ce que vous utilisez les liens "2003", "2004", "2005" pour naviguer par année ? b- est-ce que vous utilisez les liens "janvier", "février", "mars" ... pour naviguer par mois ? c- est-ce que vous utilisez les liens vers les jours dans un calendrier pour naviguer ? 2- Quand vous utilisez ce type de navigation c'est pour : (merci de ne mettre que ce qui est le plus courant) (merci de ne pas parler en théorie mais par constatation de ce que *vous* faites en pratique) a- rechercher un article vu préalablement (ou dont on vous a parlé) qui a eu lieu récement (donc on remonte mois par mois ou jour par jour) b- rechercher un article vu préalablement (ou dont on vous a parlé) en connaissant sa date approximative c- rechercher un article vu préalablement (ou dont on vous a parlé) sans vraiment connaitre de plage de date utile d- chercher un article intéressant dans la liste (on remonte mois par mois pour trouver les articles qui semblent intéressants à première vue) e- même chose que 2d mais uniquement pour quelques thèmes bien particuliers f- chercher les articles qui répondent à un problème que vous avez actuellement g- avoir un apperçu du contenu du site h- chercher un article qui a eu lieu peu avant ou peu après celui que vous êtes en train de lire (on cherche le mois ou la date en cours) i- autre (préciser) 3- Pour l'utilisation mise en avant au 2, si cette navigation par date n'était pas disponnible, vous utiliseriez (plusieurs choix sont possible mais merci de les trier en partant du plus utile vers le moins utile) : a- le moteur de recherche interne par mots clés b- un moteur de recherche interne complexe (tris sur les dates, thèmes, mots clés) c- un moteur de recherche externe d- un simple historique page par page (pas de segmentation par annee/mois/jour) e- une navigation par catégorie/thème f- autre (préciser) 4- Ce type de navigation est utile (de manière globale) : (pour chaque cas répondre : nécessaire / utile / peu utile / inutile ou presque) a- dans la page d'accueil b- dans le plan du site c- dans la page de recherche d- dans la page d'aide à la navigation e- à partir d'un billet (pour naviguer dans le mois ou la date du billet en cours, ou dans les dates approchantes) f- à partir d'un biller (non restreint à la date ou au mois du billet en cours) g- dans toutes les pages (par exemple dans un menu ou une colonne fixe) h- dans une page dédiée à la navigation par date i- ailleurs (préciser) 5- Si vous aviez le choix, que préfériez vous avoir comme outil pour résoudre votre problème exprimé à la question 2 ? (question libre) Mon but va être d'analyser ces réponses, voir si ce type de navigation est utile, ou, comment ... et vous proposer en retour des solutions avec d'autres types d'interface pour répondre à votre problème de la question 2. Merci d'avance (si ça marche j'ai le même genre de démarche à faire pour d'autres objets d'interface, mais une chose à la fois) <Edit Arlette : Post déplacé dans le salon pour qu'il soit visible par un plus grand nombre de Hubiens >

Attention je ne suis pas objectif. Ceci dit je te conseille fortement le livre "PHP 5 avancé", disponnible aux éditions Eyrolles. Tu peux le trouver en ligne avec quelques chapitres exemples sur http://www.eyrolles.com/Informatique/Livre...hp-5-avance.php Comme le titre le laisse entendre il y a des sujets plutot avancés qui trainent au milieu mais il reste accessible pour un débutant qui n'a pas peur d'apprendre (en tout cas je n'ai pour l'instant eu aucun retour me disant le contraire). Il y a eu un ou deux fils dans le forum au sujet des livres PHP et au moins un sur celui là précisément. Je te laisse y jeter un coup d'oeil aussi.

Le problème est toujours là. L'utilisation d'informations sémantiques nécessite que ces informations soient remplies et bien remplies. L'utilisateur saura toujours mentir (il l'a montré par le passé sur les <meta>), c'est le point faible de la chaîne. Du coup pour les moteurs de recherche le plus simple c'est de ne se baser sur l'utilisateur que pour un minimum de choses. Plus on se base sur le marquage, plus on permet de se faire leurrer si l'utilisateur ment. C'est pour ça que je crois qu'à court terme la sémantique dans les moteurs de recherche publiques généraux ne dépassera pas la gestion des liens, les titres et ce genre d'informations basiques. Maintenant, à partir du moment où on est séparé de la problématique du moteur de recherche (qui de toutes façons ne nous fait pas confiance), quel risque a t'on de faire les choses correctement ? en fait c'est là toute la problématique : montrer que ça peut servir dans le futur et que de toutes façons ça ne sera pas négatif. Tout ce qui fait le final c'est la question de la poule et de l'oeuf, le moteur ne se servira pas de ces marquages tant qu'ils n'existeront pas de façon correcte et sûre, et les auteurs ne les utiliseront pas tant que ça ne servira à rien dans les moteurs/navigateurs. Il faut bien amorcer la pompe et les auteurs me paraissent les mieux placés pour l'instant. Bientot ça sera le tour des navigateurs et des petits outils client qui peuvent donner des gadgets et petits plus. Seulement après, quand les choses seront suffisament amorcées et stabilisée de manière "non biaisée", on pourra risquer de faire intervenir les moteurs de recherche. En apparté : Non, pas s'il n'y a pas des garde fous qui permettent d'éviter que le concours pourrisse le reste du Web (je parle en particulier du spam). Si j'avais une idée de règle ou de technique intelligente pour régler la question je l'aurai proposée à Stephane, malheureusement je n'en ai pas. Indépendamment, ça m'a pris du temps et je ne crois pas que je sois de nouveau près à y consacrer tout ça. J'ai peur que ça ne m'apporte pas assez. Tiens, d'ailleurs, si le nofollow était implémenté sur la majorité des wiki/forums/blogs, la question se poserait moins déjà

Pour moi contenu c'est la même chose que message. Le message est le contenu de ma donnée informatique. Si tu préfères tu peux remplacer "contenu" par "message" dans tous mes écris car je l'utilise dans ce sens là. Pour reprendre tes exemples : 1/ Il ne s'agit pas de tout permettre de retranscrire, mais de faire correctement le minimum qui permet à tout le monde de comprendre. C'est à dire séparer les livres, dans chaque livre séparer les versets, marquer les paragraphes et les titres. Je ne vois ici nulle part quelque chose qui ne peut pas être mis sous forme fonctionnelle et sémantique. Ca ne veut pas dire que mon marquage va *tout* couvrir, mais il va couvrir un langage commun qui sera déjà une bonne base. C'est la même chose pour ton trémolo sur le sermon, je met ma balise <em> car c'est bien une emphase. Certes ça ne traduit pas forcément toute la donnée (je ne sais pas quelle type d'emphase c'est), mais ça la traduit déjà mieux que si j'avais simplement fait une mise en italique avec une police tremblante. Rien ne m'empêche d'ailleurs de faire les deux (le <em> et la police tremblante). Le 2/ est à mon avis hors contexte. Il ne s'agit pas de dire que le marquage va résoudre tous les problèmes et permettre d'informer sur tout. Il ne protègera pas contre les sorties de contexte, contre les doubles sens, contre toutes ces choses spécifiques liées au sens du contenu. Maintenant ça n'empêche en rien de structurer le message de façon à faire apparaitre les blocs fonctionnels et blocs de sens qui peuvent l'être de façons à ce que ce message soit plus facilement traité et compris par les machines. Ca ne résoudra pas tes problèmes de sens et de contexte mais ça ne les empêche pas non plus. Par contre ça résoudra d'autres problèmes. Quant au 3/ je ne réagis pas à une page qui contient des <h1> là, je réagis au message initial de ce sujet (je n'étais pas dans le précédent). Et ce message là est tout à fait explicite Maintenant, même s'il ne l'était pas. En quoi cela rend t'il impossible le fait de signaler ce qui est coté sens et fonctionnel ? Dans tes cas certes le marquage ne résoud pas tous tes problèmes, il n'empêche pas d'être mal compris, il ne permet pas plein de choses sur le contexte. Mais en aucun cas il n'a dégradé quoi que ce soit. Par contre il peut éventuellement permettre à bien des machines d'avoir une meilleure connaissance du message pour pouvoir le présenter et le traiter de manière plus efficace (à défaut d'avoir une bonne connaissance et un traitement complet). Bref, toujours pas de message qui perde quelque chose à être marqué correctement. Toujours pas de message qui soit impossible à retranscrire dans le cadre du standard et qu'il soit possible de retranscrire en dehors. C'est uniquement ça mon propos. Maintenant pour ce qui est du fait de pouvoir donner mon avis et dire ce que je pense ... il me semble qu'à chaque fois j'argumente très largement, j'explique et je discutte. Il ne s'agit pas de choses posées comme ça qui ne servent à rien comme tu semble le penser. Si tu le prend mal ou que tu as l'impression que ça ne sert à rien j'en suis désolé, mais pour le coup je suis convaincu du contraire

Euh ... on doit avoir un problème de vocabulaire là. Une pensée, une idée .... pour moi tout ça c'est du contenu. Le contenant c'est éventuellement le fichier informatique, le format. Le contenu c'est ce que tu veux exprimer, transmettre ou tout du moins transcrire. Même si c'est une pensée ou une idée, même si tu penses que ça ne peut pas être mis sous forme logique/fonctionnelle/sémantique (pourquoi ?), ça reste du contenu. En gros tu viens d'esquiver mais tu ne répond pas Pourquoi ta pensée et ton idée ne peut pas être mise de manière sémantique logique et/ou fonctionnelle ? as tu un exemple ? parce que là je vois toujours une grosse affirmation qui sert de base à toute ta réflexion et ... pour moi elle est fausse. Je peuxme tromper, mais ça peut aussi ne pas être le cas. Tout le monde a toujours l'impression d'être un cas spécial qui doit sortir du cadre de la majorité. Pourtant, si tout le monde est bien unique au niveau de ce qu'il veut faire ... la plupart rentrent bien dans ce cadre de la majorité. On est toujours dans un espace d'échange. Si j'exprime un avis *argumenté* face à ce que je comprend être ta situation, rien ne t'empêche de repréciser en quoi ta situation est différente et te faire du cadre. A moi après de répondre en quoi tu te trompes en croyant être sorti du cadre, ou à reprendre mes idées avec ce que tu m'as apporté comme nouvelle base. En venant sur un forum c'est bien ça le principe. Si tu attend que tout le monde dise "oui" simplement par précaution parce qu'on n'est pas à ta place, je ne vois pas l'intérêt . Le problème c'est qu'ici tu évites la seconde étape. Tu nous parles d'un hypothétique cas qui ne peut pas convenir à une structuration logique, basée sur le sens et la fonction des différents éléments ... mais tu ne donnes aucun exemple ou aucune information quand ton te dis que c'est très peu probable que ce soit le cas. Après c'est sur que si en plus tu nies la possibilité de l'autre d'émettre un jugement (un avis et un jugement pour moi c'est bien la même chose, tant que ce n'est pas quelque chose de définitif), ça ne permet pas beaucoup d'avancer. De notre coté il me semble qu'il y a eu beaucoup d'arguments d''avancés, il n'y a pas de jugements non fondés à l'emporte pièce. Ils sont certes potentiellement dans l'erreur (et je serai ravi d'en changer si je vois que c'est pertinent) mais au moins ils se basent sur quelque chose. Là tu les réfutes en disant "vous ne devez pas juger" et "non ça n'est pas possible". C'est un peu dur à admettre, tu ne crois pas ?

C'est à dire ? quel contenu ne pourrait pas être structuré de façon sémantique et logique ? as tu des exemples ? pour l'instant tu parles de cadre trop restreint, mais j'ai du mal à voir un exemple concret Bien entendu. Mais je ne prend pas bien mal au sens objectif. Je me donne le droit de dire quand je trouve que quelque chose est mal ou que quelque chose est bien. Je me donne le droit d'avoir un avis et en plus de l'exprimer, c'est si inadmissible ? Il faut arrêter ce pseudo pragmatisme. Quand je trouve que quelque chose est mauvais je le dis. C'est aussi simple que ça. Je ne vais pas faire semblant de ne pas avoir d'avis sous prétexte de liberté. J'ai un avis, je l'exprime, maintenant ce n'est effectivement que mon avis. Comme ce n'est que mon avis je n'engage que moi. Si ça te choque c'est probablement que tu prend ça pour plus que "mon avis". Il ne faut pas être allergique aux termes bien et mal, et croire après que finalement personne n'a le droit de donner aucun jugement sur ce qu'il se passe. Chacun a son jugement et c'est très bien ainsi, il n'y a pas à s'en cacher. Oulà, loin de moi l'édée de supprimer la forme. Mais ce que je conteste c'est que s'exprimer pleinement sur la forme doivent passer par un mauvais balisage du fond. Je suis convaincu qu'il n'y a nullement d'opposition et que non, pour t''exprimer pleinement tu n'as pas besoin de sortir du sentier de la langue commune. Oui ? au nom de quoi n'aurais-je pas le droit d'avoir un avis la dessus ? au nom de quoi n'aurais-je pas le droit de l'exprimer ? Etant intéressé et concerné par la question, ayant l'impression d'avoir une vue bien éclairée sur le sujet, il me semble que oui, je peux me permettre de porter un jugement. Le tout c'est de ne pas oublier que ce n'est que "mon" jugement et pas "LE" jugement. Ah mais ... utilises en d'autres, il n'y a pas que le HTML, il y a plein d'autres langues en informatique, plein d'autres formats de contenu. Le HTML n'est qu'un parmis tant d'autres. Choisis celui que tu veux, mélanges les même s'ils le permettent (basés sur une même grammaire avec des espaces de noms). Mais quelle que soit la langue que tu vas utiliser tu utiliseras bel et bien un langue, avec un sens bien précis derrière chaque terme, une grammaire bien orientée. Alors certes tu peux t'amuser à créer des mots et des figures de styles, mais c'est là que l'analogie s'arrête. Elle s'arrête parce que la langue parlée est faite pour l'être humain, qui arrive à faire des déductions et des connotations de contexte. La langue informatique c'est à destination de programmes, qui eux ne savent interpréter que ce qui est prévu et codifié. Du coup, en informatique, quelle que soit la langue que tu parles, hors quelques cas rares d'expérimentation, il faut essayer de respecter la grammaire et le sens de chaque terme. Attention, quand on parle de dissocier le fond de la forme ce n'est pas pour dire que la forme est annexe ou qu'elle doit être remisée au second plan. C'est simplement permettre à la machine de connaitre et le fond, et la forme, de savoir ce qui se rapporte à quoi. Quand on parle de séparer ce n'est pas tant une séparation technique (qui elle bénéficie plus à l'auteur qu'aux autres) qu'une meilleure description. Confondre le fond et la forme c'est par exemple mettre un <font> pour faire un titre. Le problème n'est pas tant que la forme est dans le HTML, le problème c'est plus que la machine ne connait plus là *que* le forme, elle n'arrive pas à connaitre le rôle de cette mise en forme. La séparation c'est d'abord et en priorité le fait de pouvoir se renseigner sur l'un et l'autre aspect indépendament, pas le fait de pouvoir annuler l'un des deux. Je suis d'accord. Le W3C fait sa communication à l'intention des techniciens et professionnels. C'est une spécification technique, pas une documentation utilisateur. Des documentations il en existe, l'utilisateur final ne devrait pas avoir à connaitre le W3C, il ne devrais avoir à connaitre que les documentations finales ... ou même, dans l'idéal, uniquement les outils qui masquent cette couche. Quand j'utilise mon téléphone je n'ai pas à connaitre la dizaine de standards qui composent la transmission, par contre j'ai intérêt à les respecter. Ca devrait être la même chose en informatique. La différence c'est que pour une très large majorité, pour l'instant, ceux qui codent du HTML sont des techniciens (j'entend par là qu'ils s'intéressent à la technique, pas forcément qu'ils en font un métier). Et quelqu'un qui vient ici acquiert presque à tous les coups le statut de technicien à mes yeux. On manque d'outils qui permettraient au non technicien de faire les choses à peu près correctement Sans crier au scandale, il est peut être du rôle de ceux qui ont une bonne expertise d'aller lui recommander la bonne utilisation, lui déconseiller fortement la mauvaise et lui expliquer le pourquoi de tout ça (si ça l'intéresse), non ? Ca ne me choque pas qu'un non technicien fasse n'importe quoi, c'est normal. Mais ça ne m'empechera pas de lui faire remarquer pour qu'il s'améliore et qu'il change ça. Il est normal que l'amateur néophyte n'atteigne pas le même final que l'expert, et fasse des choses qui ne sont pas bien. Maintenant est-ce qu'on doit lui cacher que ce n'est pas bien ? On s'adresse à des gens responsables et matures, plus à des enfants à qui on dit que son gribouilli est le plus beau du monde. Il me semble qu'entre gens intelligents et d'un age correct on peut dire "oui c'est un gribouilli, oui c'est normal que tu fasses ça au départ, mais non ce n'est pas un chef d'oeuvre, c'est un mauvais dessin". Pour revenir à du concret, quel est donc ce contenu que tu n'arrives pas à faire en le marquant correctement de manière conforme ? existe-t'il réellement ? Pour ma part tout ce que je dis ici bas est reprenable à l'envie. Tout ce que je demande c'est que les extraits ne soient pas trop courts (pour éviter d'être coupés du contexte et pris à contre sens), et qu'il y ait un lien vers la source de l'extrait. Tu peux te lacher. Concernant le lien j'irai voir plus en détail mais de ce que j'ai lu en diagonal j'ai peu de choses à rajouter à ce qu'avait dit Raphael, je m'y retrouve assez. Je dois juste avoir un avis plus "idéaliste qui rêve au futur", comme d'habitude.

cf l'article que j'ai cité, il est possible dans une majorité de cas de faire un marquage fonctionnel avec des classes ou ce genre de chose, de définir des comportements dans un fichier javascript externe et de relier les deux avec des gestions d'évenements DOM. Au niveau technique ça marche exactement pareil que les on* dans le code HTML mais sur le principe c'est AMHA beaucoup plus dans la philosophie de conception de stricte séparation. C'est un peu plus complexe à coder au départ, par contre ça amène probablement plus de confort et de simplicité sur le long terme. A toi de voir si ça correspond à ce que tu cherches. Pour moi c'est un peu comme si tu conseillais aux gens de ne pas se préoccuper de l'orthographe et de la grammaire parce qu'il y a un correcteur dans le traitement de texte. Ces outils sont intéressants, ils sont certainement sous utilisés, mais ils ne sont que des roues de secours ou des "dernière étape". Ce d'autant plus qu'ils souffrent du même problème que les navigateurs et les correcteurs de traitement de texte : l'ambiguité et la connaissance restreinte. Comment tidy va bien pouvoir corriger "<b> hello <p> World " ? comment peut il savoir si ce que cherche à faire l'utilisateur c'est réellement le théorique <p><b> hello </b></p><p> world </p> ou si c'est <p><b> hello </b></p><p><b> world </b></p> ? difficile voire impossible de savoir. Voilà pour le problème d'ambiguité. Pour les attributs il peut éventuellement repérer qu'il y a des majuscules en trop parce qu'il a été programmé pour vérifier ce point de détail particulier. Mais que fera t'il quand il tombera sur une erreur non prévue ? genre oublier le "v" de onmouseover ? Les outils comme tidy c'est très bien pour essayer de voir ce que corrige le logiciel, mais ça ne remplace pas la connaissance pour le rédacteur de ce qui est "juste" ou "faux". Ca n'empeche pas le rédacteur de devoir essayer de taper juste dès le départ. D'autant que comme tous les correcteurs automatiques, des fois il se plante sur ce que voulait réellement faire le rédacteur et corrige d'une mauvaise manière.

Tu compares des choux et des carottes aussi. Tu compares une grammaire (XML) et un langage (HTML). Effectivement, tu ne peux que arriver à la conclusion que la grammaire est plus libre, vu qu'elle permet de créer plusieurs langages. Maintenant ce n'est qu'un leurre, parce que pour pouvoir utiliser ton XML tu vas être obligé de définir un langage par dessus, donner du sens à tes différentes balises. Alors soit tu le fais dans ton coin et seul toi pourra te servir du XML, soit tu diffuse ton langage et tu viens de créer quelque chose d'aussi restreint que HTML. La seule différence c'est que ton langage à toi sera moins répandu. Effectivement le HTML n'est pas un langage "libre" à tout faire. On s'est entendu sur certaines balises avec un sens bien précis pour faire quelque chose de bien précis. Ca ne couvre pas (et ne peut pas couvrir) tous les cas d'application et n'est pas adapté à la description de tout et n'importe quoi. Par contre l'avantage c'est que tout le monde parle la même chose. Tu peux créer n'importe quel langage avec ton XML, dès que tu essayes de le "fixer" pour qu'il soit standardisé, tu auras forcément cette même impression de langage figé et restreint. Là tu n'as pas cette impression avec XML car ce n'est pas un langage, mais le XML n'est lui pas utilisable directement donc tu ne résoud rien. Tu as une réunion avec plein de gens de nationalités différentes qui ne parlent pas toutes les langues. Tu as le choix entre laisser chacun parler sa langue, qui est très riche et permet de dire plein de choses mais que personne ne va comprendre ... et celui de tous parler une langue commune que personne ne maitrise vraiment donc qui va être limitée coté possibilitées mais qui va permettre de réellement échanger quelque chose. Toute la problématique des standards est là. C'est pour ça qu'il est toujours très dangereux de convaincre les gens d'utiliser un standard à base d'arguments techniques. Tot ou tard il y a un moment où il sera techniquement plus intéressant de faire autrement. Le standard n'est pas fait pour être "meilleur" (même si forcément il s'y essaye), mais pour être "commun". C'est son seul but, le fait qu'il soit plus intéressant techniquement ne peut être qu'une conséquence ou un bonus. On fait dire trop de choses de manière floues sur le W3C (du type du trop ambigue et incomplet "un site standard est plus accessible") et maintenant les gens se rendent compte que ce n'est pas aussi magique que ce qu'ils avaient compris et rejettent tout en bloc au lieu de faire le tri. C'est dommage.