Opera pourrait rendre son moteur de rendu Presto open source

Opera pourrait rendre son moteur de rendu Presto open source

Faut-il encore en faire quelque-chose

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

21/02/2013 3 minutes
48

Opera pourrait rendre son moteur de rendu Presto open source

Opera pourrait finalement rendre son moteur de rendu Presto open source. Une éventualité qui fait suite à l’annonce surprise de l'utilisation de Webkit dans la prochaine version majeure du navigateur.

opera

Opera 12.14 équipé du moteur Presto

 

Opera a provoqué la surprise récemment en annonçant un changement radical dans son navigateur : l’abandon de son moteur de rendu maison, Presto, au profit de Webkit. Une décision sans doute dictée par la nécessité de survivre face à une concurrence déchainée. Webkit est déjà une référence, notamment dans le monde du mobile, et on le retrouve plus particulièrement dans Chrome de Google et Safari d’Apple.

 

De fait, on pouvait se poser la question de savoir ce qui se passerait pour Presto. Après tout, Opera a largement investi dans son moteur et le navigateur s’était notamment illustré pour sa reconnaissance des technologiques du web. Paul Rouget de chez Mozilla a en fait repéré une information intéressante dans la liste de diffusion de Webkit.

Le code source de Presto pourrait bien être libéré 

Le directeur technique d’Opera, Håkon Wium Lie, est ainsi venu présenter sa société peu de temps après l’annonce, pour indiquer que sa société participerait désormais à l’évolution du moteur. Il a notamment rappelé que Webkit avait été précédemment KHTML, et que ce dernier avait été réécrit par Lars Knoll. Ce développeur avait travaillé pendant des années chez Trolltech, alors éditeur de l’environnement Qt, et avec lequel Opera partage un bâtiment à Oslo.

 

Mais le point intéressant est venu plus tard, quand le développeur Michelangelo De Simone a demandé sans détour à Håkon Wium Lie si Opera comptait rendre Presto open source. Le directeur technique n’a pas éludé la question : « Il se pourrait que le code de Presto soit libéré, mais pour l’instant toute notre attention est concentrée sur la transition. Pour l’instant, tout va bien ». Ce n’est pas un oui massif, mais ce n’est pas un non. On pourrait en fait soupçonner Lie de répondre au conditionnel simplement pour que l’attention se concentre sur la vraie annonce, celle du passage à Webkit.

 

Dans le cas où Presto deviendrait open source, cela ne garantirait pas forcément sa survivance. Webkit et Gecko (Mozilla) sont déjà open source et le maintien de ces moteurs réclame déjà des hordes de développeurs. Aussi, si le code source de Presto était libéré, cela ne signifierait pas pour autant que des développeurs seraient prêts à s’y pencher.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le code source de Presto pourrait bien être libéré 

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (48)


benamey
Le 21/02/2013 à 17h 38



Aussi, si le code source de Presto était libéré, cela ne signifierait pas pour autant que des développeurs seraient prêts à s’y pencher.





On pourrait imaginer que Mozilla abandonne Gecko et qu’ils adoptent Presto si ce dernier devenait open source. <img data-src=" />



Quoi qu’il en soit 3 moteurs open source ce serait pas mal comme situation.


Rozgann Abonné
Le 21/02/2013 à 17h 39

Ce serait bien qu’ils distribuent les sources de tout le navigateur, pas seulement de Presto. De cette manière, l’ancienne version pourrait continuer à être maintenu par la communauté. Si c’est uniquement le moteur de rendu, l’intérêt est plus limité je trouve, même si on ne peut que s’en réjouir.


zaknaster
Le 21/02/2013 à 17h 44







benamey a écrit :



On pourrait imaginer que Mozilla abandonne Gecko et qu’ils adoptent Presto si ce dernier devenait open source. <img data-src=" />



Quoi qu’il en soit 3 moteurs open source ce serait pas mal comme situation.





Pourquoi Mozilla voudrait abandonner Gecko ?



sr17
Le 21/02/2013 à 17h 54

Tout cela ne démontre qu’une seule chose : la norme HTML n’existe pas. Trop touffue, trop complexe donc trop difficile à implémenter. Trop de complexité pour trop peu de puissance, ce qui favorise la prolifération d’améliorations propriétaire.



Ce qui prévaut finalement comme toujours en pareil cas, c’est l’implémentation.



Le standard tends à devenir celui de l’implémentation la plus utilisée.



Au final, on peut toujours se réjouir en se disant qu’au moins cette fois, c’est un code libre que tout le monde peut utiliser et améliorer.



Mais si l’on veut vraiment sortir un jour de cette problématique, c’est la norme HTML et sa machine virtuelle qu’il faudra repenser. La rendre plus synthétique, plus puissante et plus simple.



Alors nous pourrons dire qu’il existera une véritable norme.



Doctor Drue
Le 21/02/2013 à 18h 05







sr17 a écrit :



Tout cela ne démontre qu’une seule chose : la norme HTML n’existe pas. Trop touffue, trop complexe donc trop difficile à implémenter. Trop de complexité pour trop peu de puissance, ce qui favorise la prolifération d’améliorations propriétaire.



Ce qui prévaut finalement comme toujours en pareil cas, c’est l’implémentation.



Le standard tends à devenir celui de l’implémentation la plus utilisée.



Au final, on peut toujours se réjouir en se disant qu’au moins cette fois, c’est un code libre que tout le monde peut utiliser et améliorer.



Mais si l’on veut vraiment sortir un jour de cette problématique, c’est la norme HTML et sa machine virtuelle qu’il faudra repenser. La rendre plus synthétique, plus puissante et plus simple.



Alors nous pourrons dire qu’il existera une véritable norme.





De quelle “machine virtuelle” s’agit - il ?



Et pourquoi on n’a pas ce “problème” d’améliorations propriétaires avec les spécifications de langages (comme le C ou le C++) ?



Je doute de tes arguments, mais je suis novice, donc je pose ces questions.



GentooUser
Le 21/02/2013 à 18h 11







zaknaster a écrit :



Pourquoi Mozilla voudrait abandonner Gecko ?





+1



De plus Mozilla c’est spécial, cette fondation a été crée justement pour recevoir et faire vivre le code libéré par Netscape.



N’empêche ça pourrait être pal mal Presto est libéré, il se développe communautairement, devient un référence, Google l’adopte pour Chrome, Opera migre sous Presto… <img data-src=" />



zefling Abonné
Le 21/02/2013 à 18h 18







zaknaster a écrit :



Pourquoi Mozilla voudrait abandonner Gecko ?







Surtout que Gecko c’est HTML & XUL, donc ça poserait problème.



zempa Abonné
Le 21/02/2013 à 18h 30







NotoRaptor a écrit :



De quelle “machine virtuelle” s’agit - il ?



Et pourquoi on n’a pas ce “problème” d’améliorations propriétaires avec les spécifications de langages (comme le C ou le C++) ?



Je doute de tes arguments, mais je suis novice, donc je pose ces questions.





Il n’y a pas de machine virtuelle.

Les navigateurs ont un moteur de rendu qui va interprété le HTML et le CSS pour la mise en page, et un moteur javascript pour … le javascript.



Les normes “HTML” sont celles “étiquetées” W3C.

S’il est vrai que durant la période IE/Netscape, c”était le fouillis, car pour être honnête pas grand monde se souciait du W3C, aujourd’hui, on est loin de cette situation. Le ramdam autour du “HTML5” confirme cela.



La principale difficulté d’implémentation dans le “HTML”, ce sont les propriétés CSS. Il faut bien comprendre que les CSS sont avant tout un langage descriptif. Ce n’est pas un langage avec une suite d’instructions qui s’exécute les unes après les autres. Dans ce genre de cas, il est relativement simple de prédire ce qu’il va se passer : il suffit de suivre la suite d’instructions comme on suit une recette de cuisine.

Quand on définit une nouvelle propriété CSS, il faut s’assurer qu’elle n’entrera pas en conflit avec celles existantes. Et comme on est à l’échelle de la description, les effets de bords deviennent difficiles à anticiper. C’est pour cela qu’il est nécessaire d’implémenter une nouvelle spécification avant sa validation : c’est un exigence nécessaire pour sa mise en oeuvre.

Et cela n’est pas du à des normes mal ficelées mais à son ADN même : le descriptif. Et c’est d’ailleurs assez logique que les CSS soient descriptives vu que c’est précisément leur but : mettre en page du contenu HTML.



Doctor Drue
Le 21/02/2013 à 18h 43







zempa a écrit :



…





Merci, c’est ce que je pensais <img data-src=" />.



ra-mon Abonné
Le 21/02/2013 à 18h 51



Paul Rouget de chez Mozilla a en fait repéré une information intéressante dans la liste de diffusion de Webkit.



D’autres petits curieux, plus ou moins anonymes l’avaient déjà signalée, depuis les mêmes sources, dans vos colonnes, il y a quelques jours déjà :

http://www.pcinpact.com/news/77522-opera-abandonne-son-moteur-rendu-et-passe-a-w… <img data-src=" />









benamey a écrit :



On pourrait imaginer que Mozilla abandonne Gecko et qu’ils adoptent Presto





Et dans la foulée que Microsoft adopte ce petit Gecko orphelin… Et qu’ensuite le W3C adopte Trident pour Amaya \o/

On fait tourner les moteurs de rendu, c’est d’la bonne, c’est ça ?







Rozgann a écrit :



Ce serait bien qu’ils distribuent les sources de tout le navigateur, pas seulement de Presto. De cette manière, l’ancienne version pourrait continuer à être maintenu par la communauté.





Ça fait toujours autant rêver l’Open Source à ce que je vois <img data-src=" />

D’après un ancien d’Opera, l’ouverture du code ne servirait pas à grand chose sans l’aide des anciens “corps”… (cf. dernier § dehttp://generatedcontent.org/post/43036827576/hey-o-lets-go )







zaknaster a écrit :



Pourquoi Mozilla voudrait abandonner Gecko ?





Au hasard, pour pouvoir entrer sur la livebox d’Orange ou dans des Net TV ?







GentooUser a écrit :



ça pourrait être pal mal Presto est libéré, il se développe communautairement, devient un référence





Et explose les scores de parts de marché pour enfin passionner les développeurs Web… Enfin, tout ce que quelques centaines de professionnels de la Profession n’ont pas réussi à faire pendant presque 20 ans… C’est magique l’Open Sourcitude <img data-src=" />






Doctor Drue
Le 21/02/2013 à 18h 56







ra-mon a écrit :



Et explose les scores de parts de marché pour enfin passionner les développeurs Web… Enfin, tout ce que quelques centaines de professionnels de la Profession n’ont pas réussi à faire pendant presque 20 ans… C’est magique l’Open Sourcitude <img data-src=" />





Ce n’est pas comme ça que WebKit a commencé ?



zaknaster
Le 21/02/2013 à 18h 58







ra-mon a écrit :



Au hasard, pour pouvoir entrer sur la livebox d’Orange ou dans des Net TV ?





Ca me parait bien peu de chose <img data-src=" />



GentooUser
Le 21/02/2013 à 19h 25







ra-mon a écrit :



C’est magique l’Open Sourcitude <img data-src=" />





C’est pas comme si le moteur le plus populaire du moment venait du projet KDE…



Et puis combien de geek prescripteurs pour conseiller Opera s’il avait été libre ?



sr17
Le 21/02/2013 à 19h 28







NotoRaptor a écrit :



De quelle “machine virtuelle” s’agit - il ?







http://www.pcinpact.com/news/67170-chrome-javascript-v8-webgl-garbage-collector….





Et pourquoi on n’a pas ce “problème” d’améliorations propriétaires avec les spécifications de langages (comme le C ou le C++) ?





Ce problème existe aussi avec le C/C++ sur les fonctionnalités périphériques.



Mais le coeur du langage étant justement assez simple, synthétique et puissant, les programmeurs peuvent s’en contenter pour la très grande majorité des logiciels. Ceux qui sont avisés évitent de s’aventurer à utiliser ce qui n’est pas standard.




ra-mon Abonné
Le 21/02/2013 à 19h 37







NotoRaptor a écrit :



Ce n’est pas comme ça que WebKit a commencé ?





C’est surement un peu moins angélique que ça. Webkit, il aura toujours un fort gout de pomme, hein <img data-src=" />

Enfin Apple, Google, Adobe, Nokia, c’est p’t’être un genre de communauté de gens de l’Open Source, va savoir <img data-src=" />







GentooUser a écrit :



Et puis combien de geek prescripteurs pour conseiller Opera s’il avait été libre ?





Ah ça il y en aurait eu pour conseiller Opera, je me doute. Et on aurait eu droit bien avant 2013 à un IE-Like basé sur Presto, à coup sûr… et si ça se trouve avec de la bonne pub, les marketeux de l’Open Source auraient pu en vendre en masse <img data-src=" />




SebGF Abonné
Le 21/02/2013 à 19h 39







GentooUser a écrit :



C’est pas comme si le moteur le plus populaire du moment venait du projet KDE…



Et puis combien de geek prescripteurs pour conseiller Opera s’il avait été libre ?







Tu sais, peu importe l’origine du moteur de rendu, s’il est propulsé sur une plateforme dominée par deux gros acteurs (en l’occurence Apple et Google pour le mobile), il sera number one.



Au hasard, Trident… IE6… Windows, PDM majeure du Desktop, moteur de rendu dominant du Web fin 90’s début 2000 dont le souvenir fait encore frissonner dans le dos. Quand t’as une multinationale au cul pour te propulser, ça aide. (comme Chrome, un gros “PRENDS CHROME PAUV’ NAZE” sur la home de Google et Youtube, plus la pub dans les métros et galeries marchandes, ça fait son effet)



Et perso j’ai toujours recommandé Opera à mon entourage (avec à chaque fois présentation des pour et des contres), j’ai rarement eu des déçus qui m’ont dit “beuh il est nul”.

Et je suis pourtant un Linuxien convaincu <img data-src=" />



ra-mon Abonné
Le 21/02/2013 à 19h 42







SebGF a écrit :



Et perso j’ai toujours recommandé Opera à mon entourage





C’est marrant, j’ai jamais pensé à recommander Opera… j’ai toujours cru qu’il avait été développé QUE pour moi <img data-src=" />



sr17
Le 21/02/2013 à 19h 44







zempa a écrit :



Il n’y a pas de machine virtuelle.

Les navigateurs ont un moteur de rendu qui va interprété le HTML et le CSS pour la mise en page, et un moteur javascript pour … le javascript.







http://www.pcinpact.com/news/67170-chrome-javascript-v8-webgl-garbage-collector….



Le cœur d’exécution javascript est bien une machine virtuelle.



Après, je conçoit qu’on peut se battre sur la sémantique, mais cela n’aurait pas beaucoup d’intérêt.





Les normes “HTML” sont celles “étiquetées” W3C.

S’il est vrai que durant la période IE/Netscape, c”était le fouillis, car pour être honnête pas grand monde se souciait du W3C, aujourd’hui, on est loin de cette situation. Le ramdam autour du “HTML5” confirme cela.



La principale difficulté d’implémentation dans le “HTML”, ce sont les propriétés CSS. Il faut bien comprendre que les CSS sont avant tout un langage descriptif. Ce n’est pas un langage avec une suite d’instructions qui s’exécute les unes après les autres. Dans ce genre de cas, il est relativement simple de prédire ce qu’il va se passer : il suffit de suivre la suite d’instructions comme on suit une recette de cuisine.

Quand on définit une nouvelle propriété CSS, il faut s’assurer qu’elle n’entrera pas en conflit avec celles existantes. Et comme on est à l’échelle de la description, les effets de bords deviennent difficiles à anticiper. C’est pour cela qu’il est nécessaire d’implémenter une nouvelle spécification avant sa validation : c’est un exigence nécessaire pour sa mise en oeuvre.

Et cela n’est pas du à des normes mal ficelées mais à son ADN même : le descriptif. Et c’est d’ailleurs assez logique que les CSS soient descriptives vu que c’est précisément leur but : mettre en page du contenu HTML.





Attention, je n’ai jamais dit que la norme était mal écrite. J’ai dit que ce standard est trop touffu, pas assez puissant, pas assez synthétique, ce qui le rends quasiment impossible à implémenter.



Comme tu semble l’avoir compris, le problème viens en partie du fait que c’est une norme descriptive. C’est beau sur le papier, mais cela aboutit en pratique à des choses très complexes et finalement peu puissantes.



Le rapport complexité/puissance est très mauvais.



D’ou viens cette erreur ?



Cette vision descriptive nous viens des mathématiques. On a des données, on leur applique des formules.

Et vous savez quoi ? Cela plaît énormément aux gens qui ont été (dé)formés par les maths avant même d’apprendre l’informatique.



Mais c’est terriblement inefficace en pratique.



Les paradigmes efficaces en informatique sont plutôt ceux basés sur des programmes plutôt que sur des formules. Mais ça, cela plaît moins aux théoriciens.



Les “normes” édictées par le W3C posent problème depuis le départ. Et ce n’est pas forcément que de la faute des programmeurs qui font les navigateurs. Peut être serait t’il temps d’ouvrir les standard du web à la réflexion d’autres écoles de pensées.










SebGF Abonné
Le 21/02/2013 à 19h 48







ra-mon a écrit :



C’est marrant, j’ai jamais pensé à recommander Opera… j’ai toujours cru qu’il avait été développé QUE pour moi <img data-src=" />







Opera est parfait tout en restant modeste et humble, comme moi en gros. <img data-src=" />



vt-n
Le 21/02/2013 à 19h 54







sr17 a écrit :



Ce qui prévaut finalement comme toujours en pareil cas, c’est l’implémentation.







Je pense qu’Internet en lui même évolue trop vite par rapport à la norme.

Je ne trouve pas la date à laquelle les travaux sur le HTML5 ont débutés, mais ça fait un moment que j’en entends parler. La finalisation n’est prévue que pour 2014. C’est bien trop long je trouve.



Au final, chacun y va de son implémentation.



Einstein-Rosen-Podolsky
Le 21/02/2013 à 20h 30

Oui, et il a intérêt à la rendre open source presto…<img data-src=" />


sr17
Le 21/02/2013 à 20h 37







vt-n a écrit :



Je pense qu’Internet en lui même évolue trop vite par rapport à la norme.

Je ne trouve pas la date à laquelle les travaux sur le HTML5 ont débutés, mais ça fait un moment que j’en entends parler. La finalisation n’est prévue que pour 2014. C’est bien trop long je trouve.



Au final, chacun y va de son implémentation.







Tout à fait.



Une grande partie des problèmes viens du fait que la norme as toujours été très en retard sur les besoins.



Mais si elle est perpétuellement en retard c’est justement parce qu’elle manque de puissance et de souplesse à la base et c’est pour cela qu’elle s’adapte si mal aux besoins nouveaux pour lesquels elle doit évoluer à chaque fois.



Le HTML est simplement basé sur des paradigmes inefficients.



Quand vous programmez en C++, vous n’avez pas besoin de modifier le langage pour faire un nouveau logiciel.



GentooUser
Le 21/02/2013 à 20h 38







vt-n a écrit :



Je pense qu’Internet en lui même évolue trop vite par rapport à la norme.

Je ne trouve pas la date à laquelle les travaux sur le HTML5 ont débutés, mais ça fait un moment que j’en entends parler. La finalisation n’est prévue que pour 2014. C’est bien trop long je trouve.



Au final, chacun y va de son implémentation.





Surtout que les usages ont déjà changés, aujourd’hui on croise de plus en plus de toolkits javascript genre node.js, Backbone.js, Sproutcore… les développeurs codent directement sites et webapps en JavaScript sans toucher directement la moindre ligne de html.



Ça relègue le HTML au rôle de simple backend graphique multiplateformes pour le rendu, à ce niveau là pourquoi ne pas passer directement à du WebGL ou de l’EGL ?



Mimoza Abonné
Le 21/02/2013 à 21h 12







sr17 a écrit :



http://www.pcinpact.com/news/67170-chrome-javascript-v8-webgl-garbage-collector….



Le cœur d’exécution javascript est bien une machine virtuelle.



Après, je conçoit qu’on peut se battre sur la sémantique, mais cela n’aurait pas beaucoup d’intérêt.







Tu ne fait pas la distinction entre le HTML et le Javascript … à partir de la il est difficile de discuter avec exactitude. <img data-src=" />

Zempa a parfaitement décrit la réalité <img data-src=" />



Anonyme
Le 21/02/2013 à 21h 41







ra-mon a écrit :



C’est surement un peu moins angélique que ça. Webkit, il aura toujours un fort gout de pomme, hein <img data-src=" />

Enfin Apple, Google, Adobe, Nokia, c’est p’t’être un genre de communauté de gens de l’Open Source, va savoir <img data-src=" />







Webkit est basé sur KHTML, le moteur de Konkeror, navigateur www de KDE.



sr17
Le 21/02/2013 à 21h 54







mimoza a écrit :



Tu ne fait pas la distinction entre le HTML et le Javascript … à partir de la il est difficile de discuter avec exactitude. <img data-src=" />

Zempa a parfaitement décrit la réalité <img data-src=" />







Pourquoi veux tu absolument dissocier des technologies qui sont totalement et étroitement associées en pratique ?



Peut t’on vraiment affirmer que HTML ne fait pas partie des éléments de l’environnement d’exécution sandboxé qu’est le navigateur web ?



Pour ma part, je pense au contraire qu’il faut considérer cela comme un tout parce que le logiciel ne tournera pas en pratique si il ne dispose pas de ce tout.




127.0.0.1
Le 21/02/2013 à 22h 04







mimoza a écrit :



Tu ne fait pas la distinction entre le HTML et le Javascript … à partir de la il est difficile de discuter avec exactitude. <img data-src=" />

Zempa a parfaitement décrit la réalité <img data-src=" />







Lorsqu’on parle de plateforme Java ou .Net, on ne fait pas non plus la différence entre Java, AWT, C# ou WPF. Ca forme un “tout”.



Pour le web 2.0, c’est analogue. Le browser est un environnement d’exécution (runtime env.) pour “application” codée en javascript+html+css.



Si un nouveau browser sort sans gérer javascript ou sans gérer HTML/CSS ou en gérant mal l’intégration des deux, c’est inutilisable en tant que browser. En ce sens, l’objectif d’un browser web c’est bien d’exécuter correctement les “applications” web 2.0.



Mimoza Abonné
Le 21/02/2013 à 22h 09

<img data-src=" /><img data-src=" /><img data-src=" />


zefling Abonné
Le 21/02/2013 à 23h 22







GentooUser a écrit :



Ça relègue le HTML au rôle de simple backend graphique multiplateformes pour le rendu, à ce niveau là pourquoi ne pas passer directement à du WebGL ou de l’EGL ?





<img data-src=" /> T’oublie que le HTML est aussi un format de documentation qui doit normalement fonctionner sans CSS, ni JS (j’ai eu une fois à faire ça pour un site).



C’est un peu comme dire que comme le PDF permettent la 3D, ne faut plus faire que du PDF 3D. Enfin, ça empêchera pas les applis full-canevas, sauf que niveau WAI ça doit être encore plus catastrophique qu’une appli full-flash.



vt-n
Le 21/02/2013 à 23h 34







GentooUser a écrit :



Surtout que les usages ont déjà changés, aujourd’hui on croise de plus en plus de toolkits javascript genre node.js, Backbone.js, Sproutcore…







Exact !



Chrome à jeté un gros pavé dans la marre lorsqu’il est arrivé.

Pour avoir connu cette période, niveau JavaScript, il y a eu un avant Chrome et un après Chrome. Ne serait-ce que d’un point de vue “facilité de prise en charge”. Le JavaScript est devenu bien moins prise de tête à écrire (d’un point de vue compatibilité entre navigateurs).

On ne peut pas non plus lui enlever le fait qu’il était particulièrement véloce.

Certains avaient essayé de rendre JavaScript plus user-friendly avant lui, mais je pense que c’est son arrivée qui a renversé la donne.







sr17 a écrit :



Peut t’on vraiment affirmer que HTML ne fait pas partie des éléments de l’environnement d’exécution sandboxé qu’est le navigateur web ?







Tu as à mon avis raison, à une époque c’était une autre histoire. Maintenant, HTML, CSS, JavaScript sont liés à un tel point que l’on ne peut plus les dissocier.

Après, oui, ce sont des technologies différentes, oui, on peut créer un site en utilisant uniquement du HTML, mais elles se complètent tellement, qu’au final…



Pour l’évolution, j’aimerais énormément que les syntaxes du type LESS (CSS) soient directement prises en charge par le navigateur. Mais ce n’est qu’un détail.



zefling Abonné
Le 21/02/2013 à 23h 46







vt-n a écrit :



Pour l’évolution, j’aimerais énormément que les syntaxes du type LESS (CSS) soient directement prises en charge par le navigateur. Mais ce n’est qu’un détail.





LESS, ça finira par ne plus servir à grand-chose :





Yolélé
Le 21/02/2013 à 23h 49







vt-n a écrit :



Exact !



Chrome à jeté un gros pavé dans la marre lorsqu’il est arrivé.

Pour avoir connu cette période, niveau JavaScript, il y a eu un avant Chrome et un après Chrome.







<img data-src=" />



vt-n
Le 21/02/2013 à 23h 51







zefling a écrit :



LESS, ça finira par ne plus servir à grand-chose :





vt-n
Le 21/02/2013 à 23h 52







Yolélé a écrit :



<img data-src=" />





Développe !



zefling Abonné
Le 21/02/2013 à 23h 57







vt-n a écrit :



Woaw, j’étais pas au courant !



Ça promet !



Merci !







Je suis pas mal la partie CSS, donc je connais tous les modules en préparation… (et aussi ceux qui rament à mort pour diverses raisons <img data-src=" />). Je peux dire que depuis 6 mois, ça rarement autant bougé, mais il y a trop de module, et quand on regarde les discutions ç’a l’air d’être un bordel sans nom de faire en sorte que tout fonction de façon cohérente. Le pire reste le nommage, car ils doivent s’assurer que ça soit aussi logique en cas d’ajouts futurs.



Note : l’écriture verticale a foutu un sacré merdier.



sr17
Le 22/02/2013 à 00h 03







zefling a écrit :



<img data-src=" /> T’oublie que le HTML est aussi un format de documentation qui doit normalement fonctionner sans CSS, ni JS (j’ai eu une fois à faire ça pour un site).



C’est un peu comme dire que comme le PDF permettent la 3D, ne faut plus faire que du PDF 3D. Enfin, ça empêchera pas les applis full-canevas, sauf que niveau WAI ça doit être encore plus catastrophique qu’une appli full-flash.







Ce que tu dit est vrai, mais en même temps, c’est une minorité de pages : on ne peut quand même pas nier que la plupart des sites sur internet comportent aujourd’hui en majorité des pages avec des combinaisons assez complexes de css+javascript. Et même dans les documentations, les pages web simples sont de plus en plus rares.



Cela me rappel qu’on parle toujours des avantages des théories descriptives en prônant leur simplicité. Mais on omet de dire que les exemples de la vie réels sont toujours beaucoup plus complexes. Et c’est la ou le bat blesse.



HTML a toujours brillé dans les exemples simples et théoriques mais ne s’est jamais vraiment bien adapté à ce que voulaient faire les webmasters qui l’utilisaient de manière concrète. Et encore moins à ceux qui auraient voulu faire quelque chose un tant soit peu avancé.



Finalement, malgré les évolutions, certaines choses qui devraient être simple sont encore trop complexes à mettre en oeuvre.



Simplifier pour rendre plus puissant ? C’est précisément le genre de “reset” que la technologie OpenGL a fait.




vt-n
Le 22/02/2013 à 00h 06







zefling a écrit :



Je peux dire que depuis 6 mois, ça rarement autant bougé, mais il y a trop de module, et quand on regarde les discutions ç’a l’air d’être un bordel sans nom de faire en sorte que tout fonction de façon cohérente.







Je suis très peu l’actualité :) !



C’est assez incroyable de le voir évoluer si rapidement !



psn00ps
Le 22/02/2013 à 02h 14







GentooUser a écrit :



N’empêche ça pourrait être pal mal Presto est libéré, il se développe communautairement, devient un référence, Google l’adopte pour Chrome, Opera migre sous Presto… <img data-src=" />





Je sais pas si ce sont des Pall Mall, mais c’est de la bonne. <img data-src=" />



Anonyme
Le 22/02/2013 à 04h 34

IE va enfin pouvoir se doter d’un vrai moteur <img data-src=" />


Anonyme
Le 22/02/2013 à 08h 19

Manque plus que le reste le soit aussi et je veux bien retenter <img data-src=" />


zefling Abonné
Le 22/02/2013 à 08h 40







sr17 a écrit :



Ce que tu dit est vrai, mais en même temps, c’est une minorité de pages : on ne peut quand même pas nier que la plupart des sites sur internet comportent aujourd’hui en majorité des pages avec des combinaisons assez complexes de css+javascript. Et même dans les documentations, les pages web simples sont de plus en plus rares.







Perso, j’essaie d’utiliser au maximum les possibilité du CSS + HTML pour réduire mon JS. Mais je ne nie pas qu’il est souvent compliqué de s’en passé sans faire quelque chose de lourd à l’utilisation.



lateo
Le 22/02/2013 à 10h 58







Rozgann a écrit :



Ce serait bien qu’ils distribuent les sources de tout le navigateur, pas seulement de Presto. De cette manière, l’ancienne version pourrait continuer à être maintenu par la communauté. Si c’est uniquement le moteur de rendu, l’intérêt est plus limité je trouve, même si on ne peut que s’en réjouir.







Genre ils ont déjà trop de parts de marché, et ils devraient se saborder eux-même en se mettant en concurrence avec un fork de leur ancien browser <img data-src=" />



Anonyme
Le 22/02/2013 à 13h 48

Hu? Si leur moteur est écrit en C et pas dans cet infâme c++ comme gecko et webkit, je suis preneur.


lateo
Le 22/02/2013 à 14h 42







ra-mon a écrit :



C’est marrant, j’ai jamais pensé à recommander Opera… j’ai toujours cru qu’il avait été développé QUE pour moi <img data-src=" />







<img data-src=" />



sky99
Le 22/02/2013 à 16h 21







sr17 a écrit :



Tous tes messages dans ce thread





Salut!

J’ai quand même du mal à te suivre. Déja, machine virtuelle html?

Ensuite, HTML!=javascript.

J’entends ton propos sur la complémentarité de html+js+css.

Maintenant HTML c’est une norme “standalone”, point.



Un peu comme avec le modèle réseau OSI, d’autres standards se batissent

dessus, mais HTML reste HTML.

HTML fonctionne sans javascript, sans CSS et sans rien d’autre.

Certes, JS, c’est sympa et tout. Mais on peut très bien faire du HTML sans javascript. Pour ma part, je fais à peu près exclusivement mes développements web

en php qui sort du HTML+CSS. Hormis des cas spécifiques et rares (j’avais

fait des tests d’interfaces ludiques en ajax à une époque), je n’utilise pas javascript, et si je m’en sers, c’est que c’est une feature suplémentaire dont

la désactivation ne gènera rien.



D’autre part, n’oublions pas l’aspect DOCUMENT du html. ça reste un point

important, capital même. J’utilise fréquement du XML avec XSLT pour afficher

mes documents XML en HTML. Ben si j’étais obligé d’utiliser tout un tas de surcouches à chaque fois, ce serait chiant!



Bref, toutes ces histoires de fonctionalités suplémentaires, ça ne me pose pas de problème, tant qu’on maintient des modèles simples de base.



Quand à ton propos sur le fait que HTML est trop touffu, je ne le comprends pas.

HTML4, c’est quand même une spécification simple, efficace, claire et facilement apréhendable. Elle manque peut être de possibilités sémantiques, mais elle n’est

pas complexe.

Pour HTML5, je ne sais pas trop, déjà la norme n’est pas finie, ensuite je ne m’y suis pas vraiment intéresse. Les ajouts sont chouettes, mais pas nécessaires dans 99% des cas (je grossis peut être le trait ici).



Le point crucial dans HTML ça reste la possibilité d’avoir un document contenant

des données sémantiques, et dont la préntation reste séparée du contenu.

Ce à quoi on peut très bien parvenir avec HTML.



Donc à mon sens, tes remarques s’appliquent davantage a javascript, peut être à CSS, mais pas à HTML.




sky99
Le 22/02/2013 à 16h 23







zefling a écrit :



Perso, j’essaie d’utiliser au maximum les possibilité du CSS + HTML pour réduire mon JS. Mais je ne nie pas qu’il est souvent compliqué de s’en passé sans faire quelque chose de lourd à l’utilisation.





Je trouve ça assez sain. D’autre part, si le javascript est nécessaire pour un site, que fait l’utilisateur quand il n’a pas de JS, que l’interpréteur JS foire, plante, ou autre?

Je ne suis pas du tout contre JS, au contraire, ça permet des choses assez formidables. Mais à mon sens, tout doit fonctionner de façon agréable sans. Et même en AJAX, ou on peut toujours avoir des liens classiques et des méthodes pour charger le contenu classique de façon non dynamique, quitte à recharger la page.



sr17
Le 22/02/2013 à 17h 40







sky99 a écrit :



Salut!

J’ai quand même du mal à te suivre. Déja, machine virtuelle html?

Ensuite, HTML!=javascript.

J’entends ton propos sur la complémentarité de html+js+css.

Maintenant HTML c’est une norme “standalone”, point.



Un peu comme avec le modèle réseau OSI, d’autres standards se batissent

dessus, mais HTML reste HTML.

HTML fonctionne sans javascript, sans CSS et sans rien d’autre.

Certes, JS, c’est sympa et tout. Mais on peut très bien faire du HTML sans javascript. Pour ma part, je fais à peu près exclusivement mes développements web

en php qui sort du HTML+CSS. Hormis des cas spécifiques et rares (j’avais

fait des tests d’interfaces ludiques en ajax à une époque), je n’utilise pas javascript, et si je m’en sers, c’est que c’est une feature suplémentaire dont

la désactivation ne gènera rien.



D’autre part, n’oublions pas l’aspect DOCUMENT du html. ça reste un point

important, capital même. J’utilise fréquement du XML avec XSLT pour afficher

mes documents XML en HTML. Ben si j’étais obligé d’utiliser tout un tas de surcouches à chaque fois, ce serait chiant!



Bref, toutes ces histoires de fonctionalités suplémentaires, ça ne me pose pas de problème, tant qu’on maintient des modèles simples de base.



Quand à ton propos sur le fait que HTML est trop touffu, je ne le comprends pas.

HTML4, c’est quand même une spécification simple, efficace, claire et facilement apréhendable. Elle manque peut être de possibilités sémantiques, mais elle n’est

pas complexe.

Pour HTML5, je ne sais pas trop, déjà la norme n’est pas finie, ensuite je ne m’y suis pas vraiment intéresse. Les ajouts sont chouettes, mais pas nécessaires dans 99% des cas (je grossis peut être le trait ici).



Le point crucial dans HTML ça reste la possibilité d’avoir un document contenant

des données sémantiques, et dont la préntation reste séparée du contenu.

Ce à quoi on peut très bien parvenir avec HTML.



Donc à mon sens, tes remarques s’appliquent davantage a javascript, peut être à CSS, mais pas à HTML.







Quelques remarques.



HTML norme standalone ? Oui, bien sûr tant qu’on reste dans la théorie.



Mais dans la pratique, si tu veux faire quelque chose de vendable et au gout du jour, ça sera bien sûr une usine à gaz de HTML+CSS+Javascript.



HTML norme simple, claire et propre ? La encore, tant qu’on reste sur le papier ou dans les exemples scolaires, c’est le cas.



Maintenant, essaye d’en faire quelque chose de concret. Et la, non, ce n’est plus propre, ce n’est plus simple. Regarde le code de la très grande majorité des sites et les contorsions qui doivent être faites pour arriver à un exemple réel.



Toute la différence est entre la théorie et la pratique. En théorie c’est beau, c’est simple, c’est propre. En pratique, c’est complexe, tordu et pas propre.



Pour expliquer les choses simplement, la courbe puissance/complexité n’est pas bonne. Et c’est un problème lié aux paradigmes utilisés.



Pour te donner un autre exemple plus compréhensible, c’est le cas de XSLT. Ca parait simple, beau et puissant tant qu’il s’agit d’effectuer des transformations simples et basiques. Mais dès qu’il y a un peu de complexité (la plupart des cas réels), ça devient très pointu à utiliser. Dans la pratique la majorité des informaticiens préfèrent utiliser un programme de transformation associé à un parser XML. Parce qu’au final, c’est plus simple et plus puissant. Et que contrairement à XSLT, ça peut tout faire.



Maintenant, je comprends que ce que je dit n’est pas forcément simple à appréhender pour qui ne connaît pas les subtilités des différentes écoles de pensées du monde l’informatique.




canard_jaune
Le 25/02/2013 à 07h 54







sr17 a écrit :



Tout cela ne démontre qu’une seule chose : la norme HTML n’existe pas. Trop touffue, trop complexe donc trop difficile à implémenter. Trop de complexité pour trop peu de puissance, ce qui favorise la prolifération d’améliorations propriétaire.



Ce qui prévaut finalement comme toujours en pareil cas, c’est l’implémentation.



Le standard tends à devenir celui de l’implémentation la plus utilisée.



Au final, on peut toujours se réjouir en se disant qu’au moins cette fois, c’est un code libre que tout le monde peut utiliser et améliorer.



Mais si l’on veut vraiment sortir un jour de cette problématique, c’est la norme HTML et sa machine virtuelle qu’il faudra repenser. La rendre plus synthétique, plus puissante et plus simple.



Alors nous pourrons dire qu’il existera une véritable norme.





C’est peut-être pour cela que HTML n’est PAS une norme <img data-src=" />.

http://fr.wikipedia.org/wiki/Normes_et_standards_techniques#Standard <img data-src=" />