CSS : Opera s'habille un peu chez WebKit

Florian Innocente |
Opera a décidé de se rallier à certains préfixes CSS gérés par les navigateurs basés sur le moteur de WebKit, tels Chrome et Safari. Une décision prise à contrecœur, mais destinée à assurer une compatibilité entre le navigateur norvégien et des sites dont les développeurs privilégient les syntaxes WebKit.

Certains sites utilisent en effet des propriétés CSS basées sur des possibilités de WebKit encore au stade de l'expérimentation (lire aussi Les préfixes vendeurs en CSS). Il arrive que des équivalents - indépendants d'un navigateur - existent, mais des auteurs préfèreront cibler un moteur de rendu qu'ils estiment le plus répandu. Alors qu'ils pourraient décliner leur code pour chaque navigateur, en plus d'un format générique.

Faruk Ateş, un développeur, donne trois exemples types : la formulation des développeurs "paresseux", celle qui inclut la formulation standard et enfin, celle qui prend en compte chaque navigateur, avec au début le préfixe ad-hoc (webkit, moz, ms, etc).

selector {
-webkit-transform: rotate(5deg);
}



au lieu de :

selector {
-webkit-transform: rotate(5deg);
transform: rotate(5deg);
}



Ou, mieux encore :

selector {
-webkit-transform: rotate(5deg);
-moz-transform: rotate(5deg);
-ms-transform: rotate(5deg);
-o-transform: rotate(5deg);
transform: rotate(5deg);
}



Opera régnait à peu près seul auparavant sur les plateformes mobiles (sur le mois de mars dernier, l'éditeur dit avoir comptabilisé 168,8 millions d'utilisateurs uniques, +64% en un an) puis Android et iOS sont arrivés avec WebKit, Microsoft met les bouchées doubles avec Windows Phone et Mozilla tente de se faire une place.

Devant le succès rencontré par WebKit et malgré une solide présence sur les mobiles, Opera redoute de voir son navigateur marginalisé, d'autant plus si des développeurs s'en tiennent à cibler uniquement WebKit dans leur code. L'éditeur a donc décidé «d'aliaser», dans l'outil d'émulation d'Opera Mobile, une série de propriétés CSS utilisées avec le préfixe webkit, afin qu'elles pointent vers la fonction équivalente dans Opera. Dès lors, ce dernier ne sera pas pénalisé sur des sites dont il sait pourtant interpréter les CSS. Mozilla pourrait faire de même, mais Microsoft pour sa part l'a exclu.

Faruk Ateş, lui-même développeur, récuse cette idée d'une certaine facilité chez ses pairs. De son point de vue, WebKit a pris à un moment clef un ascendant technique sur ses concurrents, en évoluant aussi plus vite. Ensuite les Mozilla, Microsoft et Opera, toujours de son point de vue, n'ont pas suffisamment investi dans la mise au point d'outils open source pour aider les développeurs à produire un bon code CSS qui permettent aujourd'hui d'éviter ces problèmes de fragmentation.
Tags
avatar elamapi | 
C'a'd que ça devient juste lourdingue, quand on fait un site Web, dans un "langage" soit disant "portable" de devoir adapter le code pour 35 navigateurs. Parce que pour le moment, on a IE (x version), Opera, Safari, Chrome (et oui, bizarrement, safari et chrome, tout deux basés sur WebKit gère certaine extensions différement), Firefox, Konqueror (la encore, certaine extensions ne sont pas géré de la même façon que WebKit safari et chrome). Bref, si à chaque version de navigateur qui veut se différencier il faut adapter son code, je comprend les devs d'en cibler un spécifiquement. Et dans ce cas précis, chrome à l'avantage d'etre présent partout ou presque (pareil pour FF). Ce qui n'est pas le cas de safari,ie ni même opéra.
avatar RedMak | 
@elamapi +1 faut pas aussi oublier les navigateurs mobile qui sont basé sur webkit, pour vous donner un exemple, j'ai développé une app pour wp,ios,androidet et blackBurry , tou fonctionne bien sur les 3 dernier ( à peut pres ) mais sur WP sa ne demarre meme pas dut au moteur de rendu qui n'est pas webkit sur se termial.
avatar Bad2climb | 
Pour régler le problème des prefixes: http://leaverou.github.com/prefixfree/
avatar Almux | 
Est-ce "être flemmard" que de rechercher la simplicité? Ou, n'est-ce que de l'égo de butineurs que de vouloir absolument "sortir son truc"? Franchement, là, chapeau Opera! Et que les autres en prennent de la graine! Laissez-nous faire nos sites avec 1 SEUL LANGAGE et, butineurs, arrangez-vous pour intégrer ce qu'il faut pour que ça fonctionne! Raz-le-bol de vos guéguerres!
avatar Sephi-Chan | 
Ceux qui n'incluent pas les préfixe et la déclaration sans préfixe sont des burnes, voilà tout. Il faut arrêter les conneries : la charge de travail supplémentaire est infime. De plus, on ne manque pas d'outils pour simplifier encore plus la tâche : entre les scripts comme Prefix Free et les préprocesseurs (SCSS, SASS, Less, etc.), il n'y a aucune excuse.
avatar elamapi | 
@Sephi-Chan Le soucis, ce n'est pas la "charge" de travail, le soucis, c'est que ton site va être visible maintenant avec le navigateur X, et dans 2 jours, il ne sera plus visible avec le navigateur Y. Tu va devoirs faire de la veille techno et revoir le bon fonctionnement de tout tes site avec chaque version de chaque navigateur. Et la, tout d'un coup, ça devient juste chiant. Bien sur, si t'as ton blog perso chez wordpress ça ne t'impacte pas trop. Maintenant si tu est fournisseur d'API, que tu devs plusieurs gros site bien complexe coté clients, alors passer ton temps à vérifier que tout fonctionne (cad un test de non regression total) tu va voir que 1- La charge est juste bien plus grande que ce que tu penses. 2- C'est un travail HYPER chiant et absoluement pas gratifiant. PS: Dans le cas des API, je te passe le cas des clients qui les utilisent et qui vont te pourrir à longueur de journée parce que leur site (fait avec tes api) ne fonctionnent pas, plus ou mal. Non, clairement, la normalisation HTML / CSS devrait être UNIQUE pour tous et les interfaces UNIQUES. Osef de l'implementation. Ca va jouer sur les perfs uniquement.
avatar Elcos | 
c'est une bonne idée de la part d'Opera, on aura enfin Opera mobile sur iphone au lieu d'Opera mini qui reste trop limité. enfin, j'espère aussi qu'Opera adoptera Web-Kit pour la version desktop aussi, comme ça plus d'incompatibilité.
avatar jipeca | 
C'est mieux de réinventer la roue ?
avatar gregelhombre | 
Ce qui serait interressant Serait de savoir sur macG les proportions d'opera....
avatar Domsou | 
@Sephi-Chan : + 1
avatar enkyl31 | 
Pour faire un parallèle, ça reviendrait à écrire vos articles pour chaque. Frison de navigateur. De plus, l'exemple utilisé peut paraître simple, mais lorsqu'il faut en plus assurer une compatibilité descendante sur IE, ça devient la traversée du Styx. Il y a donc autant de développeurs feignants que de journalistes paresseux :)
avatar sylver | 
Le problème de fond n'est à mon avis pas le temps que ça demandera en plus aux développeurs (cet aspect est d'ailleurs un faux problème), mais c'est plutôt qu'on est en train de retomber dans le syndrôme "IE only" d'il y a quelques années. A cette époque, sous prétexte qu'IE avait 90% de parts de marché, de nombreux concepteurs de sites ne s'embêtaient pas à suivre les recommandations officielles, mais utilisaient des syntaxes (noms de balises, règles CSS, fonctions javascript) compatibles uniquement IE. Les développeurs de navigateurs concurrents étaient donc obligés de programmer leurs navigateurs pour qu'ils interprètent ces syntaxes spécifiques à IE en plus des syntaxes standardisées et équivalentes, sans quoi les utilisateurs les rendaient coupables de ne pas savoir afficher correctement un site web. Aujourd'hui de nombreux concepteurs web voulant utiliser des effets CSS qui ne sont pas encore standardisés (mais qui sont en cours de l'être) se rabattent sur les syntaxes spécifiques aux navigateurs. Ils utilisent pour cela les préfixes des navigateurs (-webkit-, -o-, -moz-, etc.). C'est d'ailleurs la technique recommandée par le W3C. Le problème c'est que, Webkit devenant majoritaire, certains concepteurs de sites peu consciencieux se contentent d'utiliser les commandes avec les préfixes spécifiques à Webkit. Et du coup Opera, comme peut-être d'autres développeurs de navigateurs plus tard, se mettent à interpréter aussi ces commandes venues d'un autre constructeur pour que les utilisateurs ne les accusent pas d'être incapable d'afficher un site web correctement. Pourtant il FAUT que les préfixes spécifiques à chaque navigateur RESTENT spécifiques à chaque navigateur. Sans cela, on est reparti pour replonger dans la même jungle dans laquelle les développeurs de navigateurs et de sites web se trouvaient au début des années 2000. Et si vous étiez dans l'une ou l'autre de ces deux catégories à cette époque, vous devriez vous rappeler à quel point c'était triste.
avatar Adricol0 | 
C'est clair que c'est lourd de créer un CSS ( et parfois un HTML ) pour chaque navigateur voir pour chaque version d'un même navigateur ( merci IE ). C'est réellement une perte de temps et de confort pour le dev et le visiteur. Vivement qu'ils se mettent d'accord, et vite !
avatar makidoko | 
Oui, avant on devait développer pour 2 navigateurs : IE et les autres. Maintenant on doit développer pour un nombre indéfini de navigateurs. Je refuse! J'ai toujours refusé le support IE6 auparavant. Actuellement, j'ai un site qui, sous IE 8, affiche un cadre bleu autour d'une image.. et tout fonctionne normalement sous tout autre navigateur. Ben je m'en fous, en fait. Tant pis. Il y a des standards? Respectons les, point barre. Si les utilisateurs de navigateurs pourris ont des rendus pourris, ils finiront bien par utiliser un vrai navigateur. C'est à nous de montrer la voie opérationnelle à l'utilisateur. Pas le contraire. Le seul bug dans cette affaire de CSS à la mode de chacun, c'est le temps interminable qu'il faut au W3C, juge de paix, pour pondre une spécification définitive ; les propritétés de radius et rotation, par exemple, ne semblent pas être si absconces ou inappropriée dans une mise en page qu'il faille réfléchir à 500 fois avant de les valider. Juste une spécification.. J'ose pas imaginer s'ils devaient développer les implémentations. nous en serions au HTML 0.9b et CSS ne serait même pas encore rêvé.
avatar Sephi-Chan | 
@ Elemapi Je ne comprends pas de quoi tu parles : des APIs qui servent du CSS ? Ce que je veux dire, c'est que dans tes CSS, quand tu as besoin d'une ombre portée, tu intègres la règle CSS générique, ainsi que les versions prefixées. Les règles CSS3 sont supportées ou ne le sont pas.
avatar Almux | 
@silver Perso, je suis d'accord pour TOUT... sauf de devoir tout recommencer en mode "commentaires conditionnels" et autres multiplications de carrefours de langages!...
avatar nayals | 
Allez hop, j'ai fait un site, qui respecte les normes du W3C, qui fonctionne très bien sur Chrome, Safari, Firefox, Opera, mais qui n'est même pas utilisable sur Internet Explorer. Merci microsoft de respecter les normes du web, grace à vous, je vais devoir rajouter des lignes un peu partout, une pour IE6 par ci, une pour IE8 par là... Mais bien sûr, aucun utilisateur lambda n'est au courant de ça, et tous préfèrent utiliser Internet Explorer >.< Grrrr
avatar san lee | 
Suis d'accord avec makidoko, s'ils se bougeait les fesses le W3C, on en serait pas là… Parce que bon, le CSS 3, ca a debuté en 1999 !!! 13 ans et c'est toujours pas fini… Sûr qu'ils ont eu le temps d'en sortir des versions de navigateurs et qu'ils partent a droite a gauche maintenant… Si il y a une pierre a jeter, perso je la lance sur le W3C moi…
avatar Jean-Jacques Cortes | 
Il faudrait rappeler la raison de ces différents préfixes : c'est à cause de la lenteur de réaction du W3C à mettre en place CSS3. Tant que le W3C mettra dix ans entre chaque version de CSS pour l'établissement d'une norme commune à toutes les plateformes, chacun bricolera dans son coin.

CONNEXION UTILISATEUR