LaurentDenis

Impact certain, en effet, et réaction immédiate : "clic" dans mon Opera, et si d'aventure le plugin flash était resté activé par accident, je le désactive illico. La pub en flash est sans doute une source de bénéfices conséquents côté agences . Elle est surtout lassante côté utilisateurs Combien d'argent dépensé en vain par les commanditaires de sites ? [edit: typos]

Non, il n'y a aucun rapport. C'est juste un point de vue technique. Conseiller de développer d'abord pour les navigateurs qui ont le meilleur support CSS est simplement le fruit de l'expérience : c'est la méthode la plus rapide et la plus efficace. Développer pour un navigateur dont le support CSS est médiocre, quelque-soit ce navigateur, et devoir ensuite adapter une feuille de style mal conçue au départ... ne fait qu'entraîner d'inutiles pertes de temps. [edit: typos]

J'en remets une couche, en fait (plus abrupte que la précédente, mais le chantage m'agace) : Repasser au bon vieux HTML, non, ce n'est pas ça que tu es tenté de faire : ce qui te démange, c'est de rester dans des habitudes de codage qui ont certes fait leur preuves empiriques à l'époque où les standards étaient une illusion pour doux-dingues, mais qui ne sont plus justifiables ajourd'hui et qui, surtout, n'ont aucun avenir. Ces habitudes ont pourtant indiscutablement un atout majeur et indiscutable : tu les connais du bout des doigts, à tel point que tu ne vois plus le coût de développement du bon vieux "cross-brower" à l'ancienne. Bien-sûr, le développement "standard" aura aussi son coût. Un double coût, pour toi : - celui, inévitable, lié aux implémentations plus ou moins suffisantes dans les divers navigateurs au regard de ton projet. Nous y avons tous droit. Mais quoi de neuf de ce point de vue par rapport au cross-browser à l'ancienne ? Si, une nouvelle chose, à l'usage : on y passe beaucoup moins de temps. - celui, plus personnel, d'une remise en cause de l'acquis : oublier IE, oublier la page identique dans tous les navigateurs, faire en fonction de "ce que cela devrait être" et puis ensuite adapter à ce que c'est, plutôt que faire en fonction de ce que c'est un peu partout et perdre du temps à en tenir compte. Ah ! C'est qu'il me mettrait de mauvais poil, l'animal. En pénitence, je chercherai le hack qu'il lui faut pour sa page si personne ne se dévoue...

Article très attendu.

Désolé d'être un peu abrupt (Pas du tout désolé, en fait) : Prendre IE comme navigateur de référence lors du développement CSS est sans doute la pire erreur possible (pas tout à fait, au-delà, il y a NS4.7...). IE6 est actuellement le navigateur "récent" qui a le plus médiocre support CSS2 en termes de positionnement, de dimensionnement (box model, le problème de Pixame), de contenu géréné... Le principe de base d'un développement rapide en CSS est : - de prendre comme navigateur de référence un de ceux ayant le support CSS2 le plus étendu : Mozilla (FireFox), Opera, Safari. - une fois la CSS callée selon le standard, voir le résultat dans les navigateurs "buggués" (internet Explorer) et chercher les hacks nécessaires ou laisser la page se dégrader tranquillement. Le corollaire de CSS est en effet une petite révolution culturelle : admettre qu'une page ne soit pas rendue de la même manière partout. En partant par exemple de deux constats simples : - un navigateut texte ou Web-TV n'en fera pas la même chose qu'un navigateur graphique. - le navigateur graphique spécifique pour lequel le développeur se sera efforcé de développer le site ne donnera pas le même rendu chez moi, dès lors que j'ai des préférences et des styles d'utilisateur. (Pixame: ce dernier point ne concerne pas l'erreur dans ta page ; le premier point est en revanche le fond de ton problème).

Je cherche toute url pertinente et de préférence documentée directement par Google sur le sujet "Google Definition". Plus spécialement, je cherche à déterminer la liste des balises supposées servir de base à ce service : - <dfn> ? - <dl><dt>... ? - <strong> ? - <b> ? Allez, je vais bien intéresser quelques-uns des spécialistes du référencement de ce forum

Effectivement, le contaste liens/couleur de fond est trop faible, particulièrement pour le menu d'accessibilité.

Ah ! Monique : la magie des styles utilisateurs dans Opera ! Une p'tite feuille de style maison appliquée à la volée à la page en cours peut révéler bien des choses Par exemple (empruntés à Eric Meyer): Pour révéler les images sans alt: img {border: 3px solid red !important; padding: 2px !important; background: lime !important;} img[alt] {border-width: 0 !important; padding: 0 !important;} Pour révéler les styles internes: *[style] { border: 2px dashed red !important; } les balises FONT: FONT, FONT * {font-weight: bold !important; color: yellow !important; background: red !important; border: 3px solid lime !important; padding: 0.25em !important;} les tableaux: table {border: 1px solid red !important; margin: 3px !important;} th {border: 1px dotted red !important;} td {border: 1px dotted purple !important; padding: 2px !important;} Et aussi: Linéariser tous les tableaux: @charset "UTF-8"; /* Name: Disable tables Version: 1.01 Author: Opera Software ASA Description: This style sheet disables tables. Copyright © 2003 Opera Software ASA. */ table, caption, tr, thead, tfoot, tbody, th, td { display: block !important; float: none !important; max-width: none !important; min-width: 0px !important; width: auto !important; max-height: none !important; min-height: 0px !important; height: auto !important; /* text-align: left !important;*/ } thead, th {font-weight: bolder !important;} Pour montrer le contenu de head, voir http://www.blog-and-blues.com/2004/fevrier...ecor_en_CSS.asp Et on peut en imaginer bien d'autres...

Le style switcher peut être traité côté serveur, sans javascript. Mais il est vrai que c'est typiquement une fonctionnalité présentative, non indipensable à une expérience correcte du site... Le javascript est un moindre mal dans ce cas. Sinon, pour l'accessibilité: - un moteur de recherche interne serait bienvenu (Google, au pire) - les listes de l'annuaire sont trop longue pour être facilement "audibles". Il faudrait fragmenter. - ajouter un title sur les liens de validité et de gnu pour la navigation en mode "lister les liens de la page" :

Je n'ai fait qu'un bref passage en page d'accueil sans regarder le code. Deux-trois remarques vite fait : - style switcher nécessitant javascript, agaçant ; - une fois passé en version anglaise, impossible de revenir à la version française, et message d'erreur en passant à la version allemande (probablement une erreur d'url); - les abréviations ont des title suprenants dans la version anglaise ("$$~"); - date sans mention de l'année dans "Quoi de neuf" (C'est fou combien il traîne sur le Web de rubriques "Quoi de neuf" datant des années 90... Autant s'en différencier ) - <rss version="0.91">... pourquoi pas 1.0, 2.0 ou Atom ? - style interne sur une image : pourquoi pas dans la CSS externe ? - des <br /> dans l'édito : pourquoi pas des paragraphes distincts ? - il manque un ou deux </li>; - utiliser &amp; et non & dans les url. Bon, finalement, j'ai regardé un peu le code, vite fait Heu... Quand même, Y'a du bon aussi [edit, j'oubliais : Opera 7.50 Win]

AAA, AA et A sont les trois niveaux de validation accordés par le validateur Bobby, concernant le respect des Directives pour l'accessibilité aux contenus Web (version 1.0) du W3C, autrement dit l'accessibilité formelle du site aux utilisateurs handicapés. La validation (X)HTML vérifie que le code des pages respecte formellement l'une des spécifications HTML / XHTML du W3C. Ce n'est donc pas la même chose. A noter cependant : la validation complète de l'accessibilité nécessite que les pages soient par ailleurs valides du point de vue (X)HTML.

Je me souviens que nous nous étions posés la question au moment de fixer les règles éditiorales d'OpenWeb. Nous avions estimés qu'un article ne devait pas aller en-dessous du niveau h4. Au-delà, ce serait le signe d'une certaine confusion... Bien-sûr, c'est lié à un certain contexte éditorial (sans compter une part d'arbitraire). Un document beaucoup plus long à la thématique très vaste n'a pas à obéir aux mêmes règles. Inversement, un post de weblog a peu de raison d'aller au delà de "titre de post" / "sous-titre". A noter aussi : les listes de définitions se révèlent souvent un auxiliaire très utile dans le détail de la structure.

Pas si simple, si on veut bien oublier ces fichus navigateurs graphiques et leur media "screen" : - on saute systématiquement les écrans... en media "projection" (donc toujours uniquement via CSS). Voir par exemple http://www.opera.com/support/tutorials/operashow/ et les exemples d'utilisation de Yan Hixon, http://ln.hixie.ch/?start=1076441294&order=-1&count=5 - De même, les tablettes braille "n'affichent" qu'un nombre limité de caractères à la fois, et un navigateur texte (Lynx) affiche une longue page fenêtre après fenêtre. Mais là, c'est sans aucune possibilité de contrôle sur le découpage de la part du concepteur...

Que veux-tu dire par "saut de page" ? S'il s'agit d'affichage à l'écran, "screen" n'est pas un média paginé... Pas de "saut de page" possible En revanche, lors de l'impression d'une page HTML dont la présentation est contrôlée par une feuille de style, "print" est paginé et des sauts de pages peuvent être suggérés en CSS (suggérés, mais pas nécessairement imposés à l'utilisateur).

Je ne suis peut-être pas très bien réveillé ce matin, mais il n'y aurait pas une petite confusion entre - IE5 Windows, qui ne supporte pas le doctype switching, - et IE5 Mac, qui a été le premier navigateur à implémenter le doctype switching ? Ou alors, tu utilises http://dean.edwards.name/IE7/ pour les IE5 windows, qui rétablit le modèle de boîte standard, mais au prix d'un hack beaucoup plus lourd que le box model hack. Sinon, sur le fond du box model : ma préférence va à la solution la plus valide, c'est à dire des dimensionnements suffisamment fluides pour se dégrader correctement dans le box model Microsoft, sans qu'aucun hack ne soit nécessaire... Contrôler un rendu au pixel près est certes très tentant, mais pas dans l'esprit des CSS, qui est d'indiquer et non de figer le rendu utilisateur.

Hum... ce petit décalage, c'est bien que ta <div id="titre_site"> déborde de quelques pixels vers le bas et recouvre la bordure de <div id="header"> ? Il est dû au modèle de boîte (mode de calcul des hauteurs et des largeurs des blocs). IE5 et IE5.5 utilisent un modèle microsoft pour lequel il faut prévoir des dimensions spécifiques en utilisant par exemple le box model hack: #titre_site { ... position: absolute; top: 119px; voice-family: "\"}\""; voice-family:inherit; top: 120px; } html>body #titre_site { top: 120px; } En supposant ici que le décalage est de 1px : on envoie à IE un top: 119px; et on rétablit pour les "bons" navigateurs un top: 120px; Voir http://openweb.eu.org/articles/dimensions_boites_css/ Au passage, es-tu sûr que le float:left sert à quelque-chose pour #titre_site ? D'autre part, plutôt qu'un <div id="header"> <div id="titre_site">Aspirlux Beauport enr.</div> </div> Pourquoi ne pas utiliser l'élément <h1> qui est fait pour ça ? <div id="header"> <h1>Aspirlux Beauport enr.</h1> </div> Et pour indiquer ce que signifie ce mystérieux enr. (je suppose que ça ne doit pas être enragé : <h1>Aspirlux Beauport <acronym title="enragé">enr</acronym>.</h1>

Pas si simple. On a parfois des retours d'expérience inattendus : j'ai constaté avec des enfants amblyopes (déficience visuelle provoquant par exemple une perception en "tunnel")que des liens portés par une image animés sont plus facilement perçus, car ils se détachent immédiatement du contenu "statique" de la page De même, avec des enfants très jeunes (classe maternelle). En revanche, lorsqu'une partie seulement des liens sont animés, les liens textuels deviennent du coup moins perceptibles ou moins attirants... Mais si tous les liens sont animés et qu'il y en a beaucoup, ça gigote dans tous les sens et ça devient confus... Pas si simple, je vous dis

Qu'en est-il de <div lang="..."> ? Passe-t-il aussi bien que <span lang="..."> ?

Hum... faute d'un encodage correct dans ces sites, et selon ma configuration locale, je vois sur mon écran en guise de petites notes : - des points d'interrogation, - ou des carrés vides... Il faut que je triture un peu mon navigateur pour avoir les petites notes... Bof, donc.

J'ai un doute à la vue de ton code : tu utilises cette image map... pour faire des liens réels vers d'autre pages, ou juste pour afficher une carte et des informations au survol de la souris ?

A priori :tes deux <div> suivant le titre <h2>News</h2> étant en float, il manque en fin de <div class="centre"> un séparateur doté de la propriété "clear: both" (par exemple, un <hr />) Ne pas se fier à "height" d'une manière générale. Le flux l'emporte dans bien des cas sur l'implémentation médiocre de cette prioriété...

Le problème des accesskeys est en effet principalement un problème d'implémentation. Le standard en lui-même est, en tant que principe, un excellent outil... dont l'utilisation est considérablement limitée à cause du comportement des navigateurs graphiques, oraux, etc. Ils devraient en effet être au moins capables de signaler les accesskeys présents dans le code... Cela dit, la norme pourrait évoluer sur un point : l'attribution des touches pourrait être du ressort du media utilisateur, et non du côté serveur. Autrement dit, un attribut accesskey="accesskey" permettrait de signaler au navigateur qu'il doit attribuer une touche d'accès clavier au lien ou à l'élément de formulaire, en fonction du stock disponible localement et des préférences de son utilisateur... Par ailleurs, d'une manière générale, je suis frappé du peu d'intérêt apparent des éditeurs d'outils comme Jaws ou HPR envers les normes et le balisage d'accessibilité : - aucune documentation sur le support HTML pour les concepteurs (pour savoir quels éléments et attributs sont exploités par Jaws et HPR... il faut tester soi-même) - des outils HTML de base sont peu ou pas exploités, ou commencent seulement à l'être : l'attribut longdesc dans les premiers Jaws, acronym et abbr encore aujourd'hui, tabindex... On a le sentiment d'outils à la philosophie très "propriétaires", exploitant pleinement leur situation de "niche".

Attention : des feuilles alternatives ne seront reconnues comme telles par Mozilla et Opera que si elles sont attachées au document avec un <link rel="alternate stylesheet"...> (ignoré par les navigateurs 4.x et toutes les versions d'IE) Pour les media, la css media="print" est le plus souvent en <link rel="stylesheet"> puisque Netscape 4 ne reconnaît que le media="screen"...

- Le problème de désactiver la CSS ne remet pas en cause la validité de l'@import : c'est simplement une insuffisance de l'extension FireFox en question. - Le type de media n'est pas perdu. Il peut (et doit) être précisé pour <style>. - Accessibilité : _AT_import permet au contraire d'améliorer l'accessibilité (ou plus précisément l'interopérabilité) en évitant un rendu graphique risquant d'être illisible dans les navigateurs de génération 4

J'ai un menu personnalisé dans Opera qui me permet de démarrer les autres navigateurs installés sur ma machine et de leur faire afficher la page que je suis en train de voir dans Opera. J'affiche donc d'abord ma page en cours de développement dans Opera. Une fois la CSS callée, j'utilise mon menu pour voir le résultat dans les autres navigateurs. Au fur et à mesure des modifications de la CSS, il me suffit d'actualiser les affichages... On peut faire exactement la même chose en se servant de Mozilla ou de FireFox (Mais là, je laisse le soin à un habitué des extensions de donner les liens et les explications ) Pour Opera, le plus facile est d'installer le W3-dev Menu de Toby A Inkster qui ajoute aux menus standards d'Opera un excellent menu de développement. Une fois le W3-dev Menu installé, il suffit d'éditer son fichier ini et d'y ajouter les commandes correspondants aux différents navigateurs dont on dispose. Chez moi, ça donne par exemple : [LaunchWin Menu] Item, "FireFox" = Execute program, "firefox", "%U" Item, "Mozilla" = Execute program, "mozilla", "%U" Item, "Internet Explorer 6" = Execute program, "iexplore", "%U" Item, "Internet Explorer 5.5" = Execute program, "C:\Program Files\oldie\ie55\iexplore.exe", "%U" Item, "Internet Explorer 5.0" = Execute program, "C:\Program Files\oldie\ie50\iexplore.exe", "%U" etc On peut d'ailleurs personnaliser ce menu de toutes sortes de manières pour y mettre des moteurs de recherche spécifiques, des liens vers les traductions des spécifications en français, vers des sites ressources francophones...