LaurentDenis
-
Compteur de contenus
1 281 -
Inscrit(e) le
-
Dernière visite
Tout ce qui a été posté par LaurentDenis
-
Automne semble un CMS intéressant, mais (sachant que je n'ai pas eu le temps de l'installer et de voir les options)... les sites que tu donnes en exemple n'ont pas de doctype. Un peu gênant côté compatibilité XHTML (mais sans doute réparable aisément)...
-
Juste pour dire que je dois interrompre momentanéement cette discussion passionnante... pour cause de week-end quand même un peu consacré à mes gosses, mais qu'on se retrouve la semaine prochaine Nous, cette 'aprem', on va au cirque, na
-
Euh... uniquement si le conteneur est lui-même positionné, non ? Dans le cas contréaire, l'élément en position absolue ne tient pas compte du tout de son "conteneur" et se positionne par rapport au dernier conteneur positionné (au pire : body ou html). Oui, je n'avais pas précisé (c'était déjà très long, comme explication) : - dans tous les cas, un élément en position absolue se place en référence à son conteneur, - le conteneur est par défaut le conteneur intial (donc <body> en HTML, <html> en XHTML) - mais si l'élément parent est lui-même en position: relative (avec/sans top, left...), ou en position:absolute, ou en position: fixed... il devient le conteneur. Il y a peut-être une formulation ambigüe là-dessus dans la spec, je n'ai pas le temps de vérifier immédiatement. Heu... Tout élément se positionne par rapport à son conteneur, qu'il soit en flux, doté d'une position:relative, absolute, fixe ou flottant Ce n'est pas un critère déterminant. Ce n'est pas un critère du tout, en fait La différence, c'est qu'un élément relatif, lui, est d'abord placé selon le flux dans son conteneur, puis déplacé indépendamment de celui-ci. Ce n'est pas le placement de l'élément lui-même qui compte, c'est son effet sur le placement des autres éléments. A la différence d'un élément positionné au sens propre du terme, un élément en position relative agit toujours sur les autres éléments selon les règles du flux normal : son décalage relatif n'est pas pris en compte à ce moment Le critère, c'est le degré d'interaction avec les éléments suivants/précédents. Et là, la position relative ne crée par de différence par rapport au flux (voir l'exemple sur la marge latérale dans mon message ci-dessus), à la différence des float (exception à la règle du flux pour les éléments blocs autorisant l'élément suivant à se placer à sa droite) et de la position absolue (aucune interaction). Exact, quoique qu'ils dépendent des éléments flottants. Non: - le placement d'un élément en position absolue (/fixed) ne dépend que des coordonnées issues de top, left... dans son conteneur. Il ignore totalement tous les autre éléments. C'est un foutu individualiste Il n'y a aucun "second flux" qui puisse le concerner... Complètement associal, le gars, je te dis ! - un élément flottant... dépend du flux et des autres éléments flottants. Lui, c'est le compliqué qui: - laisse aux autres le droit de le "peloter" abusivement : répandez-vous donc voluptueusement à ma droite, jeune homme... - mais qui pique une crise s'il n'a pas la place de s'étaler à sa convenance : Il m'embête lui... je file à la ligne, moi. Peut-être, pour lui, pourrait-on parler (abusivement) d'un "flux spécifique aux floats successifs"... Mais là, on sort de ce qu'on décrivait ci-dessus pour entrer dans des comportements spécifiques.
-
Toutes mes excuses : trop pressé hier soir, je ne t'ai fais qu'une réponse minimale et abrupte. En fait, j'avais un mal de crâne de première, ayant fraîchement perdu mes lunettes toutes neuves Bref, je vois bien l'intérêt du clik sur la zone entière et pas seulement sur le texte du lien... Quoique ce soit inhabituel. Tu dois pouvoir retrouver ce comportement sans passer par le display:block, en jouant sur la largeur/hauteur du <a>, il me semble. Sinon, la page me semble à présent correcte sous IE6.
-
Une dernière petite remarque pour clôre ce dimanche matin stimulant : On aborde le plus souvent les mises en pages CSS d'un point de vue purement "géographique" (ça va se placer où ? ça va mesure combien en hauteur/largeur ?) Mais il est utile, pour bien comprendre ce qu'il se passe normalement, et aussi quand il y a un bug de navigateur, d'y penser chronologiquement : dans le processus de rendu CSS, ça se met d'abord là, puis ça se propulse ici... et ensuite, ça joue ou ça ne joue pas quand c'est le tour de l'élément suivant. Voilà pour mes deux sous de pragmatiste invétéré
-
Je me permets de répondre à Sibelius ici plutôt qu'en privé, pour éclaircir les choses sur mes articles d'OpenWeb souvent cités ici, et dire clairement qu'en ce qui me concerne, tout ceci ne constitue que des matériaux librement utilisables pour les améliorer. C'est une très bonne critique, au contraire. Ma série d'articles sur le positionnement/les dimensions dans OpenWeb a été écrite il y a largement plus d'un an, sur des premiers jets beaucoup plus anciens, et commence à être très datée (par exemple, sur les flottant et clear ou sur le modèle de boîte). Et j'avoue franchement que je ne voyais pas bien, à ce moment là, ce qui posait précisément des problèmes à beaucoup de gens dans le système CSS... parce qu'il y avait encore peu de gens qui s'en servaient Elle aurait besoin d'une refonte complète, en tout cas. Celle-ci est sur mon interminable "todo list" personnelle, mais si quelqu'un veut le faire plus rapidement pour le publier où il veut, ou bien y contribuer pour faire bouger l'auteur, ce serait merveilleux La dernière chose sur laquelle je revendiquerai des droits exclusifs, ce sont bien mes maladroites tentatives d'explication ! A chacun d'en faire ce qu'il souhaite, s'il peut en tirer quelque-chose, avec ou sans reformulation. Cela dit, je pense qu'un article intéressant pourrait effectivement sortir de ce sujet, en réorganisant plus rigoureusement ce qui s'y dit, et en l'illustrant. J'ai quelque-chose en train sur le sujet depuis quelques temps, mais comme j'avance à un rythme d'escargot... C'est celui qui veut qui s'y colle ou qui participe Enfin, vu son origine, le meilleur endroit pour publier cet article me semblerait-être... le Hub
-
[edit] C'est tellement long que je mets des "En bref" en gras pour les gens pressés [/edit] Hum... Je crois qu'une bonne partie de tes question sont liées à la distinction à faire entre : - les schémas de positionnement : "placer" un élément, ce qui est dans un certain nombre de cas indépendant de ses dimensions. - le calcul des hauteurs et des marges : une fois placé, un élément a une certaine hauteur qui interviendra dans le calcul des dimensions de son conteneur, et dans le placement d'autres éléments qui le suivent dans l'abre du document. Un rappel pour ce qui suit (ce n'un qu'un des cas de figures du calcul des dimensions, mais c'est le plus fréquent, et celui qui intervient dans les questions ci-dessous): http://www.w3.org/TR/REC-CSS2/visudet.html#q17 A partir de là : Non... et oui un peu : - Oui, un élément en position relative reste un élément en flux, et les comportements sont donc effectivement très proches. - Mais un élément en flux n'est pas placé, "puis" décalé selon sa marge : il est placé en fonction de ses marges, (avec fusion des marges verticales des boîtes blocs), et agit avec ses marges sur le placement de l'élément en flux qui le suit. - alors que le décalage d'un élément en position relative, après son placement, n'agit plus sur le placement de l'élément qui le suit. Prenons les deux exemples suivants : span { margin-left: -40px; } <p>Exemple de <span>position relative</span></p> et span { position: relative; left: -40px; } <p>Exemple de <span>position relative</span></p> Le résultat est trompeusement identique, en effet : dans les deux cas, les mots "position relative" sont décalés vers la gauche et recouvrent les mots qui précèdent. Mais le mécanisme est en réalité bien différent. Il suffit d'ajouter du contenu pour s'en apercevoir : Exemple de <span>position relative</span> et encore du contenu Cette fois, on voit bien la différence : - Quand les éléments sont placés uniquement en flux, le "et encore du contenu" est placé immédiatement à côté du contenu du span, car il l'a suivi dans son margin-left: -40px : les élément sont placés en fonction de leurs marges respectives; - Quand le span est placé en position relative, le "et encore du contenu" est placé exactement comme si le span n'avait pas subit son décalage vers la gauche (il y a un espace de 40px entre les deux) : la position relative du span n'a aucune influence sur le placement des éléments qui le suivent. Dans le même ordre d'idée, une position relative du type top: -40px permet de décaler le span vers le haut indépendamment de son bloc conteneur, ce qu'une marge top négative ne permettrait pas de faire. En bref: Un élément en flux+position relative est: - placé normalement et c'est ce placement qui influera sur le placement à l'écran des éléments précédents/suivants. - puis décalé horizontalement/verticalement, et ce décalage n'a pas d'influence sur le placement à l'écran des éléments précédents/suivants. Heu... Ce serait plutôt le contraire : - Dans les deux cas, les éléments en flux normal/en flux+relative se placent en fonction de l'élément en flux/flottant précédent... - Mais le "décalage" de l'élément en position relative, qui intervient après le placement en flux, et qui donne le placement final, est totalement indifférent à l'élément qui le précède (il peut le recouvrir, voir les exemples précédents) Hum... le raccourci est un peu rapide : ne mélangeons pas "placer un élément dans un conteneur" et "calculer les dimensions du conteneur" (voir la citation de CSS2 en début de post) Pour les éléments en position absolue, l'élément tient compte de son conteneur pour se placer : c'est celui-ci qui sert de référence aux valeurs des propriétés top, left, etc. En revanche, comme l'élément en position absolue est retiré du flux, il n'intervient plus dans le calcul de la hauteur/largeur de son conteneur... ce qui peut effectivement le faire "dépasser" en bas et/ou à droite de celui-ci, voir le faire sortir complètement. Il en est de même d'un élément flottant : - il se place le plus à gauche/droite possible dans son conteneur, donc en référence à celui-ci. - mais comme il autorise les éléments qui le suivent à se placer à côté de lui au lieu de les "rejetter à la ligne", il est soustrait du calcul de la hauteur du conteneur, d'où les dépassements que l'on évite avec la propriété clear. En bref : un élément positionné se place toujours en fonction des limites de son conteneur, mais ensuite, il n'intervient pas toujours dans le calcul des dimensions de celui-ci. Oui. En bref : un conteneur en flux ne tient pas compte de ses enfants positionnés (float, position absolute, fixed et relative) pour établir ses dimensions... (Au passage, le body est obligatoirement en flux en HTML, mais pas en XHTML. Et ca devient beaucoup plus amusant si le conteneur est lui-même positionné, car CSS2 n'est pas assez précise sur le sujet et autorise plusieurs interprétations possibles... Mais bon, on en reparlera une autre fois ) Tout à fait : le flottant sort du calcul de la hauteur. Mais ton test doit prendre garde à différencier les éléments concernés : les boîtes blocs/en ligne/anonymes/remplacées/non remplacées ne se comporteront pas de la même façon du point de vue du calcul des dimensions. Ceci risque de te compliquer l'interprétation de tes résultats. Le mieux et le plus simple pour explorer ces mécanismes est de tester sur des boîtes blocs non anonymes et non remplacées (des paragraphes et des spans). En bref : il est préférable de tester les positionnements et les dimensionnements CSS sur des paragraphes et des span que sans contenu (avec juste des couleurs, des hauteurs et des largeurs) ou juste du contenu anonyme (le texte mis dans une div) : c'est en effet concrètement le mode de rendu le plus courant dans les documents réels, et les autres types de contenu ont des comportements très spécifiques.
-
Supprime l'inutile display:block pour le h5 a
-
C'est un exposé clair et très systématique, en effet. Je ferais cependant deux petites réserves : - L'étape "Step 6. Colored boxes" consistant à donner temporairement une hauteur arbitraire à ses conteneurs principaux avant de les positionner donnera parfois des résultats totalement imprévus quand on passera à l'étape suivante et qu'on remplacera cette hauteur abritraire par un contenu réel. - Plus généralement, cette méthode fait abstraction du problème de mode de rendu CSS "Strict" / "Quirks"... qui peut lui aussi entraîner des suprises lorsqu'on se met à positionner (étape 5) ou à styler l'intérieur des conteneurs (étape 8). Il est prudent de déterminer dès le départ dans quel mode de rendu on va se trouver dans les principaux navigateurs, et en particulier dans IE6.
-
En bâclant ça schématiquement, et en regrettant de ne pas avoir le temps de mettre quelques petits dessins pour illustrer : A partir du code HTML, le moteur CSS du navigateur détermine un arbre du document, c'est à dire une structure hiérarchisée pyramidale où chaque élément, ou chaque portion de contenu, a un élément parent unique, et peut-être lui-même parent d'autres éléments. Au sommet, le "parent ultime" de l'ensemble est l'élément racine du document (concrètement <body> en HTML, <html> en XHTML). Chaque élément présent dans l'arbre du document génère une boîte CSS, qui peut être principalement: - une boîte bloc - ou une boîte en ligne. Cette boîte définit un conteneur pour ses éventuels éléments enfants. Les boîtes sont traitées grosso-modo selon l'ordre de leur apparition dans le code HTML. Chacune va se placer à l'écran en obéissant à un des 3 schémas de positionnement CSS : - le positionnement en flux, qui comprend principalement les éléments: *qui n'ont pas de propriété position, ce qui revient à dire position:static *qui ont une propriété position:relative - le positionnement flottant: les éléments qui ont une propriété float:left ou float:right. - le positionnement absolu: les éléments qui ont: * une propriété position: absolute * ou une propriété position fixed Dans le schéma de positionnement en flux, la place finale à l'écran d'une boîte est déterminée par sa nature de boîte bloc ou en ligne, et par l'interaction avec les boîtes avoisinantes : - les boîtes blocs se succèdent verticalement, séparées par leurs marges. Une boîte bloc "repousse la boîte suivante à la ligne" - les boîtes en ligne se succèdent horizontalement, et se fractionnent en boîtes en ligne empilées verticalement si elles ne disposent pas de la largeur suffisante. Une boîte en ligne "repousse la boîte en ligne suivante vers la droite" s'il y a assez de largeur disponible, vers le bas dans le cas contraire. Les éléments dotés d'une propriété position:relative sont des éléments en flux traités en deux temps : - la boîte est alors placée selon les règles du flux ci-dessus, - puis elle est décalée horizontalement et/ou verticalement à partir de cet emplacement. Dans le schéma de positionnement des flottants, la place finale à l'écran d'une boîte dépend beaucoup moins de la nature de la boîte (elle devient de toute façon une boîte bloc) : une boîte flottante est d'abord placée conformément au flux, puis elle est retirée de celui-ci pour être repoussée le plus loin possible vers la droite ou vers la gauche dans les limites du conteneur. Une boîte flottante ne "rejette plus à la ligne" les boîtes bloc qui viennent après elles dans l'arbre du document : celles-ci peuvent s'écouler à côté d'elle. Dans le schéma de positionnement absolu, la place finale d'une boîte ne dépend plus de sa nature originelle de boîte bloc ou en ligne, et n'interagit plus avec les autres boîtes du flux : la boîte dotée d'une propriété position:absolute ou position:fixed n'est pas d'abord placée dans le flux. Elle est immédiatement placée "arbitrairement" à une position donnée dans son conteneur, quitte à recouvrir d'autres boîtes ou à être recouverte par d'autres boîte. En conclusion : C'est le degré de liberté donnée à une boîte par rapport à sa nature bloc/en ligne et par rapport à l'action des autres boîtes qui différencie les 3 schémas de positionnement: - Dans le flux, une boîte se place selon sa nature de boîte bloc / en ligne, et en interaction complète avec les autres boîtes du flux; - Dans les flottants, une boîte se place d'abord selon le flux, mais l'interaction avec les autres boîtes est allégée, puisqu'elle autorise celles-ci à se placer à côté d'elle. - Dans le positionnement absolu, une boîte se place sans aucune interaction avec les autres boîtes. Elle est totalement libérée du flux. Il faut faire attention au mot position qui induit en erreur si on le prend au sens intuitif (un élément en position:relative n'est pas un élément positionnné). Il ne faudrait employer ce mot qu'avec le sens de "valeur de la propriété qui s'appelle "position".
-
Non. Cette valeur d'attribut "newonglet" n'aurait aucun sens en dehors d'une poignée de navigateurs graphiques, c'est à dire dans la quasi-totalité des medias d'accès au Web, ce qui serait contraire au principe d'interopérabilité. Contrairement à un éventuel "newonglet", "_blanck" ne préjuge pas du fonctionnement propre du media... D'autre part, dire que "l'attribut target disparaît" est très approximatif... et finalement faux. En effet, pour être exact: - cet attribut est effectivement invalide en XHTML1.0 Strict - Au-delà d'XHTML1.0 cependant, le Module Target de Modularization of XHTML existe bien. Il n'a simplement pas été retenu dans la liste des modules définissant XHTML1.1, mais rien n'empêche de l'utiliser dans une autre combinaison de modules XHTML - Pour l'avenir, le projet actuel d'XHTML2.0 et le projet de spécification XFrames conservent un attribut target susceptible, en l'absence de cible identifiée, de permettre à un navigateur visuel d'ouvrir la ressource visée dans une nouvelle fenêtre.
-
Lien ne fonctionnant pas dans un cadre en flaot
LaurentDenis a répondu à benjiiim - Forum : (X)HTML et CSS
C'est le cas, en effet. Mais le recouvrement par les titres est un bug, non un comportement normal. z-index ne marchera pas sur le <ul> flottant. Il faut: - inclure le <ul class="intro"> dans une div auquel s'applique le z-index; - ajouter une marge droite pour les titres réservant l'espace du float; Ce qui donne: <div id="hack" style="z-index: 99;"> <ul class="intro"> <li><a href="http://www.house-boat.net/fr/pedro.asp">Pedro 36</a></li> <li>America 38</li> <li><a href="http://www.house-boat.net/fr/a43.asp">America 43</a></li> <li><a href="http://www.house-boat.net/fr/a50.asp">America 50</a></li> </ul> </div> <h2 style="margin-right: 250px;">America 38</h2> <h3 style="margin-right: 250px;">4 personnes</h3> -
L'éternel fantasme du document inviolable sur le Web... Impossible à réaliser Dès lors qu'un texte est accessible à un navigateur Web (et il faut bien qu'il le soit pour être affiché)... il est copiable, enregistrable, etc. Il sera de toute façon copié (dans des caches de navigateur, de moteur de recherche, etc). Les quelques "astuces" que tu trouveras pour empêcher le clic droit (accèsau menu >Enregistrer sous, >Imprimer la page) ou la sélection de texte... gêneront inutilement les utilisateurs honnêtes, et n'empêcheront pas les plagieurs de copier tes textes.
-
Pour ces deux exemples... les colonnes ne sont pas de même hauteur Il suffit de leur appliquer une bordure pour s'en rendre compte, par exemple #column_one,#column_two {border: 1px solid red;} pour http://hivelogic.com/ Elles donnent en revanche l'illusion de l'être, grâce au jeu des couleurs d'arrière-plan, et à quelques div imbriquées. C'est une ruse classique lorsque le design n'intègre pas de bordures.. ça fait... longtemps que je travaille avec les CSS sans tableaux, et j'ai commencé à en avoir une utilisation "mature" justement quand j'ai appris où ne pas m'en servir. Accessoirement, j'ai bien précisé que les colonnes de hauteurs identiques pouvaient être réalisées sans tableaux imbriqués, avec un simple tableau unique à deux cellules... Les tableaux utilisés pour la présentation : - ne sont pas une solution à utiliser si on peut faire autrement, - ne sont pas une solution à utiliser si l'accessibilité de la page est compromise, - ne sont pas une solution à utiliser si on peut se passer de la présentation qui les nécessite, - mais ne sont pas une solution invalide, - et sont à utiliser avec parcimonie, sans fausse pudeur cependant.
-
Je serais curieux de voir un site réalisant ceci de manière fiable sans multiplier les hacks Que vaut-il mieux : - un rendu hasardeux avec une CSS bidouillée, pour un effet visuel somme toute mineur ? - un tableau d'une ligne, deux cellules... parfaitement accessible (linéarisation correcte), géré aisément et proprement en CSS, avec un minimum de code supplémentaire en HTML ? - ou renoncer sagement à cet effet (ce que je fais personnellement en attendant des navigateurs supportant correctement les propriétés de hauteur) ?
-
Les solutions de cryptages ont toutes un inconvénient commun : celles qui sont efficaces rendent l'adresse inaccessible à certains utilisateurs... qui sont autant de clients potentiellement manqués pour un site de ce type.
-
Utilise un tableau. La gestion de hauteur (height et min-height) en CSS n'est pas suffisamment bien supportée selon les navigateurs pour que les hacks nécessaires soient rentables.
-
pb avec le OE de Oeuf dans balise alt et title
LaurentDenis a répondu à Anonymus - Forum : (X)HTML et CSS
Selon une vieille légende, quand l’ISO (Organisation internationale des standards) a défini l'iso-8859-1 en 1987, le représentant français de l’AFNOR (Association française de normalisation) a "oublié" les ligatures o-e majuscule et minuscule parce que ces caractères ne figuraient pas... sur le clavier de sa machine à écrire favorite Il est vrai que ces caractères ne figurent pas dans l'encodage habituel des document en français (iso-latin) et ne sont normalisé qu'à partir d'UTF-8 -
Au cas où tu ne connaîtrais pas : XULfr est un wiki en français, très actif.
-
comment insérer une page web dans une autre page ?
LaurentDenis a répondu à euphoria - Forum : (X)HTML et CSS
S'il s'agit de récupérer le contenu d'une page d'un site dont tu n'es pas l'auteur... Il est évident que ce type de technique ne sera pas donnée ici. -
Heu... <pre> est un élément bloc. C'est son contenu qui ne peut être que inline. (L'équivalent inline de <pre> est <code>)
-
Les bugs d'IE5 Mac sur l'overflow sont expliqués ici : http://www.l-c-n.com/IE5tests/overflow/ Mais il semble que celui-ci n'ait pas de solution... Sauf peut-être (non-testé): http://www.sam-i-am.com/work/sandbox/css/o...w-auto-fix.html
-
Article : accessibilité et référencement
LaurentDenis a répondu à Sebastien - Forum : Accessibilité et Ergonomie Web
Lorsque je lis: ... J'ai beau tortiller dans tous les sens, je comprends que l'accessibilité vise aussi les moteurs de recherche A l'origine, cette comparaison avait pour but de donner une image de ce qu'était un utilisateur aveugle. Pas d'assimiler spider et handicapé. Il y a des "points de contact", bien-sûr. Les Standards tentent d'être un ensemble d'outils cohérents qui visent des problématiques "orthogonales" (interopérabilité, ergonomie, accesibilité, sémantique...), difficiles à séparer sans simplifications abusives. ... Métadonnées non exploitées actuellement par les aides à l'accessibilité. le contenu alternatif est justement le contenu de <object> : <object type="application/x-shockwave-flash" data="images/banner.swf" width="288" height="128"> <param name="movie" value="images/banner.swf" /> <img src="banner.gif" width="288" height="128" alt="banner" /> </object> Ici, l'image sera affichée en l'absence de support Flash (ou de support d'<object>) -
Modération : Le Hub ne publie aucune adresse de site au contenu illégal, et Noddy a très bien respecté cette règle Merci de ne pas l'enfreindre de manière détournée... Le post de Sebastien a été modifié en conséquence.
-
Modération : Avant de poser une telle question, qui appellerait en réponse un exposé complet des techniques du référencement, merci de lire ...les publications du Hub sur le sujet (Le 1er message du fil a été modifié pour supprimer le sous-entendu diffamatoire qu'il contenait).