[Résolu]Une solution parfaite entre design fixe et extensible?

Bonjour,

Je me penche depuis un moment sur le designs de sites internet. Et il faut bien dire qu'entre design fixes et extensibles, mon coeur balançait.
Voila ce que je reprochais aux designs fixes (en px) :
- Ils sont trop étroits (760px). Si on les élargit, les utilisateurs en 800*600 sont oubliés, et si on le laisse à cette taille, les utilisateurs en 1280*1024 trouvent qu'il y a trop de bande blanche. De plus, si on a un design à base de 3 colonnes, il ne reste plus assez d'espace pour le design central.
- En termes d'accessibilité, je ne les trouve pas top : le par exemple on veux agrandir le texte, on se retrouve avec un design complètement anarchique: Des mots longs qui dépassent des menus latéraux, des menus horizontaux sur plusieurs lignes (et souvent l'image de fond qui ne suit pas), ...

Comme compromis, je créais des design fixes d'une largeur supérieure à 760px s'il y avait 3 colonnes, afin que la somme des 2 premières atteigne 760px (et je ne mettais dans la colonne de droite que des informations facultatives).

Contre les design flottants (en %) :
- Si on a des bannières ou des images de fond, c'est un véritable casse-tête chinois
- Il faut pour le bien mettre des min-width et max-width pour éviter que le site ne ressemble plus à rien, et là il faut jongler avec les bugs d'IE (je le déteste celui là)...

Lorsque j'utilisais ce genre de design, je laissais un peu tomber les utilisateurs d'Internet Explorer en leur collant un design fixe, et je m'occupais des utilisateurs de Firefox avec un design extensible.

Ayant un ami ayant des gros problèmes de vue, j'ai pu remarqué qu'il était quasiement exclu d'internet, car lorsqu'il grossissait trop les polices, tout se chevauchait, et plus rien n'était lisible... N'étant pas satisfait de ces deux solutions, j'en ai cherché une troisième, et j'ai construit mon design à base de em.
Les avantages me semblent assez importants :
- Quelle que soit la taille des polices, j'ai un design nickel.
- Plus de soucis de taille d'écran, l'utilisateur n'a qu'à zoomer ou dézoomer pour avoir le résultat qu'il préfère.
- Pas de soucis d'imcompatibilité avec IE
- Pas de soucis avec les banières et images de fond : elles aussi sont redimensionnées. Et si on grossit trop le site, on peut supposer que la personne est malvoyante, donc même si les images pixellisent légèrement, ce n'est pas gênant.
- On peux imaginer un bouton augmentant la taille des polices sur le site, et par la même occasion sa largeur...

Je vous mets mon test : http://www.les-heritiers-de-ma-duk.info/test/ .

Bon ok, je sais que je ne suis sûrement pas le premier à faire ça, mais c'est suffisament rare pour être notable (par exemple il n'y a pas de gabarit de ce type sur ce site, dans la page en listant plusieurs).

Que pensez-vous de ma solution? Vous semble-t'elle un bon compromis? Y aurait-il une bonne raison pour que ce genre de design ne soit pas utilisé?

Merci de vos retours...
Modifié par Helldream (15 Feb 2007 - 19:48)

Helldream a écrit :


Merci de vos retours...

Salut,

je pense qu'il te reste beaucoup à apprendre.

Vérification avec firefox

. dégradation inadmissible et scrollbar horizontale dès le 1er Ctrl+ (résolution avec largeur 1024 px)

. scrollbar horizontale dans le cas d'une résolution avec largeur de 800px.


Remarque 1 :
Ne jamais utiliser un dimensionnement de conteneur (largeur) en em sans que cela reste sous controle par un max-width. Si l'utilisateur n'utilise pas Opera avec la fonctionnalité "fit to width" active, c'est un désastre annoncé.

Remarque 2 :
les bonnes idées ne valent que si elles sont abouties et opérationnelles.

Je suis peu fan de cette technique, pour deux raisons.

La première, c'est que cela revient globalement à faire ce que font Internet Explorer 7 et Opera 9 (et peut-être les versions précédentes) avec leur fonctionnalité de zoom, qui agrandit texte et images de manière plus ou moins homothétique. Sauf que là on passe par l'augmentation de la taille du texte du document, qui correspond à une fonctionnalité différente. Les utilisateurs qui y ont recours (soit ponctuellement pour augmenter la taille du texte sur tel ou tel site, soit de manière globale en configurant leur navigateur pour avoir une taille de texte par défaut différente de la valeur standard de 16px) s'attendent donc à une certaine réaction, et en obtiendront une différente (effet de zoom intégral). Voilà pour la première réserve (on aurait pu sans doute rajouter que les zooms homothétiques très importants seront obtenus facilement... avec une loupe d'écran).

La deuxième concerne l'effet de zoom intégral lui-même. Je le trouve pour ma part moyennement satisfaisant (voire assez peu satisfaisant). Des zooms légers (de 120 à 200%, suivant la largeur d'origine du site et la largeur disponible à l'écran) sont intéressants, mais dès que la largeur du site dépasse la largeur de la fenêtre du navigateur on rencontre déjà un problème : une partie de l'information est hors-champ. Pire encore : avec un zoom trop fort, une même ligne de texte peut devenir plus large qu'un écran, et le texte illisible sans défilements constants à droite puis à gauche puis à droite puis à gauche puis... etc.

Sur ton exemple, un zoom de 300% de la taille du texte (quatre fois « Ctrl + » avec Firefox) fait que le texte de la colonne centrale dépasse la largeur de l'écran... sur mon écran en 1280px de large. Avec une résolution de 1024px de large, ça commence à dépasser à partir de 200%. Je rappelle qu'il s'agit d'un même flot de texte, pas de plusieurs textes ou éléments séparés.

Pour ma part, ce deuxième défaut me semble rédhibitoire, et je réserve donc les EM à la gestion de la taille du texte, pas à celle des largeurs de blocs... mais ça n'est qu'un avis personnel, et je donne peut-être trop d'importance à ce problème de lisibilité.

@Christian :

- Pour ce qui est de la dégradation, je ne vois pas de quoi tu parles.
- Par contre, pour la scrollbar horizontale, c'est vrai. Cependant, que vaut-il mieux : une scrollbar horizontale, ou des mots qui dépassent du design? Personellement, à choisir, je préfère la première solution. Car essaie par exemple de mettre le mot "informatique" sur une colonne, disons de largeur 150px (en supposant que la largeur des menus latéraux soient fixes, pour simplifier), avec une police relativement importante d'origine (par exemple une verdana avec em=1) : tu me diras ce que tu en penses, même après un seul zoom...
- Tu parles aussi d'une scrollbar horizontale dans le cas d'une largeur de 800px, et là encore c'est tout à fait vrai, mais c'est un choix. Je ne fais pas partie de ces inconditionnels qui font la chasse aux scrollbar horizontales : essaie de faire par exemple un design de ecommerce en 800 (enfin 760)px de large, avec 3 colonnes (surtout si ton client veux par exemple afficher 3 produits sur une seule ligne), et là encore tu me donneras tes retours... La solution que j'utilise, c'est justement de proposer une largeur de 760px uniquement pour les 2 premières colonnes.
- Enfin, tu me dis que j'ai encore pas mal de choses à apprendre. J'en suis conscient (toi aussi d'ailleur, comme le reste du monde), mais dire ça uniquement parce que je propose un solution qui ne répond pas à des critères personnels, là je ne suis pas d'accord. En effet, je ne connais pas exemple aucune recommendation plus ou moins standardisée, mentionnant des règles à respecter pour le design d'un site (en termes de largeur). Enfin, j'ai cru remarquer que AOL (http://www.aol.fr/) utilisait cette méthode. Et je doute que ceux qui on fait ce site soient des débutants. Ils sont même peut être bien plus expérimentés que toi...

Cela dit, je ne dis pas ça de façon agressive, hein, je te remercie de ton retour, et le but est justement de débattre sur ce sujet. Si tout le monde était d'accord, cela n'aurait aucun intérêt.


@Florent

- Pour ce qui est de la fonction "Zoom", je ne la connais pas (je garde encore IE6 pour le moment, et je n'utilise pas Opéra... c'est peut être un tord d'ailleur). Donc là dessus, je te fais confiance.
- Pour la loupe de Windows par contre, tu n'as pas tord. Sauf qu'ici, tu n'as pas la dégradation du texte lorsque tu grossis beaucoup, et l'ensemble de la page est grossie. C'est quand même mieux, par exemple pour voir une image grossie en entier. Et après tout, le grossissement des polices sur n'importe quel site peut être concerné par cette remarque : qu'est ce que ça apporte de plus que la loupe? Mis à part de faire foirer le design, dans plus d'un cas....
- Tu dis que ça étonne l'utilisateur, qui ne s'attends pas à ça. C'est tout à fait vrai, mais est-ce vraiment un mal? Ce qu'il veux, c'est avant tout de pouvoir lire le texte (en plus gros). Et l'attente est belle et bien comblée.
- Il est tout à fait vrai que la largeur de l'écran est dépassée au bout d'un moment. Mais dans la plupart des sites, déjà avec un zoom de 200%, tu commences à avoir un design dégradé. De plus, il faut se rendre à l'évidence : quelqu'un qui zoom à 400% n'utilisera pas un écran 17". Car de toutes façons aucun site n'est lisible à ce taux de grossissement sur un tel écran. On n'aura que quelques mots par ligne, le design sera complètement foutu... Et ça même avec un écran 21" (bah oui, si on ne modifie par la largeur du site selon le nombre de em, ton design ne ressemblera a rien au centre, et sur les cotés tu auras des méga bandes blanches, ou si le design est extensible, tu auras quand même des menus sur plusieurs lignes, ou des mots qui dépassent des menu etc). Avec ma solution, tu pourras avoir un design impécable, même avec un gros zoom (avec un grand écran, ou en étant obliger d'utiliser la barre de scroll, mais bon, il n'y a pas de solutions parfaite).
- Pour le zoom de 300%, essaie par hasard de faire ce zoom sur la page d'accueil d'Alsacreations : http://www.alsacreations.com/ ... OK, là le texte central ne nécessite pas de scrollbar, mais pense-tu sincèrement que le site est utilisable tel quel (par exemple regarde les menus hauts et latéraux)? Et encore, il faut bien reconnaitre que comparé à la majorité des sites, celui-ci s'en sort très très bien.

En tous cas merci aussi pour ton retour


Pour résumé, avec ce que vous m'avez dit, je reconnais que ce n'est pas une solution parfaite, mais il me semble que ce soit un très bon compromis entre le design fixe et extensible. Cela dit, si vous avez des exemples de site "modèle", permettant par exemple le zoom à 300%, sans l'utilisation de javascript, et aussi compatible qu'avec les em (concernant les différents navigateurs), et enfin sans l'utilisation de 36 hacks pour IE (il faut reconnaitre que les hacks sont bien pratiques, mais rendent au final de code plus compliqué, et le résultat n'est pas garanti, si par exemple IE évolue. Bon OK, on peux toujours rêver!), je suis preneur .

Un petit commentaire en passant : je considère que maintenant que les utilisateurs de résolution 800*600 sont moins de 20%, il ne faut plus faire les sites internet POUR eux (par exemple en mettant une largeur de 760), mais faire un site poour ceux étant en 1024*768 (la majorité), et vérifier qu'il soit consultable par ceux ayant une plus basse résolution. Par exemple pour mes design, si la personne a accès par défaut (pour une police de base) au menu de navigation, et au contenu de la page, ça ne me gêne pas qu'il y aie une scrollbar, et un menu droit non visible par eux avec des données secondaires ne gênant pas la navigation.
D'après vous, faut-t'il mieux que 10% de la population sous 800*600 quitte votre site parce qu'il y a une scrollbar (pour un menu facultatif), ou que 10% des personnes en 1024*768 le quitte parce qu'ils trouvent que vos informations sont trop collées les unes aux autres, et que le site est bien trop étroit par rapport à la quantité d'informations contenue??
Modifié par Helldream (15 Feb 2007 - 10:53)

Le problème, c'est que tu tiens plus à la conservation du design qu'à l'accessibilité aux contenus, semble-t-il. La page d'accueil d'Alsacréations est, comme tu le soulignes, un bon exemple de page qui supporte bien un très fort agrandissement (300-400%) de la taille du texte, à l'exception de deux éléments :
- le menu de navigation horizontal ;
- un texte positionné en absolu dans la colonne de droite.
Ces deux points auraient pu être corrigés s'ils avaient été pris en compte dès la conception de cette feuille de style. Ce n'est donc pas le choix d'un site en largeur fluide qui est en cause, mais bien des problèmes de conception sur des détails précis.

Je suis tout à fait d'accord pour dire que les designs fluides (largeur automatique ou largeur maximale à 100%) ou fixes posent problème pour l'agrandissement du texte, dans le cas des zones de texte réduites en largeur ou en hauteur (menus, colonnes étroites...). Mais c'est un problème que l'on peut traiter dans une certaine mesure, en visant non pas une conservation idéale du design de départ, mais la permanence des informations. Un texte qui dépasse d'une colonne de 150 ou 200px de large ça n'est pas très glamour, mais si ce texte ne chevauche pas d'autres contenus et s'il reste lisible (penser : couleurs de fond !), ça n'est pas bien catastrophique.

Tu dis que personne ne va zoomer à 300-400% s'il a un écran en 17". Qu'en sais-tu ? Avoir un problème de vu signifie-t-il nécessairement que l'on a les moyens de se payer un 21" ?
Pour information, je soulignais que ton exemple commençait à poser problème pour une résolution de 1024px de large à partir d'un zoom de 200%. Ce qui n'est pas si énorme, tout de même. Pour ma part, ça me semble trèsproblématique.

Pour ce qui est d'IE7 et d'Opera : oui, tu devrais tester ces navigateurs (et en disposer pour des tests réguliers). Considérer Firefox comme la référence et IE6 comme le machin qu'il faut réussir à faire marcher, c'est un peu limité, et c'est passer à côté de plusieurs aspects de la conception selon les Standards (note en passant : même Firefox a des bugs et des limitations...).

Helldream a écrit :
si vous avez des exemples de site "modèle", permettant par exemple le zoom à 300%

La fonctionnalité d'agrandissement des caractères des navigateurs, en dépit de ce que suggère son implémentation dans FF et Safari, n'est pas destinée à dépasser les tout premiers niveaux d'agrandissement (voir l'implémentation d'IE).

Chercher à produire des designs supportant ce type d'agrandissement des tailles de caractères est inutile. Ces niveaux d'agrandissement élevés relèvent de zoom graphiques (opera, IE7) ou d'aides techniques (loupe d'écran)...

Eh oui : il faut parfois rappeler que l'utilisateur, fusse-t-il en situation de handicap, doit également s'assumer et disposer d'outils appropriés.
Modifié par Laurent Denis (15 Feb 2007 - 11:35)

Disons pour résumer que je ne sais plus vraiment sur quel pieds dancer:
- si je fais un design fixe à 760px, je ne peux pas mettre 3 colonnes : il ne faut pas se le cacher 150px par colonne c'est un minimum si l'on veux mettre des mots un tant soit peu long, et si j'en ai déjà pour 300px de menus latéraux, 460px pour le contenu standard, si l'on veux faire une présentation graphique (par exemple pour un site de ecommerce montrer plus d'une jaquette de cd sur la largeur), ce n'est pas défendable
- si le design fait plus de 760px, là je me fais tapper dessus car les utilisateurs ayant de basses résolutions ont une scrollbar
- si je fait un design dynamique, on me dit qu'il faut mettre des min-width et max-width car sinon les lignes de texte sont trop longues. Donc il faut commencer à jongler avec des hacks qui marchent plus ou moins (car par exemple, je ne pense pas qu'on puisse faire de design extensible sous IE, si javascript est désactivé). De plus commencer à mettre 36 div juste pour rendre compatible les sites avec IE, c'est une perte de temps, ça complexifie la maintenance, et en plus le résultat n'est pas garanti. De plus, pour le design, c'est un casse-tête.
- Si je fais un design à base de em, ce n'est pas ça non plus à cause des scrollbars, une fois encore.

Au final, quelle est la meilleure solution? Une solution qui marche partout? En sachant qu'il n'est pas facile de faire comprendre à un client qu'il ne peux pas mettre d'image de fond à un cadre, parce que sa largeur va varier, et que je ne suis pas graphiste?

Ce n'est pas que je veux favoriser le graphisme par rapport à l'accessibilité, mais justement que je pense aux personnes handicapées, et avoir des sites illisibles parce que tout se chevauche, ou que le design foire au point de rendre le site purement moche et peu accessible, ce n'est pour moi pas une bonne solution.

Et en effet, les personnes ayant de problèmes de vues ont très très souvent un grand écran. Pourquoi : être en 800*600 avec un écran 21" permet d'avoir déjà un affichage de grande taille, avant même de commencer à utiliser des zooms, qui rendent souvent les applications/site plus ou moins inutilisables (justement à cause du chevauchement)... C'est justement en observant le comportement de ce genre de personne que j'en suis arrivé à cette conclusion!
Modifié par Helldream (15 Feb 2007 - 12:04)

Helldream a écrit :
- si je fais un design fixe à 760px, je ne peux pas mettre 3 colonnes
- si le design fait plus de 760px, là je me fais tapper dessus car les utilisateurs ayant de basses résolutions ont une scrollbar

Tu t'es déjà dit que certains objectifs pouvaient parfois être contradictoires, et que l'on ne peut pas toujours ménager et la chèvre et le chou ?

Si tes contraintes en termes de contenus à présenter t'imposent trois colonnes et une colonne centrale importante, et que tout ça ne peut pas tenir sur du 760px de large... eh bien, dépasse donc cette largeur ! Certes, ça donnera un site plus difficile à visiter pour 10-15% des utilisateurs, mais peut-être plus efficace pour tous les autres.

Le tout, c'est d'être conscient de l'impact des décisions que l'on prend. Si tu peux argumenter qu'un design en largeur fixe, à 980px, est la meilleure réponse vu les contraintes du projet, pas la peine de se mettre martel en tête.

Le compromis que tu esquissais plus haut (les deux colonnes principales sont visibles en 800x600, et une colonne d'importance secondaire est hors-champ) me semble d'ailleurs plutôt intéressant.

Helldream a écrit :
si je fait un design dynamique, on me dit qu'il faut mettre des min-width et max-width car sinon les lignes de texte sont trop longues.

Surtout des max-width. Ça passe très bien dans les navigateurs modernes. Parmi les navigateurs encore largement utilisés, seul IE6 ne comprend pas cette propriété. Il existe effectivement un semblant de solution, pas tout à fait satisfaisant mais déjà intéressant. L'utilisation des commentaires conditionnels permettra de faire les choses proprement en adressant la solution en question à IE6 uniquement (laissant IE7 appliquer le max-width comme les autres navigateurs modernes), sans avoir recours à des hacks peu fiables et potentiellement dangereux.

Helldream a écrit :
Donc il faut commencer à jongler avec des hacks

Non, justement, pas de hacks. Et sans utiliser 36 divs « juste pour rendre compatible les sites avec IE ».

Helldream a écrit :
qui marchent plus ou moins (car par exemple, je ne pense pas qu'on puisse faire de design extensible sous IE, si javascript est désactivé)

On peut tout à fait faire un design extensible avec IE6, que javascript soit activé ou non.
C'est la limitation de la largeur qui sera difficile avec IE6, pas la réalisation d'un design extensible.

Helldream a écrit :
En sachant qu'il n'est pas facile de faire comprendre à un client qu'il ne peux pas mettre d'image de fond à un cadre, parce que sa largeur va varier, et que je ne suis pas graphiste?

Euh... c'est pas bien compliqué de mettre une image de fond (ou une image de contenu, hein, c'est parfois utile...) pour un bloc de largeur variable. Images répétables, dégradé vers une couleur de fond... les solutions sont multiples. Je te laisse jeter un oeil au bandeau de titre ce forum, par exemple.

Florent V. a écrit :

Surtout des max-width. Ça passe très bien dans les navigateurs modernes. Parmi les navigateurs encore largement utilisés, seul IE6 ne comprend pas cette propriété. Il existe effectivement un semblant de solution, pas tout à fait satisfaisant mais déjà intéressant. L'utilisation des commentaires conditionnels permettra de faire les choses proprement en adressant la solution en question à IE6 uniquement (laissant IE7 appliquer le max-width comme les autres navigateurs modernes), sans avoir recours à des hacks peu fiables et potentiellement dangereux.

Tu peux me donner un petit exemple SVP? (je reconnais que j'ai un peu la flemme de chercher)

En tous cas merci beaucoup pour vos réponse, je commence à entrevoir la lumière sur plusieurs points. J'hésite encore entre design fixe et extensible, mais je sais mieux comment mettre ces deux solutions en place!

Helldream a écrit :

Tu peux me donner un petit exemple SVP? (je reconnais que j'ai un peu la flemme de chercher)

J'espère pour toi que personne n'aura la flemme de te répondre
Sinon, Florent V et moi avons de belles signatures pertinentes...

Ne t'en fais pas, j'ai déjà regardé la FAQ plus d'une fois. Et tu remarqueras d'ailleur que je n'ai pas pour habitude de poster des questions dont la réponse se trouve dans la FAQ. Voici ce qui pourrait me concerner :

a écrit :
1- Concernant max-width, qui est une propriété très utile pour les design fluides à largeur controlée, on peut, par exemple, utiliser cette technique JavaScript développée ici : http://www.svendtofte.com/code/max_width_in_ie/

Ca utilise donc le javascript...

a écrit :
On peut aussi gérer la situation où le JavaScript est inactif en jouant sur le fait que plusieurs déclarations de la même propriété sont écrasées par la dernière de ces déclarations :

[...]
Dans ce cas si JavaScript est inactif le deuxième width sera purement et simplement ignoré et on aura un résultat en design fixe "raisonnable" d'une largeur de 770px.

Donc dans ce cas, pas de design extensible sans javascript, sous IE avec cette solution. C'est pour cela que je demande à Florent V. s'il connait un autre moyen pour utiliser max-width sous IE sans javascript, chose que je ne pensais pas possible de faire

J'ai lu ceci sur un forum sous Linux : "A l'heure actuelle, il s'est formé une sorte d'aristocratie de Linux qui essaye de maintenir ses connaissances pour elles et d'en priver les autres en innondant chaque débutant de documentations". J'ai hélas l'impression que cela ne s'applique pas que pour Linux. La solution à mon problème se trouve peut-être quelque part, dans le fin fond qu'une documentation, d'une FAQ, ou d'un site. Mais passer 1 semaine dans l'espoir de la trouver, non. Je suis d'accord qu'il ne faut pas non plus à l'inverse poser une question sans faire l'effort de se documenter un peu avant, les personnes ont d'autres choses à faire qu'à répéter 36 fois les mêmes choses. Mais tout de suite lance "t'as qu'à chercher sur Google", ou ici "vas voir la FAQ" sans chercher à comprendre le vrai problème, c'est un peu facile aussi.

Le but d'un forum est de PARTAGER, pas de faire briller son savoir, ou de réciter ses solutions miracles en balançant tout ce qui sort de son petit monde...

Désolé, je me rends compte que je suis un peu agressif dans ce sujet, et je tiens à m'en excuser. Ce n'est pas trop mon genre, mais il y a des comportements qui ont tendance à me faire sortir de mes gonds. Merci en particulier à Florent V., Laurent Denis et , et Christian Le Bouler qui m'ont permis de comprendre et d'apprendre certaines choses

Helldream a écrit :
Le but d'un forum est de PARTAGER, pas de faire briller son savoir, ou de réciter ses solutions miracles en balançant tout ce qui sort de son petit monde...

Du calme... Nous connaissons tous le but d'un forum, merci de nous le rappeler.

Je trouve ça étrange de t'emporter après avoir dit :

Helldream a écrit :
(je reconnais que j'ai un peu la flemme de chercher)

Remettons un peu les choses en place : Raphaël réagissait à ton « je reconnais que j'ai un peu la flemme de chercher », en l'interprétant peut-être comme du je-m'en-foutisme. Et c'est vrai que c'est une interprétation possible, car rien ne disait que tu avais déjà fait des recherches mais sans forcément trouver les réponses que tu cherchais. Maintenant c'est dit, et je propose qu'on en reste là.

Par contre, Raphaël te renvoyais à la FAQ du forum... suite à ta question sur les commentaires conditionnels. Ça n'était pas un « RTFM » (read the fucking manual), mais simplement une indication pertinente : en effet, la FAQ contient un item nommé « Qu'est-ce que les commentaires conditionnels ? ». Je te laisse le consulter pour plus d'informations sur le sujet.

Maintenant, le cas d'IE et de max-width. Il faut rappeler quelques petites choses :

1 - Limiter la largeur maximale pour éviter d'avoir des lignes de textes trop longues n'est pas une contrainte d'accessibilité, mais une simple optimisation ergonomique (donc : facultative).
2 - Internet Explorer 7 gère correctement max-width, ce qui signifie que cette optimisation ergonomique devient disponible pour une part importante d'utilisateurs (bientôt la majorité, vu les parts de marché de Firefox et IE7).
3 - Internet Explorer 6 ne gère pas du tout max-width (non implémenté), mais comme dit en (1) ça n'est pas bien grave ! Au pire, si la mise en page réalisée exige une limitation de la largeur pour un rendu correct, on basculera sur un design fixe pour Internet Explorer 6 (via les commentaires conditionnels).
4 - Si on veut tout de même un peu plus de souplesse avec Internet Explorer 6, il existe une méthode via l'utilisation de Javascript et le test de la largeur de body, méthode documentée dans le tutoriel « Faire un site pour toutes les résolutions » disponible sur Alsacréations. Ça n'est pas parfait, ça n'est pas un max-width correctement émulé, mais ça peut être utile.

Au final, il s'agit d'utiliser au mieux les capacités respectives des différents navigateurs. IE6 est limité, pourquoi vouloir forcément obtenir exactement le même résultat que dans des navigateurs plus performants (dont IE7) ?

C'est vrai que ça aurait pu être mal interprété, mais d'un autre coté j'ai bien parlé de hack plus haut pour compenser ce manque de max-width, et pour moi (je n'ai peut être pas la définition de "hack"), la technique utilisant javascript est un hack. Ce qui aurait pu mettre la puce à l'oreille sur les recherches effectuées. En plus, je ne demandais pas "qu'est ce que les commentaires conditionnel?", mais "peux-tu me donner un exemple de son application?" dans un cas précis...

Cependant, je le reconnais (je l'ai d'ailleur déjà reconnu un peu plus haut), j'ai eu tord de m'emporter. Il est vrai que passer des heures pour chercher à contourner les limitations de IE6 ont quelque fois tendance à m'exaspérer (comme beaucoup de monde je suppose), ce qui explique mon ennervement quand on me dit en gros "t'as qu'à chercher" Mais bon, ce n'est pas une raison pour se défouler sur les personnes qui sont quand même là pour m'aider (sinon elles n'auraient pas pris la peine de me répondre).

Comme tu le disais, il vaut mieux en rester là, de toutes façons j'ai eu les réponses à mes questions grâce à vous, et ce qui pourrait encore être dit sera donc hors sujet

Merci à tous pour votre aide, et pardon pour l'agressivité, qui au final n'était pas dirigée vers vous!

Helldream a écrit :
Merci à tous pour votre aide, et pardon pour l'agressivité, qui au final n'était pas dirigée vers vous!

Tape sur ton écran, ça défoule.

Au final, est-ce que tu considères que ton sujet est [Résolu] ?

Helldream a écrit :

Ca utilise donc le javascript...

Et alors ???

C'est quoi ton problème ?

Tu as une solution qui élargit au maximum la possiblité d'utilisation du max-width + une dégradation on ne peut plus correcte en cas de js inactif pour le reliquat = (IE js inactif) - IE7.
Le tout de manière parfaitement non envahissante pour la feuille de style principale et réservé au versions d'IE adéquates, par l'utilisation des commentaires conditionnels, ce qui résoud les problèmes qu'entrainent l'utilisations des hacks = absence totale de perennité de la technique en fonction de l'évolution des implémentations.

Et tu veux encore courrir après on ne sait quoi ? Laver plus blanc que blanc ?

Il est inutile et naïf d'avoir de telles positions de principes.

. Le javascript est totalement non problématique s'il est utilisé de manière critique et prudente.

. les hacks sont à éviter pour les raisons indiquées ci dessus et donc continuer à appeler hacks des procédés qui garantissent eux la pérennité de la technique quelque soit l'évolution des implémentations c'est ne rien comprendre aux enjeux qui fondent la critique de l'utilisations desdits hacks.

Donc effectivement continuer à apprendre.
Modifié par Christian Le Bouler (15 Feb 2007 - 19:22)

Tu n'as pas tord (t'as vu, je suis devenu résonnable ). J'ai tendance à trop vouloir éviter le javascript, et dans ce cas c'est non justifié. Et en effet, je ne peux pas dire que cette méthode soit vraiment une bidouille