Il y a actuellement tout un débat sur la position dominante de webkit sur les navigateurs (mobile et desktop). Que ce dernier soit leader n’est pas le sujet mais plutôt le fait que les développeurs de site web font des versions optimisés pour ce moteur de rendu, délaissant les autres moteurs. On arrive donc avec une expérience plus pauvre sur les navigateurs embarquant des moteurs non webkit.
Même si on est bien loin des problèmes de CSS que l’on pouvait constater sur IE6, il n’en reste pas moins que l’histoire semble se répéter.
Mon avis
D’un coté je peux comprendre qu’un moteur de rendu, voir un navigateur souhaite proposer des implémentations qui leur sont propres pour proposer une expérience utilisateur plus riche. L’air de rien, c’est un moyen de se différencier de la concurrence. Le problème, c’est que les développeurs n’ont pas le temps ni les ressources pour proposer une expérience complètement iso quelque soit le moteur de rendu. Cela prendrait trop de temps et coûterait trop d’argent.
Dans l’article, les spécialistes fustigent les développeurs en indiquant que c’est à eux de faire le nécessaire. Dans le meilleur des mondes, cela pourrait être possible. Maintenant je ne pense pas que les multiples alertes suffiront à changer les habitudes des développeurs et intégrateurs. Je pense que c’est aux groupes et dev de ces moteurs et navigateurs de trouver la solution
Votre avis ?
Techno propriétaire et standards peuvent ils faire bon ménage ?
Qui doit faire le nécessaire ? les dev s?occupant des moteur de rendu + des navigateur ou les développeurs de site internet ?
Avez vous des pistes, des idées ?
C’est une vaste blague, l’hopital qui se fout de la charité !
Le rapport de force devrait indiquer la réponse :
nombre de développeurs de moteur de rendu / navigateur
VS
nombre de développeurs web
Alors on incite le plus grand nombre à s’adapter (les dev web) ou bien les grognons qui nous pourrissent la vie de spec proprio ?
A quoi sert que le W3C se décarcasse ???
Y a pas de réflexion à faire : on a gueulé contre microsoft & IE pour n’en faire qu’à leur tête. Ce n’est pas pour recommencer avec webkit ou autre.
Et y a deux trucs à changer :
Les développeurs ne doivent utiliser les extensions propriétaires ou les trucs en test (-webkit- & cie) que sur des pages … de test ou à faible diffusion.
Les navigateurs ne devraient pas diffuser des versions “grand public” (ou finales) comportant ces extensions. Si un développeur doit faire des tests avec, qu’il utilise l’itération N+1 les embarquant, mais pas celle en cours.
PS :
si on est bien loin des problèmes de CSS que l’on pouvait constater
les spécialistes fustigent les développeurs en indiquant
De mon expérience de dev web, cette histoire de prefixe pour propriétés css expérimentale ne devrait même pas exister. Un standard html 5 a été défini pour mettre tout le monde sur un pied d’égalité, et éviter ce que j’ai enduré avec les “hacks” pour qu’une page s’affiche de la même manière sous ie ou firefox… comme le dit naturellement troubl, à quoi sert le w3c ?
Avant que tout le monde soit d’accord pour TCP/IP, c’était comme ca pour le réseau avec ipx/spx, netbeui… Bien que la mise en place d’un standard ait je pense surtout été décidée pour des raisons commerciales/antitrust, ca a aussi énormément facilité la vie des développeurs.
“les spécialistes fustigent les développeurs en indiquant que c’est à eux de faire le nécessaire”
Je pense que tout le monde est d’accord, que ce sont les développeurs qui font vivre les navigateurs et pas le contraire.
Mais sans vouloir froisser personne, cela ne m’étonne pas, c’est malheureusement la mentalité qu’ont certains dev oss…
Je cite Miguel de Icaza, tiré de son célèbre article/troll :
"Back in February I attended FOSDEM and two of my very dear friends were giggling out of excitement at their plans to roll out a new system that will force many apps to be modified to continue running. They have a beautiful vision to solve a problem that I never knew we had, and that no end user probably cares about, but every Linux desktop user will pay the price.
That day I stopped feeling guilty about my new found love for OSX. "
“En février dernier, je me suis rendu au FOSDEM and deux de mes meilleurs amis ricanaient d’excitation sur leur projet de lancer un nouveau system qui obligerait beaucoup d’applications à être modifiée pour pouvoir fonctionner. Ils avaient une vision magnifique de comment résoudre un problème que je ne savais même pas que nous avions, et qui n’intéressait probablement aucun utilisateur final, mais tous les utilisateur du desktop linux devrait en payer le prix.
Ce jour là, j’ai arrêté de culpabiliser sur mon nouvel amour pour OSX.”
Inutile de dire qu’il s’est ensuite fait bashé sur la perte de backward compatibilité entre les différentes versions de gtk…
Je nuancerai ton propos : ça existe pour pouvoir tester. Tester signifie pas mettre en production ou en release publique. Si les dévs n’arrive pas à comprendre ce simple fait, c’est de leur responsabilité, moins celle du navigateur. mais c’est reste celle du navigateur de ne pas fournir au grand public des trucs qui sont finalement qu’en alpha/beta.
Le problème, c’est qu’à partir du moment où des fonctionnalités, même en bêta, alpha voire pré-alpha, sont disponibles, et fonctionnent assez bien : les dev se jettent dessus. Surtout si la fonctionnalité est à la mode.
Par exemple, lorsque qu’on a commencé à parler d’ajax, je me suis immédiatement jeté dessus… Et les soucis de compatibilité avec ie ont refait surface…
Dans mon cas, ca permettait de résoudre un problème de chargement de page trop long (page avec beaucoup de champs formulaires et générée grace à de grosses requetes sql) et rendait le backoffice bien plus agréable à utiliser… exaucant un des souhaits du patron - il fallait donc absolument que la fonctionnalité soit présente.
Résultat, j’ai justement eu le problème cité dans l’article : sur le site était mentionné “Site optimisé pour Firefox ou IE8 mini” Après tu me diras, “ben fallait solutionner le problème autrement” : le souci, c’est qu’en général, tu codes plusieurs solutions, et les décisions, c’est quelqu’un d’autre qui les prends, et ce ne sont pas les problèmes techniques qui les dérangent…
Je maintiens donc que c’est une mauvaise idée de mettre ces préfixes. La bonne démarche serait de proposer un modèle pour cette fonctionnalité, que tout le monde se mettent d’accord sur l’interface (si plusieurs équipes de dev ont la même idée), on sort une rfc, puis chacun l’implémentera de son côté. Au final, une seule et même fonction/propriété, avec la même syntaxe partout, que l’on pourra tagger selon le résultat : “experimental” ou “stable”. Et c’est là ensuite seulement, que viendra la phase de test, qui permettra alors de déterminer qui de ie/firefox/etc, a fait la meilleure implémentation.
Ce sera un processus plus lent certes, mais ca rendra la vie bien plus simple à beaucoup de gens, et ca économisera de la ressource intellectuelle, car plus besoin de mobiliser 5 équipes différentes afin d’inventer 5 syntaxes et 5 papiers pour une seule et même fonctionnalité… C’est du gaspillage… Ces gens là pourrait contribuer à autre chose, mais pour des raisons futiles (finances/ideologie) on se fait la guerre. Puis au final, on est obligé de se mettre d’accord quand le bordel est devenu ingérable… pourquoi ne pas se mettre d’accord dès le début ?
Des trucs comme ça par exemple, est-ce franchement joli à voir ?
Ca n’aurait pas été plus intelligent de faire ainsi dès le début ?
La mise en page, c’est souvent un travail d’ajustement pixel par pixel, et quand y’a 5 fois la même propriété à changer ca devient vite barbant… Sans parler également du fait que tout le monde n’a pas les mêmes versions des mêmes navigateurs, bref le dev web rien qu’en ce qui concerne l’affichage identique sur tout les navigateurs, c’est déjà une galère, pas besoin d’en rajouter…
Mais tout ca c’est utopique… C’est après que l’une des fonctionnalités spécifique ait bien marché, que l’autre s’est bien engraissé de brevets, plusieurs procès, et que tout le monde s’est bien tapé dessus que les gens se résignent à se mettre d’accord.
Il aura bien fallu 5 versions d’html pour que apparaissent et propose une (semi)alternative aux flash/applet/silverlight… et sinon oui je connais aussi les balises et :o !
Bah AJAX, c’est Microsoft qui a commencé à développer ça pas de souci de compat avec IE (et c’est aussi un exemple de techno proprio qui est (trop mal) rentré dans les moeurs.
C’est surtout que les navigateurs peuvent proposer border-radius (ou autre) de différentes façons, donc la syntaxe n’est pas forcément celle retenue. Là où ça aurait pu être plus fin, c’est un truc genre -w3c-border-radius pour indiquer quelque chose en travail, et qui ne doit pas être utilisé comme tel.
Edité le 16/02/2013 à 12:09
En fait, avant que ne paraisse cet article : www.adaptivepath.com…
J’avais absolument aucune idée de l’existence même d’XMLHttpRequest… J’ai trouvé ça “révolutionnaire” (pour reprendre les mots de feu Steve Jobs) car ca solutionnait mon problème mentionné plus haut… pour plus tard me rendre compte que c’était juste une appelation et que la technologie datait de mathusalem ! L’article aura beau dire que XMLHttpRequest n’est qu’une partie de l’équation AJAX, mais sans XMLHttpRequest pas d’AJAX :s
Après pour le IE8 mini, c’est que pour les versions antérieures c’était un activex à installer(et des clients paranos), mais ce n’est pas la raison principale… c’est surtout que l’uniformité du rendu des pages sur les versions antérieures à IE 8 était tout simplement un casse tête et qu’il n’y avait plus de murs dans mon bureau pour y fracasser ma tête.
Edité le 16/02/2013 à 15:03
(et c’est aussi un exemple de techno proprio qui est (trop mal) rentré dans les moeurs.