LaurentDenis

Chacun a sa méthode... Les uns font un croquis papier, d'autres un visuel dans un photoshop quelconque, d'autres démarrent directement l'écriture de la CSS une fois la structure HTML établie. Ne pas faire de mise en page absolue au pixel près serait déjà un bon point de départ En effet: - elles nécessitent de prendre en compte et de gérer individuellement les bugs de positionnement et de dimensionnement propre à chaque navigateur... pour constater finalement qu"il en reste souvent un où "ça coince". - elles ne peuvent pas tenir compte de la variété des configurations propres à chaque utilisateur, qui combinent leurs configurations au niveau de l'OS, au niveau du navigateur et des styles utilisateurs éventuels. Une mise en page de ce type échoue systématiquement pour un nombre imprévisible de visiteurs... La gestion la plus "saine" de l'interopérabilité (restitution de la page dans tous les medias et dans toutes les configurations locales) consiste au contraire à "laisser du jeu", en particulier dans le dimensionnement et le positionnement. Le rendu différera selon les utilisateurs... mais en limitant considérablement les risques de "casse". Bref, ne figez pas vos pages pour un "utilisateur type" : celui-ci n'existe pas

Deux remarques : boutons de navigation il faut spécifier une largeur pour le <ul> de ton header, sinon tes boutons ne sont pas placés horizontalement dans Opera (ce n'est pas un bug, mais une ambiguïté dans la spécification CSS2). Par exemple, width: 90%; Menu de navigation ton titrage n'est pas très fonctionnel dans un lecteur d'écran qui permet de naviguer de titre en titre : le menu composé de <h3> y sera considéré comme une sous-section de #contenu, et ne sera donc accessible qu'en descendant la série de titre <h3> de .cadre. Il manque en fait un <h2>Navigation</h2> : <div id="menu"> <h2>Navigation</h2> <h3>Rubrique 1</h3> Si tu veux le cacher, utilise : #menu h2 { position:absolute; left:0px; top:-500px; width:1px; height:1px; overflow:hidden; } ou plus simple : #menu h2 { position:absolute; clip: rect(1px 1px 1px 1px); } Mais surtout pas de display:none qui le cacherait aussi dans les lecteurs d'écran...

Attention : IE7 n'est pas encore en version finale (c'est encore une alpha).

La suite de ce sujet portant sur "comment ombrager une bordure" a été déplacé dans un nouveau sujet

Un avis strictement personnel, qui ne reflète que mes a-priori et mon peu de goût pour les CSS voulant tout contrôler au iota près dans tous les navigateurs : on peut faire un hack avec une plume, le plus légèrement possible. On peut aussi prendre un navigateur de front avec un buldozer. Les deux approches se défendent, mais IE7 prend un bulldozer pour viser principalement des bugs d'IE qui n'ont rien de dramatique et pour lesquels on peut facilement permettre à la page se "dégrader correctement" dans IE, sans hacks le plus souvent. Quand à implémenter artificiellement CSS3, qui n'est pas encore une spécification... aucune fonctionnalité importante d'une page ne doit reposer dessus. Cela dit, l'exploit technique est remarquable

A lire ce sujet, il est tout simplement impossible de savoir au bout du compte quelle solution exacte tu as retenue, avec quelle syntaxe, quelle erreur éventuelle, quelles possibilités à exploiter, etc. Avoir à deviner ton code avant de pouvoir t'aider complique inutilement les choses et n'encourage pas à intervenir. Merci de faire un effort de précision.

Hum... A le relire, mon petit article sur Atomz en XHTML aurait besoin d'être dépoussiéré : le contenu par défaut du champ de recherche est à supprimer, ainsi que le javascript un peu idiot qui l'accompagne

C'est illusoire et ce n'est pas souhaitable : pour que tes images et tes textes puissent être affichés par un navigateur, il faut que les informations nécessaires aient été "téléchargées" par celui-ci (le code-source de la page, les images elles-mêmes). Ils peuvent alors être copiés soit à partir du navigateur lui-même, soit en allant chercher directement les informations nécessaires dans le code-source ou dans le cache. Certes, tu trouveras quelques scripts ou instructions qui bloquent incomplètement l'accès au copié-collé depuis certains navigateurs... Ils ne fonctionneront que dans certains cas, n'empêcheront pas la copie par un autre moyen, et gêneront tes visiteurs plus qu'autre-chose. Par exemple, <meta http-equiv="imagetoolbar" content="no"> bloque la barre qui s'affiche dans IE6 au survol des images pour en faciliter justement la copie locale... Mais rien n'empêche la copie à l'aide du menu contextuel (clic droit). Bon, alors il n'y a qu'à neutraliser aussi le clic droit avec un javascript ? - les scripts en question ne marcheront que un ou deux navigateurs, et si le javascript est activé; - tu supprimes du coup les autres fonctionnalités de ce menu (ajouter aux signets, imprimer...); - il suffit d'accéder directement à l'image dans le cache du navigateur ou sur le serveur pour la copier... Des moyens plus évolués existent, mais ils restreindront l'accès à des visiteurs ayant une configuration paticulière, et/ou ne seront au bout du compte guère plus efficaces. En conclusion, le fait qu'un document puisse être reproduit est indissociable de sa diffusion sur le Web. Il est préférable d'en prendre acte et de diffuser ses créations sous une licence qui en règlemente l'usage (Creative Commons par exemple)

Google est un vieux navigateur texte, totalement indifférent aux CSS Par contre, pour éviter de trop crier et pour faciliter les copiés-collés de ton texte, ce serait bien de faire plutôt : <b class="capital">Un boxer blanc ne mérite pas de mourir à cause de sa couleur !</b> .capital { text-transform: uppercase; } (C'est plus poli )

Voilà ce sont des trucs qui fonctionnent sous xhtml alors comme "qui peut le plus peut le moins", cela devrait passer en htm Non. En HTML, les commentaires s'écrivent : <script type="text/javascript"> <!-- --> </script> Non plus. En HTML, les balises vides n'utilisent pas le /, donc: <p> ..... </p> <br> <img src="logo.gif" alt="texte de l'image"> <hr> Enfin, tu auras avantage à utiliser plutôt dans un premier temps : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> en début de document. Ceci te donnera une plus grande tolérance sur ton balisage.

http://multinux.free.fr/developpement.html au lieu de http://multinux.free.fr/Developpement.html ira beaucoup mieux

- Syntaxe de la propriété clip - Utiliser Clip pour masquer du contenu de manière accessible ? Amusante coïncidence Cela dit, le clip: rect( ) est invalide, inutile et sans aucun effet sur quoi que ce soit, faute de coordonnées à clipper.

Parier sur ce que sais, ne sais pas, n'a qu'à savoir, saura demain... un supposé internaute moyen me paraît bien risqué. L'internaute moyen n'existe pas : En revanche, je dois dire que cette pratique d'échanges de liens/partenariat (même librement consentie par les participants), ainsi que l'idée de "retenir" le visiteur par le biais d'un artifice aussi grossier que l'ouverture forcée dans une nouvelle fenêtre... tout cela me fait penser, toute proportion gardée, aux excès de la fameuse politique hypertextuelle (liens hypertextuels) du site officiel du Comité d’Organisation des Jeux Olympiques ATHÈNES 2004 : le lien hypertexte et la navigabilité sont le tissu même du Web. Vouloir les "brider" va un peu à contre-sens de celui-ci...

Les possibilités et combinaisons étant très nombreuses, tu trouveras le détail du comportement de chaque navigateur (doctype switching) selon ta syntaxe particulière en consultant : - Mozilla's quirks mode - The Opera 7 DOCTYPE Switches - Doctype switching in Internet Explorer ou Microsoft's DOCTYPE Switch Documentation Oups, j'oubliais le tableau résumé de Browser Problems with the XML Prolog

C'est exactement çà

Les commentaires conditionnels sont bien détaillés dans Conditional Comments for Internet Explorer Comme l'indique cette page, seuls les commentaires conditionnels qui réservent leur contenu à IE sont valides en (X)HTML : les CC de la forme <![if IE]>...<![endif]> qui cachent leur contenu à IE sont invalides.

Marie, dans http://www.zengrafom.org/cv/blocks_zen.css , remplace { visibility : hidden;} par : p.hidden { position:absolute; left:0px; top:-500px; width:1px; height:1px; overflow:hidden; } Ton code est un peu touffu, et il est difficile de te donner une solution complète. Mais ceci devrait déjà remédier déjà au problème des lecteurs d'écran pour lesquels tes liens risquent de ne pas avoir de contenu

En pratique, non, ça ne suffit pas. Petit résumé rapide : Un navigateur tente de déterminer l'encodage d'un document successivement : - d'abord à partir de l'en-tête HTTP Content-Type envoyé par le serveur, - à défaut, avec le prologue xml ci-dessus pour les documents XHTML, - à défaut, avec la meta http-equiv="Content-Type" content="...; charset=..." - à défaut, en tentant de deviner d'après le contenu ou selon les réglages faits par l'utilisateur qui permettent de spécifier un encodage à utiliser en cas de doute (ça, c'est la porte ouverte à toutes les erreurs possibles et imaginables). Cependant : - l'en-tête HTTP ne suffit pas, car les utilisateurs n'accèderont pas forcément au document via HTTP : il suffit qu'ils l'aient enregistré localement pour qu'ils perdent l'information d'encodage. - et le prologue XML n'est pas toujours souhaitable : il n'est n'est obligatoire en XHTML1.0 Strict que lorsque XHTML1.0 est traité en tant qu'XML, que rien n'est spécifié au niveau serveur, et que l'encodage n'est pas en utf-8 ou en utf16. On peut donc préférer l'éviter dans la mesure où il modifie le mode de rendu CSS d'Opera et d'Internet Explorer 6.0 Win qui adoptent alors le modèle de boîte Microsoft et non le modèle Standard, alors que d'autres navigateurs resteront en mode de rendu Standard. La "bonne pratique" est donc: - de fixer l'encodage avec l'en-tête HTTP si on a accès à ce paramètre serveur, par exemple avec header("Content-type: text/html; charset=ISO-8859-1"); en PHP, ou <%response.ContentType=("text/html; charset=iso-8859-1")%> en ASP. D'autres méthodes sont détaillées dans The HTTP charset parameter. - de le repréciser systématiquement dans le document lui-même, avec le prologue XML éventuellement (en XHTML, pas en HTML !), et la meta (en HTML obligatoirement, fortement recommandée en XHTML) Ce qui donne concrètement : en XHTML1.1 : <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr"> <head> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=ISO-8859-1" /> en XHTML1.0 (traité comme du HTML) : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" /> Et en HTML : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="fr"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> Voir WaSP Asks the W3C : Specifying Character Encoding pour plus de détails. Enfin, il faut encore que ton contenu respecte effectivement l'encodage en question, ce qui dépend de l'éditeur HTML que tu utilises. Ceci pose souvent un problème sous Windows avec les éditeurs qui encodent en fait en Windows-1252 les documents supposés être en ISO-8859-1. On ne s'en aperçoit que lorsqu'on utilise certains caractères Windows illégaux en HTML et XHTML. Voir Accesskey, l'essai non transformé de l'accessibilité

C'est l'une des raisons pour lesquelles je préfère nettement la solution du display:inline pour mettre une liste à l'horizontal...

Un peu surprenante, la liste qui s'inverse entre la source HTML (Tab Five en premier) et le rendu CSS (Tab Five en dernier)

Ce qui est intéressant, c'est que, d'après ces essais rapides, cette technique de masquage du texte dans le titre est extrêmement facile à utiliser...

La version de Jaws que tu utilises n'appliquerait donc pas la propriété "clip". Mais reste à voir comment le style est invoqué (link, _AT_import, règle média ?), car ce n'est pas neutre, si mes souvenirs sont exacts. Intéressant, ça. Il va falloir creuser D'autant que cette solution permettrait en fait d'éliminer le <span> commun à ces méthodes de masquage de contenu. Par exemple, pour un titre dont le contenu texte est remplacé par un logo, on utiliserait quelque-chose comme : h1 { background-image:url(titre.jpg); background-repeat:no-repeat; background-position: top left; padding-left: 200px; position: absolute; clip: rect(auto 200px auto auto); } <h1>Texte du titre</h1> (Pour une image de 200 px de large) Avec évidemment la contrainte de cette position absolue...

Tiens, au passage, il faudrait vérifier ce que donne dans les navigateurs et les lecteurs d'écran : ul li a span { span { position: absolute; clip: rect(1px 1px 1xp 1xp); clip: rect(1px, 1px, 1px, 1px); } <li><a href="lien1"><span>Titre du lien1</span></a></li> Cette syntaxe de clip ramènant à zéro la zone de visibilité du span... ce pourrait être une alternative au FIR et à la méthode de Bohman.

Bon, nous avons finalement réglé ces questions ailleurs Mais : Concrètement, un auteur développe sa CSS dans l'éditeur de son choix... mais en observant le rendu dans au moins un navigateur. Dans ton cas, Mozilla. Sachant qu'il existe des différences d'implémentation CSS entre tous les navigateurs, parfois minimes, parfois importantes, ne pas regarder ensuite quel est le résultat dans les autres navigateurs (les plus courants) est soit suicidaire, soit une manière déguisée de développer pour un navigateur unique. En revanche, développer dans l'un des navigateur au support CSS le plus conforme à la spécification CSS2 (Mozilla, FireFox, Opera, Safari), puis effectuer les corrections parfois indispensables (pour IE donc le plus souvent)... semble être la démarche la plus efficace. Dans le cas de ta CSS, très peu de corrections étaient nécessaires, et elles concernaient en grande partie des syntaxes non supportées par IE... mais que rien ne justifiait là où une autre syntaxe bénéficiait d'une support plus large. Pour preuve, la CSS en question corrigée passe très bien actuellement dans IE

Oui, tout à fait. Mais il faut s'entendre sur le sens de "standard" : - il n'existe pas de structure-type standardisée à l'échelle d'un document entier ou d'un type de contenu. Une galerie d'image peut librement être structurée avec des listes de définitions, un tableau, une liste non ordonnée, des paragraphes, etc. Sans qu'aucune de ces structures ne soit dans l'absolue préférable, ni ne puisse être fixée par une norme. - en revanche, il existe un standard définissant précisément la grammaire HTML, c'est à dire l'utilisation normalisée des éléments HTML. Par exemple, ton : <h2>Titre></h2>Texte ... n'est pas conforme au standard HTML défini par la spécification HTML4.01 : celle-ci interdit à un élément <p> de contenir un élément titre <h2> Par contre : <h2>Titre></h2> Texte ... est tout à fait "standard", c'est à dire correcte selon cette spécification. Autrement dit, avec les normes (X)HTML publiée par le W3C, tu as les règles standardisées de l'utilisation des élément HTML... Mais c'est à toi de les appliquer de la manière la plus pertinente possible pour structurer tes documents