28173 sujets

CSS et mise en forme, CSS3

Pages :
(reprise du message précédent)

Laurent Denis a écrit :


Que voilà un chiffre intéressant. Il répondrait enfin à une question qu'un tas de gens se sont posé.

Une source ? Hum ?


Je citais de mémoire une étude Xiti sur laquelle je ne parviens pas à remettre la main malgré de longues recherches.

Histoire d'avoir quelque chose à répondre, j'ai fureté un peu partout et la source la plus crédible que j'ai pu trouver est celle-ci :
http://www.w3schools.com/browsers/browsers_stats.asp
qui donne un chiffre nettement différent de celui de Xiti : 10%

Et bien soit, mea maxima culpa, si le problème concerne 10% des utilisateurs, on ne peut pas les laisser en plan !
Je viens de tester avec succès ce qui suit pour offrir une alternative aux internautes ayant désactivé le javascript :

<!--[if IE]>
	<NOSCRIPT>
		<STYLE>
			HTML {OVERFLOW: auto;}
		</STYLE>
	</NOSCRIPT>
<![ endif]-->

C'est quelques lignes sont à ajouter à la fin des styles définis par Alan. Elles font en sorte qu'un navigateur sans Javascript puisse scroller la page en mode traditionnel. Les blocs fixes ne sont plus fixes, mais au moins le site reste parfaitement naviguable.

Laurent Denis a écrit :


HTML 4.01 frameset et XHTML1.0 frameset sont des DTD tout à faire propres, convenables et fréquentables, quand elles répondent aux besoins exprimés.

Les standards commencent par là: assumer la DTD dont on a besoin Smiley cligne

<edit>
Ou renoncer au besoin malavisé, bien-sûr.

Dans ce cas précis, les hauteurs sont l'un des espaces incontrôlables dont l'utilisateur a besoin pour que ça marche chez lui. Le Web repose actuellement, en gros, sur le scroll vertical et la non-maîtrise des hauteurs côté auteur. En attendant les media queries et/ou le protocole CC/PP qui permettront de négocier les styles et le contenu en fonction de la résolution du client, cet espace est vraiment indispensable.

On peut bidouiller des solutions apparentes, bien-sûr. Ou on peut assumer et retourner aux formats plus anciens et problématiques par ailleurs qui le permettent incidemment. Mais, et c'est l'important, on ne le fera pas de manière satisfaisante en termes de qualité en forçant les formats stricts et transitionnels actuels à le faire. Ils ne sont pas faits pour ça.
</>


Je trouve ce discours trés théorique pour 2 raisons :
1- Compte tenu du parc absolument considérable de PC dans le monde, j'ai bien peur qu'il faille attendre plus d'une décénie avant que les standards actuels ne puisse être considérés comme "remplacés" par d'autres, quels qu'ils soient. Même dans 10 ans, il est probable qu'il restera quelques pourcents d'internautes naviguant avec IE 6. Et croire que les standards à venir ne présenteront aucun problème de compatibilité est à mon avis hypothétique. Je préfère être plus pragmatique et rechercher, pour chaque problème, une solution qui fonctionne aujourd'hui.
2- Je n'adhère pas à l'affirmation "les standards actuels ne sont pas fait pour ça". La norme CSS telle qu'elle se présente aujourd'hui est à mon sens parfaitement adaptée au besoin. Il se trouve simplement que IE ne l'implémente pas entièrement. Gérer ce navigateur par des commandes spécifiques me semble donc logique et cohérent à défaut d'être satisfaisant d'un point de vue intellectuel. En refusant d'exploiter les possibilités des standards actuels, on se prive par contre des bénéfices du progrès qu'ils apportent et on bloque leur évolution.

En résumé, et puisque tu proposes trés noblement d'assumer ses choix et ses besoins, je suggère d'assumer aussi le monde tel qu'il se présente aujourd'hui : imparfait. La recherche d'une solution "parfaite" dans un monde imparfait est illusoire. Contentons nous de solutions qui marchent dans la plupart des cas. Audiard disait : "2 cons qui marchent iront toujours plus loin qu'un intellectuel assis".
Modifié par zapman (13 Jul 2006 - 03:21)
mpop a écrit :
À vrai dire, Alan propose deux solutions alternatives.
L'une a nécessite qu'IE6 utilise le modèle de boîte traditionnel (et non pas le modèle de boîte CSS standard), ce qui est provoqué par la présence d'un prologue XML en début de code. En jouant bien sur les critères du commentaire conditionnel, on peut se débrouiller pour que ça passe bien dans IE 5, 6 et 7.
Principal problème : IE6 est en mode quirks, ce qui n'est pas une bonne nouvelle pour le reste de la mise en page du site…

La deuxième solution ne pose pas ce problème, mais repose sur du Javascript. Si javascript désactivé…


Si on m'imposait une telle mise en page je n'utiliserais pas le seconde possibilité qui nécessite encore une alternative en cas de javascript désactivé.
Le première en revanche ne me poserait pas de problème. J'ai l'habitude de tenir compte d'IE5 qui ne connait pas le mode standard. Cela revient donc juste à mettre IE 6 dans le même sac.

En bidouillant encore un peu, j'ai trouvé une autre possibilité qui ne nécessite plus de basculer IE 6 en quirks mode.
En ajoutant padding-top à HTML, si on spécifie un hauteur de 100% et overflow:auto à Body, celui-ci va prendre 100% de la zone de visualisation moins la hauteur du padding-top (où sera alors logé dans ce cas le header).
Voir l'exemple par ici.
Modifié par Alan (13 Jul 2006 - 10:20)
Alan a écrit :
En bidouillant encore un peu, j'ai trouvé une autre possibilité qui ne nécessite plus de basculer IE 6 en quirks mode.
En ajoutant padding-top à HTML, si on spécifie un hauteur de 100% et overflow:auto à Body, celui-ci va prendre 100% de la zone de visualisation moins la hauteur du padding-top (où sera alors logé dans ce cas le header).
Voir l'exemple par ici.

Bravo!! C'est donc la meilleurs technique, ou la première la vaut???
<edit:>
Avec quels navigateurs l'avez vous testé? Moi sur ie6 et ff 1.5.0.4, aucun problème
Modifié par sousoulebarbu (13 Jul 2006 - 11:14)
Alan a écrit :
Si on m'imposait une telle mise en page je n'utiliserais pas le seconde possibilité qui nécessite encore une alternative en cas de javascript désactivé.
Le première en revanche ne me poserait pas de problème. J'ai l'habitude de tenir compte d'IE5 qui ne connait pas le mode standard. Cela revient donc juste à mettre IE 6 dans le même sac.

En bidouillant encore un peu, j'ai trouvé une autre possibilité qui ne nécessite plus de basculer IE 6 en quirks mode.
En ajoutant padding-top à HTML, si on spécifie un hauteur de 100% et overflow:auto à Body, celui-ci va prendre 100% de la zone de visualisation moins la hauteur du padding-top (où sera alors logé dans ce cas le header).
Voir l'exemple par ici.

Désolé Alan, mais cette solution présente le même invénient que celle proposée par mpop en page 1 de ce topic :
a écrit :
si le bloc principal contient une ancre du type
<a name="mon_ancre">Texte de l'ancre</a>
lorsque l'on clic sur un lien désignant cette ancre
<a href="#mon_ancre">texte du lien</a>
le texte contenant l'ancre ne se positionne pas en tête de bloc, comme cela devrait être le cas, mais sous le header.
En clair, il est impossible d'utiliser les ancres avec cette solution.


Personnellement, je reste donc sur ta solution N°2 plus les quelques lignes que j'y ai ajouté pour les utilisateurs ayant désactivé le Javascript.
@Zapman : il n'y a pas ce problème avec les ancres destinations, ça ne se positionne pas sous le header. D'ailleurs comme tu peux voir, le haut de la barre de scroll est en dessous du header, un élément cible aurait du mal à se retrouver sous le header Smiley cligne (et j'avais quand même testé).

@sousoulebarbu: le code de base est simple et fonctionne sur les navigateurs modernes (firefox, opera, IE 7 bêta, Safari/Konqueror..). Pour IE 5 / 5.5 / 6 le même résultat est obtenu via bidouillage en commentaire conditionnel.
Concernant les versions anciennes : je viens de regarder avec IE 4, cela s'affiche normalement mais le header défile avec la page. Idem avec IEmac. Pas testé NS4...

Ca me semble quand même plus simple de ne pas chercher à imiter des frames sans frame ou des tableaux sans tableau... bref, ne pas rester dans le anciennes habitudes.
Modifié par Alan (14 Jul 2006 - 07:15)
Bonjour,

Puisqu'apparemment, vous êtes fermement décidés à poursuivre dans cette voie ( Smiley cligne ), attention aux problèmes qui deviennent beaucoup plus apparents dès qu'on quitte les exemples fictifs pour passer aux contenus réels.

Par exemple:
- s'assurer que le contenu du header ne sera pas rogné si la taille d'affichage des polices est plus grande que ce qui a été prévu (c'est un des rares cas où un dimensionnement en em peut être approprié).
- de même, s'assurer qu'il n'y a pas de superposition des textes du header et du contenu lorsque l'utilisateur désactive l'affichage des couleurs et agrandit le texte (dans les navigateurs / outils d'accessibilité ayant le bug de la transparence en cas de désactivation des couleurs : Firefox, IE5.x)
- attention aux navigateurs (FF notament) dans lesquels l'utilisation des flèches pour accéder au scroll peut être perturbée.
- conserver un espace suffisant pour le contenu, pour que l'utilisateur en résolution réduite ne soit pas obligé de le consulter tant bien que mal dans une boîte à la hauteur trop réduite.
- savoir que ce type de page pourra être très déroutante dans une loupe d'écran, où il peut être difficile de se rendre compte que le header est fixe.

De même que les flottants n'ont pas été conçus dans CSS2 pour faire des mises en page en colonnes, le positionnement n'a pas été conçu dans l'idée de partitionner la zone d'affichage. Les usages ont largement débordé, faute de pouvoir ou de vouloir utiliser autre chose. Ce n'est pas forcément bien grave, mais il faut être conscient qu'on surcharge ainsi les contraintes de rendu, et les risques pour ces fichus utilisateurs aux moeurs imprévisibles Smiley cligne
Désolé, Alan, ma remarque n'était pas vraiment claire. Voici ce qui se passe si on augmente les tailles de police et que l'on réduit la taille de la fenêtre :
http://www.rankspirit.com/alan/alan.gif

Cette expérience a été faite avec Internet Explorer 6, ta solution 2 modifiée et ta solution 3.
Avec FireFox, les 2 solutions donnent évidemment le même résultat (celui correspondant à l'image de gauche ci-dessus).


Laurent Denis a écrit :
- s'assurer que le contenu du header ne sera pas rogné si la taille d'affichage des polices est plus grande que ce qui a été prévu (c'est un des rares cas où un dimensionnement en em peut être approprié).

C'est en effet le cas avec la solution N°2. Dans la mesure où le header contient géréralement un logo ou une image de hauteur fixe, ça n'est pas forcément un inconvénient majeur, mais... à surveiller lors de son utilisation.
Laurent Denis a écrit :
- de même, s'assurer qu'il n'y a pas de superposition des textes du header et du contenu lorsque l'utilisateur désactive l'affichage des couleurs et agrandit le texte (dans les navigateurs / outils d'accessibilité ayant le bug de la transparence en cas de désactivation des couleurs : Firefox, IE5.x)

C'est le cas de la solution 3 [EDIT] voir la remarque d'Alan ci-dessous.
Laurent Denis a écrit :
- attention aux navigateurs (FF notament) dans lesquels l'utilisation des flèches pour accéder au scroll peut être perturbée.

[EDIT]Voir les remarques d'Alan ci-dessous
Laurent Denis a écrit :
- conserver un espace suffisant pour le contenu, pour que l'utilisateur en résolution réduite ne soit pas obligé de le consulter tant bien que mal dans une boîte à la hauteur trop réduite.

En effet. Eviter donc un header de très grande hauteur. Cela dit, l'immense majorité des internaute dispose désormais d'écrans de grande taille. A moins d'exagérer gravement avec la taille du header, il n'y aura pas de souci.
Laurent Denis a écrit :
- savoir que ce type de page pourra être très déroutante dans une loupe d'écran, où il peut être difficile de se rendre compte que le header est fixe.

Là, j'avoue mon incompétence : je n'ai pas de loupe d'écran.


Donc, en effet, ces solutions ne sont pas absolument "parfaites" et doivent être utilisées en connaissance de cause.

Mais en donnant aux concepteurs de site la possibilité de mettre en place une barre de menu fixe, elle présente un avantage qui me semble absolument formidable : la barre de menu fixe offre un confort de navigation indéniable et permet à l'identité du site de rester toujours présente.

Je vais personnellement mettre en oeuvre la solution 2 sur mon site et je suis absolument convaincu d'y gagner en termes de fidélisation et de satisfaction des 99% de visiteurs auxquels cette solution ne posera pas de problèmes de navigation.

Mais chacun voit midi à sa porte Smiley smile
Modifié par zapman (15 Jul 2006 - 09:29)
S'il s'agit de ça, Zapman, tu obtiendras strictement le même résultat, dans l'exemple 2 et 3, en spécifiant "overflow:hidden" pour le header (ne serait-ce que dans le commentaire conditionnel).

Concernant la navigation clavier, le gros problème se pose pour Firefox antérieur à la version 1.5 : impossible de scroller via les flèches. (de même il n'est pas possible d'utiliser la molette de souris.)
A partir de la version 1.5, le scroll par flèche est possible, mais, comme pour opera, il faut d'abord amener l' "attention" (via tabulation pour Firefox) sur la boîte scrollable.
Pour Internet Explorer, aucun problème de ce coté (puisqu'en fait le scroll est directement sur BODY) sauf dans le solution qui passe par javascript.
Alan a écrit :
S'il s'agit de ça, Zapman, tu obtiendras strictement le même résultat, dans l'exemple 2 et 3, en spécifiant "overflow:hidden" pour le header (ne serait-ce que dans le commentaire conditionnel).
Bon sang, mais c'est bien sûr !

Alan a écrit :
Concernant la navigation clavier, le gros problème se pose pour Firefox antérieur à la version 1.5 : impossible de scroller via les flèches. (de même il n'est pas possible d'utiliser la molette de souris.)
A partir de la version 1.5, le scroll par flèche est possible, mais, comme pour opera, il faut d'abord amener l' "attention" (via tabulation pour Firefox) sur la boîte scrollable.
Pour Internet Explorer, aucun problème de ce coté (puisqu'en fait le scroll est directement sur BODY) sauf dans le solution qui passe par javascript.


Merci pour ces précisions et bravo pour tout ça. Quel talent !
Laurent Denis a écrit :
De même que les flottants n'ont pas été conçus dans CSS2 pour faire des mises en page en colonnes, le positionnement n'a pas été conçu dans l'idée de partitionner la zone d'affichage.

+1

Suivant le site/l'application web à réaliser, je préconiserais :
– un position: fixed dégradé en position: absolute ou en position: static dans Internet Explorer 5 et 6 (via des commentaires conditionnels) ;
– l'utilisation de frames.

Le premier dans le cas où le souci est simplement esthétique (j'aimerais bien que mon bandeau de titre reste toujours à l'écran…). Le deuxième dans le cas où une structure partitionnée est indispensable aux fonctionnalités demandées, comme par exemple pour une application web.
Un des problèmes que pose le positionnement fixe de ce genre de header, c'est qu'il devient problématique de faire un lien vers un élément du document puisque celui-ci serait recouvert par le header (même problème qu'avec la première méthode que tu as indiquée)
Modifié par Alan (16 Jul 2006 - 10:38)
Je suis en train de mettre en pratique la solution N°3 de Alan et je constate un problème que je ne m'explique pas : lorsque l'on réduit la largeur de la fenêtre à l'extrême, avec Internet Explorer, l'ascenseur vertical fini par disparaître (on peut le constater en utilisant cet exemple)

Si je loge une image dans le bloc "#content", cela se produit dès que je réduit la largeur de ma fenêtre en-dessous de la largeur de l'image.

Quelqu'un aurait-il une explication et/ou une solution ?
Pages :