LaurentDenis
-
Compteur de contenus
1 281 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par LaurentDenis
-
J'étais sûr qu'on ariverais là : le problème, en fait, ce n'est pas la gestion des flottants ni des largeurs, mais cette fichue idée d'avoir des arrière-plan et des bordures de colonnes de même hauteur, quelque-soit le contenu ! - pour les arrière-plans, ça se simule en jouant sur l'arrière-plan du bloc conteneur initial - pour les bordures, là, seul un tableau peut le faire de manière fiable. En effet, il n'existe en CSS2 aucun mécanisme permettant d'associer le rendu de la hauteur d'éléments visuellement juxtaposé, hormis: - display: table-cell (très mal supporté) - min-height / max-height (mauvaise idée et très mal supporté)
-
Trois remarques en vrac sur l'utilisation de <dl> pour structurer un contenu à la place d'un titre <hn> : Le "pseudo-titre" en <dt> sera actuellement ignoré par les mécanismes qui extraient les titres d'une page afin d'en donner un sommaire : - extentions pour les navigateurs graphiques destinés à faciliter la navigation - lecteurs d'écrans en mode "navigation dans les titre" - scripts générant des tables des matières - etc. D'autre part, ce qui semble tentant dans la substitution d'une <dl> à un <hn>, c'est son rôle apparent de "conteneur structurel" qui dirait "dans cette section (dl), j'ai un titre (dt) et du texte (dd)". Une sorte d'anticipation très partielle sur l'élément <section> d'XHTML2.0 et ses titres associés ? Enfin le fait que <div> soit "générique", ou plutôt neutre du point de vue sémantique ne doit pas faire oublier que cette neutralité est justement là pour lui permettre "d'ajouter de la structure" au document. L'amusant, c'est qu'Eric Daspet m'avait tenu à peu près le même discours quand j'avais usé et abusé des <dl> dans mon propre blog
-
Problème de listes décalées vers la droite
LaurentDenis a répondu à Kimberlyclarko - Forum : (X)HTML et CSS
Lire et relire Consistent List Indentation sur ce problème qui revient souvent : Pour créer l'espace nécessaire aux puces d'une liste <ul>, les navigateurs n'ont pas tous adoptés la même méthode : - les navigateurs basés sur Gecko (FireFox, Mozilla) appliquent par défaut un padding-left de 40px à <ul>, et placent la puce dans ce padding. - IE et Opera appliquent une margin-left de 40px à <ul>, et y placent la puce : Quand on modifie uniquement soit la marge, soit le padding d'un <ul>, on se retrouve donc avec un résultat différent selon les navigateurs. Il faut donc toujours spécifier à la fois les valeurs de margin et de padding pour les éléments <ul>, en mettant l'un à zéro. -
body { margin: 0; padding: 10px; } #gauche, #droite,#centre { margin-bottom: 10px; } #gauche { float: left; width: 120px; border: 1px solid; } #droite { float: right; width: 120px; border: 1px solid; } #centre { margin: 0 130px; border: 1px solid; } #pied { clear: both; border: 1px solid; } <body> <div id="gauche"> gauche </div> <div id="droite"> droite </div> <div id="centre"> centre </div> <div id="pied"> pied </div> </body> Tout est affaire de compromis
-
Tiens, il arrive qu'on soit ennuyé par les 3 colonnes en flottants parce que le contenu placé en colonne central est précédé par celui du menu de gauche (dans le HTML brut) Un petit essai amusant pour commencer son HTML avec le contenu central, en intervertissant à l'écran les deux premiers flottants grâce à la position relative : body { margin: 0; padding: 0; } #gauche,#droite,#centre { margin: 1em 0; } #gauche { float: left; width: 25%; background-color: yellow; position: relative; right: 45%; } #droite { width: 25%; background-color: yellow; float: right; } #centre { float: left; width: 45%; background-color: red; position: relative; left: 27.5%; } #pied { clear: both; background-color: yellow; } <body> <div id="centre">centre</div> <div id="gauche">gauche</div> <div id="droite">droite</div> <div id="pied">pied</div> </body>
-
Malgré leur nom, les listes de définition ne sont pas limitées par la spécification à définir Elles conviennent en fait à plusieurs cas où on associe explicitement dans une liste un terme (ou une expression) et un contenu. La spécification cite par exemple les dialogues (personnage / réplique) Un article intéressant sur le sujet : Les listes de définitions : mal utilisées ou mal comprises ? Cela dit, c'est aussi une mode à l'heure actuelle, avec parfois un peu d'abus.
-
? Des width en % règlent le problème. <edit>Voir les pages d'exemple de http://openweb.eu.org/articles/initiation_float/ </edit>
-
Que veux-tu dire par "variable en fonction de la page" ? - ton contenu et ton pied étant en flux, le pied est forcément en dessous du contenu - tes colonnes latérales étant en float et ton pied en clear:both... idem. Ou penses-tu à un problème de largeur ?
-
ça, c'est le problème des colonnes obtenues en position absolue : les colonnes latérales sont ici totalement extraites du "flux" vertical de la page, et n'ont plus aucun effet sur les autres éléments. Pour déterminer la position verticale du pied de page, il ne reste donc que le seul élément en flux, c'est à dire la colonne centrale... Ce type de mise en page peut être aisément réalisé avec les flottants : - contenu en flux - colonnes latérales flottantes - pied de page en flux avec une propriété clear:both qui le rejette sous les flottants. PS: Raphael a un gros préjugé envers les flottants
-
Le blocage plus facile du javascript dans IE ne fait que rendre plus évident deux vieux problèmes : - une page Web, c'est en fait uniquement du HTML, et seul son contenu HTML sera disponible en toutes circonstances. - il est risqué de conditionner l'accès à un site à un profil arbitraire d'utilisateurs (mes lecteurs utilisent principalement tel navigateur qui offre telle fonctionnalité). En fait, on oublie peut-être souvent qu'un document Web n'est pas écrit pour les utilisateurs. Il est écrit pour les machines (navigateurs, robots, traducteurs, parseurs, synthétiseurs vocaux, scripts...). Et aucune "machine" n'a jamais eu d'obligation en matière de support du javascript
-
display n'est pas une propriété spécifique au media screen (ou à tout autre media "visuel"). C'est une propriété qui agit quelque-soit le media, et donc aussi bien dans un navigateur vocal (Opera) à travers une CSS "all". Cependant, elle ne doit pas agir sur un navigateur vocal dans une CSS "screen". Mais ceci se double d'un comportement erroné des lecteurs d'écrans (Jaws...) qui ne sont pas des navigateurs, mais des synthétiseurs vocaux dépendant du navigateur graphique pour accéder au contenu Web : ils interprètent partiellement les CSS <edit>ou reçoivent le résultat de celle-ci</edit> quelque-soit le media, et appliquent la propriété display:none dans un certain nombre de cas. Les combinaisons de ces cas selon les lecteurs sont telles qu'un display:none dans une CSS "screen" masque toujours du contenu à au moins un lecteur d'écran. Tant qu'on y est : visibility:hidden est au contraire une propriété uniquement visuelle, théoriquement sans effet dans un media vocal. De fait, elle est ignorée par Opera. Mais là encore, il y a un bug des lecteur d'écran qui leur fait appliquer ce visibility:hidden de la même manière que le display:none. En bref : - display:none ne doit jamais être utilisé pour masquer du contenu dans un lecteur d'écran, et c'est normal dans une CSS "all", mais dû à un bug dans une CSS "screen". - visibility:hidden ne doit pas être utilisé non plus, mais cette fois uniquement en raison d'un bug. Le Web "aural" en est encore à ses premiers balbutiements...
-
Heu... le clavier de Sibelius a fourché et trahit son maître, qui voulait dire que display:none est pris en compte par les lecteurs d'écran et autres médias vocaux. Les navigateurs textes n'étant pas graphiques, ignorent tout CSS
-
Laurent Jouanneau ( http://ljouanneau.com/blog/ ) avait publié une solution comparable, avec un javascript non obstructif si ma mémoire est bonne. Pour celle que tu signales, il faut voir en effet ce que ça donne en remplaçant display:none par une solution accessible du type clip. Cela dit, j'ai des problèmes de rémanence du tool-tip dans Opera (pas testé plus avant dans d'autre navigateurs). Enfin, et surtout, ça reste inaccessible pour qui ne navigue qu'au clavier dans un navigateur graphique, comme la plupart des :hover sur autre-chose que des liens... La meilleure page accessible est finalement plutôt "plate".
-
Sauf erreur de ma part, Visual Friendly vient de changer assez récemment son fusil d'épaule et de découvrir les vertus des Standards : il faut leur laisser un peu de temps
-
Là, effectivement, ton cas est révélateur d'un éditeur qui n'encode pas en utf-8 (voir l'article de Steve Frécinaux sur OpenWeb) Le problème actuel de support d'utf-8 tient en fait essentiellement, je crois, à son support par les éditeurs (et non les navigateurs)... et principalement ceux sous Windows, il faut en convenir.
-
Les possibilités sont nombreuses, mais l'essentiel est de placer l'info quelque-part "en dur" comme texte HTML, hors attribut, en effet. - notes (au fil du texte sans CSS, joliments positionnés dans une colonne adjacente au texte avec CSS) - parenthèses - page de glossaire et d'aide, avec lien direct - à la limite, pourquoi pas des popups sur un intranet, si le lien va sur l'entrée correspondante du glossaire en l'absence de javascript - etc. C'est assez frustrant de ne pas exploiter pleinement title sur les éléments pour lesquels il n'y a pas de comportement systématique du navigateur... Mais encore une fois, si l'information n'est qu'un "ajout" non essentiel à la compréhension du contenu, c'est différent.
-
Oui, utf-8 est plus "complet". Il y a aussi un autre avantage à l'utiliser, quand on passe par xml : c'est un encodage par défaut de celui-ci
-
Je serais curieux d'avoir des avis plus éclairés, mais il me semble que: - ISO est plus répandu surtout parcce qu'il était là avant utf-8, qu'utf8 est encore mal connu, et que le webmastering est parfois très conservateur - les éditeurs (wysiwyg) proposent encore très souvent ISO par défaut, et utf-8 en option. - utf-8 traîne encore la réputation de ne pas être bien supporté (ce qui est faux). Cela dit, pour qui n'écrit que dans une seule langue, iso est tout à fait approprié.
-
La discussion ( http://www.alsacreations.com/blog/index.ph...-et-sigles#c832 ) portait sur la manière d'ajouter une information sur le sens d'un mot, à l'aide d'un code du type : <span title="une petite explication">le mot</span> (Sachant que le mot en question n'est pas une abréviation et qu'abbr ne se justifiait pas plus qu'un autre balisage plus précis). Cet emploi de span est correct: - span est un élément neutre sémantiquement, destiné à permettre d'ajouter de la structure lorsqu'aucun élément HTML plus précis ne convient - title est un attribut destiné à ajouter un information, notament textuelle. Mais avec des réserves sur l'accessibilité : pour que l'information soit accessible, encore faut-il que l'attribut title soit restitué. Or : - Les navigateurs graphiques le feront lorsque le mot sera survolé, ce qui suppose que l'utilisateur en ait l'idée, et la possibilité. On peut le lui suggérer avec la présentation CSS qui convient (curseur, soulignement), mais ce sera impossible pour celui qui ne peut pas utiliser la souris (handicap moteur). - Les navigateurs textes ne restituent pas le title - Les lecteurs d'écrans ne restituent pas le title d'un élément span, sauf erreur de ma part, et Opera 7.60 ne le lit pas. - Qu'en est-il sur un mobile ? Bref, title est un moyen apparemment très séduisant, mais à utiliser, AMHA, avec prudence sur les éléments autres qu'abbr et a : l'information donnée doit être un "plus", et son absence ne doit pas compromettre la compréhension du document.
-
J'oubliais un lien vers un excellent document du W3C sur ce genre de questions: http://www.yoyodesign.org/doc/w3c/web-quality/
-
J'avoue ne pas trop saisir le sens de ta question L'idée selon laquelle les Standards limiteraient la créativité... n'est pas neuve, et oublie toujours que le Web est (de plus en plus) un assemblage totalement hétéroclite de technologies, de medias, de systèmes d'exploitation, d'application de rendu et d'utilisateurs aux besoins variés. Disons rapidement que sans un minimum de cohérence et de normes, diffuser largement un site deviendrait un casse-tête au coût prohibitif. Bref, les normes sont indispensables à l'interopérabilité au sein du système. D'autre part, un standard n'est rien d'autre qu'une technologie. Ce qui limite éventuellement la créativité, ce sont les défauts éventuels de la technologie, ainsi que son niveau d'implémentation, mais pas son caractère normalisé. Enfin, les Standards Web étant conçus de manière cohérente, ils créent en se "rejoignant" d'autant plus de possibilités à explorer, et stimulent la créativité. Voir par exemple les possibilités offertes par la modularité XHTML (X-Voice est un bon exemple). Dernière chose : ton exemple des propriétés d'opacité permet de rappeler que les Standards ne sont pas des normes figées: -moz -opacity devient valide en CCS2.1 (extensions CSS préfixées) Evidemment, il faut aussi que la technologie propriétaire suive : l'équivalent microsoft filter:alpha(opacity) devra juste changer de syntaxe pour devenir valide
-
Les lecteurs d'écran "classiques" n'implémentent pas les CSS aural. A l'heure actuelle, les seuls navigateurs vovaux supportant CSS aural sont : - Emacspeak (linux) - Opera 7.60 (Windows XP) A noter qu'Opera implémente le module CSS3 Speech, et non CSS2, ainsi que XHTML+Voice Profile 1.2
-
FINI les AV et les Spywares. Tout ça sans MAJ !
LaurentDenis a répondu à darkbzh - Forum : Virus et Sécurité informatique
Hum... Un minimum de prudence s'impose : Source : http://www.lesnouvelles.net/?id=583 -
est ce qu'on utilise ces crochets [] dans les css
LaurentDenis a répondu à Mado - Forum : (X)HTML et CSS
Les crochets [] permettent de "cibler" un sélecteur sur un élément doté d'un attribut donné, ou même plus précisément selon la valeur de cet attribut. Un exemple classique d'utilisation : générer en CSS la mention de la langue du document cible d'un lien <a href="..." hreflang="en">...</a> <a href="...">...</a> Le premier lien pointe vers un document en anglais, ce que signale son attribut hreflang. Avec la règle CSS : ... on sélectionne tous les liens ayant un attribut hreflang pour afficher à la suite le contene de l'attribut, ce qui donnera (en) pour notre lien en anglais. (le \00A0 est un simple espace insécable). Avec la règle CSS : ... on ne sélectionne que les liens ayant un attributs hreflang avec la valeur "en", pour afficher à la suite la mention (en anglais) Dans les deux cas, le second lien ci-dessus, qui n'a pas d'attribut hreflang, ne sera pas concerné. Ce type de sélecteur rend également bien service pour différencier les éléments input selon leur type quand on style un formulaire... J'oubliais : ça ne marche pas dans IE Win, et peu de navigateur supportent des opérateurs plus complexes que le simple = -
Non, cela ne pose pas de problème au navigateur tant que, pour chaque page, l'encodage est correctement indiqué, et notamment que l'éventuel en-tête HTTP est identique à l'encodage réel du document.