Je te ferais remarquer que la grammaire du XHTML est à l'identique de ce qu'on trouve dans HTML.
On appel soupe de balise une mauvaise utilisation du langage (genre 15 tableaux imbriqués pour afficher trois cadres).
>CSS devrait passer au xml aussi, non ?
CSS n'a pas été conçu que pour HTML, mais aussi pour XML. Ça fait donc longtemps que tu peux utiliser css avec du xml. Tu peux trés bien ouvrir un document xml dans un navigateur, lié à une feuille de style CSS via une processing instruction xml-stylesheet.
>Alors c'est sûr, ça sera un peu plus pénible à utiliser avec un éditeur de type 'nano', mais tellement plus facile avec un éditeur xml...
je vois absolument pas le rapport. Je vois pas par exemple en quoi Nvu est compliqué à utiliser (où l'utilisateur ne voit pas une seule balise à l'horizon, et où il peut styler en CSS sans qu'il le sache pratiquement). Et on fait pareil avec XML dans Etna (éditeur XML wysiwyg).
mouai bof, je trouve pas qu'il soit plus avantagé sur tf1 que sur une autre chaine (m'enfin si tu le dis...) Cependant, faut pas se faire d'illusion, les millions qui les servent à financer leurs campagnes, ils ne sont pas sorti de nulle part.. Ils sont forcément "sponsorisé". Par exemple, on pourrait dire la même chose de Royal vis à vis de canal +. Dans l'émission Le Grand Journal par exemple, c'est lèche botte à tout va envers Royal, et c'est souvent questions qui fachent envers les autres candidats. (il y a même des invités non politique qui l'ont fait remarqué à Denisot en direct..)
>c'est un homme qui ne pense qu'à lui, qui compare tout à lui,
Ouaou... Et tu crois que les autres politiciens sont comment ? Non mais franchement, c'est une vérité de lapalisse que tu nous dit là hein. Je ne sais pas, prend Royal par exemple. Un culte de la personnalité sans aucune mesure quand même. Y a qu'a voir son spot de propagande à la télé. Elle prend une pose style joconde, elle se prend pour le centre du monde dans ses discours. Bref, y en a pas un pour racheter l'autre à ce niveau là. Faut arrêter le FUD.
Bref dans cet example, ça va chier si ton image est plus haute que ton texte, a ce moment là ton image va déborder du bord de ton cadre.
Ok, j'ai compris ce que tu voulais faire. Certes, il faut bricoler, mais le comportement que tu décris de float est tout à fait normal et conforme aux spécifications. Float, ça retire du flux la boite sur lequel il est appliqué. c'est donc normal que la boite jaune ne prenne pas la hauteur de celle flottante, puisque cette dernière n'est plus contenue "visuellement" dans la boite jaune.
Bref, ce n'est pas "une merde" comme tu dis, c'est juste que le float de CSS2 ne correspond pas à tes besoins.
Ceux pour qui la syntaxe HTML suffit, ils feront leurs pages en HTML5. Et pour ceux qui voudront mélanger ce que propose html5 avec d'autres langages XML (genre, intégrer du MATHML, du SVG etc), ils utiliseront le XHTML5.
HTML5 et XHTML5, c'est le même langage, ce sont juste des syntaxes différentes (l'une SGML, l'autre XML). Je ne vois pas en quoi l'un des deux va disparaitre, vu qu'ils reposent sur les mêmes spécifications, proposent les mêmes balises et attributs.
C'est finalement comme XHTML1 et HTML4 : ils proposent les mêmes balises, les mêmes attributs. Bref, c'est le même langage, mais une syntaxe différente. Pour rappel : http://openweb.eu.org/articles/differentes_dtd/
« C'est prévu dans CSS3, et ça fonctionne dans Firefox 1.0+ -moz-border-radius »
Navré mais c'est une spécificité firefox/mozilla, j'ai toujours pas vu une vrai règle css dispo a ce propos.
C'est une spécificité Mozilla dans le sens où il y a le -moz- devant le "border-radius". Border-radius étant le style que tu cherches dont la spec est décrite dans le brouillon de CSS3. Et comme c'est un brouillon, Mozilla l'a implémenté mais a mis son prefixe devant. Ainsi, au cas où la spec sortirait en candidate recommandation mais avec des modifications, Mozilla ne serait alors pas en contradiction avec la spec CSS3.
De nombreux styles Mozilla implémentant des styles de CSS3 ou CSS2 mais dont les specs étaient flous ou non figées, sont passés par le stade "-moz-". Et ils ont retirés le -moz- quand l'implémentation correspondait bien à la spec finale. Et c'est souvent le même processus chez d'autres éditeurs (les styles prefixés par un "-kkchose-" étant autorisés par la spec CSS)
Ce que je veux est simplement pouvoir soumettre la form avec un envoie de fichier (si possible avec indicateur de progression) sans recharger la page. Leur xforms et webform sont a mon avis complètement inutiles, trop compliqué pour ce que c'est. Moi ce que je veux est pouvoir simplement côté client envoyer sans soumettre (et donc recharger la page) simplement un formulaire.
Les specs que tu appels inutiles et compliquées (webforms ? compliqués ??? Tu es sûr d'avoir lu la spec ou même mon billet ?) te permettent justement de faire ce que tu décris.
Navré mais j'ai regardé leur balises, rien de concret, ça me donne l'impression d'avoir été conçu pas des mathématiciens sans penser au gens normaux...
J'ai pourtant je pense bien expliqué simplement dans mon billet dont j'ai donné l'url. Si tu l'avais lu correctement, tu aurais vu que, pour éviter de remplacer la page, il suffit juste de renvoyer un code http 204 (simple fonction header() en php). Si tu trouve cela pas concret, je sais pas ce qu'il te faut
Désolé mais les specs j'appelle pas ça une doc, pour moi c'est une daube infâme illisible.
Il est vrai que les specs ne sont pas fait pour les utilisateurs finaux de la techno, mais pour ceux qui l'implémente. Mais franchement, celle de HTML5 et webforms sont quand même relativement simple par rapport à d'autres. En attendant que des tutos sortent pour les utilisateurs finaux comme toi, une fois que la spec sera figée et sera une recommendation.
Des choses intéressantes que j'ai retenus : - href dans toutes les balises
Je suis pas vraiment de ton avis. Ça risque d'être un super beau bordel surtout si tu as toute une arborescence de balises avec chacune un href... Pour le user, ça va être imbitable.
display: integrated; /* à l'intérieur, ne débordera pas du conteneur */
display: float; /* flotant à l'intérieur, débordera du conteneur */
integrated ? ça veut pas dire grand chose, et surtout ta définition ne permet pas de comprendre ce que tu veux.
Va voir aussi la spec CSS3 qui propose d'autres valeurs pour le display.
surtout qu'un clear: left; ne va pas prendre en charge l'élément float du conteneur, puis remonter, mais va clear sur toute la page !!!)
Là tu énonces un bug de IE je pense... En tout cas chez moi, un clear:left n'a jamais annulé tous les float. Enfin en tout cas je n'ai jamais rencontré le problème. (enfin bon, je ne m'amuse pas non plus à mettre des floats dans tous les sens)
il serait bon d'avoir enfin un round corner qui marche et standard.
c'est prévu dans CSS3, et ça fonctionne dans Firefox 1.0+ ( -moz-border-radius)
Après les derniers vrais manques sont les histoires de soumissions de form en javascript, j'ai toujours pas trouvé comment simplement envoyer un fichier sur un serveur en xmlrpc.
xmlhttprequest ? sinon que ce soit XForms ou les webform en HTML5, ça apporte de nombreuses améliorations à ce niveau. http://ljouanneau.com/blog/2006/08/30/587-web-forms-2 . Et avec XForms, tu peux envoyer les données dans le format que tu veux.
Après pour la sémantique et autre je pense qu'on met la charrue avant les boeufs. Comprendre on fixe un api avant d'avoir fait un panel des besoins et bonnes pratiques.
C'est le but de html5. Regarde la spec et les nouvelles balises qu'il propose avant de critiquer dans le vide.
la section head toujours pas standardisée depuis des années
pardon ? c'est standardisé depuis des années dans HTML et XHTML.. Et standardisé des "metas", ce ne serait pas logique, puisque par définition, les métas est une manière d'enrichir le head selon tes propres besoins.
M'enfin peut être que les microformats pourraient résoudre ton problème.
tu n'auras jamais à utiliser IE, pour la bonne raison qu'aucun dev web n'utilisera XHTML2...
Et puis bon, c'est un peu de la vision du future à 2 balles que tu nous dis là :-). IE, le seul navigateur actuelle à ne pas prendre en charge XHTML 1. Et Microsoft qui soutiendrait XHTML 2 à l'avenir ? la bonne blague :-)
Bon sinon rassures-toi : bien qu'il y ait des participants au working group XHTML2 qui viennent de Microsoft, ils n'ont pas dit un seul mot depuis des années.. Bref, l'implication de Microsoft dans XHTML2 est quasi nulle. Et je ne parle pas des autres éditeurs de navigateurs, qui sont aussi totalement absent pour la plupart.
Je ne vois pas comment un langage puisse avoir un avenir, si les principaux intéressés ne contribuent pas à l'élaboration de ses specs. Et si ils ne contribuent pas (que ce soit MS ou les autres), c'est qu'il y a un problème dans XHTML2 n'est ce pas ? ;-)
Il ne parle pas par exemple des élements audio, video, meter, progress, figure, canvas, source, datagrid, command, menu : tout plein de truc pour développer des applis web modernes sans avoir à pondre des centaines de lignes de code javascript.
Et il ne faut pas oublier non plus la partie javascript, avec les objets Storage (déjà implémenté dans FF2), le drag and drop (déjà en partie dans le trunk de Firefox 3), l'aspect offline (déjà dans le trunk Firefox 3) etc...
Bref, XHTML2 fait totalement l'impasse sur tout ça, qui sont pourtant nécessaires de nos jours !
Et je ne parle pas des formulaires. Là où HTML5 rajoute quelques attributs qui apportent la puissance nécessaire et comblent les manques actuels, XHTML2 propose tout bonnement d'utiliser XForms. La bonne blague, quand on connait la complexité de XForms ! Xforms, c'est trés bien pour des formulaires complexes, mais c'est overkill pour la majorité des formulaires web.
Le gros avantage de HTML5, est qu'il se base sur quelque chose d'existant, tandis que XHTML2 pas beaucoup. C'est donc plus facile pour les développeurs : ils peuvent passer "en douceur" de HTML4 à HTML 5. Et les pages HTML5 se dégraderont mieux dans un navigateur qui ne le supporte pas que XHTML2 (on sait tous le problème du content-type du xhtml 1.1, qui n'est pas reconnu par IE, donc chez 80% des utilisateurs, alors imaginez le problème d'un nouveau langage XHTML2 pas vraiment compatible avec les autres...).
C'est aussi plus facile pour les éditeurs de navigateurs pour implémenter (x)HTML5 plutôt que XHTML2. Ils n'ont pas à tout recoder, mais juste à rajouter des choses. Et pas la peine de me signaler qu'il y a beaucoup de balises en commun dans XHTML2 avec XHTML1 : les specs sont différentes, donc faut réécrire une bonne partie du truc. Par exemple, le fait qu'on puisse mettre un href (donc des liens) sur toutes les balises, n'est vraiment pas anodin en terme d'implémentation et de reprise de code de xhtml1.
>Je trouve domage que Mozilla et Opera qui sont deux navigateurs à suivres les normes du web jouent au Microsoft de 1998.
Comme je disais dans un autre commentaire, Mozilla, Opera et Apple sont les principaux éditeurs de navigateurs. L'autre grand acteur, c'est Microsoft. Bref, franchement, ce que font Mozilla, Opera et Apple n'est franchement pas comparable avec ce que faisait Microsoft et Netscape dans leur coin dans les années 90. là on a 3 acteurs majeurs qui marchent main dans la main ! si MS n'a pas voulu suivre le WHATWG, c'est quand même pas le probleme des autres ! Je dirais me que c'est le contraire : Microsoft, avec son WPF et autre XAML, et à ne pas suivre le W3C ou le WHATWG, continuent à faire cavalier seul !
>j'y retrouve la quasi totalité des balises que je connais.
Tu as quand même pas mal de nouvelle balises. Et lire une liste de balise ne suffit pas ;-) Il faut voir par exemple les conséquences des balises section, l ou h (au niveau css par ex)
>Et dire que HTML5 est plus "démocratique" que XHTML c'est une farce
Compte le nombre de site en HTML. Compte ceux en XHTML (valide). Les premiers sont une écrasante majorité quand même..
Tu es devant ton cerisier tous les jours toutes la journée pour affirmer qu'elles ne butinent pas ?
De toute façon, tu sauras bien si elles sont passées ou non : tu le verras au nombre de kilo de cerises que tu récolteras ;-) enfin plutôt du nombre de cerises que tu verras pousser, parce qu'entre la maturation et la ceuillette, je sais qu'il y a beaucoup d'oiseau qui s'en donnent à coeur joie :-)
> ben oui, je ne vois pas pourquoi je devrais être un super webmaster agréé bac+5 et tuticuanti pour pouvoir mettre les photos de mes enfants en ligne
Excuse moi, mais un utilisateur lambda n'a pas à coder une page html : il utilise les outils à sa disposition (nvu, dreamweaver, ou même mieux, un soft de gestion de gallerie de photos en php ou autre).
Dans openoffice, tu tapes les balises xml opendocument ? non, j'en suis sûr.
Je vois pas en quoi c'est génant d'avoir un langage un peu plus complexe. L'objectif de l'informatique, c'est pas coder. C'est utiliser. C'est aux outils de cacher toute la complexité d'un système, d'un langage.
>chacun fait ses trucs à sa sauce dans son coin...
ah eumh.. Tu es sûr d'avoir bien lu la news ?
Apple, Opera et Mozilla ont travaillé ensemble au WHATWG pour élaborer un HTML5, et tu appelles ça "chacun fait ses trucs à sa sauce dans son coin" ? Dis moi, peux tu me citer d'autres "grands" éditeurs de navigateurs web, à part Microsoft ?
Quant à XHTML 2, lit la spec, et tu verras que ça n'a plus vraiment grand chose à voir avec XHTML 1 et HTML. C'est un langage mort né parce qu'aucun grand éditeur ne participe activement à son élaboration.
Par contre, à propos de CSS3, c'est vrai qu'il faudrait que le working group au w3c se bouge un peu plus. Mais bon, ça avance, ça avance :-)
XHTML 2 n'a strictement rien à voir avec ce que je raconte. Moi je parle d'un XHTML 1++ (non standard).
XHTML 2 fait table rase sur HTML/XTHML. C'est un tout autre langage. Il est mort né pour moi... (y a qu'à voir le working group XHTML2 : aucun des grands acteurs coté navigateur y participe activement, même si le nom de certains, comme Microsoft y sont inscrit).
De ce que je vois dans FF3, il me semble en tout cas que ce qui est dispo au niveau HTML l'est aussi au niveau HTML5 (si mes souvenirs sont bons, il n'y a que le parser qui change dans Firefox entre HTML et XHTML, et les noeuds DOM crées dans les deux cas sont les mêmes objets C++).
Il y a aussi des différences, mais essentiellement au niveau du modèle de boite CSS. (par exemple, en HTML, la balise body , n'est pas une boite, alors que XHTML, elle l'est).
as tu regardé ce que proposait HTML 5 ? Et est ce que tu fais du dev web ?
Tout ce que propose le WHATWG :
- il y a déjà une partie qui sont déjà en cours de normalisation au w3c (XBL2, xmlhttprequest &cie)
- dans le HTML5, il y a des choses qui simplifient la vie du developpeurs. Faut voir le nombre de ligne de code qu'il faut actuellement pondre pour faire des sites web ajax qui bougent dans tous les sens. C'est tout bonnement horrible. Alors que dans HTML5, il y a des balises et attributs qui simplifient énormément de choses et qui nécessitent moins de code à écrire.
Et il faut savoir que des trucs de HTML5 (mais pas tout) sont en cours d'intégration dans Firefox 3.
Enfin, XHTML n'a jamais été qu'une simple reformulation de HTML en XML : il n'y a rien de plus, rien de moins en XHTML par rapport à HTML ! Mêmes balises, mêmes attributs.
HTML 4.1 strict = XHTML 1.0 strict
HTML 4.1 transitionnal = XHTML 1.0 transitionnal
Et je suppose, que ce qu'on aura en HTML, sera dispo aussi en XHTML (dans firefox). Donc bref...
(y a même des trucs de HTML5 en cours d'intégration dans Firefox 3, qui seront aussi dispo directement dans XUL...)
>Bon, tout d'abord désolé si je t'ai un peu ennervé, ce n'était en aucun cas le but
moi aussi, je me suis peut etre énervé un peu :-)
>je regrette simplement le coût d'accès à ces technologies qui est assez important
oui, certainement par un manque de visibilité des produits qui existent déjà. Maintenant je ne comprend pas le cout d'accés. À moins que tu n'es jamais fait de web, les technos mozilla, c'est quand même en grande partie des standards (CSS, HTML, javascript, XML, DOM etc...). Il y a juste le langage XUL en lui même qui necessite un apprentissage (qui n'est quand même pas compliqué à la base...) et le dev de composant XPCOM (là je reconnais, c'est plus hardu, surtout si on les fait en C++).
>car la dernière fois que j'ai essayé xul j'ai pas tout capté
Tu as lu les traductions des tutos xulplanet sur http://xulfr.org ? Tu es allé posé des questions dans le forum de xulfr ?
>ce que je regrette c'est simplement qu'il n'y ait pas une volonté clair et franche de la fondation mozilla pour mettre en avant ces technologies.
Il y a une volonté claire et franche de les mettre en avant : c'est le but de l'existance de devmo. Mais faire la doc de cet éco-système gigantesque, ça prend du temps.
>J'ai l'impression que beaucoup est fait pour promouvoir firefox (ce qui est très bien) et beaucoup moins sur les autres produits et encore moins sur les plateformes de dev.
> c'est quand même un beau monstre (ne serait-ce que par la quantité de code dans mozilla...)
Tu as mis le doigt sur l'origine des problèmes ;-) (gecko est parmis les plus gros projets open source en terme de lignes de code). Mais je peux t'assurer que tout est fait pour simplifier les API dans la mesure du possible. (et au passage, au niveau des performances et occupation mémoire; Gecko 1.9 va être vraiment mieux de ce point de vue).
ouai ouai. Personnellement, ça me fatigue les remarques négatives que y a pas assez de doc, y a pas d'environnement de dev nia nia nia... des remarques comme les tiennes, j'en ai toutes les semaines (On a beau faire le maximum qu'on peut, on s'en prend toujours plein la gueule, ras le bol)
Bon déjà, d'une part, c'est en partie faux, parce que la doc a pas mal evoluée quand même hein, et qu'il existe des plugins pour éclipse. D'autre part, xulrunner c'est libre, la doc sur devmo ou xulfr, ce sont des wikis.
Ça vous emmerde que la doc soit incomplète ? ça vous emmerde que les IDE soient pas assez évolués ? Ça vous emmerde que XulRunner a tel ou tel défaut ? Ça vous emmerde que Apollo ou WPF fasse de l'ombre à la seule alternative libre ? Alors arrêtez de vous plaindre, et venez nous aider : cliquez sur "editer la page" dans les wikis, ou ouvrez votre éditeur de code pour améliorer les plugins eclipses ou XulRunner. On ne demande que ça ! Plus on sera nombreux, plus vite ça s'améliorera.
[^] # Re: balise canvas et XHTML
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
Je te ferais remarquer que la grammaire du XHTML est à l'identique de ce qu'on trouve dans HTML.
On appel soupe de balise une mauvaise utilisation du langage (genre 15 tableaux imbriqués pour afficher trois cadres).
>CSS devrait passer au xml aussi, non ?
CSS n'a pas été conçu que pour HTML, mais aussi pour XML. Ça fait donc longtemps que tu peux utiliser css avec du xml. Tu peux trés bien ouvrir un document xml dans un navigateur, lié à une feuille de style CSS via une processing instruction xml-stylesheet.
>Alors c'est sûr, ça sera un peu plus pénible à utiliser avec un éditeur de type 'nano', mais tellement plus facile avec un éditeur xml...
je vois absolument pas le rapport. Je vois pas par exemple en quoi Nvu est compliqué à utiliser (où l'utilisateur ne voit pas une seule balise à l'horizon, et où il peut styler en CSS sans qu'il le sache pratiquement). Et on fait pareil avec XML dans Etna (éditeur XML wysiwyg).
[^] # Re: Mouais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Politique] Sarkozy est-il ce qu'il prétend être ?. Évalué à 2.
[^] # Re: Mouais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Politique] Sarkozy est-il ce qu'il prétend être ?. Évalué à 8.
Ouaou... Et tu crois que les autres politiciens sont comment ? Non mais franchement, c'est une vérité de lapalisse que tu nous dit là hein. Je ne sais pas, prend Royal par exemple. Un culte de la personnalité sans aucune mesure quand même. Y a qu'a voir son spot de propagande à la télé. Elle prend une pose style joconde, elle se prend pour le centre du monde dans ses discours. Bref, y en a pas un pour racheter l'autre à ce niveau là. Faut arrêter le FUD.
[^] # Re: Mouais
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [Politique] Sarkozy est-il ce qu'il prétend être ?. Évalué à 3.
Il s'est expliqué sur le sujet à plusieurs reprises dans des émissions (le grand journal sur C+ par ex)
# WPF/E
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Marre de flash ?. Évalué à 4.
[^] # Re: Css3 et marcher sur la tête...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
Ok, j'ai compris ce que tu voulais faire. Certes, il faut bricoler, mais le comportement que tu décris de float est tout à fait normal et conforme aux spécifications. Float, ça retire du flux la boite sur lequel il est appliqué. c'est donc normal que la boite jaune ne prenne pas la hauteur de celle flottante, puisque cette dernière n'est plus contenue "visuellement" dans la boite jaune.
Bref, ce n'est pas "une merde" comme tu dis, c'est juste que le float de CSS2 ne correspond pas à tes besoins.
Heureusement, dans CSS3, ils sont en train de réflechir pour prendre en compte le cas que tu décris, avec la propriété clear-after : http://www.w3.org/TR/2002/WD-css3-box-20021024/#the-clear-af(...) Par exemple, il suffira de mettre dans ta div article :
<div class="article" style="background: yellow; clear-after:left;" >
plus besoin de ta div hidden.
[^] # Re: Css3 et marcher sur la tête...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
Ceux pour qui la syntaxe HTML suffit, ils feront leurs pages en HTML5. Et pour ceux qui voudront mélanger ce que propose html5 avec d'autres langages XML (genre, intégrer du MATHML, du SVG etc), ils utiliseront le XHTML5.
HTML5 et XHTML5, c'est le même langage, ce sont juste des syntaxes différentes (l'une SGML, l'autre XML). Je ne vois pas en quoi l'un des deux va disparaitre, vu qu'ils reposent sur les mêmes spécifications, proposent les mêmes balises et attributs.
C'est finalement comme XHTML1 et HTML4 : ils proposent les mêmes balises, les mêmes attributs. Bref, c'est le même langage, mais une syntaxe différente. Pour rappel : http://openweb.eu.org/articles/differentes_dtd/
[^] # Re: Css3 et marcher sur la tête...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
C'est une spécificité Mozilla dans le sens où il y a le -moz- devant le "border-radius". Border-radius étant le style que tu cherches dont la spec est décrite dans le brouillon de CSS3. Et comme c'est un brouillon, Mozilla l'a implémenté mais a mis son prefixe devant. Ainsi, au cas où la spec sortirait en candidate recommandation mais avec des modifications, Mozilla ne serait alors pas en contradiction avec la spec CSS3.
De nombreux styles Mozilla implémentant des styles de CSS3 ou CSS2 mais dont les specs étaient flous ou non figées, sont passés par le stade "-moz-". Et ils ont retirés le -moz- quand l'implémentation correspondait bien à la spec finale. Et c'est souvent le même processus chez d'autres éditeurs (les styles prefixés par un "-kkchose-" étant autorisés par la spec CSS)
Les specs que tu appels inutiles et compliquées (webforms ? compliqués ??? Tu es sûr d'avoir lu la spec ou même mon billet ?) te permettent justement de faire ce que tu décris.
J'ai pourtant je pense bien expliqué simplement dans mon billet dont j'ai donné l'url. Si tu l'avais lu correctement, tu aurais vu que, pour éviter de remplacer la page, il suffit juste de renvoyer un code http 204 (simple fonction header() en php). Si tu trouve cela pas concret, je sais pas ce qu'il te faut
Il est vrai que les specs ne sont pas fait pour les utilisateurs finaux de la techno, mais pour ceux qui l'implémente. Mais franchement, celle de HTML5 et webforms sont quand même relativement simple par rapport à d'autres. En attendant que des tutos sortent pour les utilisateurs finaux comme toi, une fois que la spec sera figée et sera une recommendation.
[^] # Re: Css3 et marcher sur la tête...
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
Je suis pas vraiment de ton avis. Ça risque d'être un super beau bordel surtout si tu as toute une arborescence de balises avec chacune un href... Pour le user, ça va être imbitable.
integrated ? ça veut pas dire grand chose, et surtout ta définition ne permet pas de comprendre ce que tu veux.
Va voir aussi la spec CSS3 qui propose d'autres valeurs pour le display.
Là tu énonces un bug de IE je pense... En tout cas chez moi, un clear:left n'a jamais annulé tous les float. Enfin en tout cas je n'ai jamais rencontré le problème. (enfin bon, je ne m'amuse pas non plus à mettre des floats dans tous les sens)
c'est prévu dans CSS3, et ça fonctionne dans Firefox 1.0+ ( -moz-border-radius)
xmlhttprequest ? sinon que ce soit XForms ou les webform en HTML5, ça apporte de nombreuses améliorations à ce niveau. http://ljouanneau.com/blog/2006/08/30/587-web-forms-2 . Et avec XForms, tu peux envoyer les données dans le format que tu veux.
C'est le but de html5. Regarde la spec et les nouvelles balises qu'il propose avant de critiquer dans le vide.
pardon ? c'est standardisé depuis des années dans HTML et XHTML.. Et standardisé des "metas", ce ne serait pas logique, puisque par définition, les métas est une manière d'enrichir le head selon tes propres besoins.
M'enfin peut être que les microformats pourraient résoudre ton problème.
[^] # Re: balise canvas et XHTML
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
à noter qu'un XHTML 5, la version XML de HTML5 est prévu hein..
http://www.whatwg.org/specs/web-apps/current-work/#html-vs
[^] # Re: Ironie
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 5.
Et puis bon, c'est un peu de la vision du future à 2 balles que tu nous dis là :-). IE, le seul navigateur actuelle à ne pas prendre en charge XHTML 1. Et Microsoft qui soutiendrait XHTML 2 à l'avenir ? la bonne blague :-)
Bon sinon rassures-toi : bien qu'il y ait des participants au working group XHTML2 qui viennent de Microsoft, ils n'ont pas dit un seul mot depuis des années.. Bref, l'implication de Microsoft dans XHTML2 est quasi nulle. Et je ne parle pas des autres éditeurs de navigateurs, qui sont aussi totalement absent pour la plupart.
Je ne vois pas comment un langage puisse avoir un avenir, si les principaux intéressés ne contribuent pas à l'élaboration de ses specs. Et si ils ne contribuent pas (que ce soit MS ou les autres), c'est qu'il y a un problème dans XHTML2 n'est ce pas ? ;-)
Pour moi, XHTML2 n'a aucun avenir.
[^] # Re: X/HTML5 Versus XHTML2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 5.
Le type a oublié 95% des nouveautés de (x)HTML5. Il n'a pas du lire vraiment la spec. http://www.whatwg.org/specs/web-apps/current-work/
Il ne parle pas par exemple des élements audio, video, meter, progress, figure, canvas, source, datagrid, command, menu : tout plein de truc pour développer des applis web modernes sans avoir à pondre des centaines de lignes de code javascript.
Et il ne faut pas oublier non plus la partie javascript, avec les objets Storage (déjà implémenté dans FF2), le drag and drop (déjà en partie dans le trunk de Firefox 3), l'aspect offline (déjà dans le trunk Firefox 3) etc...
Bref, XHTML2 fait totalement l'impasse sur tout ça, qui sont pourtant nécessaires de nos jours !
Et je ne parle pas des formulaires. Là où HTML5 rajoute quelques attributs qui apportent la puissance nécessaire et comblent les manques actuels, XHTML2 propose tout bonnement d'utiliser XForms. La bonne blague, quand on connait la complexité de XForms ! Xforms, c'est trés bien pour des formulaires complexes, mais c'est overkill pour la majorité des formulaires web.
Le gros avantage de HTML5, est qu'il se base sur quelque chose d'existant, tandis que XHTML2 pas beaucoup. C'est donc plus facile pour les développeurs : ils peuvent passer "en douceur" de HTML4 à HTML 5. Et les pages HTML5 se dégraderont mieux dans un navigateur qui ne le supporte pas que XHTML2 (on sait tous le problème du content-type du xhtml 1.1, qui n'est pas reconnu par IE, donc chez 80% des utilisateurs, alors imaginez le problème d'un nouveau langage XHTML2 pas vraiment compatible avec les autres...).
C'est aussi plus facile pour les éditeurs de navigateurs pour implémenter (x)HTML5 plutôt que XHTML2. Ils n'ont pas à tout recoder, mais juste à rajouter des choses. Et pas la peine de me signaler qu'il y a beaucoup de balises en commun dans XHTML2 avec XHTML1 : les specs sont différentes, donc faut réécrire une bonne partie du truc. Par exemple, le fait qu'on puisse mettre un href (donc des liens) sur toutes les balises, n'est vraiment pas anodin en terme d'implémentation et de reprise de code de xhtml1.
>Je trouve domage que Mozilla et Opera qui sont deux navigateurs à suivres les normes du web jouent au Microsoft de 1998.
Comme je disais dans un autre commentaire, Mozilla, Opera et Apple sont les principaux éditeurs de navigateurs. L'autre grand acteur, c'est Microsoft. Bref, franchement, ce que font Mozilla, Opera et Apple n'est franchement pas comparable avec ce que faisait Microsoft et Netscape dans leur coin dans les années 90. là on a 3 acteurs majeurs qui marchent main dans la main ! si MS n'a pas voulu suivre le WHATWG, c'est quand même pas le probleme des autres ! Je dirais me que c'est le contraire : Microsoft, avec son WPF et autre XAML, et à ne pas suivre le W3C ou le WHATWG, continuent à faire cavalier seul !
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
Tu as quand même pas mal de nouvelle balises. Et lire une liste de balise ne suffit pas ;-) Il faut voir par exemple les conséquences des balises section, l ou h (au niveau css par ex)
>Et dire que HTML5 est plus "démocratique" que XHTML c'est une farce
Compte le nombre de site en HTML. Compte ceux en XHTML (valide). Les premiers sont une écrasante majorité quand même..
# Attend le résultat
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal [HS] Où sont les abeilles ?. Évalué à 1.
De toute façon, tu sauras bien si elles sont passées ou non : tu le verras au nombre de kilo de cerises que tu récolteras ;-) enfin plutôt du nombre de cerises que tu verras pousser, parce qu'entre la maturation et la ceuillette, je sais qu'il y a beaucoup d'oiseau qui s'en donnent à coeur joie :-)
[^] # Re: balise canvas et XHTML
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
[^] # Re: XHTML 5
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 3.
Excuse moi, mais un utilisateur lambda n'a pas à coder une page html : il utilise les outils à sa disposition (nvu, dreamweaver, ou même mieux, un soft de gestion de gallerie de photos en php ou autre).
Dans openoffice, tu tapes les balises xml opendocument ? non, j'en suis sûr.
Je vois pas en quoi c'est génant d'avoir un langage un peu plus complexe. L'objectif de l'informatique, c'est pas coder. C'est utiliser. C'est aux outils de cacher toute la complexité d'un système, d'un langage.
[^] # Re: balise canvas et XHTML
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
ah eumh.. Tu es sûr d'avoir bien lu la news ?
Apple, Opera et Mozilla ont travaillé ensemble au WHATWG pour élaborer un HTML5, et tu appelles ça "chacun fait ses trucs à sa sauce dans son coin" ? Dis moi, peux tu me citer d'autres "grands" éditeurs de navigateurs web, à part Microsoft ?
Quant à XHTML 2, lit la spec, et tu verras que ça n'a plus vraiment grand chose à voir avec XHTML 1 et HTML. C'est un langage mort né parce qu'aucun grand éditeur ne participe activement à son élaboration.
Par contre, à propos de CSS3, c'est vrai qu'il faudrait que le working group au w3c se bouge un peu plus. Mais bon, ça avance, ça avance :-)
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 2.
XHTML 2 n'a strictement rien à voir avec ce que je raconte. Moi je parle d'un XHTML 1++ (non standard).
XHTML 2 fait table rase sur HTML/XTHML. C'est un tout autre langage. Il est mort né pour moi... (y a qu'à voir le working group XHTML2 : aucun des grands acteurs coté navigateur y participe activement, même si le nom de certains, comme Microsoft y sont inscrit).
[^] # Re: XHTML 5
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 4.
Il y a aussi des différences, mais essentiellement au niveau du modèle de boite CSS. (par exemple, en HTML, la balise body , n'est pas une boite, alors que XHTML, elle l'est).
[^] # Re: utilité ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Apple, Opera et Mozilla poussent HTML5. Évalué à 4.
Tout ce que propose le WHATWG :
- il y a déjà une partie qui sont déjà en cours de normalisation au w3c (XBL2, xmlhttprequest &cie)
- dans le HTML5, il y a des choses qui simplifient la vie du developpeurs. Faut voir le nombre de ligne de code qu'il faut actuellement pondre pour faire des sites web ajax qui bougent dans tous les sens. C'est tout bonnement horrible. Alors que dans HTML5, il y a des balises et attributs qui simplifient énormément de choses et qui nécessitent moins de code à écrire.
Et il faut savoir que des trucs de HTML5 (mais pas tout) sont en cours d'intégration dans Firefox 3.
Enfin, XHTML n'a jamais été qu'une simple reformulation de HTML en XML : il n'y a rien de plus, rien de moins en XHTML par rapport à HTML ! Mêmes balises, mêmes attributs.
HTML 4.1 strict = XHTML 1.0 strict
HTML 4.1 transitionnal = XHTML 1.0 transitionnal
Et je suppose, que ce qu'on aura en HTML, sera dispo aussi en XHTML (dans firefox). Donc bref...
(y a même des trucs de HTML5 en cours d'intégration dans Firefox 3, qui seront aussi dispo directement dans XUL...)
[^] # Re: Témoignage
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 2.
moi aussi, je me suis peut etre énervé un peu :-)
>je regrette simplement le coût d'accès à ces technologies qui est assez important
oui, certainement par un manque de visibilité des produits qui existent déjà. Maintenant je ne comprend pas le cout d'accés. À moins que tu n'es jamais fait de web, les technos mozilla, c'est quand même en grande partie des standards (CSS, HTML, javascript, XML, DOM etc...). Il y a juste le langage XUL en lui même qui necessite un apprentissage (qui n'est quand même pas compliqué à la base...) et le dev de composant XPCOM (là je reconnais, c'est plus hardu, surtout si on les fait en C++).
>car la dernière fois que j'ai essayé xul j'ai pas tout capté
Tu as lu les traductions des tutos xulplanet sur http://xulfr.org ? Tu es allé posé des questions dans le forum de xulfr ?
>ce que je regrette c'est simplement qu'il n'y ait pas une volonté clair et franche de la fondation mozilla pour mettre en avant ces technologies.
Il y a une volonté claire et franche de les mettre en avant : c'est le but de l'existance de devmo. Mais faire la doc de cet éco-système gigantesque, ça prend du temps.
>J'ai l'impression que beaucoup est fait pour promouvoir firefox (ce qui est très bien) et beaucoup moins sur les autres produits et encore moins sur les plateformes de dev.
Oui, pour Mozilla, Firefox est LA priorité, car c'est grâce à Firefox que les technos Mozilla peuvent mieux s'incruster sur les postes utilisateurs et c'est le seul produit avec lequel ils arrivent à gagner de l'argent, donc c'est le seul qui leur permettent de financer les développements des technos Mozilla. Voir plus d'explications ici et là : http://ljouanneau.com/blog/2007/04/04/663-l-avenir-de-xul-et(...)
http://www.fdeshayes.net/index.php?2007/04/03/85-interview-l(...)
> c'est quand même un beau monstre (ne serait-ce que par la quantité de code dans mozilla...)
Tu as mis le doigt sur l'origine des problèmes ;-) (gecko est parmis les plus gros projets open source en terme de lignes de code). Mais je peux t'assurer que tout est fait pour simplifier les API dans la mesure du possible. (et au passage, au niveau des performances et occupation mémoire; Gecko 1.9 va être vraiment mieux de ce point de vue).
[^] # Re: CSS
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Petit test de Debian Etch. Évalué à 2.
[^] # Re: Témoignage
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Microsoft est mort et le logiciel libre n'y est pour rien ?. Évalué à 2.
Bon déjà, d'une part, c'est en partie faux, parce que la doc a pas mal evoluée quand même hein, et qu'il existe des plugins pour éclipse. D'autre part, xulrunner c'est libre, la doc sur devmo ou xulfr, ce sont des wikis.
Ça vous emmerde que la doc soit incomplète ? ça vous emmerde que les IDE soient pas assez évolués ? Ça vous emmerde que XulRunner a tel ou tel défaut ? Ça vous emmerde que Apollo ou WPF fasse de l'ombre à la seule alternative libre ? Alors arrêtez de vous plaindre, et venez nous aider : cliquez sur "editer la page" dans les wikis, ou ouvrez votre éditeur de code pour améliorer les plugins eclipses ou XulRunner. On ne demande que ça ! Plus on sera nombreux, plus vite ça s'améliorera.
Merci.