Demande d'avis

Bonjour à tous,

je viens de tomber sur un site qui me laisse très perplexe...

le site en question

Ce post n'est en aucun cas de la pub inavouée et je n'ai rien à voir avec ce site. J'ai simplement voulu le visualiser sous IE6 au départ (le résultat est relativement catastrophique). Je suis passé sous Moz où tout va très bien mais j'ai zieuté le code pour comprendre quelle(s) fonctionnalité(s) extraordinaires nécessitaient un navigateur de dernière génération.

En lisant le code, je suis encore plus perplexe en fait. J'aimerai donc avoir votre avis sur les détails que vous remarquez, qui vous semblent suspect ou bien, au contraire.

D'avance, merci.

Bonjour,

(...)

EDIT: en te relisant, je pense que tu voulais un avis technique et pas ce que je viens d'écrire, dsl
Modifié par Felipe (21 Aug 2008 - 17:43)

Bonjour,

Le rendu dans IE6 n'est pas «catastrophique», il est juste «nu»: la feuille de styles n'est pas chargée. Le message spécifique qui apparait est apparemment servi uniquement si l'en-tête HTTP User Agent correspond à IE (ou à IE6?), et il est réservé à IE6 et inférieurs via un commentaire conditionnel.

La feuille de styles est importée avec la syntaxe (valide) suivante:

@import "/assets/styles/" screen;

Syntaxe qu'IE6 ne comprend pas (contrairement à IE7), et qui représente un bon moyen de filtrer IE6.

C'est donc un choix du concepteur du site. Si ce dernier passe par là, il l'expliquera peut-être.

Mais si tu lis la feuille de styles, tu remarqueras que de nombreux sélecteurs utilisés ne sont pas compris par IE6. Appliquer cette feuille de styles à IE6 donnerait quelque chose d'assez étrange, je pense.

A ce sujet, tout à fait d'accord.

Mais est-ce justifié, au final ? Il ne me semblait pas impossible d'arriver à un résultat équivalent adapté pour ie6. Mais je me trompe peut-être

Une autre question que je me pose, c'est au sujet de ceci :

<h2>
			<img
				alt="Hello. We are Deaxon. We build beautiful, hand-crafted websites. We'd love to do it for you."
				src="assets/images/header/claim.png"
				width="452" height="150"
			/>
		</h2>

Personnellement, j'aurai placé un texte dans la balise H2 et je lui aurai assigné un ID avec l'image en background et le text en indent (-4000) pour "l'effacer". Au final, quelle démarche vous semble la plus adaptée ?
Modifié par bhen (22 Aug 2008 - 10:39)

Salut,

bhen a écrit :
Personnellement, j'aurai placé un texte dans la balise H2 et je lui aurai assigné un ID avec l'image en background et le text en indent (-4000) pour "l'effacer". Au final, quelle démarche vous semble la plus adaptée ?

L'image transporte une information, sa place est dans le code HTML. Et pour rendre l'information accessible si l'image ne peut être affichée, on utilise l'attribut alt de l'image. Il est là pour ça, et ça fonctionne parfaitement.

Le bricolage background CSS + text-indent négatif n'est tout simplement pas logique. De plus ce n'est pas accessible: les visiteurs qui ont accès aux styles mais pas aux images ne verront rien du tout

bhen a écrit :
Personnellement, j'aurai placé un texte dans la balise H2 et je lui aurai assigné un ID avec l'image en background et le text en indent (-4000) pour "l'effacer". Au final, quelle démarche vous semble la plus adaptée ?

Oui mais... cela aurait apporté quoi de plus ?
Ce serait pour l'accessibilité ? le référencement ? la sémantique ?

Le contenu des attributs "alt" est très bien lu et compris par tous les agents utilisateurs. Tout aussi bien que du texte "pur" masqué par bidouille et qui - au final - posera toujours un problème d'accessibilité sur une configuration précise.

EDIT : grillé
Modifié par Raphael (22 Aug 2008 - 11:01)

bhen a écrit :
Il ne me semblait pas impossible d'arriver à un résultat équivalent adapté pour ie6.

Pas impossible, mais laborieux. Rajouter +25% à +50% au temps nécessaire à l'intégration, pour ce genre de design plutôt fouillé. Sans compte que ça demanderait de modifier en bonne partie le code HTML, ici réduit au minimum grâce à l'utilisation des sélecteurs CSS 2.1 que ne supporte pas IE6.

Enfin, ça dépend des objectifs du site. Dans le cas présent, ça filtre les clients potentiels.

merci,

j'ai encore bcp à apprendre

J'arrive un peu tard, tout semble avoir été dit par mes érudits confrères

Au passage, j'appuie tout à fait Florent lorsqu'il parle d'objectifs. Il est certain qu'un site institutionnel imposera des contraintes différentes d'un portfolio d'agence web démarchant avant tout des créatifs, des agences de pub, …

Autre exemple simple rencontré récemment: je crée un site pour vendre une application destinée à Mac OS uniquement. Au niveau commercial, j'aurai tout intérêt à favoriser un support parfait de Safari qui représentera très certainement un pourcentage élevé de visiteurs plutôt que de chercher un support intégral d'IE6. À priori, ce dernier n'est pas ma cible, j'y consacre donc un budget réduit.

Ce n'est donc pas (seulement) une question d'éthique, c'est platement budgétaire. Il n'y a pas de solution unique à toutes situations, c'est au cas par cas

c'est un peu extrême quand même... On en revient presque à JVAchez et son naviagateur d'un autre age

Personnellement je donne de moins en moins d'importance au rendu sous IE6, mais enlever carrément la feuille de style rend le site difficilement lisible pour un utilisateur traditionnel...

a écrit :
mais enlever carrément la feuille de style rend le site difficilement lisible pour un utilisateur traditionnel...

Avec une structure robuste non c'est justement l'inverse de ton impression.

C'est ce qui distingue un bon site d'un mauvais.

Ce qui reste difficilement preceptible pour moi (encore), c'est le fait de tenir compte de la sémantique, de l'accessibilité mais de composer avec tout cela selon les objectifs différents d'un site (visuel, référencement ou autre ...) et de faire varier la structure selon le besoin.

Cela sous entend qu'il n'y a jamais qu'une seule bonne solution à prendre comme référence mais plutôt que c'est variable selon chaque template.

Pourquoi ai-je arrêter le delphi...

Salut,

bhen a écrit :
Ce qui reste difficilement preceptible pour moi (encore), c'est le fait de tenir compte de la sémantique, de l'accessibilité mais de composer avec tout cela selon les objectifs différents d'un site (visuel, référencement ou autre ...) et de faire varier la structure selon le besoin.

Cela sous entend qu'il n'y a jamais qu'une seule bonne solution à prendre comme référence mais plutôt que c'est variable selon chaque template.

Oui et non...

La majeure partie du document reste structurée uniquement en fonction du contenu: titres, citations, etc. C'est ce balisage là qui est "sémantique" et permet de rendre une page compréhensible et claire sans les éléments visuels ajoutés.

Le layout et le design imposent parfois certains choix, comme celui de mettre telle colonne avant telle autre dans le code HTML, rajouter un div apparemment inutile à tel endroit, ... Mais beaucoup de ces concessions sont dues aux limitations de CSS, notamment dans les posibilités de positionnement des éléments

Ah oui, et ceux qui adaptent leur code HTML à des objectifs de référencement devrait penser à revoir leurs contenus

Thomas D. a écrit :
Ah oui, et ceux qui adaptent leur code HTML à des objectifs de référencement devrait penser à revoir leurs contenus

Tandis que ceux qui adaptent leur code HTML à des objectifs de design sont des gens raisonnables.

Florent V. a écrit :

Tandis que ceux qui adaptent leur code HTML à des objectifs de design sont des gens raisonnables.

Dans une certaine mesure, oui. Quoiqu'il faille distinguer "design" et "layout"...

Restent les idéalistes qui refusent ce genre de concessions