oui mais pour moi, se plaindre de l'arrivée d'extensions propriétaires ce n'est pas une réaction saine. Je ne vois pas en quoi ça impacte le projet Mozilla. Ça n'a même strictement rien à voir. Ce sont des projets "étrangers" au projet Mozilla.
Ce genre de plainte, c'est du FUD d'intégriste (qui n'a trouvé que ça comme critique pas constructive pour 2 sous)
Et alors ?
Quand bien même il y en a qui veulent faire des extensions propriétaires, qu'est ce que tu en a à fiche ?? T'es jaloux ? Ça va t'empecher de dormir ? Ou d'utiliser Firefox ?
Et la prochaine étape : les nouvelles fonctionnalités qui seront diffusées en tant qu'extensions propriétaires....
Si vraiment ils le font, en quoi est-ce génant ? En quoi ça va t'empecher d'utiliser Firefox ?
Allez, un peu d'honnêteté : à quand un Firefox shareware ?
Dit, tu sais ce qu'est la licence GPL ? Et ses avantages ? Je te demande ça parce que les sources de Mozilla Firefox sont sous GPL. Et que même si il y aurait un "firefox shareware", ça ne changerait rien du tout. As tu lu la licence MPL, sous laquelle sont également les sources de Mozilla Firefox ? Depuis longtemps, elle permet de faire un "firefox shareware". Ce que fait d'ailleurs une certaine société du nom de Netscape.. Est ce que cela a empéché l'utilisation et le développement de Mozilla Firefox ? Assurément, non.
Bref, tu crie au loup pour rien, car finalement, il n'y a rien de changé pour les utilisateurs et la communauté.
(Je m'attend à voir ce genre de reflexion à propos d'un firefox shareware sur d'autres sites où la philosophie du libre est peu connu ou incomprise, mais trouver ça ici, sur DLFP, je m'y attendais pas du tout ! Faut le faire !)
À propos de ce flou, ne vous inquietez pas, les explications vont venir. Je donnerais des liens vers ces futures explications (certainement en français en plus ;-) au cours de la journée..
À part ça, si j'ai bien compris, les statuts de la MoCorp ne permettent pas les stocks options ou autres rachats. Comme le dit Franck Hecker :
there are no outside investors, no stock grants or stock options for employees or others, and no possibility of an IPO, acquisition, or other “liquidity event”.
La MoCorp semble en fait avoir juste ce qu'il faut au niveau juridique pour ne pas entraver des relations commercial, ce qui semble plus difficile avec une fondation. Et une entité commercial est certainement plus "crédible" ou "acceptable" (je n'arrive pas à trouver le bon terme) vis à vis d'une autre entité commercial. Il n'y a pas ce "flou" justement que lorsqu'il n'y a qu'une fondation, au niveau de la frontière entre les activités non lucratives et les activités commerciales. Là au moins, c'est plus clair.
il y a le xhtml 1.0 strict ("strict" par opposition à "transitionnal"), et il y a le xhtml 1.1 (tout court).
par contre, xhtml 1.1 est une évolution de xhtml 1.0 strict.
Et il n'y a aucun interet à passer en xhtml 1.1 puisque dans ce cas, il faut envoyer au navigateur le type mime application/xml+xhtml, ce que le navigateur le plus utilisé au monde ne comprend pas.
> les différences entre le 1.0 transitionnal et le 1.0 stric sont tres peu nombreuses
euh si quand même. En tout cas, elles sont énormes. Puisqu'en transitionnal, tu as toutes les balises et attributs de présentation. tu peux toujours te permettre d'éviter css, donc de melanger design et structure et donc produire du code plutôt difficile à maintenir et à évoluer.
à noter aussi que même en xhtml 1.0 strict, tu peux toujours faire une soupe de tag immonde (utiliser les tableaux à tout va pour le design), donc pour le web semantique, tu repassera :-p Bref, c'est pas xhtml 1.0 strict qui te force à faire du web sémantique.
Utiliser les seuls avantages à utiliser XHTML plutôt que HTML, est la possibilité de manipuler le contenu dans tout les sens comme tout fichier XML, et d'intégrer d'autres langages XML dans la même page, comme SVG, MATHML etc... Si on n'a pas besoin de ces avantages pour son site, HTML 4.01 suffit largement aux besoins.
Par contre, il ne faut pas esperer un support CSS2 , même équivalent à ff. donc pour acid2, on continuera de rever longtemps. Et on oublie complétement CSS3. Pour par exemple les coins arrondis (border-radius dispo sous le nom -moz-border-radius), ils ne trouvent rien de mieux que de proposer une méthode completement pourrie avec un tableau bien merdique.( http://blogs.msdn.com/ie/archive/2005/06/23/431980.aspx(...) )
Pour le XHTML, et les headers xhtml : on va encore attendre un peu (IE 8 ?)
en gros : pour moi, ce IE7 n'est qu'un gros coup de pub pour pas grand chose, juste pour montrer au reste du monde "coucou on est là nous aussi", face à la montée en popularité des autres navigateurs comme FF.
Pendant ce temps là, Firefox 1.5 est en préparation (pour septembre 2005 apparement), avec le support natif de SVG, de XForms, d'encore plus de styles CSS3/CSS2 (non, il ne passera pas encore acid2) notament les styles de colonnes "fluides".
De ce fait, il est trés trés facile de charger la langue au moment de l'execution comme tu dit.
Le problème est juste une histoire de packages. ils ne fournissent pas les paquages de langues séparement pour Firefox, alors qu'ils le font pour la suite Mozilla. Pourquoi ? j'en sais rien...
pour ton information, toutes les chaînes de langues se trouvent justement dans des fichiers séparés.
Plus précisement, dans des DTD (ba oui, tout est xml dans firefox ;-) ) ou des fichiers properties et que l'on inclus via des entités (DTD) ou balises stringbundle
pour google map, je ne vois pas trop.
mais pour gmail.. Ba compare son interface avec celle de ton client mail favori (ou thunderbird par exemple) et tu verras ce qu'il manque..
En xul, tu peux faire une interface utilisateur comme dans n'importe quel logiciel desktop (FF ou thuderbird est en XUL par exemple). En html, c'est plutôt penible, voir impossible..
cela apporte aussi beaucoup au développeur : comme je disais, il n'y a pas besoin d'une tonne de scripts JS pour faire un menu déroulant, un arbre, des onglets etc.. Juste quelques balises...
Ici on parle d'*applications* web, dont l'usage est, d'aprés ce que j'ai compris, réservé à certaines personnes, en l'occurence, les administrateurs de la webradio. ll est donc tout à fait envisageable pour ces personnes d'imposer à utiliser un navigateur précis pour utiliser l'appli. (surtout que cela ne devrait pas être trés dur, ici il s'agit de firefox, utilisable sur de nombreuses plateformes et librement disponible).
Il faut je pense faire la part des choses entre sites web, et appli web. L'un est déstiné à être vu par le plus de monde possible -> standards incontournables pour sa réalisation. L'autre est déstiné à être utilisé en général par un nombre restreint de personnes. Qui, dans le cas, de mediabox, est une appli choisie par ces mêmes personnes (si elles veulent pas de xul -> elles peuvent toujours choisir une autre appli pour leur webradio, mais bon, vu ce que cela apporte en terme d'interface utilisateur, cela vaut bien l'installation d'un firefox..)
à mon avis, javascript/dom/services web n'est pas la problèmatique ici. Ce genre de chose sont tout autant nécessaire en XUL et en HTML.
La problèmatique est plutôt d'avoir une interface utilisateur potable.
HTML n'est *pas* prevu pour faire une interface utilisateur. À moins de passer par des tonnes de scripts. Et encore.
En xul, quelques balises bien placées, et tu as des tree view, des menus déroulants et plein d'autres widgets avec 0 lignes de codes JS.
c'est ce qu'il compte faire si j'ai bien compris son explication.
Mais ça ne serait jamais alors que du XUL-like, sans rien autour (XBL, overlay etc..). Comme la majorité des moteurs XUL-like ( dont une liste est ici http://xul.sourceforge.net(...) ). C'est à dire que ça reprend seulement le concept général de XUL (interface déclaré dans un fichier XML).
Si il veut vraiment faire du XUL comme il est possible de faire dans Mozilla, il sera obligé de casser KaXUL. En effet, Kaxul fait un truc tout con (et pas super beau en définitive, le développeur l'affirme lui même dans sa présentation), c'est qu'il parse le fichier XUL, pour générer un contenu .ui (qui est également un fichier XML d'interface), pour ensuite être interpreté par la lib QT.
Actuellement donc, cela veut dire que tu ne peux faire que du XUL statique. Car si tu veux faire du XUL "dynamique", c'est à dire pouvoir en javascript modifier la structure du fichier XUL (via le DOM), profiter d'un système de template, ou profiter de XBL (les composants XBL sont attachés aux balises XUL via des styles CSS, ce qui permet d'attacher, ou de détacher des XBL n'importe quand durant l'execution de ton programme), si tu veux pouvoir faire tout ça donc, cela signifie qu'à la moindre modif XUL, le contenu ui devra être regénéré, et reparsé par QT etc...
Ce qui n'est, à mon sens, pas du tout optimum. L'affichage ne se base plus directement sur un contenu DOM original comme c'est le cas dans Mozilla, mais via des moyens détournés, des transformations trés coûteuses en temps d'execution.
Si on veut avoir du vrai XUL dans Konqueror, il faut hacker KHTML, et pas passer par des moyens détournés à la KaXul, donc pas par les fichiers ui.
Le problème que je vois moi, c'est que les technologies de Mozilla (XUL, XBL, overlay, templates etc...) sont trés liées les unes avec les autres, ce qui résulte qu'il n'y a pas 36 moyens d'implementer tout ça ensemble je pense. Il faut le faire comme c'est fait dans Gecko (au niveau architectural j'entend). Est ce qu'alors KHTML a une architecture suffisement souple pour qu'on puisse ajouter toutes ces technos ensemble ? Je ne sais pas...
En tout cas, la majorité des moteurs XUL-like ne sont guère allé plus loin que le support du seul langage XUL (donc en gros, supporter une simple liste de balises et transformer chacune en appel de fonctions d'une API de widget, ce que ne fait absolument pas Gecko). La difficulté de mise en oeuvre des autres technos toutes ensembles doit être en partie la cause de ce simple support. (même si je reconnais que cela peut être suffisant dans beaucoup de cas). En tout cas, à mon sens, On ne peut pas dire que c'est du XUL comme dans Mozilla.
Le XUL (le vrai, celui de Mozilla), souvent copié, mais jamais égalé.
> Encore un mec qui croit que c'est aux utilisateurs de s'adapter aux contraintes techniques de son produit ...
Non, je ne crois absolument pas ça. Nvu est fait pour faire du HTML/XHTML. Pas pour faire du faux HTML avec des balises bizarroïdes dedans qui ne sont conformes à rien du tout.
Comme dis le commentaire du dessus, si tu veux faire de l'ASP, il y a des outils trés bien chez Microsoft. C'est leur problème si ils ne suivent pas les standards. Pas celui de Nvu. Ils n'ont pas les mêmes objectifs, c'est tout.
Pour faire une course de F1, tu utilises une F1, pas un tracteur. Là c'est pareil. Pour faire du HTML, tu peux utiliser Nvu, il est fait pour ça. Si tu veux faire de l'ASP, tu utilises les outils qui sont fait pour (Frontpage, VS.net..).
En clair : l'utilisateur doit utiliser le meilleur outils pour faire ce qu'il a à faire. et pas à l'outils de devenir une usine à gaz pour contenter tout le monde. (aurez tu oublier la philosophie des programmes Unix ? Ils font une seule chose, mais ils le font bien)
Le type montre trés bien qu'il ne sait absolument pas de quoi il parle. Des extensions, ce n'est pas que du XUL. Et du XUL, ce n'est pas seulement une simple liste de balise. Il a *un peu* oublié XBL, les overlays, la localisation, RDF, les templates, les skins etc..
En fait, ça me fait doucement rigoler car les responsables du summer of code savent qu'ils vont économiser 4500$ (sûrement aussi sur d'autres projets). Je doute que le gars arrive à faire en 2 mois ce que des dizaines d'ingénieur ont fait en plusieurs années dans Mozilla. (et ils le savent trés bien puisqu'ils ont embauché des ingénieurs de Mozilla...)
Bref, ne vous réjouissez pas trop vite. L'implementation de XUL dans konqueror ne pourra être qu'une implementation trés incomplète. Et n'offrira que peu de compatibilité avec les fichiers XUL de Mozilla.
Une balise <% ... %>, comme celles utilisées pour l'ASP n'est pas conforme vis à vis de XML/SGML. Ce n'est donc pas traitable par un parser HTML conforme. Dans Nvu, le parser ne reconnaissant pas une balise, convertit les < et > en entité < et > (et encore, je crois que c'est un vilain hack, le parser devrait refuser de charger le document à cause de ces vilaines balises non conformes, donc, tu vois qu'il y a déjà un effort de fait :-p )
Quand bien même le parser reconnaitrait cette balise, cela signifie qu'il faudrait créer un objet spécifique DOM n'existant pas dans la spec DOM (beurk), avec toutes les conséquences que cela impliquerait dans le coeur de gecko (faire des hacks de partout pour parser, serialiser, afficher etc ce genre de balise). Bref, ça obligerait à faire un truc super crade dans le code de gecko je pense.
Contrairement à la balise <?...?> qui est définit dans la spec XML comme étant une "processing instruction".. Et encore, la spec indique clairement que le <? doit être suivi d'un nom : <?xml ...?> <?foo ...?> etc.. D'où le support des balises <?php ?> mais pas de <? ?> dans Nvu.
disons qu'il faut remettre ce billet dans le context du blog. En lisant d'autres billets du blog, tu apprends toutes ses déboires avec l'administration, toutes les galères qu'il a eu administrativement pour monter sa boite. D'où le pétage de plomb décrit dans ce billet :-)
en fait, j'ai dit un peu n'importe quoi. J'ai oublié un truc, c'est que dans un arbre DOM classique, tout est gardé dans les noeud textes, y compris les espaces, les sauts de lignes etc... Donc normalement, tout est restitué à la serialisation.. Mais historiquement, le parser HTML de gecko virait les espaces et saut de ligne en trop lorsqu'il générait le DOM. Du coup, à la serialisation... Mais il semble en fait que Daniel ait hacké le parser pour préserver ces espaces. (le parser XML lui, a toujours preservé les caractères blancs en trop)..
> pourquoi Nvu s'embete-t-il a modifier du code dont je n'ai pas touché en wysiwyg? Il ne peut pas le laisser tranquille?
Il s'embete pas à modifier le code, il ne peut pas faire autrement, tout simplement. Et il peut pas le laisser tranquille
Quand tu edites une page HTML en wysiwyg : le fichier est parsé et transformé en arbre DOM. Cette opération est indispensable pour que Gecko puisse l'afficher. Ensuite, quand tu édites, ajoutes, modifie des trucs, cela fait des manipulations sur le DOM, pas sur le source. Quand tu bascules en source ou que tu enregistres le fichier, il y a serialisation du DOM. C'est ce qu'il y a de plus simple, et je t'assure, c'est déjà assez compliqué comme ça. Faut bien comprendre qu'un editeur HTML/XML wysiwyg ne travaille absolument pas sur le source, mais sur une representation logicielle de la structure du document (le DOM). On ne peut faire autrement à cause de l'aspect Wysiwyg. Si on travaillait directement sur la source, le rendu serait beaucoup trop lent. à chaque modif (du copier d'un bloc, à l'insertion d'un seul caractère), faudrait déjà placer la modif au bon endroit (donc trouver la balise qui correspond, changer ce qu'il y a à changer dans le source) et ensuite re-parser le source, re-interpreter les balises, et re-appliquer les styles CSS, re-faire l'affichage en conséquence etc... Ce serait, contrairement à ce que tu dis, bien plus embetant que de faire comme c'est fait actuellement. Quant à maintenir une version à la fois textuel et DOM en mémoire, ce serait d'une complexité totalement futile.
Si il fallait en plus, lors de la serialisation, remettre tout en place comme c'etait avant, cela necessiterait donc de mémoriser l'emplacement de chaque caractère, de chaque balise, de mémoriser ce qui a été modifié, ce qui ne l'a pas été, d'éventuellement tenir compte de preferences utilisateurs sur la façon de formater les nouveaus trucs etc... Bonjour alors l'occupation mémoire, les perfs et la complexité du truc. Pour un résultat finalement *vraiment* peu utile.
> Et non, désolé, je ne participerai pas, j'ai déja mon projet qui me bouffe du temps
C'étais ironique ce que je disais, car faire les modifs que tu demandes, demanderait de modifier le moteur Gecko, ce qui te prendrait des mois à le faire (à plein temps), le temps de comprendre comment ça fonctionne... (et tu perdrais ton temps car tu comprendrais que c'est finalement pas interressant de le faire, vu ce que cela impliquerai en terme de coût mémoire, perf etc.. et les conséquences sur tout le reste). C'est pour plein de bonnes raisons que ce n'est pas fait dans Nvu.. Et plein de bonnes raisons qui fait que ces modifs ne seraient pas acceptés par la fondation Mozilla (à toi donc de maintenir ton patch avec chaque version de Gecko, ce qui est trés contraignant et perte de temps...).
On attend ton patch ;-) (qu'il permette un formatage selon les souhaits de l'utilisateur, ou qu'il apporte les fonctionnalités manquantes qui t'obligent aujourd'hui à éditer encore tes pages à la main).
Si c'était si simple, il y aurait longtemps que ce serait fait :-p
De plus, je ne vois pas l'interêt d'utiliser un truc wysiwyg si on tient tellement à ce que le code source soit de telle ou telle manière. En effet, si tu tiens à un formatage précis, c'est que tu veux pouvoir l'éditer à la main, donc tu connais le HTML. L'interêt d'utiliser un truc wysiwyg dans ce cas est trés faible. Tu veux qu'il soit présenté comme ci, comme ça ? eh bien le mieux est de le taper toi-même.
De toute façon, ton formatage, il sera, quoi qu'il arrive, toujours cassé. Ne serait-ce que le formatage des nouveaux élements insérés par Nvu. Crois tu qu'il puisse deviner tout seul que *toi*, tu veux que l'indentation soit de 4 espaces, avec un saut de ligne aprés chaque balises fermantes ? On pourrait faire en sorte que ça fasse ça. Manque de bol, y a untel qui veux 2 sauts lignes, avec des indentations de 2 espaces, et 1 commentaire pour chaque balise. Et que dire de l'autre, qui veut tout sur une seule ligne parce qu'il veut économiser de la bande passante. Ou encore l'autre qui veut pas de saut de ligne aprés des li mais par contre des sauts de lignes apres des ul, etc ....
Bref, avec un minimum de reflexion, tu peux comprendre que
1) ce n'est pas simple techniquement parlant. C'est d'ailleurs un problème récurent dans tous les programmes de génération de code, que ce soit de la génération de code à la delphi, ou à la visual studio, dreamweaver etc..
2) ça n'est pas utile. La navigateur n'en a rien à fiche de la façon dont le code source est présenté. Le principal est que le code fourni soit valide, et éventuellement formaté proprement de façon à rester lisible humainement ( sans être forcément formaté selon les caprices de l'utilisateur).
Oui, t'inquiète pas, des idées pour améliorer Nvu, on en a plein :-)
Mais tu oublie un paramètre dans l'équation : le temps. Il n'a pas 4 bras, ni 10 employés pour le faire. Mais si tu nous donnes les sous pour les embaucher à temps complet (et aussi les former pendant plusieurs mois), ne te gène pas pour nous les donner ;-) .
Tout comme Dreamweaver ne s'est pas fait en 1 jour, Nvu ne s'est pas fait en un jour.
(comparer Quanta à Nvu, donc comparer du non wysiwyg à du wysiwyg, c'est un peu hasardeux je trouve, la complexité de réalisation du premier est largement inférieur à celle de l'autre, et le public visé n'est pas du tout le même...)
[^] # Re: Ca vous rappelle pas un vieux cheval de bois ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla Corp. Évalué à 6.
Ce genre de plainte, c'est du FUD d'intégriste (qui n'a trouvé que ça comme critique pas constructive pour 2 sous)
[^] # Re: Ca vous rappelle pas un vieux cheval de bois ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla Corp. Évalué à 0.
Quand bien même il y en a qui veulent faire des extensions propriétaires, qu'est ce que tu en a à fiche ?? T'es jaloux ? Ça va t'empecher de dormir ? Ou d'utiliser Firefox ?
[^] # Re: Ca vous rappelle pas un vieux cheval de bois ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla Corp. Évalué à 7.
Si vraiment ils le font, en quoi est-ce génant ? En quoi ça va t'empecher d'utiliser Firefox ?
Dit, tu sais ce qu'est la licence GPL ? Et ses avantages ? Je te demande ça parce que les sources de Mozilla Firefox sont sous GPL. Et que même si il y aurait un "firefox shareware", ça ne changerait rien du tout. As tu lu la licence MPL, sous laquelle sont également les sources de Mozilla Firefox ? Depuis longtemps, elle permet de faire un "firefox shareware". Ce que fait d'ailleurs une certaine société du nom de Netscape.. Est ce que cela a empéché l'utilisation et le développement de Mozilla Firefox ? Assurément, non.
Bref, tu crie au loup pour rien, car finalement, il n'y a rien de changé pour les utilisateurs et la communauté.
(Je m'attend à voir ce genre de reflexion à propos d'un firefox shareware sur d'autres sites où la philosophie du libre est peu connu ou incomprise, mais trouver ça ici, sur DLFP, je m'y attendais pas du tout ! Faut le faire !)
[^] # Re: Mouais...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla Corp. Évalué à 5.
Euh.. tu voulais parler de la MoCorp plutôt non ?
Personnellement, tant que Gecko, FF etc restent des logiciels libres et avec des morceaux de technologies innovantes dedans, le reste..
[^] # Re: Mouais...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Mozilla Corp. Évalué à 8.
À propos de ce flou, ne vous inquietez pas, les explications vont venir. Je donnerais des liens vers ces futures explications (certainement en français en plus ;-) au cours de la journée..
À part ça, si j'ai bien compris, les statuts de la MoCorp ne permettent pas les stocks options ou autres rachats. Comme le dit Franck Hecker :
La MoCorp semble en fait avoir juste ce qu'il faut au niveau juridique pour ne pas entraver des relations commercial, ce qui semble plus difficile avec une fondation. Et une entité commercial est certainement plus "crédible" ou "acceptable" (je n'arrive pas à trouver le bon terme) vis à vis d'une autre entité commercial. Il n'y a pas ce "flou" justement que lorsqu'il n'y a qu'une fondation, au niveau de la frontière entre les activités non lucratives et les activités commerciales. Là au moins, c'est plus clair.
[^] # Re: XHTML 1.0 transitional
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Spip 1.8.2pr1 un spip de rêve XHTML/CSS 1.0 ++ ;). Évalué à 4.
il y a le xhtml 1.0 strict ("strict" par opposition à "transitionnal"), et il y a le xhtml 1.1 (tout court).
par contre, xhtml 1.1 est une évolution de xhtml 1.0 strict.
Et il n'y a aucun interet à passer en xhtml 1.1 puisque dans ce cas, il faut envoyer au navigateur le type mime application/xml+xhtml, ce que le navigateur le plus utilisé au monde ne comprend pas.
[^] # Re: pourquoi le 1.0 Strict
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Spip 1.8.2pr1 un spip de rêve XHTML/CSS 1.0 ++ ;). Évalué à 4.
euh si quand même. En tout cas, elles sont énormes. Puisqu'en transitionnal, tu as toutes les balises et attributs de présentation. tu peux toujours te permettre d'éviter css, donc de melanger design et structure et donc produire du code plutôt difficile à maintenir et à évoluer.
pour rappel, mise à part l'aspect XML de XHTML, xhtml 1.0 transitionnal = html 4.01 transitionnal, et xhtml 1.0 strict = html 4.01 strict. http://openweb.eu.org/articles/differentes_dtd/(...)
à noter aussi que même en xhtml 1.0 strict, tu peux toujours faire une soupe de tag immonde (utiliser les tableaux à tout va pour le design), donc pour le web semantique, tu repassera :-p Bref, c'est pas xhtml 1.0 strict qui te force à faire du web sémantique.
Utiliser les seuls avantages à utiliser XHTML plutôt que HTML, est la possibilité de manipuler le contenu dans tout les sens comme tout fichier XML, et d'intégrer d'autres langages XML dans la même page, comme SVG, MATHML etc... Si on n'a pas besoin de ces avantages pour son site, HTML 4.01 suffit largement aux besoins.
[^] # Re: d'aprés les rumeurs
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IE 7 beta 1 est sortie : avis aux webmestres. Évalué à 1.
# d'aprés les rumeurs
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IE 7 beta 1 est sortie : avis aux webmestres. Évalué à 9.
à verifier, mais d'aprés les rumeurs donc d'aprés ce que j'ai lu avant la sortie quoi..., et en particulier de ce qui est dit dans le blog de IE :
- http://blogs.msdn.com/ie/archive/2005/04/22/410963.aspx(...) : png ok, et corrections de bugs CSS.
- http://blogs.msdn.com/ie/archive/2005/06/28/433569.aspx(...) : rss sera dans longhorn, donc certainement dans IE. et je ne sais pas si ce sera dans IE hors longhorn.
Par contre, il ne faut pas esperer un support CSS2 , même équivalent à ff. donc pour acid2, on continuera de rever longtemps. Et on oublie complétement CSS3. Pour par exemple les coins arrondis (border-radius dispo sous le nom -moz-border-radius), ils ne trouvent rien de mieux que de proposer une méthode completement pourrie avec un tableau bien merdique.( http://blogs.msdn.com/ie/archive/2005/06/23/431980.aspx(...) )
Pour le XHTML, et les headers xhtml : on va encore attendre un peu (IE 8 ?)
en gros : pour moi, ce IE7 n'est qu'un gros coup de pub pour pas grand chose, juste pour montrer au reste du monde "coucou on est là nous aussi", face à la montée en popularité des autres navigateurs comme FF.
Pendant ce temps là, Firefox 1.5 est en préparation (pour septembre 2005 apparement), avec le support natif de SVG, de XForms, d'encore plus de styles CSS3/CSS2 (non, il ne passera pas encore acid2) notament les styles de colonnes "fluides".
[^] # Re: bopf, c'est dans l'ordre des choses
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Les bloat-CPU. Évalué à 4.
[^] # Re: Version française
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Mise à jour de Firefox pour des problèmes de vulnérabilités. Évalué à 5.
tout est dans des fichiers de langues (soit des DTD, soit des fichiers properties) http://xulfr.org/xulplanet/xultu/locale.html(...)
De ce fait, il est trés trés facile de charger la langue au moment de l'execution comme tu dit.
Le problème est juste une histoire de packages. ils ne fournissent pas les paquages de langues séparement pour Firefox, alors qu'ils le font pour la suite Mozilla. Pourquoi ? j'en sais rien...
[^] # Re: Houlà!!
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Mise à jour de Firefox pour des problèmes de vulnérabilités. Évalué à 3.
pour ton information, toutes les chaînes de langues se trouvent justement dans des fichiers séparés.
Plus précisement, dans des DTD (ba oui, tout est xml dans firefox ;-) ) ou des fichiers properties et que l'on inclus via des entités (DTD) ou balises stringbundle
http://xulfr.org/xulplanet/xultu/locale.html(...)
[^] # Re: Re
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La mediabox404 avec une interface XUL ?. Évalué à 2.
mais pour gmail.. Ba compare son interface avec celle de ton client mail favori (ou thunderbird par exemple) et tu verras ce qu'il manque..
En xul, tu peux faire une interface utilisateur comme dans n'importe quel logiciel desktop (FF ou thuderbird est en XUL par exemple). En html, c'est plutôt penible, voir impossible..
cela apporte aussi beaucoup au développeur : comme je disais, il n'y a pas besoin d'une tonne de scripts JS pour faire un menu déroulant, un arbre, des onglets etc.. Juste quelques balises...
[^] # Re: Re
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La mediabox404 avec une interface XUL ?. Évalué à 5.
Ici on parle d'*applications* web, dont l'usage est, d'aprés ce que j'ai compris, réservé à certaines personnes, en l'occurence, les administrateurs de la webradio. ll est donc tout à fait envisageable pour ces personnes d'imposer à utiliser un navigateur précis pour utiliser l'appli. (surtout que cela ne devrait pas être trés dur, ici il s'agit de firefox, utilisable sur de nombreuses plateformes et librement disponible).
Il faut je pense faire la part des choses entre sites web, et appli web. L'un est déstiné à être vu par le plus de monde possible -> standards incontournables pour sa réalisation. L'autre est déstiné à être utilisé en général par un nombre restreint de personnes. Qui, dans le cas, de mediabox, est une appli choisie par ces mêmes personnes (si elles veulent pas de xul -> elles peuvent toujours choisir une autre appli pour leur webradio, mais bon, vu ce que cela apporte en terme d'interface utilisateur, cela vaut bien l'installation d'un firefox..)
[^] # Re: Re
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La mediabox404 avec une interface XUL ?. Évalué à 4.
La problèmatique est plutôt d'avoir une interface utilisateur potable.
HTML n'est *pas* prevu pour faire une interface utilisateur. À moins de passer par des tonnes de scripts. Et encore.
En xul, quelques balises bien placées, et tu as des tree view, des menus déroulants et plein d'autres widgets avec 0 lignes de codes JS.
[^] # Re: stratégie google
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Bounties KDE pour le "summer of code" project de Google. Évalué à 4.
Mais ça ne serait jamais alors que du XUL-like, sans rien autour (XBL, overlay etc..). Comme la majorité des moteurs XUL-like ( dont une liste est ici http://xul.sourceforge.net(...) ). C'est à dire que ça reprend seulement le concept général de XUL (interface déclaré dans un fichier XML).
Si il veut vraiment faire du XUL comme il est possible de faire dans Mozilla, il sera obligé de casser KaXUL. En effet, Kaxul fait un truc tout con (et pas super beau en définitive, le développeur l'affirme lui même dans sa présentation), c'est qu'il parse le fichier XUL, pour générer un contenu .ui (qui est également un fichier XML d'interface), pour ensuite être interpreté par la lib QT.
Actuellement donc, cela veut dire que tu ne peux faire que du XUL statique. Car si tu veux faire du XUL "dynamique", c'est à dire pouvoir en javascript modifier la structure du fichier XUL (via le DOM), profiter d'un système de template, ou profiter de XBL (les composants XBL sont attachés aux balises XUL via des styles CSS, ce qui permet d'attacher, ou de détacher des XBL n'importe quand durant l'execution de ton programme), si tu veux pouvoir faire tout ça donc, cela signifie qu'à la moindre modif XUL, le contenu ui devra être regénéré, et reparsé par QT etc...
Ce qui n'est, à mon sens, pas du tout optimum. L'affichage ne se base plus directement sur un contenu DOM original comme c'est le cas dans Mozilla, mais via des moyens détournés, des transformations trés coûteuses en temps d'execution.
Si on veut avoir du vrai XUL dans Konqueror, il faut hacker KHTML, et pas passer par des moyens détournés à la KaXul, donc pas par les fichiers ui.
Le problème que je vois moi, c'est que les technologies de Mozilla (XUL, XBL, overlay, templates etc...) sont trés liées les unes avec les autres, ce qui résulte qu'il n'y a pas 36 moyens d'implementer tout ça ensemble je pense. Il faut le faire comme c'est fait dans Gecko (au niveau architectural j'entend). Est ce qu'alors KHTML a une architecture suffisement souple pour qu'on puisse ajouter toutes ces technos ensemble ? Je ne sais pas...
En tout cas, la majorité des moteurs XUL-like ne sont guère allé plus loin que le support du seul langage XUL (donc en gros, supporter une simple liste de balises et transformer chacune en appel de fonctions d'une API de widget, ce que ne fait absolument pas Gecko). La difficulté de mise en oeuvre des autres technos toutes ensembles doit être en partie la cause de ce simple support. (même si je reconnais que cela peut être suffisant dans beaucoup de cas). En tout cas, à mon sens, On ne peut pas dire que c'est du XUL comme dans Mozilla.
Le XUL (le vrai, celui de Mozilla), souvent copié, mais jamais égalé.
[^] # Re: ASP
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 7.
Non, je ne crois absolument pas ça. Nvu est fait pour faire du HTML/XHTML. Pas pour faire du faux HTML avec des balises bizarroïdes dedans qui ne sont conformes à rien du tout.
Comme dis le commentaire du dessus, si tu veux faire de l'ASP, il y a des outils trés bien chez Microsoft. C'est leur problème si ils ne suivent pas les standards. Pas celui de Nvu. Ils n'ont pas les mêmes objectifs, c'est tout.
Pour faire une course de F1, tu utilises une F1, pas un tracteur. Là c'est pareil. Pour faire du HTML, tu peux utiliser Nvu, il est fait pour ça. Si tu veux faire de l'ASP, tu utilises les outils qui sont fait pour (Frontpage, VS.net..).
En clair : l'utilisateur doit utiliser le meilleur outils pour faire ce qu'il a à faire. et pas à l'outils de devenir une usine à gaz pour contenter tout le monde. (aurez tu oublier la philosophie des programmes Unix ? Ils font une seule chose, mais ils le font bien)
[^] # Re: stratégie google
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Bounties KDE pour le "summer of code" project de Google. Évalué à 10.
http://developer.kde.org/summerofcode/xul.html(...)
Le type montre trés bien qu'il ne sait absolument pas de quoi il parle. Des extensions, ce n'est pas que du XUL. Et du XUL, ce n'est pas seulement une simple liste de balise. Il a *un peu* oublié XBL, les overlays, la localisation, RDF, les templates, les skins etc..
Toutes les explications ici :
http://ljouanneau.com/blog/2005/06/30/447-projet-xul-dans-konqueror(...)
En fait, ça me fait doucement rigoler car les responsables du summer of code savent qu'ils vont économiser 4500$ (sûrement aussi sur d'autres projets). Je doute que le gars arrive à faire en 2 mois ce que des dizaines d'ingénieur ont fait en plusieurs années dans Mozilla. (et ils le savent trés bien puisqu'ils ont embauché des ingénieurs de Mozilla...)
Bref, ne vous réjouissez pas trop vite. L'implementation de XUL dans konqueror ne pourra être qu'une implementation trés incomplète. Et n'offrira que peu de compatibilité avec les fichiers XUL de Mozilla.
[^] # Re: ASP
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 5.
Une balise <% ... %>, comme celles utilisées pour l'ASP n'est pas conforme vis à vis de XML/SGML. Ce n'est donc pas traitable par un parser HTML conforme. Dans Nvu, le parser ne reconnaissant pas une balise, convertit les < et > en entité < et > (et encore, je crois que c'est un vilain hack, le parser devrait refuser de charger le document à cause de ces vilaines balises non conformes, donc, tu vois qu'il y a déjà un effort de fait :-p )
Quand bien même le parser reconnaitrait cette balise, cela signifie qu'il faudrait créer un objet spécifique DOM n'existant pas dans la spec DOM (beurk), avec toutes les conséquences que cela impliquerait dans le coeur de gecko (faire des hacks de partout pour parser, serialiser, afficher etc ce genre de balise). Bref, ça obligerait à faire un truc super crade dans le code de gecko je pense.
Contrairement à la balise <?...?> qui est définit dans la spec XML comme étant une "processing instruction".. Et encore, la spec indique clairement que le <? doit être suivi d'un nom : <?xml ...?> <?foo ...?> etc.. D'où le support des balises <?php ?> mais pas de <? ?> dans Nvu.
[^] # Re: Merci Glazman
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 1.
[^] # Re: Reformatage du code
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 3.
pfiouu, vivement les vacances...
[^] # Re: Reformatage du code
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 1.
Bon, vous pouvez moinsser mon message plus haut :-)
[^] # Re: Reformatage du code
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 10.
Il s'embete pas à modifier le code, il ne peut pas faire autrement, tout simplement. Et il peut pas le laisser tranquille
Quand tu edites une page HTML en wysiwyg : le fichier est parsé et transformé en arbre DOM. Cette opération est indispensable pour que Gecko puisse l'afficher. Ensuite, quand tu édites, ajoutes, modifie des trucs, cela fait des manipulations sur le DOM, pas sur le source. Quand tu bascules en source ou que tu enregistres le fichier, il y a serialisation du DOM. C'est ce qu'il y a de plus simple, et je t'assure, c'est déjà assez compliqué comme ça. Faut bien comprendre qu'un editeur HTML/XML wysiwyg ne travaille absolument pas sur le source, mais sur une representation logicielle de la structure du document (le DOM). On ne peut faire autrement à cause de l'aspect Wysiwyg. Si on travaillait directement sur la source, le rendu serait beaucoup trop lent. à chaque modif (du copier d'un bloc, à l'insertion d'un seul caractère), faudrait déjà placer la modif au bon endroit (donc trouver la balise qui correspond, changer ce qu'il y a à changer dans le source) et ensuite re-parser le source, re-interpreter les balises, et re-appliquer les styles CSS, re-faire l'affichage en conséquence etc... Ce serait, contrairement à ce que tu dis, bien plus embetant que de faire comme c'est fait actuellement. Quant à maintenir une version à la fois textuel et DOM en mémoire, ce serait d'une complexité totalement futile.
Si il fallait en plus, lors de la serialisation, remettre tout en place comme c'etait avant, cela necessiterait donc de mémoriser l'emplacement de chaque caractère, de chaque balise, de mémoriser ce qui a été modifié, ce qui ne l'a pas été, d'éventuellement tenir compte de preferences utilisateurs sur la façon de formater les nouveaus trucs etc... Bonjour alors l'occupation mémoire, les perfs et la complexité du truc. Pour un résultat finalement *vraiment* peu utile.
> Et non, désolé, je ne participerai pas, j'ai déja mon projet qui me bouffe du temps
C'étais ironique ce que je disais, car faire les modifs que tu demandes, demanderait de modifier le moteur Gecko, ce qui te prendrait des mois à le faire (à plein temps), le temps de comprendre comment ça fonctionne... (et tu perdrais ton temps car tu comprendrais que c'est finalement pas interressant de le faire, vu ce que cela impliquerai en terme de coût mémoire, perf etc.. et les conséquences sur tout le reste). C'est pour plein de bonnes raisons que ce n'est pas fait dans Nvu.. Et plein de bonnes raisons qui fait que ces modifs ne seraient pas acceptés par la fondation Mozilla (à toi donc de maintenir ton patch avec chaque version de Gecko, ce qui est trés contraignant et perte de temps...).
[^] # Re: Reformatage du code
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 6.
Si c'était si simple, il y aurait longtemps que ce serait fait :-p
De plus, je ne vois pas l'interêt d'utiliser un truc wysiwyg si on tient tellement à ce que le code source soit de telle ou telle manière. En effet, si tu tiens à un formatage précis, c'est que tu veux pouvoir l'éditer à la main, donc tu connais le HTML. L'interêt d'utiliser un truc wysiwyg dans ce cas est trés faible. Tu veux qu'il soit présenté comme ci, comme ça ? eh bien le mieux est de le taper toi-même.
De toute façon, ton formatage, il sera, quoi qu'il arrive, toujours cassé. Ne serait-ce que le formatage des nouveaux élements insérés par Nvu. Crois tu qu'il puisse deviner tout seul que *toi*, tu veux que l'indentation soit de 4 espaces, avec un saut de ligne aprés chaque balises fermantes ? On pourrait faire en sorte que ça fasse ça. Manque de bol, y a untel qui veux 2 sauts lignes, avec des indentations de 2 espaces, et 1 commentaire pour chaque balise. Et que dire de l'autre, qui veut tout sur une seule ligne parce qu'il veut économiser de la bande passante. Ou encore l'autre qui veut pas de saut de ligne aprés des li mais par contre des sauts de lignes apres des ul, etc ....
Bref, avec un minimum de reflexion, tu peux comprendre que
1) ce n'est pas simple techniquement parlant. C'est d'ailleurs un problème récurent dans tous les programmes de génération de code, que ce soit de la génération de code à la delphi, ou à la visual studio, dreamweaver etc..
2) ça n'est pas utile. La navigateur n'en a rien à fiche de la façon dont le code source est présenté. Le principal est que le code fourni soit valide, et éventuellement formaté proprement de façon à rester lisible humainement ( sans être forcément formaté selon les caprices de l'utilisateur).
[^] # Re: bof...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Nvu 1.0 est sorti. Évalué à 6.
Oui, t'inquiète pas, des idées pour améliorer Nvu, on en a plein :-)
Mais tu oublie un paramètre dans l'équation : le temps. Il n'a pas 4 bras, ni 10 employés pour le faire. Mais si tu nous donnes les sous pour les embaucher à temps complet (et aussi les former pendant plusieurs mois), ne te gène pas pour nous les donner ;-) .
Tout comme Dreamweaver ne s'est pas fait en 1 jour, Nvu ne s'est pas fait en un jour.
(comparer Quanta à Nvu, donc comparer du non wysiwyg à du wysiwyg, c'est un peu hasardeux je trouve, la complexité de réalisation du premier est largement inférieur à celle de l'autre, et le public visé n'est pas du tout le même...)