Laurent J a écrit 2933 commentaires

le xhtml 1.1 strict n'existe pas !

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.

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.

encore un qui n'a pas tout compris... et qui fait des hors sujet...

Si quelqu'un serait assez intelligent pour faire subir a IE 7 une batterie de tests : compatibilité PNG, CSS 1/2, header XHTML, acid2, RSS,

à 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".

ça existe déjà. c'est fait par la société transmeta. là où bossait linus torvalds il y a quelques temps.

voir ma réponse plus haut

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...

> Pourquoi ne pas faire comme Opera ?

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(...)

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...

ce n'est pas de l'intégrisme primaire.

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)

L'implémentation de XUL dans Konqueror est pure utopie, surtout quand le type annonce que ça va permettre d'utiliser les extensions pour Firefox.

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.

encore un mec qui croit que tout est facile...

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é &lt; et &gt; (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)..

pfiouu, vivement les vacances...

oh ! Daniel a tout de même reussi à le faire :-)

Bon, vous pouvez moinsser mon message plus haut :-)

> 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).

> Glasman aurait pu s'en inspirer ;-)

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...)

voir les liens à gauche sur nvu.com (ça se passe donc, pour le français, ici : http://frenchmozilla.sourceforge.net/nvu/(...) )

La version française de Nvu 1.0 devrait arriver dans les heures qui viennent.

Mon avis va certainement paraître un peu subjectif vu que je bosse chez D.I., mais il me semble qu'une bonne partie des utilisateurs de Dreamweaver sont des Monsieur tout le monde, qui utilisent Dreamweaver parce que c'est le plus connu, pour faire leur page perso ou les 3 pages plaquettes du site de leur boîte.

Et je suis prêt à parier que ce genre d'utilisateur ne connaissent qu'un dixième des possibilités de Dreamweaver (tout comme 90% des utilisateurs de MS Word qui ne connaissent qu'un dixième des possibilités de Word). Un logiciel comme Nvu leur suffirait amplement. C'est en ce sens, dans ce contexte, que je dis que Nvu est un concurrent de Dreamweaver.

Maintenant, un peu de patience, Nvu en est seulement à sa première version stable. J'aimerais bien mettre la main sur Dreamweaver 1.0 pour savoir si il gérait aussi bien les CSS, les templates (oui parce que Nvu utilisent des templates contrairement à ce que dit un commentaire plus haut), ou produisait du code pas trop crade et valide.

Le problème, c'est que, il me semble, tous les gros projets doivent avoir le même problème. Comme tous les projets du libre tendent à devenir gros (je pense à Firefox, OO.org, Evolution, ou des projets largement utilisés comme ça), je pense qu'il faudrait sérieusement réfléchir à des moyens de pas rebuter les contributeurs non-régulier de tels projets.

Euh, ce serait bien de ne pas généraliser ! Ce n'est pas parce qu'avec struts tu as eu des problèmes qu'il faut croire que, tous les gros projets ont ces problèmes .
(et puis bon, entre nous, struts, est *vraiment* un petit projet par rapport à Firefox ou OO.org... en terme de nombre de ligne de code, il est loin d'être dans la catégorie poid lourd, crois moi)

Conçernant Mozilla, ils ont réflechi à des moyens de ne pas rebuter les contributeurs, mais ce n'est finalement pas évident du tout. Pour "faciliter" les contributions ils ont développé bugzilla.

Alors certes, certains se plaignent que c'est compliqué, que recuperer les sources de Firefox et compiler, c'est compliqué, etc.. Mais c'est, je dirais, à la hauteur de la complexité d'un tel projet. Il est clair qu'il faut faire un gros effort au début, ne pas hésiter à lire les docs. Il faut aussi bien rechercher si le bug en question n'est pas déjà référencé, ou même corrigé.

Le plus dur en fait, le plus rébutant, c'est de s'immerger dans un tel projet, avec l'apprentissage des technos, des coding practice etc... Ça prend des mois (pour Mozilla/Firefox). Alors c'est sûr que dans ces conditions, ce n'est pas le developpeur lambda débarquant dans le projet qui va pouvoir pondre un patch en 2 jours. Plus c'est gros, plus c'est difficile (surtout pour un truc aussi complexe comme le moteur d'un browser). Le meilleur bugzilla-like du monde ne pourra rien y changer à ce niveau là.

Et donc, les contributeurs occasionnels n'existent pas vraiment sur de gros projets comme Mozilla. Il y a des rapporteurs de bug occasionnel, mais les "patcheurs" occasionnels sont trés rares.

Bon, alors mettons les choses au point un peu...

Je fais du libre (je suis développeur). 100% du libre. Dans mon boulot, ou à la maison (je suis un geek, en plus d'être développeur). Et ma boîte fait du libre (éditeur de logiciel, pas SSLL). 100% du libre. Et ça va bien, je te remercie, mon salaire a toujours été versé jusqu'à maintenant. J'ai à manger dans mon assiette. et y en a aussi dans celle de ma femme, de mon cochon d'inde, de mes deux tortues et de mon poisson rouge (oui, y en a des bouches à nourrir chez moi). J'arrive même à payer les traites de ma maison (et à troller sur IRC). C'est pour te dire !
Ok, la taille de notre boîte n'est pas encore celle de Microsoft. Mais on y travaille.

Pourvu que ça dure ! (Parce que bon, tu me fais peur avec tes histoires..)

> mais qui es tu donc Ô mytèrieux personnage ?

C'est un pote de Pierre Tramo.