je suppose que tu critique bien fort toutes les bibliothèques du genre libogg, libpng, etc. En effet, elle deviennent très rapidement en situation de presque-monopole.
Tu compares des motocyclettes avec des poids lourds de 30 tonnes. Tu compares des projets de quelques (dizaine de?) milliers de lignes de code, avec des projets qui en font plusieurs millions.
D'autre part, OGG, png et compagnie, sont spécifiées. Il y a une spéc, indépendante de l'implémentation, qui permet à quiconque de réaliser une implémentation. De plus, ces spécifications ne bougent pas toutes les quinzaines de jours (ça se compte plutôt en années). Alors, à part réécrire une implémentation pour le plaisir tous les 3 mois, il n'y a pas forcément d'intérêt à forker.
Et dans mon post, je parle du cas où il n'y a plus de spec au niveau HTML &co. Ce qui risque d'arriver car les spec HTML/CSS et autre technos sont en constantes évolutions, à tel point qu'il y a plein de trucs pas spécifiés dans webkit.
Il permet à tous de créer son propre moteur de recherche rapidement : il suffit de forker webkit et zou.
Moteur de recherche ? c'est quoi le rapport avec un moteur de rendu HTML comme webkit ?
Et forker webkit ? si c'est juste avoir 1 patch ou deux, ok. Mais forker pour faire des développements lourds, cela nécessite alors des gros moyens. La complexité d'un moteur de rendu HTML/CSS n'est en rien comparable avec celle d'une lib ogg ou jpeg.
Dans ce cas il me semble que mutualiser les efforts me semble aller dans le sens du progrès, puisque ça libère du temps pour faire autre chose : de nouvelles fonctionnalités, des tests plus poussés, se concentrer sur l'interface,
Oui et non. Si on veut standardiser, il faut deux implémentations (requises par le W3C), sur des bases de code différentes, si on veut pouvoir lever les problèmes d'une spécification. Cela est lié, encore une fois, à la complexité d'un moteur de rendu. Plusieurs implémentations valident le fait que cela est implémentable justement. Le fait que ce soit implémenté dans un projet ne permet pas de valider une spéc. Cela est déjà arrivé qu'un truc pouvait être implémenté dans un moteur et pas dans un autre, ou plus difficilement, à cause de l'architecture utilisée.
Sans être connaisseur, il me semble que le respect des normes HTML/CSS, etc. est surtout le fait des développeurs, qui utilise des trucs pas finalisé.
oui, mais ils ne devraient pas.
Il faudrait donc se poser la question pourquoi ces gens-là ne veulent pas se conformer aux normes ?
par incompétence. un vrai développeur web a conscience, selon moi, des conséquences de ne pas respecter les normes. Et donc, il ne doit pas utiliser des trucs expérimentaux, car il sait, quand il est compétent, que ce sont des trucs pas terminés, proprios, et donc qui ne fonctionnera pas dans les autres navigateurs. Pire, si c'est une feature qui devient standard, par exemple une propriété CSS, le prefixe -webkit-* (ou -moz-*) saute dans les versions suivantes du navigateur, et du coup la fonctionnalité utilisée sur le site n'existe plus. Bref, un site soit-disant "optimisé pour webkit" devient… non optimisé pour webkit. Un comble quoi.
[^] # Re: Analyse de glazou
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Opera passe à Webkit. Évalué à 2.
Tu compares des motocyclettes avec des poids lourds de 30 tonnes. Tu compares des projets de quelques (dizaine de?) milliers de lignes de code, avec des projets qui en font plusieurs millions.
D'autre part, OGG, png et compagnie, sont spécifiées. Il y a une spéc, indépendante de l'implémentation, qui permet à quiconque de réaliser une implémentation. De plus, ces spécifications ne bougent pas toutes les quinzaines de jours (ça se compte plutôt en années). Alors, à part réécrire une implémentation pour le plaisir tous les 3 mois, il n'y a pas forcément d'intérêt à forker.
Et dans mon post, je parle du cas où il n'y a plus de spec au niveau HTML &co. Ce qui risque d'arriver car les spec HTML/CSS et autre technos sont en constantes évolutions, à tel point qu'il y a plein de trucs pas spécifiés dans webkit.
Moteur de recherche ? c'est quoi le rapport avec un moteur de rendu HTML comme webkit ?
Et forker webkit ? si c'est juste avoir 1 patch ou deux, ok. Mais forker pour faire des développements lourds, cela nécessite alors des gros moyens. La complexité d'un moteur de rendu HTML/CSS n'est en rien comparable avec celle d'une lib ogg ou jpeg.
Oui et non. Si on veut standardiser, il faut deux implémentations (requises par le W3C), sur des bases de code différentes, si on veut pouvoir lever les problèmes d'une spécification. Cela est lié, encore une fois, à la complexité d'un moteur de rendu. Plusieurs implémentations valident le fait que cela est implémentable justement. Le fait que ce soit implémenté dans un projet ne permet pas de valider une spéc. Cela est déjà arrivé qu'un truc pouvait être implémenté dans un moteur et pas dans un autre, ou plus difficilement, à cause de l'architecture utilisée.
oui, mais ils ne devraient pas.
par incompétence. un vrai développeur web a conscience, selon moi, des conséquences de ne pas respecter les normes. Et donc, il ne doit pas utiliser des trucs expérimentaux, car il sait, quand il est compétent, que ce sont des trucs pas terminés, proprios, et donc qui ne fonctionnera pas dans les autres navigateurs. Pire, si c'est une feature qui devient standard, par exemple une propriété CSS, le prefixe -webkit-* (ou -moz-*) saute dans les versions suivantes du navigateur, et du coup la fonctionnalité utilisée sur le site n'existe plus. Bref, un site soit-disant "optimisé pour webkit" devient… non optimisé pour webkit. Un comble quoi.