C’est totalement prévisible maintenant que tous les navigateur tourne sous blink/chrome. Qu’est ce que l’on va s’en faire chier sur des spécificité d’un navigateur minoritaire là où une solution facile fonctionne très bien sur la majorité des navigateur.



Et je le rappelle, les “standards du web” ne font pas loi, c’est que des recommandations de la W3C qui n’a aucune autorité légale là dessus.

C’est un exercice de pensée je rappelle que Schrödinger n’a torturer aucun chat.



C’est pourtant exactement ce qui est dit : Twitter a utiliser un comportement indéfini (faut-il encore savoir que ce comportement est indéfini) et ça ne pose aucun problème pour la très vaste majorité des utilisateurs ce que Mozilla a répondu qui oui mais non, ce n’est pas comme ça qu’il faut faire selon la W3C.



En effet, si tu as déjà développé, tu fais souvent du code de manière empiriques : tu testes, ça fonctionne comme tu souhaitse, bon, ben ok, ça passe. Comme tu le dis, internet c’est complexe (putain la dernière fois que j’ai fait du web, je me suis pris la t^te tellement c’était le bordel), tu ne peux pas forcément tout connaître, et donc si tu trouve un façon de faire qui fonctionne (après avoir testé une vingtaine de solutions trouvées sur stackoverflow), tu acceptes que ça fonctionne ainsi et que c’est normal jusqu’au jour où ça ne fonctionne pas.



Et là j’en viens au soucis de productivité. SI tu bosses en SSII, si ce n’est pas dans le cahier des charge, ne le fait pas, tu ne gagneras rien à le faire. Firefox c’est 7% du marché, est-ce que c’est rentable de supporter à 100% ce navigateur ? bien souvent ça passe à peut prêt bien, c’est pratiquement invisible, c’est souvent sur des fonctionnalités bien poussées, un petit catch d’erreur et tu passe ça sous le tapis ni vue ni connus ça fait l’affaire.



Par exemple ici, les utilisateurs de Firefox n’ont pas été inpacté dans leur utilisation de Twitter, le site fonctionnait parfaitement bien. Le seul soucis, c’était que si tu éteignais ton navigateur (qui ferme son navigateur aujourd’hui ?) ben le cache qui aurait du être supprimé ne l’est pas. Là en tant que dev, tu as 3 possibilité : tu t’en fout, tu trouve une solution propre (à priori c’est ce qui a été fait) où à defaut un bidouillage pour que ça passe. Dans ce dernier cas, si aucune solution n’était trouvable (ce qui n’est pas le cas ici), Twitter aurait pu tout à fait supprimer l’utilisation du cache sur firefox pour les données sensibles, ça aurait fait le taf à 100%, Twitter aurait alors été juste moins rapide sur firefox. Mais bon, on s’en branle, firefox c’est très minoritaire, et ça fonctionne quand même très bien.

manu-smx a écrit :



Je suis pas dev, mais clairement le « tu teste, ça fonctionne, ben ok » non ! Oui pour du test, oui pour un projet sans ressources, oui pour une blague, mais non pour un truc autant utilisé que le site de twitter.

C’est à cause des comportements comme ça, « ça fonctionne donc c’est bon » notamment, « qu’on a des PC de plus en plus puissants mais de plus en plus lents ».

Arrêtons de miser sur le low-cost, le vite-fait, bien fait. J’en ai marre des gens qui ne font pas leur taff correctement, c’est insupportable.



Et le côté, domination de google, je ne peux pas rester neutre non plus dessus, les monopoles sont et resteront toujours à éviter dans notre société d’humains égoïstes.



stou pour moi ! :)







Aujourd’hui, on ne développe plus en assembleur vanilla, on développe avec des bibliothèque qui sont elle même développé avec des bibliothèques…

Par exemple, si tu développes dans un langage compilé, tu ne sais pas forcément ce que va faire le compilateur. Je ne connais personne qui a lu un jour le code de GCC (compilo C open source de Linux). On peut avoir une vague idée de ce qui devrait se passer au minimum, je sais aussi qu’il y a des tonne d’optimisation dont je ne connais pas les détails. Du coup, même un langage aussi simple et bas niveau que C, je suis incapable de te dire ce qui se passe réellement derrière.

Pour ainsi dire, c’est impossible de développer comme on développé dans les années 80 en assembleur vanilla sur des processeurs x86 qui avait encore une véritable architecture de x86 documenté (depuis les pentium c’est une architecture RISC qui émule du CISC : on nous ment déjà matériellement).



De plus, l’autre point est que l’on développe de moins en moins en langage compilé et bas niveau et on va privilégier la simplicité et la souplesse des langages interprétés (ou compilé à la volée) ce qui nécessite forcément plus de ressource pour une même fonction. Cependant, là où il a fallut 3 jours à développer dans le premier cas, ça n’a pris que 1h en utilisant la bonne bibliothèque.



Par exemple, Twitter a développé une boite à outils pour créer l’affichage de site web : bootstrap. Mais la team qui le développe et celle qui l’utilise ne sont surement pas les même et je pense que bon nombre de personne qui l’utilise n’ont pas une connaissance total de ce qu’il y a derrière.







zefling a écrit :



Je peux à peu près te dire ce qu’il peut se passer. Google décidera tout seul de l’avenir du web, c’est son équipe qui accepte les pull request. La documentation du W3C n’aura plu aucun valeur, c’est le code source de Blink qui sera la référence (et bien-sûr ces bug comme à l’époque d’IE6). De faite, aucune fork ne sera longtemps valide, car il finira par s’écarter du comportement de Blink qui est la référence.

Le HTML/CSS ne pourront servir que pour le web, et rien d’autre. Actuellement il existe de moteurs pour d’autres applications : libre, pdf.



Actuellement le fait qu’il y ait des instances extérieurs qui marchent sur un consensus, ce qui permet d’avoir plusieurs implémentation pour vérifier que la spéc n’est pas débile. On peut même participer, j’ai déjà fait une remarque sur une des spécs du W3C qui a été acceptée.

Si on était parti sur c’est le premier qui a raison, on aurait la spéc pourrie des Flexbox, la spéc pourrie des Grid Layout (réécrite 2 fois), et j’en passe (y’en a plusieurs en réécriture ou abandonnées, car elles ne servent à rien ou font doublon). On pourrait aussi avoir des trucs balises spécifiques que seul Google Chrome comprendra l’intérêt. C’est pas parce que c’est open source que tout le monde lit le code, s’il faut lire le code source pour comprendre un truc, presque aucun développeur web le fera. Perso, quand je regarde le code de WebRender, je comprends pas grand-chose.



Et pour finir, Google Chrome n’est pas open source, Chromium l’est. Perso, je ne connais pas la différence exacte entre les deux, mais je peux vous dire que c’est pas un juste un Chromium recharté.







Pourquoi tu parles de PDF alors que PDF est une format créé, détenu et géré par Adobe ? Et les logiciel gérant le PDF autre qu’Acrobat Reader, je n’en connais pas qui gère l’intégralité des spécificications de PDF.



De nombreux langage de programmation sont géré plutôt de manière centralisé (si ce n’est pas la plupart) et pourtant ils évoluent, les remarques et le critiques de la communauté sont pris en compte… ca fonctionne plutôt bien. Ce n’est pas parce que Google pourrait avoir le dernier mot qu’il ne va pas tenir compte des remarque de la communauté.



TU remarquera que je parle plus de Blink que de Chrome, car ici c’est le moteur qui est important, pas la fenêtre autour. Je sépare bien le navigateur du moteur de rendu. Edge, Opera, Brave, Chrome sont 4 navigateurs, mais ils partagent le même moteur (plus ou moins).

Oui, mais les spec d’HTML/Javascript sont toujours ouverte aussi (après, je me rappelle d’acid test sur lequel même avec des spec ouvertes aucun navigateur n’y arrivait)

Mais comme j’ai dit, même si PDF c’est ouvert, ça permet de créer des PDF simple correct, mais je ne sais pas s’il existe beaucoup de bibliothèque capable d’utiliser l’intégralité des spécificité de ce format. En tout cas les lecteurs PDF capables de les exploiter sont rares, voir il n’existe que celui d’Adobe

Par exemple on peut avoir de la 3D interactive comme dans ce PDF, firefox et sumatra PDF disent niet.



Pour les DRM (et plus exactement les EME), ça ne semble pas poser de problème pour firefox. Et il me semble que c’est justement passer par la W3C selon le protocole normal prévu et pas par la pression d’un unique acteur comme Google. Justement, ça montre que même le système actuel permet ce genre de chose.

AMP : les spécs sont toujours open source et disponible gratuitement (bonjour C++) tout comme PDF que tu cites plus haut.

Dart : je ne sais pas ce que ça vaut. Personnellement, tout ce qui pourrait remplacer javascript ne peut pas être pire que javascript (je n’ai pas encore croisé IRL quelqu’un qui aime javascript). Sinon, j’ai rien à dire là dessus. Je sais aussi que MS développe Typescript qui lui est transcompilé en javascript et de ce que j’ai cru comprendre, ça fait son petit bout de chemin.