28112 sujets

CSS et mise en forme, CSS3

Bonjour à tous,

Me revoilà après quelques mois d'inactivité "webique" !
Le retour est rude. Je repars directement sur de drôles d'événements...

Je constate un drôle de "dilution du texte"... étonnant.
Différence entre : Firefox PC et Safari Mac.
L'exemple du haut c'est une superposition des deux.

J'ai essayé de définir les tailles de texte en em comme en px, rien ne chance.

Quelqu'un a déjà rencontré ce type de comportement ? Aurait une solution ? Merci d'avance.

upload/1788-maquette.jpg
Modifié par Corinne (24 Jan 2007 - 01:21)
Ne serait-ce pas tout simplement un effet du lissage des polices, activé par défaut sous OS X ?
C'est comme sous IE7, je n'ai jamais vu un écran où cet effet de police clear type me semblait plus agréable que par défaut... Smiley fache
Bonjour et merci, c'est fort possible que cela soit dû au lissage, en effet sous Safari il est là par défaut.

Il n'y a donc, je suppose, aucun moyen de contrôler (au milimmètre, em, px ou autre) près l'espace que prendront mes textes à cause de ce lissage ?
Salut.

Corinne a écrit :
Bonjour et merci, c'est fort possible que cela soit dû au lissage, en effet sous Safari il est là par défaut.

Il n'y a donc, je suppose, aucun moyen de contrôler (au milimmètre, em, px ou autre) près l'espace que prendront mes textes à cause de ce lissage ?

Contrôler la taille des caractères "au pixel près" est de toutes façon impossible, puisqu'elle est fonction du navigateur & des paramètres du visiteur Smiley ohwell

Le seul moyen d'éviter cet écueil, c'est de passer par une image portant le texte (mais question référencement & accessibilité, saitrémal Smiley smile )
Bonjour,
Oui en effet, pas terrible de passer ça en image Smiley ohwell Je vais essayer d'éviter !
Je planche sur une solution alternative qui tolère plus facilement les compromis.
En attendant si quelqu'un a une suggestion je suis preneuse !!
Encore merci.
Oui, c'est un lissage intégré a mac os x, et donc activer sur safari puisque ce dernier utilise cocoa Smiley smile
De toutes façons, c'est pas top de se baser à ce point sur la largeur d'un texte Smiley rolleyes
Thomas D. a écrit :

Le seul moyen d'éviter cet écueil, c'est de passer par une image portant le texte (mais question référencement & accessibilité, saitrémal Smiley smile )


Non, cépatrémal.

C'est moins bien mais parfois tout à fait approprié. Si la contrainte graphique est nette, les différentes méthodes d'application de WCAG1.0 admettent le passage de texte en image (accessible, naturellement). Et celui-ci, s'il est accessible (alt) ne pose aucun problème de référençabilité.

Quoi qu'il en soit, il est réjouissant de voir que personne ne s'est manifesté pour proposer une de ces solutions tortueuses et fragiles à base de <evil>texte HTML masqué et remplacé par des background CSS</evil>... On progresse Smiley ravi
Laurent Denis a écrit :
C'est moins bien mais parfois tout à fait approprié. Si la contrainte graphique est nette, les différentes méthodes d'application de WCAG1.0 admettent le passage de texte en image (accessible, naturellement). Et celui-ci, s'il est accessible (alt) ne pose aucun problème de référençabilité.
Avec une limite en terme de longueur de l'attribut, non ?
Bonjour aux autres intervenants !

Il se trouve que j'ai des contraintes très précises à respecter au niveau de l'identité visuelle. S'il s'agissait d'un projet personnel je me débrouillerais pour éviter ce type de "rigueur visuelle". Mais là je dois faire avec et trouver une solution !

Laurent, il s'agit là du menu principal du site. Est-ce vraiment acceptable (et accessible/référençable !) pour une navigation de cette importance ?

Pour ce qui est des solutions de texte planqué, je suis pas adepte. Qui sait quelles mesures vont prendre les moteurs de recherche à l'avenir à ce sujet... Alors autant trouver des vraies solutions !

Pour ce que dit Laurent plus haut voici le résultat de mes recherches. C'est chouette et ça parle d'accessibilité (c'est déjà un bon pas !) mais pas de "référençabilité". Si vous avez d'autres sources je suis preneuse.

Extrait de http://www.la-grange.net/w3c/WAI-WEBCONTENT-TECHS/

a écrit :
5.3.1 Texte à la place des images

Les développeurs de contenu devraient utiliser les feuilles de style pour styler le texte plutôt que de représenter le texte en images. Utilisez le texte à place des images signifie que l'information sera accessible à un plus grand nombre d'utilisateurs (avec des synthétiseurs vocaux, des afficheurs braille, des afficheurs graphiques, etc.). Utiliser les feuilles de style permettront également aux utilisateurs de remplacer les styles des auteurs et de changer les couleurs ou les tailles de polices plus facilement.

S'il est nécessaire d'utiliser un bitmap pour créer un effet de texte(police spéciale, transformation, ombres, etc.) le bitmap doit être accessible (voir les sections sur les équivalents textes et sur les pages alternatives).

Ici http://www.la-grange.net/w3c/WAI-WEBCONTENT-TECHS/#text-equivalent pour les techniques.
Modifié par Corinne (24 Jan 2007 - 14:56)
Laurent Denis a écrit :
C'est moins bien mais parfois tout à fait approprié. Si la contrainte graphique est nette, les différentes méthodes d'application de WCAG1.0 admettent le passage de texte en image (accessible, naturellement). Et celui-ci, s'il est accessible (alt) ne pose aucun problème de référençabilité.
Oui bon, on se comprend, il y a moyen de le faire correctement, mais pour des textes courts (le plus souvent, c'est pour les titres que la question revient). Ici, si le soucis vient bien du lissage des polices de Mac OS X, il faudrait le faire pour l'entièreté du texte - et ça, ce n'est pas gérable ...

@ Corinne, pas de problème pour ton menu si tu laisses les images en dur, dans le code HTML.

Laurent Denis a écrit :
Quoi qu'il en soit, il est réjouissant de voir que personne ne s'est manifesté pour proposer une de ces solutions tortueuses et fragiles à base de <evil>texte HTML masqué et remplacé par des background CSS</evil>...
Tiens, et que penses-tu de celle-là ? Smiley smile
Modifié par Thomas D. (24 Jan 2007 - 15:05)