Discussion :

[Uther]

autant le premier je pourrais être d'accord, ça ne facilite clairement pas la distribution de logiciel libre (et encore, moi quand je vais chercher firefox, je le demande pas à mon voisin, donc je vais direct sur le site, donc l'excuse s'essouffle un peu) ;

Avec la licence à 6,5M$ la redistribution a l'identique serait acceptée.
Mais, un logiciel libre au delà d'un logiciel que l'on peut recopier c'est surtout un logiciel que l'on peut modifier et redistribuer avec ses modifications sans avoir à payer, ce qui ne serait plus vrai.
Utiliser H264 directement dans Firefox le rendrait non libre(du moins dans les pays ou ils sont valides), à partir du moment ou le MPEG-LA décide de faire valoir ses droits.

Ce que tu ne comprend pas c'est que pour Mozilla, il ne s'agit pas d'une question de pratique, sinon, ils auraient payé depuis bien longtemps. Ils font du logiciels libre d'abord par principe, parce qu'ils y croient. Faire du logiciel libre est dans le Manifeste de la fondation Mozilla.

autant là je ne suis pas d'accord, le web t'impose un seul et unique modèle de développement, il a beau être "libre", il est totalement dictatorial, ce qui n'est pas beaucoup mieux que d'avoir des technos propriétaires.

L’intérêt d'une entité de normalisation comme le W3C est justement que le pouvoir de décision ne repose pas sur une seule société. Et tous les choix sont intensément discutés.

Après rien ne t’empêche de faire autre chose que du web. Microsoft a essayé avec MSN sur Windows 95, il s'y est cassé les dents. L’intérêt du web c'est justement d'avoir un environnement ouvert et (relativement) cohérent.

la liberté c'est de pouvoir choisir, donc il faut le x264 ainsi que le vp8, ça fait de la concurrence, le reste du web devrait en prendre de la graine

En effet deux format videos de qualité presque identique mais incompatibles, ça c'est une très bonne leçon.

Pour pousser ce merveilleux modèle encore plus loin, chaque navigateur devrait utiliser ses propres balises, ses règles de layout, ses langages de script et on sera bientôt revenu aux temps du duel Netscape/IE, sauf que maintenant comme ils sont encore plus nombreux, ça sera encore plus de bonheur en perspective.

[stardeath]

Pour pousser ce merveilleux modèle encore plus loin, chaque navigateur devrait utiliser ses propres balises, ses règles de layout, ses langages de script et on sera bientôt revenu aux temps du duel Netscape/IE, sauf que maintenant comme ils sont encore plus nombreux, ça sera encore plus de bonheur en perspective.

(je suppose pour la suite que "merveilleux" est teinté d'une pointe non négligeable d'ironie)

totalement, et en quoi ça ferait du mal? gtk, qt, wxwidgets et win32 ont des syntaxes totalement différentes avec chacun son public et pourtant avec ces technos on peut faire des softs tournant sous windows et il n'y a pas de problème.

afficher un bouton, une checkbox ou autre ce n'est qu'une suite de points et/ou de ligne droite, le niveau d'abstraction au dessus permet la création des technos citées précédemment, pourquoi ne pourrait il pas y avoir la même chose pour le web?

et pire encore, les plugins (décriés par les intégristes du web) permettaient ça sans remettre en cause le sacro-saint html.

demain on dirait dans le développement desktop "il n'y aura plus que le dév qt qui marchera" on aurait une levée de bouclier, sur le web, non, on impose quelque chose par le dictat et on a le droit que de dire amen.

n'avoir qu'un seul compétiteur aura pour conséquence un appauvrissement des technos.

[Uther]

totalement, et en quoi ça ferait du mal? gtk, qt, wxwidgets et win32 ont des syntaxes totalement différentes avec chacun son public et pourtant avec ces technos on peut faire des softs tournant sous windows et il n'y a pas de problème.

Justement les standards du web sont aux navigateurs ce que Qt ou WxWidget sont aux différents système d'exploitations : une couche de compatibilité.
Si Qt ou wxWindows ne fonctionnaient pas de manière à peu près identique sous les différents OS qu'il supportent, ils perdraient une très grande partie de leur intérêt.

[souviron34]

totalement, et en quoi ça ferait du mal? gtk, qt, wxwidgets et win32 ont des syntaxes totalement différentes avec chacun son public et pourtant avec ces technos on peut faire des softs tournant sous windows et il n'y a pas de problème.
..
n'avoir qu'un seul compétiteur aura pour conséquence un appauvrissement des technos.

Tout à fait..

Justement les standards du web sont aux navigateurs ce que Qt ou WxWidget sont aux différents système d'exploitations : une couche de compatibilité.
Si Qt ou wxWindows ne fonctionnaient pas de la même manière à peu près identique sous les différents OS qu'il supportent, ils perdraient une très grande partie de leur intérêt.

Certainement,mais on peut pointer (avec ton post et l'autre) que tout ceci n'est quand même que de nouveaux outils/widgets par rapport à un standard qui existait avant eux .. SAUF chez M$... :

X11 et Motif..

Ils avaient été été établis par un consortium englobant tous les franiquants d'ordis.. Mais M$ n'a pas voulu s'y intégrer...

Motif était conçu pour avoir une couche dépendante du constructeur/distributeur, et le reste commun. L'implantation des widgets dépendait des constructeurs, mais ni leur définition , ni leur API...

Un seul code tournait partout....

Mais M$ a refusé de l'implanter... (alors que SCO l'avait fait, sur de PC)

Du coup, quand l'explosion marketing de M$ à la fin des années 90 sur VC++ est arrivée en force, il fallait que "tout tourne sur Windows".. Vu que M$ refusait X11 et Motif, on est reparti à zéro....

Et on a donc déjà plusieurs "boites à widgets" (celles que vous citez, mais on peut aussi citer KDE et Gnome pour Linux), qui font que passer le même programme d'une boîte à une autre est complexe....

Alors que la solution X11/Motif marchait parfaitement de manière transparente.. : le programme n'avait pas besoin d'être modifié, c'était la DLL fournie par le constructeur/distributeur de l'OS qui avait fait ses looks et additions par dessus le standard, qui était prévu pour ça..

Tout ceci dû uniquement à la force de marketing de M$ et la méconnaissance des décideurs... (et la démocratisation via le Web, qui a poussé encore plus vers Win et M$)



Quant au codec dont on parle, je regrette fortement le temps du consortium MPEG...

[stardeath]

donc tu confirmes qu'il n'y a aucune raison d'empêcher des technos concurrentes d'html à arriver sur le marché.

bah oui, avoir une api différente n'empêche pas d'avoir un rendu à base de même composant, on pourrait donc très bien programmer un site web en python, ruby ou autre et que le navigateur traduise ça en visuel de site web.

pour continuer, les plugins sont justement une continuité de qt ou wxwidget, ils fonctionnent de manière identique sous les différents OS qu'il supportent et le tout pour fonctionner soit dans l'environnement du navigateur ou même de manière autonome.

bref aucune raison de se soumettre au dictat actuel.

[souviron34]

donc tu confirmes qu'il n'y a aucune raison d'empêcher des technos concurrentes d'html à arriver sur le marché.

On ne peut empêcher..

Mais on peut regretter ..

bah oui, avoir une api différente n'empêche pas d'avoir un rendu à base de même composant, on pourrait donc très bien programmer un site web en python, ruby ou autre et que le navigateur traduise ça en visuel de site web.

???

Le LANGAGE HTML est fait pour ça, non ???


Tu confonds API et IDE..

ça n'est pas le NAVIGATEUR qui devrait traduire.. C'est l'outil qui sert à fabriquer le site..

Sinon ça veut dire que le navigateur doit être polyglotte, et n'est donc plus un standard..

Quand tu utlises du IP, tu programmes à partir d'une bibliothèque de sockets. C'est CETTE biblothèque qui formatte correctement.. Que tu ait utilisé Python, Java, .Net ou xx pour fabriquer ton prog, il marchera sur la machine pour laquelle tu l'as compilé... MAIS il commhniquera avec tout autre prog basé sur le même standard, quel que soit l'outil utilisé pour le fabriquer..




Moi je parlais des API des widgets : tu fais un site avec qt.. Si tu veux passer à wxwidget, il te faut tout refaire..

[stardeath]

les navigateurs actuels sont déjà des interpréteurs de langages à base de balise et scripts, qu'est ce qui empêcherait le fait qu'ils soient polyglottes

et surtout en quoi ça rentre en conflit avec un standard

ce qui est marrant c'est que systématiquement vous associez web et html, le html n'est pas le web.

Quand tu utlises du IP, tu programmes à partir d'une bibliothèque de sockets. C'est CETTE biblothèque qui formatte correctement.. Que tu ait utilisé Python, Java, .Net ou xx pour fabriquer ton prog, il marchera sur la machine pour laquelle tu l'as compilé... MAIS il commhniquera avec tout autre prog basé sur le même standard, quel que soit l'outil utilisé pour le fabriquer..

nié? je parle de morceaux de scripts/codes qui seront interprétés par le navigateur, et de plus, même si on compilait le site web, rien n'empêche non plus la compilation dans un langage intermédiaire qui sera recompilé ou interprété par le navigateur cible.

[Uther]

donc tu confirmes qu'il n'y a aucune raison d'empêcher des technos concurrentes d'html à arriver sur le marché.

Une techno concurrente et totalement séparée de la pile HTML/CSS/Javascript/..., qui permettrait de faire fi des lourdeur héritées du passé, je serais tout a fait pour.
Par contre une techno qui rajoute encore plus d’incompatibilités à HTML ou rajoute une nouvelle rustine par dessus, non merci.

bah oui, avoir une api différente n'empêche pas d'avoir un rendu à base de même composant, on pourrait donc très bien programmer un site web en python, ruby ou autre et que le navigateur traduise ça en visuel de site web.

Tout dépend de quoi on parle. Dans toute technologie interopérable, il y a forcément un niveau commun quelque part pour mettre les gens d'accord.
Pour les navigateurs, le dénominateur commun c'est les spécifications du W3C.

pour continuer, les plugins sont justement une continuité de qt ou wxwidget, ils fonctionnent de manière identique sous les différents OS qu'il supportent et le tout pour fonctionner soit dans l'environnement du navigateur ou même de manière autonome.

Sauf que un plugin :
- reste une rustine par dessus HTML.
- n'est pas garanti d'être présent.
- peut poser énormément de problèmes de disponibilité, sécurité, ...

Bref s'il peut permettre de résoudre un problème que les technologies standard ne permettent pas de traiter, pourquoi pas. Mais s'il y a une solution propre avec les standards autant s'en passer.

les navigateurs actuels sont déjà des interpréteurs de langages à base de balise et scripts, qu'est ce qui empêcherait le fait qu'ils soient polyglottes

Et qui déciderait de tous les langages a supporter?
Si Google décide de gérer une techno X, qui est un doublon de la techno Z de Mozilla et au passage exclut techniquement la techno Y de Microsoft. Comment on se sort de se merdier?
Est ce que tous les navigateur devraient implémenter toutes les technos que n'importe qui propose, alors qu'il ont déjà assez de travail à implémenter seulement les technologies standard?

[stardeath]

Une techno concurrente et totalement séparée de la pile HTML/CSS/Javascript/..., qui permettrait de faire fi des lourdeur héritées du passé, je serais tout a fait pour.
Par contre une techno qui rajoute encore plus d’incompatibilités à HTML ou rajoute une nouvelle rustines par dessus, non merci.

totalement. mais il y a quand même un point positif aux rustines, genre coffee script, dart ou autre c'est que c'est testable très vite, par contre tu admettras surement que je ne pense pas me tromper en disant que le monde du web ne veut pas quelque chose d'autre, rien qu'à voir ici la levée de bouclier contre coffee script, dart ou autre avec des arguments aussi fallacieux que "le web c'est html + js + css".

Tout dépend de quoi on parle. Dans toute technologie interopérable, il y a forcément un niveau commun quelque part pour mettre les gens d'accord.
Pour les navigateurs, le dénominateur commun c'est les spécifications du W3C.

le w3c n'a pas, je n'ai pas trouvé en tout cas, défini les composants standards d'une page web tel que les boutons, les champs de texte, etc.
bref sur ce point je suis d'accord, il faut que quelqu'un décide soit des composants hauts niveaux (boutons, champs de texte, etc.) soit des primitives de dessins plus "bas niveau", ou les 2 pour avoir un set utilisable et extensible.

Sauf que un plugin :
- reste une rustine par dessus HTML.
- n'est pas garanti d'être présent.
- peut poser énormément de problèmes de disponibilité, sécurité, ...

Bref s'il peut permettre de résoudre un problème que les technologies standard ne permettent pas de traiter, pourquoi pas. Mais s'il y a une solution propre avec les standards autant s'en passer.

cf mon commentaire au dessus, le moindre affront provoque systématiquement un rejet pur et simple, visiblement le monde du web n'a pas l'air de pouvoir supporter que l'on souhaite pas faire du html+css+js pour faire un site web.

Et qui déciderait de tous les langages a supporter?
Si Google décide de gérer une techno X, qui au passage et exclut techniquement la techno Y de Microsoft, et qui est un doublon de la techno Z de Mozilla. Comment on se sort de se merdier?
Est ce que tous les navigateur devraient implémenter toutes les techno que n'importe qui propose, alors qu'il ont déjà assez de travail à implémenter seulement les technologies standard?

la mode du moment dans le développement de navigateurs ce n'est certainement pas la complétion des specs html5, mais plutôt qui va afficher un pouième de nanoseconde plus vite un site web par rapport à un concurrent ... et aussi accessoirement qui va arriver à un numéro de version de son logiciel à 3 chiffres.
donc sur la masse de travail rien que pour les specs html5, il y en a surement (je ne me fais pas d'illusion), mais ce n'est pas du tout ce que les éditeurs montrent.

c'est pour ça que d'une part je suis pour les plugins, ceux qui les utilisent, tant mieux, ce qui ne veulent pas, tant mieux aussi, chacun est libre de ses choix, même si le site sera finalement moins accessible ;
et pour les rustines, qui offrent quand même de nouvelles technos en test très rapidement, et pareil qu'avant, libre à ceux qui veulent les utiliser de le faire avec tous les avanatages et inconvénients que cela engage.

mais au moins ça donne du choix à tous les allergiques des technos web actuelles, et sur ce forum on en dénombre quelques uns, moi dedans.

ps: j'ai pas répondu concernant le merdier de technos multiples, incompatibilité technique, déjà ça je dirai impossible, le but c'est d'avoir des technos concurrentes, pas un gloubiboulga de techno fesant plus ou moins la même chose. ce dernier cas c'est typiquement ce qui se passe avec javascript où plusieurs frameworks se marchent dessus.
ensuite pour le qui implémente quoi, je dirai qu'au moins ça recentrera la compétition des divers acteurs, de "qui va le plus vite" on ira vers "qui implémente le plus de technos", compétition qui sera certainement plus saine que gagner une milliseconde sur un temps déjà peu perceptible.