Ganf

A vrai dire non, d'ailleurs tu le sais aussi puisque tu les nommais .html Mais ce n'est pas le fond de mon discours. Je ne dis pas que ton fichier ne va pas s'appeler "/forum/show.php". Ce que je dis c'est que même si ton fichier s'appelle "/forum/show.php", il n'y a aucune raison pour que le visiteur voit "/forum/show.php?id=45" dans sa barre d'adresse. Tu peux tout à fait faire en sorte que l'utilisateur voit "/messages/2005/45" dans sa barre d'adresse. Ce dont je parle c'est d'une indépendance entre l'adresse publique d'une ressource et le nom & emplacement du fichier correspondant sur le disque. Avoir des extensions .php dans les adresses ne sert à rien à part casser toutes ces adresses le jour où on change de techno.

Sans vouloir être méchant, si ton PR est de 3, tu n'as franchement rien à perdre et tout à gagner En dessous de 4 j'ai plutot tendance à considérer que c'est négatif. Si tu as l'occasion de te débarasser de cette mauvaise note ce n'est pas forcément un mal. Quand à ton problème réel, la plupart des hébergeurs sympa avec un admin réactif pourront te faire ce que tu demandes. Une bonne partie des gros aussi. Tu ne devrais avoir aucun mal à trouver. Au cas où, si tu as un moteur de Rewrite, tu devrais avoir moyen de faire des redirections internes sans te poser de question. Par contre, pour les autres c'est un bon exemple : vos URL n'ont aucune raison de ressembler à votre architecture disque ou de contenir les extensions internes de votre applicatif (php, asp, html, ...). Faire ça c'est rompre une indépendance et se casser la figure lors d'un changement de technologie ou d'une évolution de l'architecture.

- essayes avec un cp IN('95270', '95510', '95400', ....) ça permettra peut être à l'optimisateur interne de faire des raccourcis. - je trouve étrange que tes condition de jointure ne soient pas en premier dans la liste des critères du WHERE. Essayes de les passer en premier, généralement Mysql se dépatouille mieux - vérifies que le champ annonces.date est bien un "char(5) binary" et pas un simple varchar(5) - met bien NOT NULL partout ou c'est possible - fais passer le activated en ENUM ou au BINARY - fais passer les champs texte et vachar en BINARY si tu n'as pas besoin d'une recherche insensible à la casse - si possible essayes de faire passer ton schéma de table "annonces" en statique au lieu de dynamique (élimines les varchar() et char() puis changes le statut via une interface d'admin) Sinon, as tu mis des bons index ? - code postal est-il en index ? - activated est-il en index ? - annonces.id_souscategorie ? etc. Avec des bons index tu peux diviser le temps par 1000 facilement si tu n'avais rien auparavant. Tous les critères principaux devraient être en index à priori. Sinon à partir de MySQL 4.0 tu as un cache de requête intégré qui peut probablement éviter de répéter trop de fois la requête si elle est excessivement gourmande. L'autre idée c'est de réduire le nombre de jointures. Il faudrait plus de précision sur tes données mais peut être que tu peux faire une requête rapide sur une table de façon à extrèmement filtrer, puis refaire une requête sur le reste des tables avec les identifiants de la première. Parfois ça réduit de beaucoup les temps de traitement sur Mysql.

Le fais tu vraiment ? sûr ? sur quel navigateur ? Parce que ce n'est pas possible nativement sur Firefox, ce n'est pas possible non plus sur MSIE (et de mémoire je ne crois pas que ce soit possible sous Opera, mais je peux me tromper). C'est justement pour ça qu'on parle de forcer. L'utilisateur peut ouvrir une nouvelle fenêtre si ce n'était pas prévu, mais pas l'inverse (*). Les gens ne sont libres que si tu ne demandes pas de nouvelle fenêtre, sinon ils sont forcés. (*) Sauf quelques rares geeks qui ont installé un plugin obscur dans le navigateur, mais je ne pense pas qu'on puisse les prendre en compte coté statistique. Si les utilisateurs sont si libres que ça, pourquoi spécifier "dans une nouvelle fenêtre" au niveau du lien ? de toutes façons les gens feront ce qu'ils veulent. C'est ce que me ferait dire ton argument.

Non, l'égo du concepteur c'est de penser que le visiteur veux forcément garder la fenêtre de départ ouverte pour y rester/revenir. C'est une assertion qui est souvent fausse. La règle de base sur le Web : "vous ne pouvez pré-supposer aucune méthode d'accès pour vos utilisateurs". Par exemple personne ne peut affirmer que l'utilisateur ne vient pas volontairement pour un de tes liens précis qu'il avait déjà repéré. Et dans ce cas là il n'a franchement aucun intérêt ) garder ta fenêtre ouverte. Tu fais trois assertions potentiellement fausses : - l'utilisateur voudra revenir sur la page de départ - l'utilisateur sait manipuler confortablement plusieurs fenêtres, plusieurs contextes et plusieurs historiques - l'utilisateur préférera revenir sur la page de départ à l'aide d'une gestion de plusieurs fenêtres plutot que les boutons d"historique (que tu viens de casser en ouvrant une nouvelle fenêtre), les recherches, les bookmark ou tout autre moyen Google, Yahoo et les autres n'ouvrent pas de nouvelles fenêtres. Pourtant s'il y a bien un type d'application ou c'est un souhait des utilisateurs c'est bien la recherche. Et c'est vrai même quand sur Yahoo on clique sur les liens des partenaires. Ces sites sont loin d'être parfaits mais ils ont certainement étudié la question. Vous vous êtes demandés pourquoi ? Quant-à dire que multiplier les fenêtres c'est faciliter le confort de l'utilisateur, là ça me parait tout à fait faux vu comme les gens sans affinité avec l'informatique ont du mal à gérer les fenêtres et contextes multiples. Tu crois qu'elles t'ont attendu ? Elles ont déjà des mécanismes pour avoir un dispositif de pointage, ou des touches pour avoir les actions souhaitées. Tu n'as rien besoin de prévoir à part peut être fournir des accesskey pour les quelques liens statiques importants (recherche, sommaire, menu ...) Pour le javascript, le onclick gère *déjà* les activations clavier, sans qu'il n'y ait rien à faire. Pour l'anecdote, et sans que ce soit une critique (parce que je comprend très bien les objectifs de ce coté là) : En informatique il y a souvent pire que de ne rien faire. Il y a faire sans comprendre et connaitre ce qu'on manipule. Je ne compte plus le nombre d'appli que j'ai vu avec des trous béants de sécurité justement parce que l'auteur a voulu rajouter des sécurités sans en comprendre le fonctionnement. L'histoire du onkeypress pour l'activation des liens par les personnes sans souris est selon moi du même ordre. C'est prendre trop de risques pour un besoin pas forcément existant.

Bien sûr qu'elles peuvent être utiles. La preuve en est pour moi que j'use et j'abuse des onglets, qui sont à peu près la même chose au niveau du concept (mais pas au niveau ergonomie). Le problème c'est qu'il est quasiment impossible pour l'auteur d'affirmer que le visiteur trouvera ça "utile". Pour ce qui est des études je te propose de quitter le domaine Web et d'aller dans les études sur l'ergonomie des modes fenêtrés et surtout du concept de fenêtre multiple + barre des taches. La plupart des gens n'utilisent qu'une seule fenêtre à la fois, maximisée. Avoir des fenêtres déclenchées involontairement qui viennent se positionner au dessus, c'est souvent mauvais. Si tu veux quelque chose d'objectif, comptes le nombre de logiciels que tu utilises et qui utilisent plus d'une fenêtre. La règle est même de commencer à ranger les barres d'outils flottantes car on s'est rendu compte que même ça c'est dérangeant. Une case à cocher ou un lien supplémentaire ? pourquoi pas. Ca se sont des solutions. Reste à trouver une manière simple et efficace pour que l'utilisateur comprenne de lui même à quoi servent ces buotons, et à ne pas trop complexifier l'interface, mais ça peut être une solution. Ce qu'il faut éviter en général de faire ce sont les target ou javascript automatiques, car eux ne permettent pas à l'utilisateur d'imposer son choix (je peux ouvrir dans une nouvelle fenetre quelque chose qui n'est pas prévu pour mais l'inverse est impossible sur la plupart des navigateurs)

Notes que c'est justement pour ça que tu ne devrais pas forcer l'ouverture d'une nouvelle fenêtre : chacun cherche des choses différentes ou a ses propres préférences. En forcant l'ouverture d'une nouvelle fenêtre tu forces tes préféences à toi alors que ce sont celles de ton visiteur qui devraient être utilisées. Il faut bien se souvenir que ce n'est pas vus qui êtes la cible de vos pages. Vos références à vous sont totalement hors sujet.

Ah ? Petit tour du propriétaire : Le onclick javascript est déjà activé si je déclenche le lien par le clavier. Le nom est trompeur, il concerne l'activation et pas uniquement le click souris. Tu peux considérer l'activation clavier comme un click clavier. Le onkeypress n'est pas nécessaire à l'utilisation du js sur tes liens, même pour le clavier. Avec ton onkeypress je ne peux plus naviguer dans mes liens. Dès que je suis sur le premier, la touche pour passer au suivant risque d'activer le premier lien sur certains navigateurs au lien de passer au suivant. C'est idiot parce que ça veut dire que seul ton premier lien est accessible au clavier, les autres sont inaccessibles alors qu'ils fonctionneraient sinon. Dans le même genre je ne peux peut être plus utiliser les touches suivantes si je suis sur un lien : ' qui permettait de faire une recherche dans les liens / qui permettait de faire une recherche dans le texte backspace qui permettait de revenir à la page précédente les flêches qui permettaient de faire défiler la page Je ne parle pas non plus des raccourcis plus classiques ou des touches que quelqu'un qui a des difficultés avec la souris peut justement avoir définit pour une action précise. Au lieu d'améliorer l'accessibilité et les possibilités de navigation clavier tu viens de casser l'utilisation du clavier sur certains navigateurs. Ta personne qui souffre d'un handicap moteur elle sera super contente, crois moi. Ca je peux comprendre. Mais il y a deux notions : le développement et la publication. Vouloir prendre comme objectif le modèle strict peut peut être une raison pour te mettre un doctype strict pendant le développement, pas pour publier avec si tu ne le respectes pas (et donc publier quelque chose de faux). Notes d'ailleurs qu'il n'y a pas besoin de mettre une DTD stricte pour tenter la validation en strict. Le validateur permet de forcer le modèle pendant le test, justement pour ce genre de cas. Tu ne te trompe pas, mettre un doctype XHTML 1.1 personnalisé ça "fonctionne" en théorie. Maintenant, quel est ton but ? - compatibilité ? quasiment aucun client ne sait interpréter les DTD perso, par contre beaucoup passeront dans un mode quirk si tu n'as pas une DTD officielle. Bref, tu dégrades la compatibilité - validité ? pour être valide avec ton XHTML 1.1 modulaire il faudrait que tu envoies ta page en application/xhtml+xml. Elle ne serait alors lisible et comprise que par un ou deux navigateurs (pas MSIE par exemple). Tu l'envois donc certainement en text/html et le résultat c'est que ce n'est pas valide - accessibilité ? en pratique il y a assez peu de clients qui connaissent le XML, c'est loupé de ce coté là aussi - plus pratique ? la plupart des éditeurs et outils savent se servir des DTD officielles, pas des personnalisées. Ca ne sera pas plus pratique non plus Oui, ça fonctionne en théorie, mais en pratique ça n'a aucun intérêt car c'est "moins bien" que les autres solutions sur quasiment tous les points. Je me demande d'ailleurs pourquoi ils ont continué à forcer la déclaration de DTD dans les versions XMLisées. Ce n'est plus nécessaire pour les clients et ça amène ce genre de problèmes. Boaf, le site ne sera pas strict, c'est un fait établi. Maintenant nous on s'en fout un peu. Par contre en informatique les logiciels ont un comportement binaire. Quelque chose est valide ou ne l'est pas. Ca ne l'est jamais "presque" ou "un peu". Ce que je veux dire c'est un lecteur HTML strict risquera de provoquer une erreur fatale sur ta page. Certes la plupart des navigateurs sont super tolérants et laxistes et tu peux te permettre de profiter de cette tolérance Mais .... quel intérêt ? qu'y gagnes tu ? si tu cherches à faire valider et à viser le modèle strict c'est bien pour ne pas reposer sur les facilités non standard du navigateur non ? ça serait aller pile contre ce que tu cherches à priori à faire avec les DTD. Sauf si j'ai mal compris Denis, il propose pile le contraire (mettre un doctype transitionnel) _AT_Denis : tu surveilles les liens entrants sur tes billets ?

Si tu veux faire simple tu utilises le transitionnel, comme tu le dis. C'est tout à vait normalisé et valide. Où est la limite du W3C ? S'il veut utiliser le doctype strict c'est lui qui se met une limitation, personne d'autre. Le modèle strict n'est pas obligatoire et le doctype strict n'apporte qu'une facilité de validation pour celui qui veut le respecter. Pour tous les autres (les lecteurs) ça n'a aucun avantage par rapport au doctype transitionnel (je parle bien de la ligne de doctype, pas du modèle utilisé dans le contenu) Quant à savoir pourquoi ça n'est pas valide en strict, c'est simplement la raison d'être du strict : se séparer à terme de tout ce qui ne décrit pas directement le contenu mais décrit la présentation. Savoir comment afficher la page n'est pas de la description de contenu mais de la présentation. Pourquoi serait-ce présent dans le strict ?

Hum ... HTML 4.01 je pense que tu veux dire. Je me permet aussi de contester le n'est *plus* : HTML 4.0 a été finalisé en 97, en contenant déjà l'attribut target en transitionel et pas en strict. Déjà je doute que tu fasses du Web depuis 97 donc le statut de cet attribut n'a jamais du changer pour toi. Mais même si c'était le cas, l'attribut target n'existait pas avant, il est absent de HTML 3.2. Ca ne marchera pas sans javascript. Bon, à la limite ça dégrade correctement donc ce n'est pas dramatique mais c'est à signaler. Le onkeypress est aussi contestable, ça veut dire que si j'appuie sur une touche en ayant sélectionné le lien, ça active le lien. Une touche ... n'importe laquelle. Y compris tabulation (normalement pour sauter au lien suivant), la touche échap, les raccourcis claviers ou les touches qui normalement n'activent pas le lien. Mais surtout ça n'a aucun intérêt par rapport à la version transitionnelle : - ton code est toujours bardé de propriété de présentation (sauf qu'au lieu d'être en HTML elles sont en Javascript) - c'est plus long et complexe à écrire - ça n'a aucun avantage par rapport à un doctype strict Et certains navigateurs ne vont plus reconnaitre correctement ta page en mode text/html, d'autres vont passer en mode quirk au lieu du mode standard et les derniers ne remarqueront même pas cette personnalisation de doctype. C'est une solution qui a d'autant moins de sens qu'un modèle ayant le module target existe déjà ... le mode transitionnel. *TRES* mauvais article à mon avis . Il préconise au beau milieu une solution qu'il qualifie de pragmatique : utiliser le target tout en gardant le doctype strict. C'est totalement idiot dans le sens que ça garde le désavantage du transitionnel (on met de la mise en forme dans le code) tout en rajoutant des incompatibilités majeures (tout client HTML strict provoquera une erreur). On est moins compatible et on n'a toujours aucun des avantages du modèle strict. Il oublie rapidement l'unique but du doctype : déclarer la grammaire utilisée. Là il utilise volontairement un doctype qui ne correspond pas à sa grammaire, ça n'a réellement aucun intérêt mis à part se la jouer en disant qu'il a un meilleur doctype que les autres. Pragamatique ? c'est au contraire inutilement extrémiste, choisir un doctype strict alors qu'il n'est pas adapté à ce qu'on fait, uniquement pour dire "je fais du strict" (alors que ce n'est pas le cas). Il oublie qu'on peut tout à fait que mettre un doctype transitionnel n'oblige pas à dégrader sa page. Tu peux mettre un doctype transitionnel en n'utilisant que l'attribut target et pas tous les autres. L'idée générale "je montre que je suis un pro parce que j'utilise un doctype strict même si mon contenu ne respecte pas ce modèle en réalité" se retrouve d'ailleurs dans la page puisqu'il a la fierté de marquer "Page conforme : XHTML 1.0 strict" alors que le validateur dit l'inverse. Mis à part faire semblant et se la jouer auprès des copains sa préconisation n'a aucun intérêt. Je ne vais pas être objectif mais je te conseille très fortement la lecture de http://www.cybercodeur.net/weblog/commenta...?idmessage=1088 L'idée principale c'est : - es tu vraiment sûr d'avoir besoin d'une nouvelle fenêtre ? dans la plupart des cas c'est une mauvaise idée - si tu es convaincu que tu en as besoin et que tu veux préciser tout ça dans ton HTML, c'est que dans la démarche tu as une démarche transitionnelle (préciser la présentation dans la description de contenu). Tu aura donc tout avantage à utiliser un doctype transitionnel ainsi que l'attribut target. C'est fait pour ça, c'est ce qui sera le plus accessible (et ça ne t'oblige pas pour autant à utilsier tous les autres éléments et attributs de présentation ; tu peux garder le reste le plus proche possible du modèle strict) - mais si tu veux vraiment utiliser un modèle strict et des nouvelles fenêtres, il y a moyen de jouer avec du javascript évolué et du marquage de contenu.

Tu peux regarder http://www.yoyodesign.org/doc/w3c/css2/syn...ml#length-units pour une description rapide des ex et em (note pour plus tard : c'est le premier lien trouvé par google si on fait une recherche avec "unité em ex")

Euh, le problème il ne vient pas de windows mais de toi. Tu as fait une mise en page au pixel qui ne supporte pas des tailles de police personnalisées. Tu as deux solutions : - revoir ta mise en page, la structurer en %, ex ou em comme unité au lieu de la structurer en pixels - spécifier explicitement une taille de police en pixel, le menu d'Internet Explorer n'aura plus d'influence. Ceci dit le même menu sous Opera, Mozilla ou Firefox aura toujours le même effet donc je doute que ce soit une bonne solution.

Pour les polices à utiliser les autres ont bien répondu. Je me contenterai de signaler celles qu'il ne faut pas utiliser : - comic sans ms (voir plus haut) - verdana (qui est super, très lisible, mais qui est trop "grosse", du coup si le texte est lisible avec verdana il sera trop petit avec les alternatives, s'il est lisible avec les alternatives il sera trop gros avec verdana)

C'est une police "fantaisie", à traiter comme telle. Notez d'ailleurs qu'elle est typée "BD", ceci explicant cela. C'est quoi qu'il en soit une police à éviter pour les textes "à lire". Elle est irrégulière, les caractères semblent plus ou moins gros, plus ou moins alignés et plus ou moins inclinés. C'est beaucoup d'effets d'optiques mais il n'en reste pas moins que c'est dérangeant. Pour ceux qui ont un peu de dislexie comme moi ca augmente l'effet "vaguelette" du texte, il "danse" plus et ça fatigue énormément, voire c'est illisible quand c'est écrit trop gros (oui oui, trop gros, pas trop petit). Même pour les autres elle est plus pénible à lire à la longue et fatigue plus, pour ceux qui ont des problèmes de lecture écran ou qui ont des problèmes de concentration ça ne peut qu'empirer les choses. Pour de petits textes courts, type légende, ou justement les bulles de bd, ça peut tout à fait convenir (même si beaucoup ne l'aiment pas), mais s'il vous plait, jamais pour des blocs de texte et encore moins sur un document complet.

En même temps si l'auteur est anonyme, il n'y a pas de droit associé (vu qu'il est lié à l'auteur), mais comme dit cariboo, le fait qu'il n'y ait rien marqué ne te donne aucun droit donc renseignes toi avant

Non non, ce n'était pas pour chaîner les deux à la suite dans la page qui créé les liens que je te disais ça, sinon il n'y a effectivement aucun intérêt (ça revient grosso modo au même) ok, j'ai mal compris la question alors. On efface tout et on recommence. Il n'y a à ma connaissance aucune fonction native pour faire ça. Si tu as un nombre de caractères spéciaux limités tu peux les lister et faire un str_replace. Sinon d'autres personnes ont déjà fait des str_replace complets (avec les majuscules accentées et tous les caractères zarb), tu pourras les retrouver sur le net. Il te faudra juste rajouter les espaces si tu veux les convertir en tiret Une autre option bien lourde c'est convertir les accents et caractères spéciaux en entités html. "é" deviendra "&eactue;" et ainsi de suite. Sauf quelques exceptions, la première lettre après le & correspond à ce que tu cherche à mettre en remplacement. Tu peux t'en servir pour reconstruire ton texte. Donc : convertir à la main les exceptions et les espaces, convertir le reste en entité, rechercher toutes les entités pour les reconvertir à leur tour en utilisant la première lettre de l'entité quand c'est une entité non numérique.

urldecode() Ces %xx sont la manière normale de coder un accent ou un caractère spécial dans une URL. Le plus code lui l'espace. Tu as fait un lien avec des caractères non ascii. Tu n'en as normalement pas le droit, c'est théoriquement incorrect. C'est ton navigateur qui, conciliant, a intercepté le problème et a converti les caractères accentués en %xx Mettre les caractères accentués dans les liens "marche" souvent mais devrait être évité. Suivant le codage caractère en cours, suivant celui de la page, suivant le navigateur, le même caractère risque de se convertir en des %xx différents (et donc ne pas donner la bonne page). Sauf erreur de ma part ton rewrite ne génère pas l'url, c'est tout le contraire, il l'intercepte et l'interprête.

euh, je vais prendre le pas des autres (note importante: je ne suis pas juriste) : - Il n'a aucune obligation de t'ouvrir un accès membre. Chacun est maitre chez lui. Il n'a aucune justification à donner. - Tes contributions ont été faites dans le cadre de la société et pour la société. Si vraiment tu vas en justice, je tiens pour probable qu'on assimile ta situation à quelqu'un travaillant pour l'entreprise familliale. Et tout ce que tu produis dans le cadre de l'entreprise appartient à l'entreprise, pas à toi. Tu ne gardes qu'un droit moral dessus et tant qu'elles ne sont pas mises hors contexte ou reprises pour une autre utilisation que celle de départ, je doute que tu puisses avoir un quelconque contrôle sur tes contributions. - Indépendament de "à qui appartiennent les droits patrimoniaux de tes écrits", en publiant sur son site je suis certain qu'un juge y verra une autorisation implicte de publication. Et sauf s'il change le contexte ou les réutilise ailleurs, je doute que tu puisses par la suite demander à les retirer du jour au lendemain. Je doute très fortement que tu gagnes quoi que ce soit en justice. A mon avis le point le plus litigieux sera le fait que tu travaillais plus ou moins pour l'entreprise à l'époque. Franchement, essayes plutot de passer par la concertation car à mon avis coté législatif c'est plutot de son coté qu'il y a le plus de chances. C'est d'autant plus vrai que ce qui fonde ta demande ce n'est pas le respect des droits d'auteur mais l'envie d'avoir un accès membre pour t'expliquer, chose qu'il est tout à fait habilité à te refuser (il n'a aucune obligation de t'offrir une tribune). A mon avis la seule chose à laquelle il est vraiment tenu c'est de ne plus rien faire à ton nom, et surtout de ne pas lire ou utiliser ce que tu peux recevoir comme mail ou contact privé (donc sans relation avec la boite). De même, sauf si tu lui demandes via de supprimer toute info personnelle te concernant, il n'aurait à priori je pense pas le droit de s'approprier tes écrits (c'est à dire de retirer les crédits ou la mention de l'auteur si elle existe), ça concerne les droits moraux et ceux-ci sont incessibles. Indépendament : - ça n'a rien à voir avec la CNIL. Ce qui aurait à voir avec la CNIL c'est éventuellement supprimer toute mention de ton nom ou de tes coordonnées (par exemple dans les champs "auteur"). La CNIL ne s'occupe que des fichiers nominatif et des traitements informatisés liés, pas du droit d'auteur. - Tu parles de réponse pour t'expliquer sur ton départ. Si il parle de ton départ dans des termes qui ne te conviennent pas et que le site peut être assimilé à un média de presse, tu peux peut être éventuellement jouer sur le droit de réponse pour lui demander de mettre une réponse de ta part. Par contre ça n'implique pas de te donner un quelconque accès ni ne lui retire son droit à mettre ce qu'il pense sur son site.

- tu n'as pas besoin de coder tes caractères étendus (accents par exemple) sous forme d'entité (é) si tu déclares correctement ton jeu de caractères dans le fichier HTML - les varchar, tinytext et autres sont des types de données pour MySQL et les autres SGBD. Leur rôle est de stocker la donnée, il ne t'aideront jamais à faire autre chose, ils n'ont en particulier rien à voir avec la notion d'échappement HTML - tu ne devrais jamais utiliser ereg_* mais toujours preg_* - tu n'as pas besoin d'ereg ou preg pour faire les échappements HTML (mise sous forme d'entités) : htmlspecialchars() et htmlentities() font très bien ça toutes seules - Par contre, de même que tu dois faire un addslahes pour éviter les apostrophes dans les chaînes SQL, de même que tu dois mettre\" pour faire un guillemet quand tu écris une chaîne PHP, en HTML certains caractères sont spéciaux car ils déclenchent des actions spécifiques. Ce sont en particulier < > et & (début et fin de balise, début d'entité). Il doivent donc être échappés si tu ne veux pas qu'ils soient interprétés et jouent leur rôle "magique". La fonction pour les échapper est htmlspecialchars(). Tous les langages, que ce soit le SQL, le shell, le HTML, ls XML, PHP ou le C, ont des caractères spéciaux pour traiter les données et nécessitent de passer par une fonction d'échappement. Ca n'a rien à voir avec "...les standards..." comme tu sembles les nommer

Tes photos (si ce sont les tiennes) sont protégées par défaut. Pas besoin de mettre un copyright, pas besoin de mettre je ne sais quelle licence, pas besoin de mettre un quelconque texte. Tant que tu pourras prouver que ce sont les tiennes, personne n'aura aucun droit de les utiliser sans ton autorisation.

Dites, c'est quoi la proportion des gens qui ont des problèmes de perception de couleurs ? visiblement c'est déjà plus que ce que je pensais

> Est-ce que l'état-civil, la carriere, les affectations [...] sont libres de droits d'auteurs ? Oui, il s'agit d'une information, l'information n'est pas sous le droit d'auteur, seul l'oeuvre est protégée. Par contre autant tu peux reprendre un état civil, tu ne peux pas le recopier, car là tu ne copierais pas que l'état civil mais aussi l'oeuvre, le texte rédigé qui parle de cet état civil. Même chose pour une définition de dictionnaire, la définition n'est pas protégée mais par contre sa formulation l'est. > les propos tenus Le droit d'auteur (du moins la partie patrimoniale) c'est 70ans après la mort de l'auteur. Pour des choses qui datent de l'empire ça devrait être bon Par contre même chose, tu peux recopier les propos, mais pas l'analyse qui va avec ou la présentation de ces propos

Qu'on soit d'accord, je ne suis pas juriste et si tu veux une vrai garantie je te conseille fortement d'aller prendre RdV avec un avocat de la propriété intellectuelle. Par contre malheureusement j'aurai tendance à dire que ta notice ne sert à rien. Tu ne peux te décharger de tes obligations légales simplement en déclinant toute garantie et toute responsabilité. En organisant le site et son contenu tu prend le rôle d'un éditeur et tu ne peux te décharger entièrement sur les rédacteurs. Si un contenu malhonnête est posté, j'ai peur que tu puisses effectivement être inquiété. Tout au plus ce que tu peux faire c'est bien afficher le nom de celui qui a soumis chaque contenu, logguer ip+heure de ton coté, et imposer l'acceptation d'une déclaration de chaque contributeur comme quoi les contenus envoyés ont les autorisations nécessaires pour une publication en ligne sur ton site (par exemple en dernière étape de la soumission avec une case à cocher). Ca ne te déresponsabilisera pas mais au moins tu pourras te retourner contre le mauvais contributeur et montrer ta bonne foi. Je ne comprend pas le paragraphe qui dit qu'il est interdit de faire quelque chose d'illégal c'est quoi le but ? la loi est déjà faite pour ça. Et ... bien entendu la dernière phrase de ta notice n'a aucune valeur. Ne peut être considéré comme accepté qu'il a effectivement lu et compris. Tant que tu n'as pas un moyen de forcer la lecture de ce texte, tu ne peux certainement pas considérer qu'il est accepté. Par contre ce qui m'intrigue le plus c'est le "pouvant causer tout dommage à toute personne ou être illégal ou contraire à la loi de quelque façon que ce soit, y compris sans y être limité, toute menace, tout harcèlement et matériel pornographique, obscène, profane ou diffamatoire constituant ou pouvant encourager un comportement considéré comme une infraction, ou être contraire à toute loi de quelque façon que ce soit". Mon dictionnaire me donne deux définitions de "profane" : - "dépourvu de caractère religieux" - "porte atteinte au caractère sacré de quelque chose; impie, sacrilège" As tu l'impression qu'être profane est illégal ? pornographique ? menaçant ? obscene ? Même en prenant la chose dans la seconde définition j'ai du mal à voir le problème. Inversement, vu la liberté de religion, j'ai presque peur que ce soit toi qui puisse être inquiété à cause de cette association malheureuse.

Un DomElement *est* un DomNode, c'est un DomNode spécial mais un DomNode quand même (en xml un élément est un noeud) : DomElement est une classe dérivée de DomNode. Est-ce que tu as bien fais attention aux espaces de nom ? à vue de nez je dirai que ton <entry> est dans un espace de nom quelconque, ce qui explique que xpth ne le trouve pas mais que le getElementsByTagName le trouve.

Le problème est (pour les paranos comme moi) qu'il n'est fait aucune mention de l'utilisation de ces données à part l'abonnement (mailing informatique ? mailing papier ? revente d'information de profil aux sociétés spécialisées ?). Il n'y a même aucune coche pour dire qu'on refuse la revente et la réutilisation de ces infos (je sais, légalement maintenant si ce n'est pas moi qui coche une autorisation ça devrait être interdit, mais comme c'est peu respecté, j'aurai préféré de l'explicite). Si un des responsables n'était pas connu je ne me serai pas inscrit. C'est peut être une info à rajouter pour ceux qui font ce genre d'offres promotionnelles.