Préfix en ligne/validateur qui a raison ?

Bonjour,
je vais sur https://autoprefixer.github.io/ je mets : transition-property: all;
le préfixeur me répond : -webkit-transition-property: all;-o-transition-property: all;transition-property: all; même chose pour transform: scale(3.6); réponse : -webkit-transform: scale(3.6);-ms-transform: scale(3.6);transform: scale(3.6);

Quand je passe mon css sur le validateur du W3C, j'ai 50 avertissements comme quoi ces prefix ne sont pas reconnus. Mais sur caniuse presque toutes ces fonctions sont en vert pour tous les navigateurs. Ce qui voudrait dire que c'est autoprefixer en ligne qui est faux.
Qui faut-il croire ? Faut-il encore utiliser ces prefix ?
Merci pour les réponses.

Bonjour,

La nécessité d'utiliser des préfixes est devenue plus rare. Mais parfois, on n'a pas le choix, donc il en reste toujours un peu dans un code css.

Les préfixeurs, eux, vont ratisser large et sans doute en mettre trop (ils supportent des navigateurs parfois très anciens).

Le validateur W3C, lui, n'a jamais fonctionné avec une fiabilité de 100%, surtout sur ce sujet. Et de toute façon, le but des préfixes, c'est justement d'offrir un palliatif quand la propriété n'est pas au point. Le validateur a donc forcément du mal à suivre puisqu'on est en terrain mouvant.

Mon conseil : tu laisses tomber les préfixeurs, tu rajoutes de temps en temps un préfixe quand tu constates qu'il est nécessaire sur les navigateurs récents, et tu ignores les alertes du validateur du W3C quand cela concerne des préfixes.

Amicalement,

Merci pour la réponse.
Surtout quand on voit sur caniuse que les quatre fonctions dont je parle (transition-duration, transition-delay, transform et linear-gradient) sont supportées dans une fourchette qui va de 95 à 97 %. La seule difficulté ayant d'avoir un jour sous la main LE navigateur ancien ou exotique qui va nécessiter un préfix.

Salut !

parsimonhi a écrit :
Le validateur W3C, lui, n'a jamais fonctionné avec une fiabilité de 100%, surtout sur ce sujet. Et de toute façon, le but des préfixes, c'est justement d'offrir un palliatif quand la propriété n'est pas au point. Le validateur a donc forcément du mal à suivre puisqu'on est en terrain mouvant.

Au contraire je pense qu'il marche très bien. Les préfixes vendeurs sont des "supports de propriétés spécifiques" à chaque navigateurs. Le W3C dans sa fonction d'uniformisation des standards ne peut pas autoriser des propriétés non standard et relatives a des navigateurs. Enfin c'est la façon dont je le vois, dites moi si je me plante complètement hein... W3C est juste très (trop?) strict mais il marche parfaitement bien.

parsimonhi a écrit :
Mon conseil : tu laisses tomber les préfixeurs, tu rajoutes de temps en temps un préfixe quand tu constates qu'il est nécessaire sur les navigateurs récents, et tu ignores les alertes du validateur du W3C quand cela concerne des préfixes.

Pour moi, oui il faut ignorer les warning du validateur W3C, il est la comme support pour respecter les gros standards mais si on fait du code un peu avant-gardiste on est vite hors de son périmètre.
Par contre les préfixeurs sont assez utiles et ca permet de ne pas s'en soucier. Pour les petits projets c'est pas indispensable en effet mais bon c'est toujours plus confortable je trouve. Et normalement on rajoute ca dans le task runner avec la minification etc on a pas besoin de tout copier coller à la main donc ca se sent même pas.

Et enfin pour éviter de préfixer des propriétés qui

Bongota a écrit :
sont supportées dans une fourchette qui va de 95 à 97 %

il faut mieux régler le prefixeur ! Tu as laissé "last 5 version" dans les options ? Tente avec ">1%" et tu peux tester avec :

.example {
    transform: rotate();
    appearance: none;
}

par exemple.

Bonne nuit !

Bonjour,

voir -o- dans des CSS, c'est un red flag pour moi. Ce préfixe a disparu avec le moteur de rendu Presto quand Opera a adopté Blink/Webkit... en 2013 avec Opera > 12.
Comme le fait remarquer _laurent, c'est bien la config de Browserslist qui pose problème.

Si tu as npm et une ligne de commande, tu peux lancer npx browserslist. Si l'outil se lance... il va râler ; à ce moment-là tu peux créer un fichier .browserslistrc avec les navigateurs souhaités (genre last 2 version) et relancer. Il te listera les navigateurs pris en compte. Si tu n'as pas npm bah va falloir créer cette chaîne à la main avec la doc à côté

firefox, chrome, edge tranquille (à moins que tu veuilles supporter les Edge non-Blink comme Edge 16 à Edge 18 ?)
ios_saf ça dépend de quelle version d'iOS tu souhaites supporter (9.3 pour l'iPhone 6 par exemple alors qu'on doit en être à 13 ou 14 pour un iPhone récent)
Le reste... oh wait il n'y a plus que Chrome qui compte de toute façon /sad
Modifié par Felipe (27 Jan 2021 - 00:57)

Bonjour,

_laurent a écrit :
Au contraire je pense qu'il marche très bien. Les préfixes vendeurs sont des "supports de propriétés spécifiques" à chaque navigateurs. Le W3C dans sa fonction d'uniformisation des standards ne peut pas autoriser des propriétés non standard et relatives a des navigateurs. Enfin c'est la façon dont je le vois, dites moi si je me plante complètement hein... W3C est juste très (trop?) strict mais il marche parfaitement bien.

Hum!

1) On va dire que pour les propriétés non standards, appelées aussi les extensions propriétaires css ("css vendor prefixes" ou "css vendor extension"), il s'en sort en émettant un "avertissement" (on notera qu'il n'émet pas d'erreur dans le cas général, et que ça lui permet de rester cohérent, car si la liste des propriétés non standards n'est pas normalisée, ce qui est normal vu que justement elles ne sont pas standards, leur existence, et la syntaxe de leur nom sont, elles, normalisées). Ceci étant, je ne parierais pas sur le fait qu'il s'en sort dans 100% des cas même en bottant en touche comme ça.

2) Il confond les propriétés non standards (i.e. les propriétés préfixées par -webkit-, -moz-, etc.) avec les variables css (préfixées par "--"). Or, c'est pourtant normalisé. C'est un peu plus gênant. Plus généralement, il a un gros problème avec les variables css ("css custom properties").

3) Il a, comme tous les outils d'une certaine complexité, une liste de bugs d'une longueur "significative" (voir par exemple https://github.com/w3c/css-validator/issues ), et en cherchant un peu, on devrait en trouver qui concerne les extensions propriétaires css directement ou indirectement.

Dire qu'il est (trop?) strict et qu'il marche "parfaitement bien" me semble donc un peu exagéré.

Ceci étant, c'est un très bon outil qu'on peut utiliser, mais aussi dont il faut savoir interpréter les résultats. Sur ce point, il me semble qu'on est d'accord.

En ce qui concerne les préfixeurs, je ne les utilise plus (code généré bien lourd pour finalement assez peu d'effet compte tenu qu'on est en 2021). Mais bon, peut-être que j'ai tort.

Amicalement,
Modifié par parsimonhi (27 Jan 2021 - 09:08)

Finalement beaucoup de réponses pointues. Du côté du validateur, je suis rassuré, 30 warning, ça fait pas beau...

Je n'ai pas d'exigence particulière pour supporter un type de navigateur peu utilisé. Par contre, je n'ai installé aucun automatisme jusqu'à présent (auto-prefixer ou prefix-free). Pour un petit projet comme le mien, j'ai fait "à la main", avec le prefixeur en ligne.

Pour le reste, le poids supplémentaire des préfix dans mon css est de 2,3 K environ (sur 18,6 K du css total). Ce n'est pas négligeable et je vais effectivement faire un peu le ménage.
Merci pour vos réponses précises.

ps : https://github.com/w3c/css-validator/issues = 404 chez moi.
ps 2: normal, il y a ta parenthèse qui bloque le lien, sur le mien, ça fonctionne.
Modifié par Bongota (27 Jan 2021 - 08:37)

Bonjour,

Bongota a écrit :
ps 2: normal, il y a ta parenthèse qui bloque le lien, sur le mien, ça fonctionne.

Merci d'avoir signalé, j'ai rajouté un espace.

Amicalement,

Bongota a écrit :
Pour le reste, le poids supplémentaire des préfix dans mon css est de 2,3 K environ (sur 18,6 K du css total). Ce n'est pas négligeable et je vais effectivement faire un peu le ménage.

Une CSS se doit d'être envoyée gzippée par le serveur au navigateur : c'est beaucoup moins d'octets réellement transférés.
Quand on compare ce qui serait transféré avec et sans gzip, la différence est minime : les préfixes sont toujours les mêmes, les propriétés écrites en double ou triple et c'est exactement ce qui se compresse le mieux. Tu auras peut-être 7,3 ko vs 7 ko au pifomètre