[accessibilité] taille de polices relatives

Alsacreationniennes, Alsacreationniens,

J'ai enfin compris comment gérer la taille du texte avec les em, avec cet article (pompage) sur les polices dynamiques (l'article de alsacreations est trop technique)

Apparemment, j'ai pu "vérifier" que la police par défaut des navigateurs est souvent 16px (Firefox - Linux, Firefox - windows, IE - windows) d'ailleur existe t-il des statistiques sur les tailles de polices par défaut suivant les navigateurs ?

Je me suis mis au CSS/XHTML il y a quelques mois pour le design et la propreté du code. Aujourd'hui, sensibilisé par l'accessibilité, je recherche à faire des sites accessibles (link speciaux, accesskey, pas de _blank ...). Mon problème, comme beaucoup de webmaster, c'est les polices relatives.
En effet ce point (!important) d'accessibilité, nuit à mon design :

Prenons l'exemple (fictif) d'une liste de 12 timbres que je représente visuellement en 4 lignes avec 3 timbres par ligne ... chaque div timbre possède (css) en background une image gif (pour les frises blanches) et une couleur (rouge: tarif rapide, vert:tarif lent). Ces div timbres sont extensibles en hauteur (car le nom des personnes représentés sur les timbres sont plus ou moins long) mais fixes en largeur.
Si j'applique dans cet exemple une taille de polices relatives, le rendu graphique est décevant : le nom des personnes sort des cadres sans parler des menu qui déborde de mes fonds dégradés ... etc ...

J'ai analysé quelques "meilleurs" (comprendre au sens trafic) sites français :

[url=http://fr.wikipedia.org/]wikipedia fr[/url] : polices relatives
[url=http://www.dailymotion.com/fr]dailymotion[/url] : polices fixes
[url=http://www.linternaute.com/]linternaute[/url] : polices fixes
[url=http://www.allocine.fr/]allocine[/url] : polices relatives
[url=http://www.clubic.com/]clubic[/url] : polices fixes
[url=http://www.lemonde.fr/]lemonde[/url] : polices fixes

Alors que faut-il faire quand on aime le design avec de belles pages pleins d'effet css et que l'on veut s'obliger au nom d'une éthique personnelle adopter les règles de l'accessibilité ?

polices relatives ? polices fixes ?

Merci

Cdt,

P75

PS: je suis pas contre d'avoir également des exemples de sites dans vos réponses
Modifié par P75 (11 Dec 2007 - 14:55)

Bonjour,

Hum...

Quelques précisions ?

- accesskey: plus problématiques pour l'accessibilité qu'autre chose. ne pas utiliser

- target blank: ne pose au contraire aucun problème d'accessibilité dès lors que l'utilisateur est prévenu via le libellé du lien ou via son attribut title

- information donnée uniquement par la couleur et/ou uniquement via CSS (rouge: tarif rapide, vert:tarif lent) : non accessible, ne jamais faire

- tailles fixes: ce sont les unités pt, cm etc. Pas le pixel. Le pixel est comme l'em. C'est une unité relative, même si IE ne la redimensionne pas par défaut via Affichage>Taille du texte. Une taille de police en pixel est en fait formellement accessible (mais il est préférable, disons, de l'éviter dans la mesure du possible)

- une liste de 12 timbres: faire des blocs extensibles selon la taille de caractères affichés. Un tableau de présentation (parfaitement accessible) fera cela très bien.
Modifié par Laurent Denis (11 Dec 2007 - 15:55)

P75 a écrit :
Apparemment, j'ai pu "vérifier" que la police par défaut des navigateurs est souvent 16px (Firefox - Linux, Firefox - windows, IE - windows) d'ailleur existe t-il des statistiques sur les tailles de polices par défaut suivant les navigateurs ?

Hello,

D'où tiens-tu cette valeur de 16px ?

En fait, par défaut, les valeurs sont censées être fluides en "em" selon la feuille de style proposée par le W3C et généralement prise en compte par les navigateurs : http://www.w3.org/TR/CSS21/sample.html

Cet article devrait te dépanner
Modifié par Raphael (11 Dec 2007 - 16:18)

merci pour votre réponse.

Laurent Denis a écrit :

- accesskey: plus problématiques pour l'accessibilité qu'autre chose. ne pas utiliser

c'est pas ce que j'ai lu : Définir des raccourcis clavier

Laurent Denis a écrit :

- target blank: ne pose au contraire aucun problème d'accessibilité dès lors que l'utilisateur est prévenu via le libellé du lien ou via son attribut title

tout à fait d'accord par ex : w3.org

Laurent Denis a écrit :

- information donnée uniquement par la couleur et/ou uniquement via CSS (rouge: tarif rapide, vert:tarif lent) : non accessible, ne jamais faire

effectivement, mais là c'était un exemple fictif la couleur apporte pas d'information c'est juste visuel.

Laurent Denis a écrit :

- tailles fixes: ce sont les unités pt, cm etc. Pas le pixel. Le pixel est comme l'em. C'est une unité relative, même si IE ne la redimensionne pas par défaut via Affichage>Taille du texte. Une taille de police en pixel est en fait formellement accessible (mais il est préférable, disons, de l'éviter dans la mesure du possible)

je pensais que selon alsacreations le px est une unité de taille fixe.

Maintenant ce n'est pas bloquant au niveau de l'accessibilité de l'utiliser ?

Laurent Denis a écrit :

- une liste de 12 timbres: faire des blocs extensibles selon la taille de caractères affichés. Un tableau de présentation (parfaitement accessible) fera cela très bien.

je n'utilise pas de tableau pour représenter des données non tabulaire. ici vous voudriez utiliser un tableau pour de la mise en page.

Bonjour Raphel,

Raphael a écrit :

D'où tiens-tu cette valeur de 16px ?

En fait, j'ai simplement regarder sur mes différents navigateurs de mes différents OS

Raphael a écrit :

En fait, par défaut, les valeurs sont censées être fluides en "em" selon la feuille de style proposée par le W3C et généralement prise en compte par les navigateurs : http://www.w3.org/TR/CSS21/sample.html

Cet article devrait te dépanner

merci pour ces liens très riches.

Au niveau du rendu et du formatage css j'utilise tripoli Connaissez vous cette feuille de style pour uniformiser les rendus ?
Modifié par P75 (11 Dec 2007 - 16:39)

P75 a écrit :

c'est pas ce que j'ai lu : Définir des raccourcis clavier

Attention aux sources vieillies en matières d'accessibilité. Les accesskeys ont révélé depuis différents problèmes, en particulier de conflits avec les racourcis clients.

P75 a écrit :

je n'utilise pas de tableau pour représenter des données non tabulaire. ici vous voudriez utiliser un tableau pour de la mise en page.

Oui. Et je vous le recommande fortement, même.

Afin d'obtenir aisément un code plus robuste, plus accessible et plus adaptable aux variations de contenu que ce que l'on peut faire actuellement via CSS.

Sinon, pour en revenir aux pixels: il est préférable de ne pas utiliser cette unité en raison des limites actuelles d'IE. C'est la politique des méthodes actuelles d'application des directives d'accessibilité WCAG (RGAA, accessiweb).

Mais, selon les contraintes graphiques par exemple, cette recommandation est aussi à mettre en balance avec l'apparition du zoom graphique dans IE7 et avec la possibilité pour l'utilisateur de désactiver la prise en compte des tailles de polices.

Laurent Denis a écrit :

Attention aux sources vieillies en matières d'accessibilité. Les accesskeys ont révélé depuis différents problèmes, en particulier de conflits avec les racourcis clients.

Merci je ne le savais pas.

Laurent Denis a écrit :

Sinon, pour en revenir aux pixels: il est préférable de ne pas utiliser cette unité en raison des limites actuelles d'IE. C'est la politique des méthodes actuelles d'application des directives d'accessibilité WCAG (RGAA, accessiweb).

Mais, selon les contraintes graphiques par exemple, cette recommandation est aussi à mettre en balance avec l'apparition du zoom graphique dans IE7 et avec la possibilité pour l'utilisateur de désactiver la prise en compte des tailles de polices.

En fait c'est préférable selon les diverses directives d'accessibilité uniquement à cause des limites d'IE.

Donc, avec la future démocratisation d'IE7, si j'ai des contraintes graphiques, je peux utiliser les PX ?

Bonjour,

Pour appuyer les remarques de Laurent :

Accessiweb interdis l'utilisation des pixels pour définir les tailles de polices de caractères :
Fiche 10.4 : Des valeurs relatives sont-elles utilisées pour dimensionner les tableaux et définir la taille des polices de caractère ?

RGAA autorise l'utilisation des pixels mais recommande de les éviter : Point de contrôle : 3.4 Utiliser des unités relatives pour la présentation

La problématique lié à IE est difficile : Par défaut IE ne redimensionne pas les tailles de polices de caractères, mais l'utilisateur peut désactiver ce comportement par défaut (options -> outils ->accessibilité -> ignorer les tailles de police).

En réalité cette option affecte la taille de police par défaut spécifié par l'utilisateur sur son poste, ce qui a souvent pour effet premier de rendre le contenu illisible .
en revanche cela permet effectivement d'utiliser les ridicules (parce que très limitées) options de modification de la taille de police (affichage->taille du texte)

Le problème c'est que le public qui à besoin d'agrandir la taille de police est très large, ce n'est pas spécifique à un "handicap", cela touche tout le monde après un certain age.

Or une immense majorité de ce public va totalement ignorer cette option d'accessibilité et se contenter de constater que l'agrandissement de la taille des polices est inopérant.

C'est la raison pour laquelle Accessiweb notamment interdis purement et simplement l'utilisation du pixels pour les tailles de caractères.

Ce qui, de mon point de vue, est une décision raisonnable eu égard au public concerné.

Par ailleurs l'utilisation de police en pixel ne change pas l'objectif de conserver la lisibilité des contenus.

Si tu a des soucis à utiliser em ou % le problème est certainement dans la manière dont tu gère les dimensions des éléments de ton design.

Si il y à des soucis à ce niveau là, l'utilisation de taille de police en pixels n'y changera rien : ça tiendras sur ton design à sa taille originale mais tu vas générer des problèmes de lisibilité dés qu'on tentera d'agrandir les tailles de police.

Et donc tu resteras inaccessible.

Ce qui me fait dire, mais c'est un avis très personnel, qu'il est beaucoup plus productif, rationnel et efficace d'utiliser em ou %, même si cela demande une plus grande maitrise dans la gestion des dimensionnements CSS

En attendant que tu acquiert cette maitrise de CSS indispensable pour l'accessibilité des contenus, je suis comme Laurent : aucun soucis moral à utiliser un tableau de mise en forme en respectant scrupuleusement ces contraintes :
- ne pas les imbriquer
- vérifier que la linéarisation est correcte.

P75 a écrit :


Donc, avec la future démocratisation d'IE7, si j'ai des contraintes graphiques, je peux utiliser les PX ?

Le Zoom graphique d'IE ne milite toujours pas pour privilégier l'utilisation de pixel pour définir la taille des polices.

Certes cela permet d'agrandir l'image de la page mais, en revanche, cela oblige à utiliser les deux ascenceurs pour naviguer sur la page ce qui complique, de nouveau, l'utilisation pour certaines catégories d'utilisateur.

Jean-Pierre
Modifié par jpv (11 Dec 2007 - 19:06)

Humpf... Je peux être agaçant ?

jpv a écrit :
RGAA autorise l'utilisation des pixels mais recommande de les éviter : Point de contrôle : 3.4 Utiliser des unités relatives pour la présentation

Pas tout à fait. L'usage des pixels est autorisé les premiers temps lors d'une prise en compte sur 3 ans du RGAA, mais proscrit au final (Année N+2). Donc, pas de pixels.

jpv a écrit :

En réalité cette option affecte la taille de police par défaut spécifié par l'utilisateur sur son poste, ce qui a souvent pour effet premier de rendre le contenu illisible .

ça, c'est un coup bas, mais en effet, oui

jpv a écrit :

en revanche cela permet effectivement d'utiliser les ridicules (parce que très limitées) options de modification de la taille de police (affichage->taille du texte)

Hum... Pas ridicule, et justement limité. Au-delà, l'agrandissement est du ressort du zoom graphique et de l'adaptation de la présentation ALA Opera ou des aides techniques (Zoom text). Il est illusoire de demander des designs supportant un facteur d'agrandissement au-delà de 150% (valeur empiriquement constatée, mais je dirais moins a priori). CSS ne tient pas, dans ce domaine, des promesses qu'elle n'a en fait jamais faite.

jpv a écrit :

Le problème c'est que le public qui à besoin d'agrandir la taille de police est très large, ce n'est pas spécifique à un "handicap", cela touche tout le monde après un certain age.

Or une immense majorité de ce public va totalement ignorer cette option d'accessibilité et se contenter de constater que l'agrandissement de la taille des polices est inopérant.

+1. Il y a un choix à faire, très difficile, entre l'accessibilité "de terrain du Web de maintenant" qui est parfois un frein à l'accessibilité sur le fond, mais qui donne des résultats immédiats, et l'intégration de l'accessibilité dans le Web, qui est le but à atteindre.

jpv a écrit :

C'est la raison pour laquelle Accessiweb notamment interdis purement et simplement l'utilisation du pixels pour les tailles de caractères.

Ce qui, de mon point de vue, est une décision raisonnable eu égard au public concerné.

Point de vue partagé hormis la question philosophique précédente. Réserve également valable pour le RGAA, évidemment.

jpv a écrit :

Si tu a des soucis à utiliser em ou % le problème est certainement dans la manière dont tu gère les dimensions des éléments de ton design.

Charte graphique à revoir, en effet. cela apparaît de plus en plus comme un problème majeur : le design accessible (au sens pauvre du mot design).

jpv a écrit :

Si il y à des soucis à ce niveau là, l'utilisation de taille de police en pixels n'y changera rien : ça tiendras sur ton design à sa taille originale mais tu vas générer des problèmes de lisibilité dés qu'on tentera d'agrandir les tailles de police.

+1, il suffit d'être dans Firefox.

jpv a écrit :

Et donc tu resteras inaccessible.

Retour aux questions philosophiques: oui, mais non. Il suffit de désactiver la CSS du site. Le fait de pouvoir la désactiver n'est jamais que la première illustration de la principale raison d'être des CSS en matière d'accessibilité: leur caractère désactivable et optionnel, fournissant ainsi une solution inébranlable en cas de problème majeur

Mais en fait, non mais oui: on sait que 99.99% des pages Web accessibles sont en fait à chier quand elles sont affichées sans CSS. Pas la faute aux développeurs, la faute à HTML, qui n'a jamais été conçu pour faire des interfaces.

Pour ma part, j'ignore toujours si on est accessible dans ce cas de figure. Il y a un point où l'aveu d'impuissance du HTML doit quand même être pris en compte. Cette notion de "contenu linéaire" lié au fondement plat du HTML, à l'absence de possibilité de définir un interface exploitable par l'UA, ça devient pesant.

jpv a écrit :

Ce qui me fait dire, mais c'est un avis très personnel, qu'il est beaucoup plus productif, rationnel et efficace d'utiliser em ou %, même si cela demande une plus grande maitrise dans la gestion des dimensionnements CSS

Sous réserve d'une charte graphique pas imbécile, oui, +1.

jpv a écrit :

Certes cela permet d'agrandir l'image de la page mais, en revanche, cela oblige à utiliser les deux ascenceurs pour naviguer sur la page ce qui complique, de nouveau, l'utilisation pour certaines catégories d'utilisateur.

Jean-Pierre

Tiens, encore un truc fondamentalement inconfortable, mais foncièrement accessible, le scroll du navigateur. Mais bon, j'ai assez trollé comme cela
Modifié par Laurent Denis (11 Dec 2007 - 19:49)

jpv a écrit :
En attendant que tu acquiert cette maitrise de CSS indispensable pour l'accessibilité des contenus, je suis comme Laurent : aucun soucis moral à utiliser un tableau de mise en forme en respectant scrupuleusement ces contraintes :
- ne pas les imbriquer
- vérifier que la linéarisation est correcte.

J'oubliais un +10, notamment pour la mise en gras. 10 ans après, et sans le savoir, Zeldman n'est pas mort, loin de là

Bonjour,

a écrit :
Humpf... Je peux être agaçant ?

Pas le temps là tout de suite mais oui, plus t'es agaçant plus je muscle mes neurones, c'est un bon deal...

Jean-Pierre

P75 a écrit :
En fait c'est préférable selon les diverses directives d'accessibilité uniquement à cause des limites d'IE.

Ça n'est pas l'unique raison. Utiliser les EM ou pourcentages permet d'avoir un rendu graphique qui dépendra de la taille de base définie par le système, le navigateur ou l'utilisateur.

À l'heure actuelle, cette taille est de 16px pour la plupart des configurations. Mais on remarque que la tendance va vers des écrans capables d'afficher un plus grand nombre de pixels sur des surfaces réduites (ou du moins pas agrandies). Cela signifie qu'un texte en Arial 12px sera lisible (pour un utilisateur de moins de cinquante ans, n'ayant pas de problème sérieux de vue) sur un écran 17 pouces en 1024x768... mais si on passe à du 1280x1024 sur un écran semblable, c'est déjà moins le cas. Sur les écrans de portables, ça s'accentue encore. Enfin, certains terminaux mobiles ont une résolution assez élevée pour une dimension (en centimètres) faible.

L'intérêt d'utiliser les EM ou les pourcentages serait donc de pouvoir demander «je veux du texte à 150% ou à 75% de la taille de texte "optimale" pour ce périphérique», et de laisser le périphérique en question, ou le système, ou encore l'utilisateur, déterminer cette taille «optimale».
Bien entendu, il n'est pas dit que ça marche parfaitement dans la pratique, ou que les logiciels ou systèmes d'exploitation ne cherchent pas à régler la question par d'autres moyens (le zoom homothétique dans Opera, IE7, Firefox 3, et Mobile Safari...).

Laurent Denis a écrit :

Pas tout à fait. L'usage des pixels est autorisé les premiers temps lors d'une prise en compte sur 3 ans du RGAA, mais proscrit au final (Année N+2). Donc, pas de pixels.

Oui j'ai mal lu en effet.
Juste une remarque : Dans le cadre de la philosophie "amélioration progressive" c'est, finalement, très étrange cette progression vers l'interdiction eu égard aux difficultés de passer des pixels aux em/%.
Souvent, pour ne pas dire toujours, cela nécessite de refaire, je trouve ça casse-gueule...

Laurent Denis a écrit :

Hum... Pas ridicule, et justement limité. Au-delà, l'agrandissement est du ressort du zoom graphique et de l'adaptation de la présentation ALA Opera ou des aides techniques (Zoom text). Il est illusoire de demander des designs supportant un facteur d'agrandissement au-delà de 150% (valeur empiriquement constatée, mais je dirais moins a priori). CSS ne tient pas, dans ce domaine, des promesses qu'elle n'a en fait jamais faite.

Le seuil de 150% que tu cites à juste titre comme valeur "empirique" est très insuffisant pour ma grand-mère qui à déjà eu du mal à comprendre comment agrandir les textes, a du mal à manipuler le scrolling et ne rentre pas "encore" dans la catégorie "aide technique".

Plus sérieusement, je suis assez d'accord sur le fait de devoir considérer le moment où un mode de consultation ne relève plus d'une situation habituelle mais d'un outillage.

A la réserve près que c'est un argument très délicat à manier en l'absence de référence objective.

De mon point de vue c'est plutôt l'absence de gestion de cette contrainte dans le projet, notamment en phase de conception, associé à une montée en compétence CSS insuffisante, qui en sont la cause.

Je ne suis pas d'accord pour présenter ce seuil comme "justement limité", je préfère nettement "minimum à garantir" ça me parait plus productif

Laurent Denis a écrit :

+1. Il y a un choix à faire, très difficile, entre l'accessibilité "de terrain du Web de maintenant" qui est parfois un frein à l'accessibilité sur le fond, mais qui donne des résultats immédiats, et l'intégration de l'accessibilité dans le Web, qui est le but à atteindre.

Oui à la condition qu'on ne fasse pas du pragmatisme "humanitaire", qu'on ne confonde pas "faire au mieux" et "faute de mieux" et qu'enfin on intègre que le handicap est perçus comme un problème à évacuer.

Autrement dit, le danger d'une approche trop pragmatique est de laisser croire à un client que les "résultats immédiats" sont suffisants, voire suffisamment efficaces.

C'est ce que j'appellerais le syndrôme des supermarchés dont les parkings sont pleins de place handicapés qui donnent accès à des entrées monumentales qui donnent accès à des rayons recomposés (toute la gamme produit accessible à hauteur de fauteuil) et qui donnent accès à des couloirs de caisse trop étroits car personne n'a exigé de disposer au moins d'une caisse adaptée.

Résultat : "résultat immédiat" et 10 ans après vous ne voyez toujours pas de handicapés faire leurs courses dans les hypermarchés.

Il y à une vertu à l'exigence c'est qu'elle maintient l'objectif vivant.

Pour le reste notamment les conditions d'applications de ces exigences c'est tout autre chose...

Laurent Denis a écrit :

Cette notion de "contenu linéaire" lié au fondement plat du HTML, à l'absence de possibilité de définir un interface exploitable par l'UA, ça devient pesant.

Tu veux parler du drame historique de relancer html ?

Non je plaisante, ce n'est pas un drame... c'est une fatalité

Laurent Denis a écrit :

Tiens, encore un truc fondamentalement inconfortable, mais foncièrement accessible, le scroll du navigateur.

Un scroll oui
Deux scrolls successif : pour moi on est clairement, en tout cas pour certains utilisateurs, au delà de la limite d'un contenu accessible et inutilisable.

Ce qui est très en vogue par les temps qui courts, une sorte de dommage collatéral à la démocratisation de ces thèmes...

<blague imbécile>Heu... oops, je voulais dire une conséquence des contraintes d'industrialisation...</blague>

troll toujours

Jean-Pierre
Modifié par jpv (12 Dec 2007 - 15:24)

En forme, à ce que je vois

jpv a écrit :

Juste une remarque : Dans le cadre de la philosophie "amélioration progressive" c'est, finalement, très étrange cette progression vers l'interdiction eu égard aux difficultés de passer des pixels aux em/%.
Souvent, pour ne pas dire toujours, cela nécessite de refaire, je trouve ça casse-gueule...

Oui. Mais il fallait gérer à la fois les refontes et les créations, le tout en tenant compte des trois ans potentiels. Autant le "no pixel Now" aurait été pertinent pour les créations, autant il était inenvisageable pour les refontes. D'où cette cote en effet mal taillée.

jpv a écrit :
Je ne suis pas d'accord pour présenter ce seuil comme "justement limité", je préfère nettement "minimum à garantir" ça me parait plus productif

D'accord pour la sémantique syndicale

(sur le fond, tu as tout à fait raison, en effet, c'est bien un minimum à atteindre, mea culpa, même s'il faut bien que les UA puissent trancher abruptement comme le fait IE).

jpv a écrit :

Oui à la condition qu'on ne fasse pas du pragmatisme "humanitaire", qu'on ne confonde pas "faire au mieux" et "faute de mieux" et qu'enfin on intègre que le handicap est perçus comme un problème à évacuer.

SNIP

La différence avec ton exemple, c'est que les caisses ne dépendent pas de leur propre norme d'accessibilité. Dans le cas des contenus Web, je voudrais, dans la famille "nowhere", 1) une UAAG actualisée et 2) des UA respectueux d'UAAG... ce qui signifie dans ce cas concret zoom graphique et ERA ALA Opera chez tout le monde. Plop.

Pour l'instant, on reporte l'insuffisance de deux des pieds du tripode ATAG WCAG UAAG uniquement sur les producteurs du contenu. C'est en tous cas de cette manière que je délimiterais précisément le problème du pragmatisme, pour ma part. Sans préjudice d'un ou deux autres appendices mutationnels (ARIA).

Me gourge ?

jpv a écrit :


Tu veux parler du drame historique de relancer html ?

tu sors.

(je suis devant, je te tiens la porte)

jpv a écrit :


Un scroll oui
Deux scrolls successif : pour moi on est clairement, en tout cas pour certains utilisateurs, au delà de la limite d'un contenu accessible et inutilisable.

Ce qui est très en vogue par les temps qui courts, une sorte de dommage collatéral à la démocratisation de ces thèmes...

Hum... Très en vogue, oui (c'est curieux, d'ailleurs). Mais au delà de la limite, je ne sais pas : quand je jongle avec Zoomtext ou des outils de loupe ou de projection équivalents, la différence ne me semble pas vraiment sensible. Me gourgerais-je encore ?

jpv a écrit :

<blague imbécile>Heu... oops, je voulais dire une conséquence des contraintes d'industrialisation...</blague>

On a pensé à fermer la porte en sortant t'aleur ?

Bonsoir,

Je suis entrain de "convertir" mon site en police et position relative avec des em et je dois dire, comme le précise Raphel dans son tutorial, je m'arrache les cheveux avec des caculs savants quand j'ai des cascade css !

@ P75

Tout d'abord excuse nous d'avoir dérivé ton sujet de nos éculubrations mais c'est pour la bonne cause.

Pour en revenir à ton sujet :

Il est très difficile de migrer un design à taille fixe vers un design hybride.

Si je peux te donner un conseil, le plus simple, et c'est vraiment le plus simple, est de repartir de la page blanche.

Tu auras peut-être des compromis à faire sur ton design original mais tu verras que tu gèreras les problèmes plus facilement.

Si tu est face à l'obligation de calcul savant c'est probablement que tu tentes de faire tenir du texte dans une structure générale qui n'est pas faite pour ça.

Surtout ne te décourage pas, vas-y doucement et n'hésite pas à demander, exemple à l'appui, tu à ici des gars très doués, très gentils et très disponibles (pas comme moi mais en ce moment je respire plus )

Jean-Pierre

jpv a écrit :

Tout d'abord excuse nous d'avoir dérivé ton sujet de nos éculubrations mais c'est pour la bonne cause.

Aucun problème ces dérives sont apporteuses de savoir

A cause des contraintes actuelles je ne peux partir de la page blanche ... je prend donc mon courage à deux mains

Quelqu'un pourrait m'expliquer les cascades de css pour les em ? Comment cela fonctionne comment et quand sont-elles ajoutées ou multipliées ?

Edit En fait je viens de comprendre le systeme des em avec des div imbriqué

Sachant que je dois convertir tous mes font-size je vais faire une feuille de style à part pour y voir plus clair
Modifié par P75 (13 Dec 2007 - 00:23)

P75 a écrit :
Quelqu'un pourrait m'expliquer les cascades de css pour les em ? Comment cela fonctionne comment sont-elles ajoutées ou multipliées ?

Vois ça avec des pourcentages si c'est l'unité em qui te perturbe, le principe est exactement pareil. Ce principe est simple dès lors que tu intègres le fait que la taille de référence d'un élément correspond à celle de son parent.
Autrement dit, si un paragraphe p se trouve dans une division div pour laquelle nous avons spécifié une taille de caractères de 90%, mon élément p aura pour base cette dernière valeur. Dans ce cas, une taille de police de 80% pour p vaudra 80% des 90% de ta division.

P75 a écrit :

Edit En fait je viens de comprendre le systeme des em avec des div imbriqué

Ah bon ben… tant mieux alors!