Plan de site — Navigation
Blog & Blues Techniques et Standards de la Qualité Web

Accueil > weblog

- Lire le billet précédent - Lire le billet suivant -

Opera et le sélecteur d'attribut [hreflang|=foo]:after

Par Laurent Denis, le 01 janvier 2005.

En découvrant le nouveau Pompage (au design particulièrement sobre et agréable), je m'aperçois d'un petit bug d'Opera qui peut se révèle particulièrement gênant puisqu'il fait disparaître l'intitulé des liens à l'affichage. Il est heureusement aisé à corriger.

[edit] L'excellent Samuel Latchman n'a d'ailleurs pas manqué de rectifier le jour même ce petit oubli dans la feuille de style de Pompage smiley clin d'oeil A défaut du bug in situ, vous pouvez donc vous reporter à cette page de test. [/edit]

Qu'en est-il exactement ?

La syntaxe concernée combine :

Le cas le plus évident est l'insertion d'un marqueur lié à la langue-cible d'un lien, sur le modèle :

a[hreflang|="en"]:after {
content: " (en)";
}

Dans ce code :

  • [hreflang|="en"] permet de viser les éléments a ayant comme valeur d'attribut hreflang l'une ou l'autre des variantes régionales en-GB, en-US, etc. aussi bien que la valeur générique en ;
  • content: " (en)"; insère le texte souhaité après le lien.

Il s'avère qu'Opera interprète incorrectement le sélecteur |=. Celui-ci l'amène à ignorer le pseudo élément :after, et à se comporter exactement comme s'il lisait en fait :

a[hreflang|="en"] {
content: " (en)";
}

...Ce qui ne signifie plus Ecris ceci... à la suite des liens de ce type, mais hélas Ecris ceci... à la place de l'intitulé des liens de ce type. Opera replace donc l'intitulé des liens par la valeur donnée à la propriété content.

Ce problème est heureusement aisé à corriger, sans compromettre la qualité de la feuille de style. Il suffit en effet de faire suivre la règle problématique par :

a[hreflang|="en"] {
content: normal !important;
}

Pour utiliser une règle générique indifférente aux différents codes de langue, on utilisera plus simplement l'une ou l'autre des possibilités suivantes :

a[hreflang] {
content: normal !important;
}

ou

a {
content: normal !important;
}

Utilisant la valeur normal ajoutée à la propriété content par CSS2.1, ces règles rétablissent le comportement voulu en annulant le remplacement de l'intitulé des liens. Bien-sûr, la langue-cible du lien ne sera pas mentionnée par Opera, mais le visiteur n'aura pas sous les yeux un contenu tronqué.

Les utilisateurs d'Opera peuvent d'ailleurs s'en inspirer et ajouter dans leur feuille de style utilisateur browser.css une règle rectifiant ce comportement une bonne fois pour toute :

a[hreflang] {
content: normal !important;
}

(Rappelons que browser.css, située dans votre répertoire profile, s'applique systématiquement à toutes les pages affichées dans Opera et surclasse les styles par défaut du navigateur. Si vous souhaitez appliquez ce style à la volée avec vos autres préférences utilisateurs, placez cette règle dans le fichier user.css situé dans le même répertoire, ou ajoutez une feuille de style utilisateur au menu style d'Opera.)

Enfin, pour conclure sur ce bug, signalons deux autres solutions possibles côté auteurs :

  • N'utiliser que le sélecteur [hreflang="en"]. Celui-ci est en effet parfaitement supporté par Opera... et conviendra parfaitement si votre contenu (X)HTML s'en tient aux codes de langue simples (hreflang="en") sans précision régionale...
  • Dans le cas contraire, utiliser un sélecteur CSS3 (supporté par les navigateurs Gecko) tel que [hreflang^="en"] ou [hreflang*="en"] à la place de [hreflang|="en"]. Ils seront ignorés par Opera 7.x et Opera 8.0 beta, mais ne compromettront pas l'accès au contenu...

Trackbacks

Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.

Commentaires

Nanonymus, le 01 janvier 2005

Et si tu passais à Firefox ? Avec lui, pas de pb avec les CSS. Pas de hack pouri pour que ça passe. Un mec qui parle de standards et qui utilise un truc proprio, ça me dépasse.
Et si c'est tout ce que tu trouves à dire sur le nouveau Pompage, alors là, c'est grave !

Kévin, le 01 janvier 2005

Haaaaaaa, je l'avais bien dis que selecteur[attribut*='valeur'] ca éxistait !
forum.alsacreations.com/t...

Pierre D, le 01 janvier 2005

Nanonymus, je crains que tu fasses un vilain raccourci. Tu devrais au contraire te réjouir que la famille gecko ne soit pas seule à respecter les standards. Les standards, c'est aussi la diversité.
De plus, Opera est un excellent navigateur.

Bonne année à tous.

Laurent Denis, le 01 janvier 2005

Le commentaire de Nanomnymus restera ici pour la postérité comme trace de l'époque pré-néanderthalo-firefoxienne smiley clin d'oeil
Cependant, pour ne pas abuser de la patience de nos lecteurs, toute autre contribution du même jet de cet auteur sera virée illico.

Au fait, bonne année à tous.

Laurent Denis, le 01 janvier 2005

@Kevin> oui, [foo*=bar] existe... potentiellement, éventuellement et provisoirement dans l'actuel projet de sélecteurs CSS3. Il existe aussi incidoirement dans les navigateurs Gecko qui implémentent expérimentalement quelques avancées CSS3, tout comme Opera implémente l'extension de la propriété content à tous les sélecteurs CSS, ou encore plusieurs éléments CSS3 speech. Tout comme IE implémente "display: inline-block" aussi, d'ailleurs.

Cela signifie simplement que ce n'est pas un mécanisme standard, qu'il ne faut pas compter que un quelconque support de celui-ci ailleurs que dans un navigateur particulier, et que c'est a priori une mauvaise solution en production "professionnelle". La solution du patch CSS2.1 avec content: normal; pour Opera est beaucoup plus rationnelle.

Dam, le 01 janvier 2005

Laurent à tu fait un rapport de bug chez Opera ?
Il sera sans doute plus utiles qu'ici smiley sourire

Philippe Worontzoff, le 01 janvier 2005

Ce qui me dérange là dedans, c'est le fait de faire un hack pour un navigateur spécifique, bien sûr, ce n'est pas un gros hack comme certains font pour MSIE, mais, tout de même, ce n'est pas l'auteur de site web qui est responsable des bugs de certain navigateur.

Je suis plutôt pour ignorer les bugs des navigateurs mal implémenté. Bien sûr, les bugs chez Opera sont bien rare et, on ne peut pas dire qu'il soit mal implémenté.

Dans le meilleurs des monde virtuel, on coderait en suivant simplement les recomandation du W3C et ce serais suffisant.

Enfin, de toute façon pour moi, ça ne change rien, en effet, avant de lire cette article, je n'utilisais de toute façon déjà que des codes de langue simples (sans précision régionale).

Néanmoins, je trouve que ce bug est grave et j'espère qu'Opera le règlera vite.

Au fait, je ne sais pas dutout comment fonctionne les rapport de bug chez Opera, si on peut voter pour un bug comme dans bugzilla, je voterais volontier.

Laurent Denis, le 01 janvier 2005

Le bug a été signalé chez Opera, bien-sûr, via www.opera.com/support/bug... .

Mais Opera ne dispose pas d'un système comparable à bugzilla permettant de "voter". Voir www.opera.com/support/bug... pour les indications sur le Bug Tracking System d'Opera, qui gagnerait effectivement à être plus transparent.

Pour le "hack" recommandé ici, je pense qu'il rentre vraiment dans la catégorie des rares hacks totalement inoffensifs, c'est à dire des "précautions à prendre" sans détourner ou compromettre la conformité actuelle / future de ses feuilles de styles. Il consiste en effet simplement à rétablir la valeur par défaut de la propriété "content" à l'aide d'un syntaxe CSS2.1 sans aucun contournement.

Cela dit, ma solution de préférence est celle passant par la CSS utilisateur, qui permet de rétablir aisément le comportement correct du navigateur smiley clin d'oeil

Moz, le 01 janvier 2005

CSS2.1 n'est pas une encore une recommandation. La CSS avec ton hack sera peut-être "conforme" (au sens de l'esprit de la spec, de la leçon tirée des implémentations et des besoins exprimés par les auteurs, bref tout ce que tu as expliqué à propos de CSS2.1) mais pas valide (validateur W3C)...

mee2, le 01 janvier 2005

Ca m'aura fait apprendre l'existence de "content: normal;". =)

En tout cas, merci pour la solution, et bonne année, sans trop de trolls. ^^

Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.