Style pour IE en 4 caractères

Salut,
Je suis tombé sur ça:

body {
    color: red; /* all browsers, of course */
    color : green\9; /* IE8 and below */
    *color : yellow; /* IE7 and below */
    _color : orange; /* IE6 */
    }

http://snipplr.com/view/36163/target-ie6-ie7-and-ie8-with-only-4-characters-hack/

Assez bizarre.
Qu'en pensez-vous?

Hello,

C'est juste une collection de hacks assez connus (et sales aussi). Il reposent sur des erreurs d'interprétation du parser de CSS pour cibler une version spécifique d'IE avec une déclaration normalement illégale.

Chez html5 boilerplate, ils utilisent ces hacks (intégration de normalize.css). Pour le code qui suit normalize, c'est mieux de s'aider des commentaires conditionnels surtout si on est débutant.
Modifié par Patidou (17 Jul 2012 - 11:05)

Patidou a écrit :
Chez html5 boilerplate, ils utilisent ces hacks (intégration de normalize.css).

Ah oui exact, ils utilisent ces hacks dégueulasses ET les classes conditionnelles sur l'élément html via commentaires conditionnels. Euh ?

Felipe a écrit :

Ah oui exact, ils utilisent ces hacks dégueulasses ET les classes conditionnelles sur l'élément html via commentaires conditionnels. Euh ?

C'est écrit "concentré de bonnes pratiques" sur l'emballage.

jmlapam a écrit :


C'est écrit "concentré de bonnes pratiques" sur l'emballage.

Tu regardes la version française du site et tu as vite compris à quel point ce truc est merdique.

Quand même, ces hacks ont eu une telle presse et sont utilisés de manière tellement répendue qu'il ne fait aucun doute que les navigateurs ne commenceront pas à les reconnaître.

Le point principal est qu'un navigateur respectant les standards devrait simplement ignorer ces déclarations. (moins certains pour le "\9", mais l'* et l'_ annulent la ligne selon les standards).

Dès lors, à moins d'une majeure régression au niveau du code des navigateurs, je crois qu'on peut considérer ces hacks comme étant totalement sécuritaires. Qui plus est, je présume que les navigateurs ont implémentés des test unitaires et que ces hacks y sont listés, alors les chances de régression sont probablement quasi inexistant. Alors, ça ne me donnera pas de l'horticaire.

Ensuite, est-ce que je m'en sers ? Bah non, pour le principe.

Cela dit, dans le cas de normalize.css. Le choix d'utiliser ces hacks me semble être le meilleur qui pouvait être fait en la matière considérant la portée du projet et les contraintes y étant reliée.

Pour le projet html5 boilerplate, ce dernier intègre normalize.css tel quel. Ceci est beaucoup plus facile à gérer lors de mise à jour (regarder un peu le foutoir des portage AMD de Backbone et underscore). Et en même temps, c'est une boilerplate, donc on prend des éléments et on en retire. Sans ces hacks c'est dommage, mais normalize.css serait immidiatement beaucoup moins fiable et ne fonctionnerait pas immédiatement "out of the box".

On peut pousser pour les bonnes pratiques. Mais dans le cas d'un projet open source largement utilisé, il faut faire des compromis entre respect des standards* et facilité d'utilisation pour le débutant/néophyte ou développeur paresseux/de talent questionnable.


* En matière de respect des standards, j'ajouterais que ces normalize.css à l'extrême les respecte puisque ces même standards couvrent assez bien la gestion des erreurs (donc, c'est standard de présumé que ces règles seront ignorés des navigateurs respectueux des standards). Et que finalement, le vrai problème est qu'on peut difficilement autrement que ciblé un agent utilisateur pour effectuer des correctif en CSS. C'est dommage, mais on joue contre des bugs d'anciens navigateurs, et contre des bugs, malheureusement les beaux principe de "feature détection" ne peuvent pas s'appliquer avec autant d'ardeur et d'efficacité que certains aspects Javascript (ou avec CSS3) ou il "suffit" de tester la présence ou non d'aspect, pas leurs erreurs d'implémentation.

Je vais fumer un gros joint de beuh pour me rabaisser au niveau de connerie du post précédent...
Modifié par jb_gfx (18 Jul 2012 - 02:52)

Tu peux aussi lire la documentation:

http://www.w3.org/TR/CSS21/syndata.html#parsing-errors

Et un article à propos de la gestion des erreurs:

http://www.xanthir.com/blog/b4JF0

Penses-tu réellement que des programmeurs aussi réputé que Nicolas Gallagher utilisent des hacks sans en avoir réellement pesé les pour et les contres ? Il n'y a pas de solution parfaite, mais l'utilisation de hacks dans le contexte de normalize.css est à mon avis totalement justifié.

Pourquoi veux tu utiliser des hacks quand les commentaires conditionnels existent ? C'est totalement contre-productif et ça ne présente absolument aucun intérêt. Et je ne parle même pas du fait de mélanger les 2 techniques (ce qui est clairement complètement con).

a écrit :

Il n'y a pas de solution parfaite

Si, justement.
Modifié par jb_gfx (18 Jul 2012 - 03:15)

a écrit :
Si, justement.

Non, justement.

Pour rappel, normalize.css est un reset CSS. Ainsi:

+ Il doit être séparé de la structure HTML (donc ne pas compter sur la présence de classe sur l'élément html)

+ Il ne doit pas augmenter la spécificité d'une règle. Dès qu'on utilise .lt-ie8 selecteur, un auteur qui ciblera seulement le sélecteur ne verra pas ses règles appliqués sur ie8 puisque les règles du reset auront une spécificité plus élevés. (C'est selon moi le principal argument du choix normalize.css)

+ La seule solution respectant les deux points au dessus est d'avoir une feuille de style séparée. Mais à ce moment, on se retrouve devant un coût important en performance pour calmer la sensibilité du validateur.

+ Ces techniques sont tout d'abord issue de Yahoo, et sont présentement utilisées sur ce même site. Si un navigateur décide de briser la compatibilité de ces hacks, il brisera le site de Yahoo pour tout ses utilisateurs. Donc, il y a des gros poids derrière le maintient de ces hacks.

Alors, non. Il n'y a pas de technique parfaite dans le cas de normalize.css

Dans le cas de style d'auteur, évidemment, je ne conseillerais pas l'utilisation des hacks. Mais dans certains cas, ces derniers ne sont pas à renier comme un lépreux.
Modifié par Vaxilart (18 Jul 2012 - 03:30)

Les resets CSS c'est vraiment la panacée et quand ils sont à base de hacks c'est encore mieux. [ /fin du mode ironique]

a écrit :

Alors, non. Il n'y a pas de technique parfaite dans le cas de normalize.css

Le cas en question est tout simplement à vomir.
Modifié par jb_gfx (18 Jul 2012 - 03:54)

Pour les hacks chez h5bp, c'est normal vu qu'ils incorpore le projet normalize.css qui lui est autonome et doit fonctionner sans les classes conditionnelles. Son auteur a expliqué ça dans un post et même si moi aussi je n'aime pas les hacks, ça me semble logique.

Et puis on parle ici de la partie reset de la css, pas du design proprement dit.

Oups j'ai sauté le message de vaxilart…
Modifié par Patidou (18 Jul 2012 - 08:53)

jb_gfx a écrit :
Tu regardes la version française du site et tu as vite compris à quel point ce truc est merdique.

Les versions internationalisées sont totalement désynchros du projet et ne sont plus supportées officiellement.

Florian_R a écrit :
Les versions internationalisées sont totalement désynchros du projet et ne sont plus supportées officiellement.

En plus le vocabulaire utilisé était… Comment dire…

J'ai retrouvé l'issue sur github pour ceux que ça intéresse : https://github.com/h5bp/html5boilerplate.com/issues/88.

Pour revenir au sujet : Pourquoi normalize utilise des hacks.

Et dans la foulée, tant qu'a faire de balancer du lien, un petit article sur les hacks "sûrs".

Florian_R a écrit :

Et dans la foulée, tant qu'a faire de balancer du lien, un petit article sur les hacks "sûrs".

Très intéressant, merci.