LaurentDenis
-
Compteur de contenus
1 281 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par LaurentDenis
-
Pour info, le label accessiweb (également référentiel des sites des administrations publiques françaises) retient la barre de 40 liens dans le contenu de la page hors menu de navigation
-
Ah... c'est la question que je me posais en ce matin. Mais je n'ai rien trouvé dans les mentions légales sur le site officiel (http://www.picasa.com/google/)... Serais-je naïf ? Peux-tu nous en dire plus ?
-
Monique, je cherchais justement un exemple de problème bien concret posé par les implémentations incorrectes et la tolérance excessive des navigateurs envers la soup de tags... Merci
-
Non, Matthieu. la séparation en question n'est pas accomplie entre HTML et XHTML, mais entre - (X)HTML transitional, - et (X)HTML strict d'autre part. C'est en effet le passage du transitional au strict qui proscrit les éléments et attributs de présentation : ( http://www.la-grange.net/w3c/html4.01/stru...obal.html#h-7.2 ) Et XHTML1.0 n'est rien d'autre à cet égard que du HTML reformulé (c'est sa définition, d'ailleurs)/ Petite expérience pratique : le code suivant... <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xml:lang="fr" lang="fr" xmlns="http://www.w3.org/1999/xhtml"> <head> <title>test</title> <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" /> </head> <body> <p><font size="1" face="Arial" color="#ff0000">test</font></p> </body> </html> ... mélange allègrement présentation et contenu, parasite joyeusement l'information avec de la mise en forme ... en XHTML1.0 transitional parfaitement valide Du point de vue séparation de la présentation et du contenu, deux documents HTML4.01 transitional et XHTML1.0 transitional sont strictement équivalents, tout comme deux documents HTML4.01 strict et XHTML1.0 strict
-
Nvu a désormais son forum dédié (en anglais): http://forum.nvudev.org/
-
Bien qu'apparemment en marge de ta question, le mémoire de Sébastien HOF sur l'ergonomie des moteurs de recherche devrait t'intéresser, je crois.
-
Disons plutôt que c'est très incomplet. Pour tout dire, j'ai sur le feu quelque-chose à ce sujet, et vos critiques virulentes sur ces idées en vrac sont les bienvenues
-
- http://openweb.eu.org/articles/initiation_css/ pour un survol rapide des propriétés CSS (il y a une partie sur les bordures) - http://www.tuteurs.ens.fr/internet/web/html/css.html pour une excellente initiation pratique aux CSS - http://www.yoyodesign.org/doc/w3c/css2/box...#propdef-border pour la spécification CSS2 concernant les bordures. Il peut y avoir des différences selon l'élément sur lequel s'applique la bordure, mais grosso modo, pour supprimer les bordure d'une image par exemple... tu écris dans ta feuille de style : img { border: 0; }
-
Petit exercice de traduction diplomatique : il ne faut pas oublier que "les technologies les plus récentes" sont ici des technologies que le W3C cherche à promouvoir pour de toutes autres raisons que l'accessibilité D'autre part, une technologie n'est disponible qu'à partir du moment où: - elle est définie par une norme en bonne et due forme, ce que ne sont ni XHTML2.0 ni CSS3 à l'heure actuelle; - elle est suffisamment implémentée par les navigateurs (AMHA, ce n'est pas le cas de XHTML1.1, ignoré par IE, les lecteurs d'écrans...) Enfin, du point de vue accessibilité, le saut qualitatif majeur a été réalisé avec le passage de HTML3.2 à HTML4.0, puis HTML4.01 : c'est là que sont normalisés les éléments et attributs d'accessibilité. allez, j'ose : XHTML n'apporte aucun gain d'accessibilité Finalement, le plus important ici, c'est adaptée à une tâche, que celle-ci concerne ou non l'accessibilité. Autrement dit: - utiliser de préférence CSS2 à CSS1, la première enrichissant l'autre et la corrigeant (les styles utilisateurs l'emportent dans tous les cas sur les styles auteurs, ce qui est important pour l'accessibilité, par exemple); - utiliser de préférence HTML4.01 à HTML4.0 , car ils sont adaptés aux mêmes tâches mais HTML4.01 corrige des défauts de HTML4.0; - utiliser XHTML1.0 plutôt que HTML4.01 quand on souhaite bénéficier des possibilités de traitement XML du contenu... - utiliser strict ou transitional de préférence à frameset, en raison des problèmes d'accessibilité des frames; - utiliser (X)HTML strict plutôt que (X)HTML transitional, quand les contraintes de production de code le permettent (ça fait partie de l'adaptation à la tâche) et qu'on veut bénéficier de la séparation contenu/présentation, de la rigueur syntaxique... - utiliser XHTML1.1 ... quand il est nécessaire pour des tâches bien précises (intégration de SVG ou de MathMl...).
-
Et pourquoi pas plutôt de jolis et légers boutons CSS ?
-
Le W3C donne toutes les explications dans FAQ: Using HTTP and meta for language information. Rapidement : La langue de traitement d'un document est unique. Il s'agit par exemple d'indiquer à un lecteur d'écran la langue dans laquelle le document sera lu par défaut, mais aussi à un navigateur graphique la police par défaut ou l'orientation à adopter pour les langues type arabe, japonais... Cette information est utilisable que le document soit consulté en ligne ou enregistré localement. Elle est théoriquement supportée par tous les medias (même les lecteurs d'écran s'y mettent depuis peu). Elle doit être indiquée avec l'attribut lang (ou xml:lang en xhtml) de l'élément HTML : - en XHTML1.1: <html xml:lang="fr" xmlns="http://www.w3.org/1999/xhtml"> - en XHTML 1.0 <html lang="fr" xml:lang="fr" xmlns="http://www.w3.org/1999/xhtml"> - en HTML <html lang="fr"> Lorsque le document contient des fragments de contenu dans d'autres langues, on utilise les mêmes attributs localement: -XHTML1.1: <p xml:lang="en"> -XHTML1.0: <p lang="en" xml:lang="en"> -HTML: <p lang="en"> La redondance lang et xml:lang est recommandée comme bonne pratique en XHTML1.0 pour assurer la compatibilité avec les navigateurs... anciens qui ne savent pas lire xml:lang. L'un ou l'autre, ou l'un et l'autre sont également valides, mais xml:lang seul est le moins indiqué, car le moins bien supporté. La ou les langues du public visé peuvent être indiquées à l'aide de metadonnées et de l'en-tête HTTP (par exemple en PHP: header('Content-Language: fr'); ). Cette-fois: - plusieurs langues peuvent être indiquées (page bilingue, par exemple) - l'information donnée avec l'en-tête HTTP est perdue lorsque la page est enregistrée localement. La meta, elle, est alors conservée (il faut donc associer les 2) - le support est plus hasardeux car rien n'oblige les medias à en tenir compte (le validateur d'acces-pour-tous en est un exemple ) Certains navigateurs, lecteurs, moteurs... sont donc susceptibles de les utiliser pour savoir comment traiter le document, mais de manière tout à fait fortuite, non normalisée et pour ainsi dire propriétaire - les meta ne sont pas normalisées, du moins, pas au sens de la norme HTML qui est imposée aux navigateurs... - ces infos sont surclassées par les attributs lang et xml:lang utilisés localement dans le document. Il existe plusieurs formes de meta disponibles, par exemple (ici en XHTML): HTTP-equiv: <meta http-equiv="Content-Language" content="fr" /> DUBLIN-CORE: <meta name="DC.Language" scheme="RFC1766" content="fr" /> Conclusion : - <html lang=".... est obligatoire - HTTP et meta sont à décider au cas par cas, selon les besoins. Mais la redondance entre les 3 ne peut pas nuire, en particulier pour compenser les comportements non standard des différents medias Ah, au fait : les codes de langue sont ici: http://www.loc.gov/standards/iso639-2/frenchlangn.html
-
perte d'affichage sous IE à cause du flux
LaurentDenis a répondu à Sylvain Trovalet - Forum : (X)HTML et CSS
Peut-être bien quelque-chose en rapport avec http://devedge.netscape.com/viewsource/200...l-style-script/ ? HTML4.01 Transitional, oui. Ce sera certainement cassé dès que quelqu'un utilisera un FrontPage quelconque pour mettre le site à jour, mais au moins ça limitera les dégats en autorisant les éléments déconseillés de présentation, la syntaxe du genre paragraphes non fermés, etc. Bonne chance -
perte d'affichage sous IE à cause du flux
LaurentDenis a répondu à Sylvain Trovalet - Forum : (X)HTML et CSS
ça ne va pas du tout, ça : du XHTML envoyé avec un doctype HTML.... est totalement invalide. Du XHTML ne peut-être envoyé qu'avec un doctype XHTML ! Donc, ici, il faut envoyer à IE du XHTML1.0. (au passage, la syntaxe du doctype HTML est erronée ; voir http://www.w3.org/QA/2002/04/valid-dtd-list.html pour les syntaxes à employer) Simple question : les auteurs du site (une Commune) maîtriseront-ils toute la production du code ? autrement-dit, n'y a-t-il vraiment aucun risque pour qu'un code non XHTML1.1 ne soit un jour ajouté sur une page ? Parce que dans ce cas-là, ça va planter En résumé, un peu brutal : être valide et conforme aux standards, ce n'est pas adopter inconsidérément le dernier standard en date... tout en envoyant un code invalide à IE... C'est adopter une démarche rationnelle et cohérente. Ici, une DTD HTML transitional serait plus appropriée, car sans doute plus en rapport avec la production réelle du site... -
Un p'tit truc tout bête pour vérifier qu'un élément ou un attribut est valide, propriétaire, obsolète, déconseillé... les tableaux récapitulatifs de la specification HTML4.01 : - Index des éléments - Index des attributs Ces tableaux sont valables aussi bien en HTML qu'en XHTML. - Les éléments et attributs absents de ces tableaux... sont invalides. - Les attributs ne sont utilisables que sur les éléments mentionnés en regard. - la colonne "Déc." permet d'identifier les éléments et attributs "déconseillés", c'est à dire les restes de HTML présentatif tolérés en (X)HTML transitional, mais qui disparaissent en (X)HTML strict et dans les spécifications XHTML suivantes. En outre, ces tableaux offrent des liens direct vers la définition des éléments et attributs dans la spécification... Bref, une référence simple à utiliser et une entrée facile dans la spécification PS: de même, pour CSS2: - Index des propriétés - Index des descripteurs
-
Les frames ne sont pas indispensables. Elles sont une solution de remplacement discutable (voir l'article mentionné par Denis) lorsqu'on n'a pas accès au traitement côté serveur (ASP, PHP...) pour gérer les include de code HTML commun aux pages (bandeau d'en-tête, menus, pied de page...). Autant le maintien des frames (mais valides HTML frameset) se justifie dans certains cas pour du contenu existant, autant il ne se justifie pas, AMHA, pour un nouveau contenu, vu la facilité d'accès à PHP.
-
Etude sur le e-tourisme en Massif Central
LaurentDenis a répondu à yannick - Forum : Le salon de Webmaster Hub
Ce document est sans doute intéressant. Mais je n'aime guère devoir donner mon nom, mon adresse mail... sur un site qui, sauf erreur de ma part , n'affiche aucune politique de confidentialité des données personnelles recueillies... pour un simple téléchargement de pdf -
Non. C'était le cas selon CSS1, mais le tir a été heureusement rectifié avec CSS2: http://www.yoyodesign.org/doc/w3c/css2/cas...important-rules Dans tous les cas, la feuille de style utilisateur l'emporte sur les styles auteurs.
-
Non : l'@import permet de cacher la CSS aux navigateurs ayant un support CSS buggués (typiquement, NS4).
-
J'avoue être perplexe... Pourrait-on avoir quelques urls des sites en question, pour aborder la discussion avec des éléments concrets en main ?
-
Bienvenue tamy. Tu trouveras dans le forum Virus et Sécurité informatique tous les conseils pour adopter une politique efficace de protection contre les virus, et notamment celui-ci : Rien ne remplace un bon antivirus PS: j'ai modifié le titre de ton sujet pour y faire apparaître ton pseudo... "Présentation" était un peu anonyme...
-
L'ouverture forcée d'un lien dans une nouvelle fenêtre est simplement typique du "Web vu par Internet Explorer", et n'a plus de sens dans le Web auquel donnent accès les navigateurs normalisés et plus évolués (navigation par onglets...) Le débat des pour et des contres va durer... autant qu'IE
-
Les deux validations (accessibilité / HTML) sont de nature totalement différente, AMHA: La validation d'accessibilité telle que décrite par yobiwan, c'est à dire au-delà de ce que peuvent apporter les validateurs autmatisés type Wave: - vise pour l'essentiel des pratiques, et très ponctuellement l'emploi formel d'un langage (label des formulaires, éléments et acessibilité des tableaux...) - vérifie la conformité en vue de l'accès des personnes à la page. A m'inverse, la validation (X)HTML: - ne concerne que l'emploi formel d'un langage, le respect de son vocabulaire (pas de marquee...), de sa syntaxe (fermeture des balises...) et de son orthographe (attributs entre guilemets doubles...) Elle est indifférente aux pratiques (remplacement des balises spécifiques par des balises génériques, comme pour les titres par exemple). - vérifie la conformité en vue de l'accès des machines à la page. Le développement actuel des lecteurs d'écran le montre bien, dans la mesure où ils sont relativement indifférents au éléments d'accessibilité normalisés du HTML, et où ils ont développés leurs propres mécanismes d'exploitation du contenu. Finalement, on pourrait structurer la démarche en fonction des couches successives sur le contenu et en fonction de l'utilisateur visé à chaque étape : - contenu brut - couche de (X)HTML pour lui donner du sens pour les machines, - couche de CSS pour lui donner un sens visuel/graphique pour les personnes, - couche d'accessibilité (pour compléter les éléments d'accessibilité requis par le XHTML comme le alt des images) pour lui donner un sens visuel/auditif... pour les personnes handicapées...
-
Pour ma part, après avoir essayé diverses solutions du type extensions FireFox, lecteur de feed intégré à opera... je suis passé à une application client spécifique (FeedDemon). La vieille histoire de l'outil spécialement conçu pour, qui se révèle en général plus efficace et plus puissant qu'un add-on dans un navigateur Mais ça n'est qu'une opinion très subjective, bien-sûr.
-
Gou, peux-tu donner une url vers le code source ? ce sera plus facile
-
Hum... peux-tu préciser un peu le "ce qu'ils devraient avoir normalement" ? Je ne suis pas sûr qu'il y ait un bug d'IE dans ce cas (ou alors, je l'ai loupé, celui-là ) En effet, normalement, c'est à dire par défaut, les éléments n'ont pas de positionnement : ils sont en flux. Tous les navigateurs, y compris IE, respectent cette règle. (Les positionnements (absolu, fixe) et le float consistent justement à extraire le bloc concerné du flux.) D'autre part, le positionnement absolu (et le fixe) ont une règle souvent oubliée : - par défaut, le bloc est positionné par rapport au bloc conteneur initial, c'est à dire en pratique la fenêtre d'affichage du navigateur. - pour le positionner dans les limites d'un autre bloc conteneur, il faut que ce dernier soit lui-même en position relative (sans forcément être déplacé, donc éventuellement sans mention de top: ni de left:...) Il arrive souvent que l'oubli de ce position:relative à appliquer au bloc conteneur provoque des rendus suprenants et déroutants