Je comprends bien que XUL à été le HTML++ de Mozilla et qu'il est impossible de l'abandonner facilement. Mais il me semble possible de le marquer comme "déprécié" et le but de mozilla-Jetpack était de le remplacer et le rendre totalement obsolète il me semble.
Bref de n'utiliser XUL que pour les extension qui n'ont pas été mise à jour, dans la même idée de rétrocompatibilité Wayland/Mir avec X11. Car c'est un peu ça : XUL est le X11 de Mozilla.
browser.html, c'est très bien, mais ils manquent encore des choses en HTML pour faire tout ce qu'on peut faire en XUL, pour qu'il remplace ce bon cher browser.xul.
Alors que Mozilla est en train de construire un OS et toute son interface en HTML/JS/CSS, ça me semblerai être un sacré échec de ne pas pouvoir utiliser HTML5 pour implémenter les quelques controls/boite de dialogues de Firefox en HTML/JS/CSS.
Et d’ailleurs que manquerai-t-il à HTML5 ? (c'est une vrai question, car techniquement : avec l'usage du Shadow Dom j'avais compris que l'on pouvait construire un composant web de toute pièce et le rendre réutilisable, bref on construit son toolkit en web)
Et puis abandonner XUL, cela voudrait dire abandonner une grosse majorité des extensions… XUL va disparaitre, mais c'est pas pour demain. Il y a énormément de boulot.
Là on est d'accord : il y a beaucoup de boulot. Donc pourquoi perdre son temps à faire évoluer un toolkit (Gtk2 vers Gtk3) alors que le but est de normaliser la pile graphique.
Je pensais que comme une date n'est qu'une string formaté d'une certaine manière du point de gecko, alors le moteur C++ n'avait pas besoin d'être touché.
Je penses que ce qu'il manque c'est une implémentation javascript/HTML du sélecteur de date en utilisant du shadow DOM (comme pour les élément range input, video etc) qui fasse la transformation en une string au format date en proposant à l'utilisateur une interface conviviale.
Mais j'ai peut être mal compris le fonctionnement de ces inputs, et du moteur de rendu web.
Pour dessiner une page Firefox utilise principalement Mozilla-Azure, qui lui même a plusieurs backend (ha j'ai trouvé ça pour dégrossir le terrain). :
- Direct2/3D (Windows),
- Quartz/Coregraphique (OSX),
- OpenGL/Cairo (Linux)
A partir de là, je pense qu'un toolkit (Xul compris) est superflu et que c'est à Gecko/Servo d'avoir des backends qui utilisent soit OpenGl/Cairo, soit Wayland/X11/Mir directement.
Comme le fait blender en utilisant de l'OpenGL pour son interface : puisque de toute façon ce logiciel implémente un rendu OpenGL et que celui-ci sera forcément lancé, on peut utiliser OpenGL partout.
Pour Firefox, mon raisonnement est le même : on a un moteur html qui est lancé, pourquoi ne pas l'utiliser partout.
Et je pense que c'est l'idée du dev mozilla à l'origine de browser.html, puisque son objectif est de ne plus avoir besoin de Xul (Xul qui est utilisé actuellement comme surcouche à Gtk2/3, cocoa, windows).
petite réflexion (mais arrêtez moi si je dis des âneries) :
- Gtk3 utilise cairo comme backend
- Gecko utilise Cairo comme failsafe backend (si il n'y a pas OpenGL)
Donc si on fait un portage Gtk3 de firefox on se retrouvera avec des cas où firefox fera appel à cairo pour dessiner la page, puis à Xul qui sous linux fera appel à Gtk3 (pour les éléments genre boutons) qui fera lui même appel à cairo pour faire ce rendu.
Ne serait-il pas plus pertinent de ne plus avoir de Xul/Gtk3/Gtk2 ni Xul/Cocoa ni Xul/(Windows je ne sais quoi), en utilisant une interface web dans gecko lui même, par exemple : browser.html
Parce que quand on a sous la main un moteur de rendu web, qui sera de toute façon lancé, la nécessité d'utiliser/se trimbaler/maintenir un toolkit est tout de même discutable.
Loin de moi l'envie de répéter les critiques des commentaires sur firefox 34.
C'est super de voir Firefox avancer et tenir tête à des géants comme Google/Microsoft/Apple dans la guerre des navigateurs.
Je suis persuadé que des projets comme Rust et servo ou browser.html représentent l'avenir et je suis très content que Mozilla soit l'acteur qui actuellement prend les engagements techniques les plus audacieux.
… Mais est-il prévu que l'amélioration du HTML5 de la future version 36 nous fasse profiter des éléments date-time ?
Car le non-support de cet élément dans firefox est une vrai plaie pour les développeurs web.
Bref est ce que quelqu'un a repris la suite des travaux de Mounir Lamouri sur les webForms ? Et si non est ce que quelqu'un est capable de me dire quel sont les éléments HTML5 à implémenter de manière prioritaire pour Mozilla ? et est-il possible de voter/influencer ces choix ?
Note: je sais que la critique est facile et qu'on va me dire que rien ne me m'empêche de l'implémenter moi même.
A cela je dirai que mon manque de compétences et de temps ne me permette pas d'effectuer cette tache, par contre j'ai l'impression que Mozilla regorge de javascript-ninjas, et qu'il suffirait qu'un seul décide de finir ce travail pour que ce soit fait dans la prochaine version de firefox.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 2.
Je comprends bien que XUL à été le HTML++ de Mozilla et qu'il est impossible de l'abandonner facilement. Mais il me semble possible de le marquer comme "déprécié" et le but de mozilla-Jetpack était de le remplacer et le rendre totalement obsolète il me semble.
Bref de n'utiliser XUL que pour les extension qui n'ont pas été mise à jour, dans la même idée de rétrocompatibilité Wayland/Mir avec X11. Car c'est un peu ça : XUL est le X11 de Mozilla.
Alors que Mozilla est en train de construire un OS et toute son interface en HTML/JS/CSS, ça me semblerai être un sacré échec de ne pas pouvoir utiliser HTML5 pour implémenter les quelques controls/boite de dialogues de Firefox en HTML/JS/CSS.
Et d’ailleurs que manquerai-t-il à HTML5 ? (c'est une vrai question, car techniquement : avec l'usage du Shadow Dom j'avais compris que l'on pouvait construire un composant web de toute pièce et le rendre réutilisable, bref on construit son toolkit en web)
Là on est d'accord : il y a beaucoup de boulot. Donc pourquoi perdre son temps à faire évoluer un toolkit (Gtk2 vers Gtk3) alors que le but est de normaliser la pile graphique.
[^] # Re: v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 1.
Je pensais que comme une date n'est qu'une string formaté d'une certaine manière du point de gecko, alors le moteur C++ n'avait pas besoin d'être touché.
Je penses que ce qu'il manque c'est une implémentation javascript/HTML du sélecteur de date en utilisant du shadow DOM (comme pour les élément range input, video etc) qui fasse la transformation en une string au format date en proposant à l'utilisateur une interface conviviale.
Mais j'ai peut être mal compris le fonctionnement de ces inputs, et du moteur de rendu web.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 2.
Pour dessiner une page Firefox utilise principalement Mozilla-Azure, qui lui même a plusieurs backend (ha j'ai trouvé ça pour dégrossir le terrain). :
- Direct2/3D (Windows),
- Quartz/Coregraphique (OSX),
- OpenGL/Cairo (Linux)
A partir de là, je pense qu'un toolkit (Xul compris) est superflu et que c'est à Gecko/Servo d'avoir des backends qui utilisent soit OpenGl/Cairo, soit Wayland/X11/Mir directement.
Comme le fait blender en utilisant de l'OpenGL pour son interface : puisque de toute façon ce logiciel implémente un rendu OpenGL et que celui-ci sera forcément lancé, on peut utiliser OpenGL partout.
Pour Firefox, mon raisonnement est le même : on a un moteur html qui est lancé, pourquoi ne pas l'utiliser partout.
Et je pense que c'est l'idée du dev mozilla à l'origine de browser.html, puisque son objectif est de ne plus avoir besoin de Xul (Xul qui est utilisé actuellement comme surcouche à Gtk2/3, cocoa, windows).
petite réflexion (mais arrêtez moi si je dis des âneries) :
- Gtk3 utilise cairo comme backend
- Gecko utilise Cairo comme failsafe backend (si il n'y a pas OpenGL)
Donc si on fait un portage Gtk3 de firefox on se retrouvera avec des cas où firefox fera appel à cairo pour dessiner la page, puis à Xul qui sous linux fera appel à Gtk3 (pour les éléments genre boutons) qui fera lui même appel à cairo pour faire ce rendu.
[^] # Re: Et quid du portage gtk3 ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 3.
Ne serait-il pas plus pertinent de ne plus avoir de Xul/Gtk3/Gtk2 ni Xul/Cocoa ni Xul/(Windows je ne sais quoi), en utilisant une interface web dans gecko lui même, par exemple : browser.html
Parce que quand on a sous la main un moteur de rendu web, qui sera de toute façon lancé, la nécessité d'utiliser/se trimbaler/maintenir un toolkit est tout de même discutable.
[^] # Re: v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 1.
Dommage, et pour la v37 non plus apparement
PS: désolé pour le double post, si un admin peut effacer celui qui est inutile, merci par avance
# v36 = Beaucoup de progrès HTML5 = support de html5 dateTime ?
Posté par trancheX . En réponse à la dépêche Firefox 35 heures. Évalué à 3.
Loin de moi l'envie de répéter les critiques des commentaires sur firefox 34.
C'est super de voir Firefox avancer et tenir tête à des géants comme Google/Microsoft/Apple dans la guerre des navigateurs.
Je suis persuadé que des projets comme Rust et servo ou browser.html représentent l'avenir et je suis très content que Mozilla soit l'acteur qui actuellement prend les engagements techniques les plus audacieux.
… Mais est-il prévu que l'amélioration du HTML5 de la future version 36 nous fasse profiter des éléments date-time ?
Car le non-support de cet élément dans firefox est une vrai plaie pour les développeurs web.
Bref est ce que quelqu'un a repris la suite des travaux de Mounir Lamouri sur les webForms ? Et si non est ce que quelqu'un est capable de me dire quel sont les éléments HTML5 à implémenter de manière prioritaire pour Mozilla ? et est-il possible de voter/influencer ces choix ?
Note: je sais que la critique est facile et qu'on va me dire que rien ne me m'empêche de l'implémenter moi même.
A cela je dirai que mon manque de compétences et de temps ne me permette pas d'effectuer cette tache, par contre j'ai l'impression que Mozilla regorge de javascript-ninjas, et qu'il suffirait qu'un seul décide de finir ce travail pour que ce soit fait dans la prochaine version de firefox.