Les préfixes constructeurs - commentaires

Les préfixes constructeurs

Pascale, David : ça montre bien en tout cas qu'il faut garder toutes les versions préfixées. ^^

Les préfixes constructeurs

Maisheuuu ! Elle est à jour :/
Faut me renvoyer à Anaheim, je ne vois que ça ;)

Les préfixes constructeurs

@Pascale : c'est normal, nous avons commencé à supporter les versions non préfixées qu'à partir d'IE10 PP6 livré avec Windows 8 Release Preview. Si tu as une version antérieure de Windows 8 (Developer Preview ou Consumer Preview), tu as une ancienne version d'IE10 qui ne supportait les gradients qu'en version préfixée.

Conclusion : mets à jour ta tablette !!! :-P

David

Les préfixes constructeurs

Sur le fait que les préfixes ont vocation à valider une syntaxe, le meilleur exemple vient de Firefox 16 qui va sortir sans préfixe pour les dégradés, et comme le montre Paul Rouget :

If you remove the -moz- prefix from your linear gradients, don't forget to update the direction syntax ("bottom left" -> "to top right")

La syntaxe a changé entre les tests et l'implémentation définitive.

Les préfixes constructeurs

C'est curieux ça : je viens de faire le test avec IE10 sous win8, ça ne fonctionne pas du tout sans le préfixe -ms ! Peut-être que cela va évoluer d'ici la sortie officielle de win8, mais je pense qu'il est plus prudent de le mettre...

Les préfixes constructeurs

Inutile de mettre -ms-gradient dans l'exemple de code : aucune version d'IE ne supporte la version avec préfixe, et IE 10 la supporte sans préfixe.

D'ailleurs un grand nombre de propriétés sont en train de perdre leur préfixe : transitions, transforms, animations, gradients dans IE 10 et Firefox 16. Voilà pourquoi il est indispensable de mettre la version non préfixée en dernière position !

Les préfixes constructeurs

@Tanguy : Il y a peu de temps, la communauté t'aurait recommandé d'y aller sur les dégradés parce que c'est bon, c'est réglé, ça bougera plus. Et puis il y a eu l'introduction du préfixe "to". Donc ça n'aurait pas aidé de consulter la communauté.

Il n'y a que deux solutions :
– ne pas utiliser les préfixes
– avoir un fallback correct si la solution préfixée ne marche pas

@Nicolas : Oups, ma énième relecture était fainéante :)

Les préfixes constructeurs

@Anthony : c'était déjà dans les références et compléments ! ;)

Les préfixes constructeurs

@Anthony Tout a fait d'accord avec toi, c'est pour ca que j'avais precise dans mon commentaire la condition de s'etre renseigner sur l'utilisabilite d'une feature css3 aupres de la communite des dev web (blogs, twitters, etc..), et grace notamment a des sites comme CanIUse ou HTML5Please sur lesquels on peut plutot bien se fier. A l'epoque ils auraient surement pointe du doigt le fait que l'utilisation des prefixes gradients n'est pas digne de confiance.
Mais ce sont evidemment pas mal de conditions qui peuvent etre contraignantes et a moduler selon les budgets et le temps alloues a chaque projet.

Les préfixes constructeurs

Ah oui et depuis le début, j'ai oublié de filer la page pour bien vivre dans le futur !

Recommandations de Mozilla

Les préfixes constructeurs

"Cependant, cela ne résoud pas le problème du « legacy. » C'est à dire du support du préfixe, une fois la version non préfixée a été déclarée stable".

Ajoute à ça que le navigateur peut ne pas être à jour... donc abandonner le préfixe dans la CSS du projet n'est pas pour autant une solution satisfaisante.

Pourquoi l'expression "doigt coincé dans un engrenage" me vient à l'esprit ? ;)

Les préfixes constructeurs

Tanguy : "A partir de ce moment la, utiliser Less/Sass pour qu'il rajoute tous les prefixes qu'il faut plus la propriete CSS n'est pas un probleme."
Et bien si justement c'est un problème. Imagine que tu développes un site à l'époque de la première version de la syntaxe des gradient. D'après ce que tu dis, tu vas inclure toutes les versions préfixées et la non-préfixée. Et bien cette fonctionnalité ne marcherait plus aujourd'hui puisque la syntaxe a énormément changé. Si c'était une prestation et qu'elle est terminée, tu n'as pas moyen d'aller modifier ce site.

Les préfixes constructeurs

Que des prefixes css se retrouvent en production je ne vois pas le probleme, ne serait que pour faire du "progressive enhancement", a condition (encore une fois une condition) de s'etre renseigner sur l'utilisabilite de tels prefixes grace a des sites comme CanIUse. A partir de ce moment la, utiliser Less/Sass pour qu'il rajoute tous les prefixes qu'il faut plus la propriete CSS n'est pas un probleme.
Je pense qu'on en revient toujours au meme conclusions a la fin : le principe est bon mais souvent son application ne l'est pas, de fait d'un manque d'education des developeurs web. C'est pour cela que des articles comme celui la son primordiales, et plus il y en aura, plus le novice qui cherchera des infos pourra en trouver facilement. Encore faut-il qu'il cherche ! Mais je m'eloigne du debat..

Les préfixes constructeurs

@Nicolas,

Oui, c'est une possibilité de signaler attention propriété instable. Mais dans ce cas, je choisirais plutôt l'option suivante : -draft-propriete: blah;. Et si les comportements sont différents en fonction des navigateurs, cela montre bien le danger d'utiliser une propriété non finie.

Cependant, cela ne résoud pas le problème du « legacy. » C'est à dire du support du préfixe, une fois la version non préfixée a été déclarée stable.

Le grand enjeu des préfixes CSS n'est pas tant technologique que structurel et social.

Les préfixes constructeurs

A mon sens, les préfixes ont leur pertinence, toutefois il faut la repenser : à mon avis, ils sont maintenant là pour dire surtout "attention, usage à risque/truc pas stable" : c'est ce que j'ai humblement essayé de transmettre dans cet article : en substance, vous voulez franchir la ligne, ok, mais vous ne pourrez plus dire que vous n'étiez pas au courant des risques en ouvrant la boite de Pandore.

Et comme tu l'as dit, Less et Sass simplifient la vie des intégrateurs, pas des navigateurs.

Les préfixes constructeurs

Partie 2

Et donc cela pose à nouveau la question en des termes différents pour les autres navigateurs… de supporter la syntaxe des préfixes d'autres navigateurs diluant un peu plus la signification des préfixes (un espace réservé et protégé pour tester une technologie). La pression essentielle pour les navigateurs est d'être compatible avec le Web et la façon dont il est écrit afin de pouvoir interprêter les pages Web.

C'est pour cela que les pratiques de less et de sass ne font qu'accentuer le problème en faisant croire à une amélioration de la situation. Finalement, ne courrons nous pas après les problèmes quand individuellement nous faisons le choix sur nos sites Web d'utiliser des propriétés qui ne sont pas prêtes. La structure sociale et économique du Web n'appelant pas à une solidarité collective de l'interopérabilité. Il y a peu de chances pour un changement de pratique des concepteurs.

Au final, cela pose la question de la pertinence des préfixes CSS dans le processus de normalisation.

Les préfixes constructeurs

Il y a deux conditions essentielles pour que les préfixes CSS fonctionnent dans l'esprit initial de leur conception :

1. les sites Web sont mis à jour en permanence.
2. les navigateurs Web ne rendent pas disponibles la fonctionnalité du préfixe dans la version finale du navigateur.

Nous savons tous que ces deux conditions ne sont pas remplies. Un site déployé est rarement retouché s'il ne fait pas partie d'un système de gestion interne. Résultat : Nombre de pages sur le Web traînent avec des préfixes qui ne devraient plus y être. Bien sûr comme dans le bug de Mozilla, certains se plaignent de l'abandon de la propriété avec préfixes. L'ironie est que les équipes de Chrome et Safari ne veulent pas laisser tomber les préfixes pour être compatibles avec les pratiques des auteurs. Nombre de sites codés uniquement pour Webkit s'arrêteraient de fonctionner proprement.

Les préfixes constructeurs

Tanguy : Oui, j'ai vu le tweet passer ce matin, je l'ai ajouté dans références et compléments ("Un exemple de dégât collatéral occasionné par l'utilisation des préfixes"), vu que c'est un exemple parfait de ces problèmes.

Les préfixes constructeurs

Je viens de voir qu'Anthony Ricaud a fait la meme remarque dans son commentaire !

Les préfixes constructeurs

Tres bon article qui resume bien les problemes potentiels lies a la mauvaise utilisation de prefixes proprietaires. C'est drole (enfin ca depend..) car je viens juste de tomber sur un tweet donnant un lien pointant vers le bugzilla de mozilla firefox, avec une personne se plaignant de l'arret de support de certains prefixes constructeurs sur la derniere version de firefox : https://bugzilla.mozilla.org/show_bug.cgi?id=765645

Ce qui amene a un autre point quand on utilise les prefixes proprietaires, non critique cependant : etre au courant quand les navigateurs "laissent tomber" les prefixes pour supporter complement la syntaxe officielle, et ainsi reagir en mettant a jour ses CSS pour virer les prefixes au fur et a mesure. Evidemment apres s'etre assurer que le pourcentage d'utilisation d'anciens navigateurs ne supportant pas les version non prefixees est negligeable. (et si on peut revenir sur un projet potentiellement deja termine, en terme de temps/cout).

Les préfixes constructeurs

Je recommande vivement aux gens d'aller faire un tour du côté de Compass (framework pour SASS) : http://compass-style.org/. Un petit exemple de ce que propose Compass sur les linear-gradient : http://compass-style.org/examples/compass/css3/gradient/

Les préfixes constructeurs

Il est important de noter que les préfixes s'appliquent aussi lorsque l'on souhaite accéder à une propriété CSS depuis Javascript.
Une bonne pratique consiste à utiliser un outil comme Modernizr pour la gestion des préfixes côté JS.

Les préfixes constructeurs

Hello,

Avec less ou saas, la maintenance est facilité avec ce type de problématique (changement de syntaxe)
En effet, en utilisant un mixin pour gérer le background, on peut avoir à modifier qu'une seule ligne si la propriété change et si les arguments du mixin sont compatibles avec la nouvelle propriété.

Les préfixes constructeurs

Je rajouterais deux erreurs commises :
– Lorsqu'une spécification est stabilisée et que la version non-préfixée est implémentée, il convient d'enlever le support de la version préfixée après un certain temps. Cela permet de "casser" les pages qui n'avaient que la version préfixée, ce qui oblige les auteurs à les corriger, ce qui rend la page compatible avec tous les navigateurs. Apple ne joue pas le jeu sur ce point et a dit à plusieurs reprises qu'ils n'enlèveront pas les versions préfixées.
– Apple (oui, encore) ne joue pas le jeu de la standardisation en ne faisant que très peu de propositions de standards. Lorsqu'ils implémentent , -webkit-device-pixel-ratio, -webkit-mask, -webkit-gradient, etc. ils ne soumettent pas de spécification au W3C. Du coup, les autres navigateurs doivent faire de la rétroingénierie, ce qui prend énormément de temps tout en n'assurant pas une compatibilité maximum.