[publipostage sur f.c.i.w.auteurs et f.c.i.w.navigateurs, suivi sur
f.c.i.w.auteurs]
Bonjour,
Nous découvrons aujourd'hui dans mon entreprise des pages où du texte
n'est plus visible dans Fx3. Après investigation, il s'avère que c'est
la propriété CSS color:transparent; qui en est la cause. Cette propriété
n'est pas appliquée dans IE 6 et 7, ainsi que Fx 2.
En cherchant un peu je suis tombé sur ce billet :
http://www.squarefree.com/2008/07/18/transparent/
Qui indique que le prb se produit aussi sur Safari, et que plusieurs
bugs sont saisis dans le Bugzilla de Firefox.
Cette décision de supporter color:transparent; m'a surpris car en lisant
la recommandation CSS 2.1 on voit bien que le mot clé transparent ne
s'applique qu'à background-color et border-color, et pas du tout à color :
http://www.w3.org/TR/CSS21/propidx.html
Et puis... tombé là-dessus :
http://www.css3.info/let-the-css-wg-know-what-you-need-from-css3/#comment-95634
Et j'ai pu constater en effet dans la recommandation CSS3 que
transparent est maintenant autorisé sur color :
http://www.w3.org/TR/2008/WD-css3-color-20080721/#transparent
Et là je me pose la question : vu qu'il y a une différence entre la
recommandation CSS 2.1 et la 3, comment faire en sorte que la css que
l'on spécifie soit lue en suivant les spécifications de telle ou telle
version de la recommandation ??
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SAM
Le 10/2/08 11:55 AM, Pierre Goiffon a écrit :
[publipostage sur f.c.i.w.auteurs et f.c.i.w.navigateurs, suivi sur f.c.i.w.auteurs]
Bonjour,
Nous découvrons aujourd'hui dans mon entreprise des pages où du texte n'est plus visible dans Fx3. Après investigation, il s'avère que c'est la propriété CSS color:transparent; qui en est la cause. Cette propriété n'est pas appliquée dans IE 6 et 7, ainsi que Fx 2.
Ça c'est vraiment une drôle d'idée quand on sait que naguère cette propriété était sans effet, et pour cause : puisque non prévue.
à quoi pensaient les membres de ton entreprise quand ils ont créé ces pages ?
Et là je me pose la question : vu qu'il y a une différence entre la recommandation CSS 2.1 et la 3, comment faire en sorte que la css que l'on spécifie soit lue en suivant les spécifications de telle ou telle version de la recommandation ??
Là ça change pas beaucoup : - avant on n'avait pas color: transparent; et donc on ne l'utilisait pas, on faisait fond = color = orange par ex - aujourd'hui on peut tenter la transparence du texte (si le navigateur le supporte) et ça ne pose pas plus de problème, si ce n'est que si ce n'est pas supporté par le navigateur le texte sera noir (ou hérité ?)
et si le fond n'est pas une image on fait à l'ancienne, voilà tout.
Et d'abord : pourquoi cacher le texte, et pas simplement son conteneur ?
-- sm
Le 10/2/08 11:55 AM, Pierre Goiffon a écrit :
[publipostage sur f.c.i.w.auteurs et f.c.i.w.navigateurs, suivi sur
f.c.i.w.auteurs]
Bonjour,
Nous découvrons aujourd'hui dans mon entreprise des pages où du texte
n'est plus visible dans Fx3. Après investigation, il s'avère que c'est
la propriété CSS color:transparent; qui en est la cause. Cette propriété
n'est pas appliquée dans IE 6 et 7, ainsi que Fx 2.
Ça c'est vraiment une drôle d'idée quand on sait que naguère cette
propriété était sans effet, et pour cause : puisque non prévue.
à quoi pensaient les membres de ton entreprise quand ils ont créé ces
pages ?
Et là je me pose la question : vu qu'il y a une différence entre la
recommandation CSS 2.1 et la 3, comment faire en sorte que la css que
l'on spécifie soit lue en suivant les spécifications de telle ou telle
version de la recommandation ??
Là ça change pas beaucoup :
- avant on n'avait pas color: transparent;
et donc on ne l'utilisait pas, on faisait fond = color = orange par ex
- aujourd'hui on peut tenter la transparence du texte
(si le navigateur le supporte)
et ça ne pose pas plus de problème, si ce n'est que si ce n'est pas
supporté par le navigateur le texte sera noir (ou hérité ?)
et si le fond n'est pas une image on fait à l'ancienne, voilà tout.
Et d'abord : pourquoi cacher le texte, et pas simplement son conteneur ?
[publipostage sur f.c.i.w.auteurs et f.c.i.w.navigateurs, suivi sur f.c.i.w.auteurs]
Bonjour,
Nous découvrons aujourd'hui dans mon entreprise des pages où du texte n'est plus visible dans Fx3. Après investigation, il s'avère que c'est la propriété CSS color:transparent; qui en est la cause. Cette propriété n'est pas appliquée dans IE 6 et 7, ainsi que Fx 2.
Ça c'est vraiment une drôle d'idée quand on sait que naguère cette propriété était sans effet, et pour cause : puisque non prévue.
à quoi pensaient les membres de ton entreprise quand ils ont créé ces pages ?
Et là je me pose la question : vu qu'il y a une différence entre la recommandation CSS 2.1 et la 3, comment faire en sorte que la css que l'on spécifie soit lue en suivant les spécifications de telle ou telle version de la recommandation ??
Là ça change pas beaucoup : - avant on n'avait pas color: transparent; et donc on ne l'utilisait pas, on faisait fond = color = orange par ex - aujourd'hui on peut tenter la transparence du texte (si le navigateur le supporte) et ça ne pose pas plus de problème, si ce n'est que si ce n'est pas supporté par le navigateur le texte sera noir (ou hérité ?)
et si le fond n'est pas une image on fait à l'ancienne, voilà tout.
Et d'abord : pourquoi cacher le texte, et pas simplement son conteneur ?
-- sm
Pierre Goiffon
SAM wrote:
Nous découvrons aujourd'hui dans mon entreprise des pages où du texte n'est plus visible dans Fx3. Après investigation, il s'avère que c'est la propriété CSS color:transparent; qui en est la cause.
Ça c'est vraiment une drôle d'idée quand on sait que naguère cette propriété était sans effet, et pour cause : puisque non prévue.
à quoi pensaient les membres de ton entreprise quand ils ont créé ces pages ?
Les styles en question sont générés par un outil wysiwyg développé en interne. La valeur "transparent" est dans la palette de couleur et aucun contrôle ne permet d'empêcher de la sélectionner pour une couleur de texte. Un oubli lors de la conception de l'outil...
Et d'abord : pourquoi cacher le texte, et pas simplement son conteneur ?
Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués). Aujourd'hui on est contraint à ce genre d'acrobaties : <http://www.robertnyman.com/2008/05/13/how-to-hide-and-show-initial-content-depending-on-whether-javascript-support-is-available/>
SAM wrote:
Nous découvrons aujourd'hui dans mon entreprise des pages où du texte
n'est plus visible dans Fx3. Après investigation, il s'avère que c'est
la propriété CSS color:transparent; qui en est la cause.
Ça c'est vraiment une drôle d'idée quand on sait que naguère cette
propriété était sans effet, et pour cause : puisque non prévue.
à quoi pensaient les membres de ton entreprise quand ils ont créé ces
pages ?
Les styles en question sont générés par un outil wysiwyg développé en
interne. La valeur "transparent" est dans la palette de couleur et aucun
contrôle ne permet d'empêcher de la sélectionner pour une couleur de
texte. Un oubli lors de la conception de l'outil...
Et d'abord : pourquoi cacher le texte, et pas simplement son conteneur ?
Je me pose aussi vraiment la question de l'utilité de ce changement ? Le
seul usage que je vois est assez négatif : feinter pour le référencement...
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les
contenus à afficher dynamiquement (tout doit être présent dans le html
mais certains éléments doivent par défaut être masqués).
Aujourd'hui on est contraint à ce genre d'acrobaties :
<http://www.robertnyman.com/2008/05/13/how-to-hide-and-show-initial-content-depending-on-whether-javascript-support-is-available/>
Nous découvrons aujourd'hui dans mon entreprise des pages où du texte n'est plus visible dans Fx3. Après investigation, il s'avère que c'est la propriété CSS color:transparent; qui en est la cause.
Ça c'est vraiment une drôle d'idée quand on sait que naguère cette propriété était sans effet, et pour cause : puisque non prévue.
à quoi pensaient les membres de ton entreprise quand ils ont créé ces pages ?
Les styles en question sont générés par un outil wysiwyg développé en interne. La valeur "transparent" est dans la palette de couleur et aucun contrôle ne permet d'empêcher de la sélectionner pour une couleur de texte. Un oubli lors de la conception de l'outil...
Et d'abord : pourquoi cacher le texte, et pas simplement son conteneur ?
Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués). Aujourd'hui on est contraint à ce genre d'acrobaties : <http://www.robertnyman.com/2008/05/13/how-to-hide-and-show-initial-content-depending-on-whether-javascript-support-is-available/>
Jean-Marc Desperrier
Pierre Goiffon a écrit :
[publipostage sur f.c.i.w.auteurs et f.c.i.w.navigateurs, suivi sur f.c.i.w.auteurs] [...] En cherchant un peu je suis tombé sur ce billet : http://www.squarefree.com/2008/07/18/transparent/ Qui indique que le prb se produit aussi sur Safari, et que plusieurs bugs sont saisis dans le Bugzilla de Firefox.
[...] Et là je me pose la question : vu qu'il y a une différence entre la recommandation CSS 2.1 et la 3, comment faire en sorte que la css que l'on spécifie soit lue en suivant les spécifications de telle ou telle version de la recommandation ??
Si tu as lu le lien du dessus, il est marqué que la présence de cet attribut dans ce pages est "due to a Microsoft FrontPage bug."
En effet, il n'y avait aucune raison avant de placer cette attribut puisqu'il ne faisait *rien*.
Le correctif est de retirer l'attribut, sa présence en CSS 2.1 était invalide puisque la propriété en question n'existait pas sur cet élément.
Pierre Goiffon a écrit :
[publipostage sur f.c.i.w.auteurs et f.c.i.w.navigateurs, suivi sur
f.c.i.w.auteurs]
[...]
En cherchant un peu je suis tombé sur ce billet :
http://www.squarefree.com/2008/07/18/transparent/
Qui indique que le prb se produit aussi sur Safari, et que plusieurs
bugs sont saisis dans le Bugzilla de Firefox.
[...]
Et là je me pose la question : vu qu'il y a une différence entre la
recommandation CSS 2.1 et la 3, comment faire en sorte que la css que
l'on spécifie soit lue en suivant les spécifications de telle ou telle
version de la recommandation ??
Si tu as lu le lien du dessus, il est marqué que la présence de cet
attribut dans ce pages est "due to a Microsoft FrontPage bug."
En effet, il n'y avait aucune raison avant de placer cette attribut
puisqu'il ne faisait *rien*.
Le correctif est de retirer l'attribut, sa présence en CSS 2.1 était
invalide puisque la propriété en question n'existait pas sur cet élément.
[publipostage sur f.c.i.w.auteurs et f.c.i.w.navigateurs, suivi sur f.c.i.w.auteurs] [...] En cherchant un peu je suis tombé sur ce billet : http://www.squarefree.com/2008/07/18/transparent/ Qui indique que le prb se produit aussi sur Safari, et que plusieurs bugs sont saisis dans le Bugzilla de Firefox.
[...] Et là je me pose la question : vu qu'il y a une différence entre la recommandation CSS 2.1 et la 3, comment faire en sorte que la css que l'on spécifie soit lue en suivant les spécifications de telle ou telle version de la recommandation ??
Si tu as lu le lien du dessus, il est marqué que la présence de cet attribut dans ce pages est "due to a Microsoft FrontPage bug."
En effet, il n'y avait aucune raison avant de placer cette attribut puisqu'il ne faisait *rien*.
Le correctif est de retirer l'attribut, sa présence en CSS 2.1 était invalide puisque la propriété en question n'existait pas sur cet élément.
Jean-Marc Desperrier
Pierre Goiffon a écrit :
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
Le lien que tu as donnée sur le site W3C en donne un autre:
I have a link on my website that goes to the main page of the site. It’s just an ordinary <a></a> tag with the text “Home”. With CSS I changed it to my logo (with background-image), but I am not able to hide the text (”display: none;” on the <a></a> removes the entire link). I don’t want to use an tag for this, because I use other style sheets without the logo - and as you know, separate content from style!
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
Pierre Goiffon a écrit :
[....]
Je me pose aussi vraiment la question de l'utilité de ce changement ? Le
seul usage que je vois est assez négatif : feinter pour le référencement...
Le lien que tu as donnée sur le site W3C en donne un autre:
I have a link on my website that goes to the main page of the site. It’s
just an ordinary <a></a> tag with the text “Home”. With CSS I changed it
to my logo (with background-image), but I am not able to hide the text
(”display: none;” on the <a></a> removes the entire link). I don’t want
to use an tag for this, because I use other style sheets without the
logo - and as you know, separate content from style!
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus
à afficher dynamiquement (tout doit être présent dans le html mais certains éléments
doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
Le lien que tu as donnée sur le site W3C en donne un autre:
I have a link on my website that goes to the main page of the site. It’s just an ordinary <a></a> tag with the text “Home”. With CSS I changed it to my logo (with background-image), but I am not able to hide the text (”display: none;” on the <a></a> removes the entire link). I don’t want to use an tag for this, because I use other style sheets without the logo - and as you know, separate content from style!
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
Bruno Desthuilliers
Jean-Marc Desperrier a écrit :
Pierre Goiffon a écrit :
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none. La solution que je connais consiste à déplacer le contenu hors du viewport, avec un positionnement absolu ou relatif et des coordonnées top/left négative (genre -5000).
Jean-Marc Desperrier a écrit :
Pierre Goiffon a écrit :
[....]
Je me pose aussi vraiment la question de l'utilité de ce changement ? Le
seul usage que je vois est assez négatif : feinter pour le
référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur
les contenus
à afficher dynamiquement (tout doit être présent dans le html mais
certains éléments
doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments
avec display:none. La solution que je connais consiste à déplacer le
contenu hors du viewport, avec un positionnement absolu ou relatif et
des coordonnées top/left négative (genre -5000).
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none. La solution que je connais consiste à déplacer le contenu hors du viewport, avec un positionnement absolu ou relatif et des coordonnées top/left négative (genre -5000).
Jean-Marc Desperrier
Bruno Desthuilliers wrote:
Jean-Marc Desperrier a écrit :
Pierre Goiffon a écrit :
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none.
Ignorent dans quel sens ? Les traitent comme si il n'y avait pas le display:none, ou bien ne le lisent pas ?
Dans le cas considéré, il me semble que les éléments qui sont masqués en mode par défaut ne doivent pas être lus, puisque l'intention de la conception du site est qu'ils ne soient pas accessibles à ce moment là, et qu'ils soient lus au moment où le js les active.
Mais si le lecteur ne traite pas le js, il vaut peut-être mieux qu'ils soient lus tout le temps.
La solution que je connais consiste à déplacer le contenu hors du viewport, avec un positionnement absolu ou relatif et des coordonnées top/left négative (genre -5000).
Bruno Desthuilliers wrote:
Jean-Marc Desperrier a écrit :
Pierre Goiffon a écrit :
[....]
Je me pose aussi vraiment la question de l'utilité de ce changement ? Le
seul usage que je vois est assez négatif : feinter pour le
référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur
les contenus
à afficher dynamiquement (tout doit être présent dans le html mais
certains éléments
doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments
avec display:none.
Ignorent dans quel sens ? Les traitent comme si il n'y avait pas le
display:none, ou bien ne le lisent pas ?
Dans le cas considéré, il me semble que les éléments qui sont masqués en
mode par défaut ne doivent pas être lus, puisque l'intention de la
conception du site est qu'ils ne soient pas accessibles à ce moment là,
et qu'ils soient lus au moment où le js les active.
Mais si le lecteur ne traite pas le js, il vaut peut-être mieux qu'ils
soient lus tout le temps.
La solution que je connais consiste à déplacer le
contenu hors du viewport, avec un positionnement absolu ou relatif et
des coordonnées top/left négative (genre -5000).
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none.
Ignorent dans quel sens ? Les traitent comme si il n'y avait pas le display:none, ou bien ne le lisent pas ?
Dans le cas considéré, il me semble que les éléments qui sont masqués en mode par défaut ne doivent pas être lus, puisque l'intention de la conception du site est qu'ils ne soient pas accessibles à ce moment là, et qu'ils soient lus au moment où le js les active.
Mais si le lecteur ne traite pas le js, il vaut peut-être mieux qu'ils soient lus tout le temps.
La solution que je connais consiste à déplacer le contenu hors du viewport, avec un positionnement absolu ou relatif et des coordonnées top/left négative (genre -5000).
Pierre Goiffon
Bruno Desthuilliers wrote:
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none. La solution que je connais consiste à déplacer le contenu hors du viewport, avec un positionnement absolu ou relatif et des coordonnées top/left négative (genre -5000).
Oui, c'est aussi ce que j'ai entendu dire et lu, par exemple ici : http://blog.alsacreations.com/2006/01/29/220-remplacement-dimages-halte-au-display-none
Bruno Desthuilliers wrote:
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur
les contenus
à afficher dynamiquement (tout doit être présent dans le html mais
certains éléments
doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments
avec display:none. La solution que je connais consiste à déplacer le
contenu hors du viewport, avec un positionnement absolu ou relatif et
des coordonnées top/left négative (genre -5000).
Oui, c'est aussi ce que j'ai entendu dire et lu, par exemple ici :
http://blog.alsacreations.com/2006/01/29/220-remplacement-dimages-halte-au-display-none
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none. La solution que je connais consiste à déplacer le contenu hors du viewport, avec un positionnement absolu ou relatif et des coordonnées top/left négative (genre -5000).
Oui, c'est aussi ce que j'ai entendu dire et lu, par exemple ici : http://blog.alsacreations.com/2006/01/29/220-remplacement-dimages-halte-au-display-none
Pierre Goiffon
Jean-Marc Desperrier wrote:
En effet, il n'y avait aucune raison avant de placer cette attribut puisqu'il ne faisait *rien*.
Le correctif est de retirer l'attribut, sa présence en CSS 2.1 était invalide puisque la propriété en question n'existait pas sur cet élément.
Ce n'est pas parce que ce n'était pas prévu dans la recommandation que les navigateurs n'en faisaient rien !
Et hier soir à la réflexion je me suis quasi persuadé que si l'on avait prévu ce transparent sur color c'était bien parce que l'on en avait une utilité (pas forcément sur un texte mais sur un tableau, ... ?). Il faut que je regarde plus avant, je manque de temps pour les tests aujourd'hui... à suivre
Jean-Marc Desperrier wrote:
En effet, il n'y avait aucune raison avant de placer cette attribut
puisqu'il ne faisait *rien*.
Le correctif est de retirer l'attribut, sa présence en CSS 2.1 était
invalide puisque la propriété en question n'existait pas sur cet élément.
Ce n'est pas parce que ce n'était pas prévu dans la recommandation que
les navigateurs n'en faisaient rien !
Et hier soir à la réflexion je me suis quasi persuadé que si l'on avait
prévu ce transparent sur color c'était bien parce que l'on en avait une
utilité (pas forcément sur un texte mais sur un tableau, ... ?). Il faut
que je regarde plus avant, je manque de temps pour les tests
aujourd'hui... à suivre
En effet, il n'y avait aucune raison avant de placer cette attribut puisqu'il ne faisait *rien*.
Le correctif est de retirer l'attribut, sa présence en CSS 2.1 était invalide puisque la propriété en question n'existait pas sur cet élément.
Ce n'est pas parce que ce n'était pas prévu dans la recommandation que les navigateurs n'en faisaient rien !
Et hier soir à la réflexion je me suis quasi persuadé que si l'on avait prévu ce transparent sur color c'était bien parce que l'on en avait une utilité (pas forcément sur un texte mais sur un tableau, ... ?). Il faut que je regarde plus avant, je manque de temps pour les tests aujourd'hui... à suivre
Bruno Desthuilliers
Jean-Marc Desperrier a écrit :
Bruno Desthuilliers wrote:
Jean-Marc Desperrier a écrit :
Pierre Goiffon a écrit :
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none.
Ignorent dans quel sens ? Les traitent comme si il n'y avait pas le display:none, ou bien ne le lisent pas ?
Pardon, je n'ai pas été clair en effet - "ignorent" dans le sens où ils appliquent effectivement la règle, c'est à dire ne "lisent" pas l'élément en question.
Jean-Marc Desperrier a écrit :
Bruno Desthuilliers wrote:
Jean-Marc Desperrier a écrit :
Pierre Goiffon a écrit :
[....]
Je me pose aussi vraiment la question de l'utilité de ce changement
? Le
seul usage que je vois est assez négatif : feinter pour le
référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur
les contenus
à afficher dynamiquement (tout doit être présent dans le html mais
certains éléments
doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments
avec display:none.
Ignorent dans quel sens ? Les traitent comme si il n'y avait pas le
display:none, ou bien ne le lisent pas ?
Pardon, je n'ai pas été clair en effet - "ignorent" dans le sens où ils
appliquent effectivement la règle, c'est à dire ne "lisent" pas
l'élément en question.
[....] Je me pose aussi vraiment la question de l'utilité de ce changement ? Le seul usage que je vois est assez négatif : feinter pour le référencement...
(snip)
J'imagine aussi, éventuellement, éviter les prb d'accessibilité sur les contenus à afficher dynamiquement (tout doit être présent dans le html mais certains éléments doivent par défaut être masqués).
Je pense que "display: none" est généralement plus adapté pour cela.
S'il me souvient bien, certains lecteurs d'écran ignore les éléments avec display:none.
Ignorent dans quel sens ? Les traitent comme si il n'y avait pas le display:none, ou bien ne le lisent pas ?
Pardon, je n'ai pas été clair en effet - "ignorent" dans le sens où ils appliquent effectivement la règle, c'est à dire ne "lisent" pas l'élément en question.
