Google et Blink tournent le dos au W3C et à Pointer Events de Microsoft

Google et Blink tournent le dos au W3C et à Pointer Events de Microsoft
au profit de Touch Events d’Apple ?

Google et son moteur de rendu Web Blink ont finalement tranché en défaveur du standard du W3C, en effet à travers un bref communiqué sur la plateforme de développement de Blink, Google vient d’annoncer l’abandon de l’API Pointer Events, jusqu’ici présentée comme le futur standard du W3C en remplacement de Touch Events.

Pour rappel Blink est le fork du célèbre moteur de rendu web Webkit actuellement utilisé par Opéra, Safari et précédemment par Google Chrome (avant d’être remplacé par Blink), alors que l’API Pointer Events est un ensemble de spécifications permettant à un navigateur de répondre aux spécificités du web sur mobile et à l’interaction tactile, l’API a été développée par Microsoft en réponse à l’imbroglio causé par Apple, qui a refusé de mettre à disposition du W3C son API Touch Events suite à un conflit de brevets.

Même si Pointer Events est plus sophistiquée que Touch Events, car conçue de manière à prendre en charge différentes entrées : tactile, stylet et souris en recourant au même Framework, ce qui est non négligeable du point de vue des développeurs, Google a avancé plusieurs arguments pour justifier sa décision.

En premier lieu, Google justifie cette décision par des problèmes de performance constatés avec l’implémentation de Pointer Events sous Blink, alors que le géant de l’IT « ne souhaite aucunement ajouter une fonctionnalité qui augmenterait encore plus le désavantage des performances du web par rapport aux plateformes mobiles natives ». Autre argument avancé, les spécifications de Pointer Events empêchent la mise en œuvre de concepts désormais communs comme le fameux tirer pour rafraîchir.

Toutefois, la véritable raison est à chercher ailleurs, les arguments techniques avancés par Google sont jugés trop faibles pour expliquer ce revirement, le principal argument de Google est le suivant : « Pointer Events ne pourra jamais supplanter Touch Events sur le Web (surtout sans le support de Safari). De ce fait, si Touch Events reste un acteur majeur du paysage, le support d’une autre technologie similaire se révèle coûteux en termes de complexité sur le long terme ». Ce dernier facteur avancé est pour le moins surprenant et semble être en faveur de la marque de la pomme, car il sous-entend l’adoption de Touch Events.

Mais la réalité est peut-être ailleurs, Google songe peut-être à développer sa propre API qui serait un compromis des deux, en tenant compte des avantages offerts par Pointer Events de Microsoft et de Touch Events d’Apple qui est déjà présent sur Webkit, quant à son adoption, cela ne peut représenter un obstacle pour Google qui règne sur 80 % de l’écosystème mobile grâce à Android.

Source : Annonce sur la plateforme de développement de Blink

Et vous ?
:fleche: Qu’en pensez-vous ?

Et voila, Google continue de faire sa soupe dans son coin.

Avant, les dev Web pestaient contre IE, maintenant on va pouvoir pester contre IE (et oui toujours) et Chrome en plus...

On va vraiment devoir reclasser le métier de développeur web dans une catégorie de « sado-mazo » quand il faudra faire de la compatibilité cross-browser...

Merci Google.

PS: En même temps, grâce à ce genre de comportement discutable, ça permet d'entrevoir un avenir fort long pour le métier de développeur web...

C'est comme s'ils n'avaient rien retenu du passé. Le web a besoin de standards que tout le monde respecte. Entre les 200 nouveaux langages censés remplacer Javascript et les moteurs de rendu ne répondant pas aux mêmes évènements, le développeur du futur n'a pas fini de perdre ses cheveux.

Citation:

---

En premier lieu, Google justifie cette décision par des problèmes de performance constatés avec l’implémentation de Pointer Events sous Blink

---

Traduction : "nous ne sommes pâs capable d'optimiser notre truc, et nous n'en avons pas envie" 8O

Citation:

---

Mais la réalité est peut-être ailleurs, Google songe peut être à développer sa propre API qui serait un compromis des deux, en tenant compte des avantages offerts par Pointer Events de Microsoft et de Touch Events d’Apple qui est déjà présent sur Webkit, quant à son adoption, cela ne peut représenter un obstacle pour Google qui règne sur 80 % de l’écosystème mobile grâce à Android.

---

Ce ne serait pas un abus de position dominante, ça, par hasard ?

Après, il y a là beaucoup de spéculations. Reste à voir comment va se dérouler la suite.

MDR !!!

Ayant commencé à dev des sites au collège à l'époque de frontpage pour les noobs et Webexpert pour les oufs, j'ai compris que niveau web il faut adopter l'attitude de "J'en ai rien à foutre". En gros simplement ignorer 99% des trucs débiles qui sortent chaque jour et en rester à l'essentiel. On assiste à une boulimie que dis-je à une chier de Frameworks redondants et bien souvent inutiles. Au niveau des APIs pareil faire du standard si Google veut faire nawak tant pis.

J'aimerais juste comprendre.. pourquoi est-ce que google tournerait le dos à la W3C ? Les pointer Event ont été inventés par Microsoft et la specs est en Candidate Recommandation, c'est donc proposé par MS et pas encore adopté en tant que norme.. http://www.w3.org/TR/pointerevents/

Après, cela soulève peut-être un débat sur pourquoi, dans un domaine qui change en permanence comme l'informatique, le W3C met des années à valider la moindre petite évolution.

Citation:

---

Ce ne serait pas un abus de position dominante, ça, par hasard ?

---

N'est-ce pas de cette manière dont Microsoft a gagné la "Guerre" contre Netscape ?

Les développeurs web ayant déjà eu à faire ce genre de pratique dans le passé, ils sauront vite faire le tri entre les possibles évolutions de normes du W3C et le rebut.
Grosse différence par rapport à l'époque IE/Netscape c'est justement le W3C. J'ai l'impression que les développeurs web préfère suivent les normes qui évoluent plus lentement (mais surement) que les normes propriétaires (qui peuvent devenir du gros n'importe quoi du jour au lendemain).

Donc Google implémentera peut-être son API mais continuera de respecter les normes si ils ne veulent pas perdre une partie de la part de marché qu'occupe Chrome.

De plus, qui dit que le W3C n'adoptera pas l'alternative de Google dans ses normes ? Dans ce cas, IE seul sera à la traîne (et Safari [troll]mais qui l'utilise en dehors des utilisateurs mac ?[/troll]).

Citation:

---

Après, cela soulève peut-être un débat sur pourquoi, dans un domaine qui change en permanence comme l'informatique, le W3C met des années à valider la moindre petite évolution.

---

Selon moi, c'est justement pour ralentir cette évolution et permettre ainsi qu'Internet ne devienne pas un gloubiboulga immonde de truc propriétaire. Même si c'est ce que veulent Apple, Microsoft et Google.

Citation:

---

Selon moi, c'est justement pour ralentir cette évolution et permettre ainsi qu'Internet ne devienne pas un gloubiboulga immonde de truc propriétaire. Même si c'est ce que veulent Apple, Microsoft et Google.

---

Certes, mais il y a sans doute un juste milieu à trouver. Quand on voit que la norme HTML5 vient tout juste d'être complétée officiellement alors qu'elle est utilisée depuis des années en production et attendue depuis encore bien plus longtemps, il y a de quoi se poser des questions.

C'est parce qu'il y a trop de monde pour décider ce que tous les autres doivent respecter. Du coup les normes mettent trop de temps à venir, ce qui ouvre une brèche à certains pour leur permettre de faire ce qu'ils veulent.

Le juste milieu, je pense, serai de retirer les IT du W3C. Car je pense qu'ils profitent de ce fait pour implémenter ce qu'ils veulent pour que ca devienne une norme. Alors que si ils ne sont pas dedans, ils devront attendre comme tout le monde.

Citation:

---

Envoyé par Sodium

Après, cela soulève peut-être un débat sur pourquoi, dans un domaine qui change en permanence comme l'informatique, le W3C met des années à valider la moindre petite évolution.

---

Parce que lorsque l'on doit établir des spécification génériques mais précises (pour éviter les "corner case") qui couvrent au mieux les différent cas d'utilisation et qui fasse autant que possible consensus, ça prend du temps.
Et pour les pressés qui voudraient se lancer dans une implémentation expérimentale, les brouillons sont disponibles.

Citation:

---

Envoyé par demonixis

J'aimerais juste comprendre.. pourquoi est-ce que google tournerait le dos à la W3C ? Les pointer Event ont été inventés par Microsoft et la specs est en Candidate Recommandation, c'est donc proposé par MS et pas encore adopté en tant que norme.. http://www.w3.org/TR/pointerevents/

---

Toutes les normes sont proposées par quelqu'un et dans la grande majorité des cas ce sont les développeurs de navigateur(Google,Mozilla, Microsoft,...) mais si elle ne fait pas un minimum consensus elle ne progressera pas.
En général quand elles ont atteint le statut de Candidate Recommandation c'est que le travail a le soutien de plusieurs acteurs et qu'on est plus loin de la validation définitive. Mozilla et Microsoft ont déjà une implémentation de la norme.
Donc le fait que Google renonce a l'implémentation qui faisait consensus auprès de tous les acteurs sauf Apple n'est pas anodin.

Citation:

---

Envoyé par demonixis

J'aimerais juste comprendre.. pourquoi est-ce que google tournerait le dos à la W3C ? Les pointer Event ont été inventés par Microsoft et la specs est en Candidate Recommandation, c'est donc proposé par MS et pas encore adopté en tant que norme.. http://www.w3.org/TR/pointerevents/

---

Le statut "Candidate Recommandation" indique quand même que le W3C s'y intéresse de près, et l'actualité autour de cette spec semblait tendre vers son adoption. Mais sur le fond tu as raison, ce titre n'est pas mérité et même si je suis un peu agacé d'attendre une vraie spec pour la gestion unifiée tactile/souris, je suis aussi curieux de voir ce que Google pourrait proposer comme spec par l'intermédiaire du WHATWG. Débattre et réviser sa copie plusieurs fois n'est pas une mauvaise chose, seulement les standards traînent un retard de plusieurs années sur les enjeux business du One Web. On a besoin d'un standard dès maintenant !

C'est quand même marrant ce qui se passe actuellement.
Microsoft qui essaie de respecter les standards et Google qui essaie de les contourner de plus en plus fréquemment.
Je ne peux pas dire que ça me surprend vu que je n'ai jamais vraiment apprécier Google et son hypocrisie légendaire.
Je suis sérieusement en train de considérer de zapper Android à court terme et de me passer de leur moteur de recherche à moyen terme.
Je n'appréciais Microsoft du temps où ils étaient presque tout-puissant dans le monde de l'informatique, et a foutu une sacré pagaille dans bien des domaines, donc je ne vois pas pourquoi j'apprécierais une compagnie hypocrite qui n'aspire qu'à nous faire retourner dans un contexte similaire.
Vivement qu'il y ait une vraie et saine concurrence, avec respect des standards, dans le monde de l'informatique et que jamais plus une compagnie ne se retrouve à la place que Microsoft avait dans le passé.

Bon vu que c'est pas clair pour tout le monde, je résume:
Les Pointer Events sont une proposition de standard, majoritairement poussée par Microsoft, à l'étude au W3C.
La position de Google est de rester et d'étendre l'API standard actuelle, les Touch Events, qui est déjà très largement utilisée. Ils feront en parallèle leurs propres propositions, comme l'a fait Microsoft pour les Pointer Events et comme le font régulièrement nombreux éditeurs et indépendants.

Bref il n'y a pas de gentil/méchant dans l'histoire, juste des opinions différentes sur les standards à adopter. Chaque équipe continuera à implémenter les standards adoptés et à faire leurs propres propositions, personne ne tourne le dos aux standards contrairement à ce que suggère le titre accrocheur de cet article...

Pointer Events initié par Microsoft devient une recommandation du W3C
Google et Apple vont-ils suivre ce nouveau standard ?

Depuis l’apparition des petits équipements à interface tactile, la souris et le clavier n’ont plus l’apanage de la référence en matière d’outils permettant d’agir directement sur le contenu des équipements informatiques. D’autres formes d’entrées telles que la gestuelle ou le stylet ont vu le jour ou du moins leur usage a été fortement renforcé. Aussi, pour encadrer les évènements issus de ces différentes formes de déclencheur d’évènements, le W3C a publié une recommandation de la norme Pointer Events. Cette norme définit le code entourant les évènements issus de l’utilisation du stylet, du doigt et de la souris sur un équipement à interface tactile ou non.

En principe, lorsqu’une nouvelle recommandation est publiée, les différents éditeurs de navigateurs devraient adhérer afin d’éviter une balkanisation du web. Mais force est de constater que ce n’est toujours le cas.

Il faut souligner que cette norme compte à son passif une grosse histoire. En effet, avant qu’elle ne soit définie, chaque acteur du web utilisait ses propres implémentations. Apple pour sa part a mis en œuvre son API nommée Touch Events qui régit les évènements issus de la gestuelle tels que le clic ou le zoom… sur ses appareils tactiles. Vu l’écosystème imposant de la firme à la pomme, le W3C a voulu faire de Touch Events une norme du web, mais s’est heurté à l’argument du brevet détenu par Apple.

Ne disposant d’aucune norme internationale sur le web à ce sujet, Microsoft a écrit de bout en bout tout le code entourant le principe de fonctionnement des évènements liés à l’interaction avec les interfaces tactiles et l’a appelé Pointer Events. C’est cette norme qui après avoir été proposée au W3C, vient de passer à l’étape de recommandation après avoir fait l’objet de plusieurs améliorations apportées par d’autres géants du web.

Google a, contre toute attente, rejeté Pointer Events depuis le stade des travaux de mise en œuvre, mais semble plus ouvert pour avancer sur la question. Mozilla en ce qui le concerne est en cours d’intégration de cette recommandation. Apple, par contre, a depuis lors soumis Touch Events au W3C qui l’a validée et recommandée. En outre, vu que Touch Events ne couvre que quelques aspects de Pointer Events, nous attendons de voir sa réaction.

Avec cette recommandation, le débat sur l’intégration de Pointer Events semble bien relancé. De Touch Events qui est utilisé par certains, mais exclut la souris ou Pointer Events qui est passé au statut de norme du web, lequel aura le dernier mot.

Source : W3C


Et vous ?

:fleche: Que pensez-vous des positions mitigées des différents éditeurs de navigateurs ?

:fleche: Comment pensez-vous le Touch Events community group accueillera cette annonce ?

J'aime comment la spec a évolué, ils n'ont pas figé l'interface Event pour laisser place à d'éventuels nouveaux périphériques (par exemple les dispositifs de réalité virtuelle qui nécessiteraient un clientZ ou quelque-chose du genre).