Les nouvelles fonctionnalités les plus intéressantes : API pour dessiner des graphiques en deux dimensions, embarquement et contrôle des contenus audio et vidéo, maintient de stockage de données côté client pour permettre aux utilisateurs d'éditer des documents ou des parties de document de manière interactive.
Rappelons que le HTML 4 a fêté ses 10 ans en décembre 2007, une éternité en informatique, particulièrement le domaine du web. Quant au XHTML 2.0, il est jugé trop compliqué et trop peu accessible pour la plupart des personnes amenées à publier sur le Web. Le XHTML 2.0 semble donc être abandonné.
Aller plus loin
- Annonce du HTML 5 (8 clics)
- Différences ente HTML 4 et HTML 5 (10 clics)
- Nouveaux éléments du HTML 5 (4 clics)
- Nouveaux attributs du HTML 5 (3 clics)
- Blog de Laurent Jouanneau : « Premier brouillon de HTML5 » (9 clics)
# Une syntaxe non xml
Posté par yellowiscool . Évalué à 1.
<head>
<meta charset="UTF-8">
<title>Example document</title>
</head>
C'est franchement pas bien beau…
Envoyé depuis mon lapin.
[^] # Re: Une syntaxe non xml
Posté par Snarky . Évalué à 6.
[^] # Re: Une syntaxe non xml
Posté par RB . Évalué à 6.
Faudra vraiment que quelqu'un m'explique l'avantage a ne plus avoir de l'xml (autre que est plus chiant que ...)
[^] # Re: Une syntaxe non xml
Posté par bichenoubi . Évalué à 5.
http://xhtml.com/fr/future/x-html-5-versus-xhtml-2/
http://www.digital-web.com/articles/html5_xhtml2_and_the_fut(...)
discussion antérieure sur le sujet: http://linuxfr.org/2007/04/13/22361.html
[^] # Re: Une syntaxe non xml
Posté par Boa Treize (site web personnel) . Évalué à 3.
Comme d'autres l'ont rappelé, tu as le choix de la syntaxe : HTML ou XML.
L'XML ayant plein d'avantages mais aussi plein d'inconvénients, listés en partie dans ce document : http://hixie.ch/advocacy/xhtml c'est très bien d'avoir le choix entre les deux.
(Et niveau « môcheté », je prends un HTML 4.01 Strict dix fois plutôt qu'un XHTML 1.0 Transtional comme on en voit trop.)
[^] # Re: Une syntaxe non xml
Posté par Moonz . Évalué à 5.
Par contre, un nouveau XHTML qui prendrait les bonnes idées de HTML 5 serait le bienvenu...
[^] # Re: Une syntaxe non xml
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
HTML5 == XHTML5
http://www.w3.org/TR/2008/WD-html5-20080122/#html-vs
En gros, pour le HTML5, tu as le choix entre la syntaxe SGML (le HTML quoi), et la syntaxe XML (donc XHTML).
Bref, c'est comme entre XHTML 1 et HTML 4.01 : ce n'est qu'une histoire de notation. Les balises, les attributs etc, sont identique dans les deux cas.
[^] # Re: Une syntaxe non xml
Posté par Boa Treize (site web personnel) . Évalué à 3.
- En HTML 5 la syntaxe est HTML ou XML ; HTML n'est plus une application SGML, il n'y a plus besoin de DTD, des règles de parsing spécifiques font partie de la norme
- Il y a un élément absent en XHTML qui existe en HTML : noscript
[^] # Re: Une syntaxe non xml
Posté par alberthier (site web personnel) . Évalué à 1.
Une page web ne pourra être interprétée correctement que par un navigateur alors qu'avec du xhtml, on pouvait faire un script avec n'importe quel langage fournissant un parser XML pour scanner une page. pff, c'est n'importe quoi, retour en 1995.
Autre point, je ne suis pas sur que ça améliore les choses d'un point de vue des applis web:
Aujourd'hui le html/xhtml est concu pour afficher des documents mais on s'en sert pour faire des applis (gmail, yahoo mail par exemple) sauf que vu que c'est pas vraiment fait pour ça et c'est donc assez lourd. Faire un layout à la Qt / GTK en Web c'est vraiment galère: genre hbox / vbox avec contraintes de taille. Pourquoi ne pas piquer un peu des idées du coté de XUL ?
[^] # Re: Une syntaxe non xml
Posté par Boa Treize (site web personnel) . Évalué à 2.
Euh dans tes rêves peut-être ? Moi, je n'ai presque jamais vu sur Internet de page XHTML complètement valide.
Et puis une page web peut tout à fait être interprétée par autre chose qu'un navigateur, BeautifulSoup s'en sort très bien par exemple.
Le seul endroit où tu as des chances d'avoir vu du vrai XHTML parsable, c'est sur un intranet ou un site pro, mais puisque HTML 5 a une syntaxe XML, rien n'empêchera l'intranet ou le site pro de continuer à être parsable si nécessaire.
[^] # Re: Une syntaxe non xml
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: Une syntaxe non xml
Posté par Boa Treize (site web personnel) . Évalué à 1.
(* sur environ 2500 sites surveillés par ce site)
[^] # Re: Une syntaxe non xml
Posté par François B. . Évalué à 1.
Mon navigateur (Firefox) se donne la peine de dire qu'il comprend le XHTML dans sa requête, le développeur propre et consciencieux ne lui enverra pas de soupe de tag HTML en réponse. Toujours d'après Firebug, la ligne Accept de la requête est "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5".
[^] # Re: Une syntaxe non xml
Posté par Jean-Philippe (site web personnel) . Évalué à 0.
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#t(...)
[^] # Re: Une syntaxe non xml
Posté par Moonz . Évalué à 4.
http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801/#s(...)
Ce qui je lirais plutôt comme "n'utilisez text/html que pour être compatible avec la vieille soupe infâme"...
[^] # Re: Une syntaxe non xml
Posté par Boa Treize (site web personnel) . Évalué à 3.
# XForms
Posté par tieum2067 . Évalué à 1.
[^] # Re: XForms
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
XForms est beaucoup utilisé en dehors du web, ou coté serveur.
[^] # Re: XForms
Posté par tieum2067 . Évalué à 2.
Et si cette norme est abandonnée par le W3C, qui sera en mesure de reprendre sa rédaction, et la faire évoluer? Cette annonce va peut être sonner le glas des projets orbeon et chiba.... En fait, je travaille sur un projet dans lequel on utilise orbeon, et on peut se demander si ce choix reste pertinent pour l'avenir...
[^] # Re: XForms
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: XForms
Posté par tieum2067 . Évalué à 2.
D'ailleurs, le lien que tu m'as donné montre qu'on a étendu les formulaires html classiques, ce qui me fait penser qu'on ne souhaite pas utiliser les Xforms. Après, j'ai peut être tout faux et on aura toujours la possibilité d'utiliser les xforms dans des document HTML5, mais alors je n'ai pas compris l'intérêt de HTML5... Si c'est "juste" rajouter des balises supplémentaires pour le contenu multimédia, pourquoi ne pas avoir apporté des modifications au XHTML 2.0?
# quid de Ogg vs Apple et Nokia ?
Posté par Gniarf . Évalué à 9.
[^] # Re: quid de Ogg vs Apple et Nokia ?
Posté par Boa Treize (site web personnel) . Évalué à 4.
Je ne sais pas ce que c'est devenu.
[^] # Re: quid de Ogg vs Apple et Nokia ?
Posté par dragoonway . Évalué à 4.
http://rudd-o.com/archives/2007/12/11/removal-of-ogg-vorbis-(...)
[^] # Re: quid de Ogg vs Apple et Nokia ?
Posté par lemoutonvert . Évalué à 0.
http://www.cedynamix.fr/dotclear/index.php?post/2007/12/14/O(...)
La source citée est espagnole (donc incompréhensible pour moi), mais rien lu de plus depuis.
# Eternité ?
Posté par XHTML/CSS inside (site web personnel) . Évalué à 9.
-qu'il soit fini (c'est un brouillon !)
-qu'il soit implémenté sur tous les navigateurs les plus utilisés... (je m'inquiète surtout pour un certain IE qui est à la bourre...)
-et enfin qu'il soit utilisé !
Je suis à 100% pour du sang neuf de ce côté... mais ça n'est pas demain la veille. :(
[^] # Re: Eternité ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
- mécanisme offline et stockage locale est operationnel depuis FF2
- canvas dans FF2 et Safari
- video en cours de dev dans FF et Opera (j'ai testé dans un FF experimental, ça marche pas trop mal ;-) )
- dans HTML5, y a pas mal de truc similaire à XUL, donc l'implémentation dans Firefox de certaines choses ne devront pas prendre trop de temps ;-)
Enfin bref, ça avance, ça avance, faut arrêter d'être pessimiste :-p Surtout quand on sait que c'est le WHATWG donc Mozilla-Opera-Apple qui pousse le HTML5. Si ils sont derrière, c'est qu'ils sont d'accord pour implémenter rapidement non ?
Conçernant IE, vu encore leur dernière connerie en date d'activer le mode standard dans IE8 avec une balise meta (ouai chouette, trois mode de rendu à prendre en compte !), je crois que les developpeurs web vont en avoir ras le bol et pousser encore plus à l'adoption d'autres navigateurs.
[^] # Re: Eternité ?
Posté par Pierre6020 . Évalué à 4.
http://ejohn.org/blog/html5-doctype/
[^] # Re: Eternité ?
Posté par Mithfindel (site web personnel) . Évalué à 5.
Hmoui, tout ça c'est bien beau, mais quid des intranets d'entreprise ? Parce que les larrons n'ont en général qu'un bon vieil IE6 des familles, intégré à leur Windows XP Pro (quand c'est pas du 5.5 sur du 2000...). Et dans les DSI, du moment qu'un navigateur est présent sur un parc de quelques 10aines/100aines de machines, ils ne s'amusent pas à en mettre un autre (surtout dans les entreprises dont l'informatique est loin d'être le fonds de commerce).
Qu'on soit bien d'accord, je suis également un ardent défenseur des standards ouverts; seulement mon job se charge tout les jours de me rappeler que les standards en entreprise, c'est bon pour les Bisounours et qu'en vrai il faut batailler dur avec les 40 modes de rendus possibles des navigateurs de chez Microsoft.
[^] # Re: Eternité ?
Posté par BAud (site web personnel) . Évalué à 1.
Tu ne crois pas si bien dire :-)
Rien n'empêche d'installer Firefox sur W2K pour autant, ce qui permet de :
- se préparer à l'éventualité d'un passage à Vista, dont IE7 soit disant respecterait mieux les standards du W3C (mais donc casserait toutes les gruikeries accumulées depuis IE4)
- promouvoir des navigateurs respectueux des standards du W3C (bin oui, c'est tout de même dommage de développer pour IE5.5, IE6 et IE7 alors qu'il suffit de développer une seule fois _bien_ et _interopérable_ puis de regarder _ensuite_ les petites adaptations qui seraient nécessaires
- penser à rester sur un navigateur directement respectueux des standards du W3C et donc conserver Firefox pour la suite, ce qui permet aussi d'espérer prendre en compte l'accessibilité http://www.w3.org/WAI/wai-fr
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: Eternité ?
Posté par Philip Marlowe . Évalué à 5.
Maintenant, chanter sur l'air de Merci Patron des Charlots (demander aux plus anciens) :
Merci MS, merci MS
Quel plaisir d'interopérer avec toi
On est vraiment fou de joie
Merci MS, merci MS
Et si les standards disparaissent
Tu susciteras une grande liesse
Et si tu veux chanter avec nous, on t'a trouvé un nom d'artiste : Lou Ravi de Redmond.
Franchement, t'es vraiment naïf ou tu le fais exprès ?
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . Évalué à 1.
De croire que IE8 va améliorer le support des standards du W3C dans ce navigateur ? Je penses pas être naïf, ca serait juste complètement stupide et mauvais pour l'image de MS que de ne pas améliorer ce point, surtout qu'il est annoncé comme étant un objectif.
Je prétend pas que ca va être parfait, je dis que ca sera sûrement mieux, tout comme ie7 est mieux que ie6.
La solution choisie, à savoir proposer un mode n'ayant pas à se soucier de gérer la compatibilité avec l'existant laisse penser qu'ils peuvent quelque chose de pas trop mal. Si on prend tous les autres formats du W3C implémentés par MS, la compatibilité avec ces standards est plus que bonne (SOAP, XPath, W3C Schema, XSLT, etc.), ils peuvent tout à fait faire pareil avec IE8.
On dirait que ca vous fait chier à l'idée que MS respecte un peu mieux les standards.
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . Évalué à 3.
mais surtout des problèmes incommensurables aux développeurs web !
Ca va être quoi le problème pour les développeurs web ? Supporter les standards va les faire chier ? Rien ne les obligera à utiliser ce mode ! Ce mode est prévu pour ceux qui veulent coder leur site en respectant les standards et ne souhaitant pas faire plusieurs versions de leur sites pour différents navigateurs, où est la mauvaise idée ?
De plus ceux que ca fait chier, rien ne les obligeras à utiliser ce mode, IE8 restera compatible avec les rendus de IE7 et IE6, donc pourquoi critiquer cette initiative ?
Tu proposes quoi sérieusement ? Que IE8 ne propose que le support strict des standards et soit incappable d'afficher correctement tous les sites qui ont été fait pour les versions précédentes de IE ? Ou plutôt que IE8 soit toujours aussi pourri au niveau des standards pour continuer à gueuler sur MS ?
[^] # Re: Eternité ?
Posté par CrEv (site web personnel) . Évalué à 9.
Qu'il y aura toujours des "ça marche sous ie donc c'est bon" qui viendront fouttre la merde
Alors oui, passer en mode correct en standard c'est casser la compatibilité des anciens sites pourris.
Mais associé à un "mettez la balise meta si vous voulez le quirks mode" permetterait à moindre frait de pousser en avant le mode correct (car sinon pourquoi ça changerait ??).
D'ailleurs, oui ie 7 est mieux que ie6
Mais comme ce putain d'ie 6 (voir même inférieur) est toujours là, ben rien ne change...
Mais bon, comme d'hab, ms a systématiquement peur d'aller en avant, d'oser casser un peu la compatibilité.
Et juste comme ça, si qqn connait la réponse :
pourquoi ne pas utiliser le doctype plutôt que meta ? ça résoudrait la plupart des problèmes non ?
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Ben justement non. C'était la solution choisie dans IE7, manque de bol les développeurs mettent leurs DOCTYPE n'importe comment, et des pages qui se déclarent comme respectant tel ou tel standard était en fait toujours codé pour IE6 : résultat IE7 affiche incorrectement de sites qui marchait sous IE6.
Du coup là ils choisissent une autre technique, celle de la balise meta, qui a très peut de chance d'être déjà utilisée sur le web.
Mais bon, comme d'hab, ms a systématiquement peur d'aller en avant, d'oser casser un peu la compatibilité.
C'est pas une question d"oser", c'est juste une solution de transition qui permet de supporter les anciens sites tout en laissant la possibilité aux nouveaux sites d'être w3c-compliant. Bref tout le monde est content.
[^] # Re: Eternité ?
Posté par CrEv (site web personnel) . Évalué à 10.
C'est zarb, c'est pas trop ce que j'avais ressenti...
Ben vi, c'est vrai au lieu de forcer les dev à faire correctement on rajoute encore une couche... pitoyable !
Mais avec une telle façon de faire, rien ne changera justement.
Ben oui, il y a la solution du doctype mais les dev win sont trop con pour l'utiliser donc on choisi autre chose.
Mais avec un tel raisonnement, pourquoi ça changerait puisque ce qu'ils font marchera d'office sous ie 6-7-8 ?
Donc comme d'hab, ils vont mettre en place des standards, personne ne saura qu'il faut mettre la balise meta (sinon ils metterait déjà correctement la balise doctype et il n'y aurait pas ce problème) et microsoft pourra dire d'une qu'ils implémentent les standards, et de deux que tout le monde s'en branle et donc ça ne sert à rien
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . Évalué à 1.
Et tu proposes quoi à part forcer les développeurs ?
Sérieux c'est débile, t'as vu le nombre de site web sur internet ? je met ma main à couper que 90% d'entre eux ne respectent pas les standards, tu voudrais que MS casse la compatibilité avec tout les sites tout ca par "respect" pour les standards ??
Ben oui, il y a la solution du doctype mais les dev win sont trop con pour l'utiliser donc on choisi autre chose.
C'est quoi cette argumentation de merde, on insulte les développeurs qui essaient de faire des sites qui marchent avec le navigateur qui a les 3/4 du marché ?
Mais avec un tel raisonnement, pourquoi ça changerait puisque ce qu'ils font marchera d'office sous ie 6-7-8 ?
Bah tous les nouveaux sites pourront être fait en suivant les standards, le développeur y aura intérêt puisqu'il pourra partir du principe qu'il n'aura qu'un seul site à développer pour Opera/Firefox/IE/Safari.
Donc comme d'hab, ils vont mettre en place des standards, personne ne saura qu'il faut mettre la balise meta
Pourquoi les développeurs l'ignoreraient ?
sinon ils metterait déjà correctement la balise doctype et il n'y aurait pas ce problème
Comme indiqué par la team IE, le problème vient du fait que beaucoup d'entête de document HTML sont générés automatiquement par des softs (Dreamwaver & co). Effectivement c'est du laxisme.
Quand tu comprendras que forcer les développeurs à migrer tous leurs sites existant (ce qui est tout bonnement innimagineable) n'est pas répondre à leurs attentes... Respecter les standards n'est pas une finalité en soit, c'est un outil pour faciliter la vie des développeurs. MS offrent le choix au développeur d'utiliser l'outil qu'il veut selon ses besoins.
et de deux que tout le monde s'en branle et donc ça ne sert à rien
Bah non on pourra enfin faire un site sans se soucier du navigateur (pour le HTML en tout cas, avec le javascript c'est pas gagné), ce dont de nombreux développeurs ne se branlent pas tellement ils passent du temps.
PS : je te rappelle que Firefox ou Safari ne sont pas full w3c-compliant, et qu'ils s'adaptent également aux sites existant, c'est ce qui fait aussi leur succès... Pourquoi tu ne les critiques pas de la même manière ? Ils pourraient systématiquement afficher un message d'erreur si une page est pas w3c-compliant !
[^] # Re: Eternité ?
Posté par CrEv (site web personnel) . Évalué à 4.
Pourquoi ne mettent-il pas la bonne balise doctype alors ?
S'ils sont capable de foutre une balise meta alors ils sont capable de mettre un doctype. Donc maintenant il suffit de choisir comment faire les choses de manière la plus élégante...
Etrange, il me semblait que tu avais écris :
Pourquoi les migrer ?
pas de doctype -> quirks mode
doctype html <= 4/xhtml <= 1.1 -> rendu classique
doctype supérieur -> rendu "standard"
Rien besoin de forcer, mais qd même inciter à faire mieux... et y'a du taff...
Et ben que microsoft fasse pression en leur disant que s'ils ne corrigent pas ça risque de poser des problèmes. Et c'est tout !
Et eux seront aussi content, ils pourront vendre des nouvelles licences ie8compatible !
Oui merci je sais, je bosse sur du ie/firefox/safari/win/mac/linux à longueur de temps.
Mais de la même manière, tant que ça bougera pas sur javascript alors on fera toujours plusieurs versions (au moins par portions).
Et de la même manière, il suffit qu'au moins deux navigateurs n'implémentent pas exactement le même ensemble de fonctionnalités pour qu'on retombe (et ce sera assurément le cas, il ne faut pas se voiler la face) dans le même cas qu'actuellement (ptetre moins pire quand même...)
Ptetre parce qu'ils ne se sont pas mis en tête d'inventer encore un nouvelle spécificité pour dire "tiens si je tournais correctement" avec une balise meta à la con
Ptetre parce que eux poussent à utiliser des standards
Maintenant oui il m'arrive de gueuler sur firefox, sur des problèmes sous mac, sur des problème avec leurs "range" concernant les sélections, etc.
Mais là on ne parle pas de ça.
[^] # Re: Eternité ?
Posté par Étienne . Évalué à 2.
pas de doctype -> quirks mode
doctype html <= 4/xhtml <= 1.1 -> rendu classique
doctype supérieur -> rendu "standard"
Rien besoin de forcer, mais qd même inciter à faire mieux... et y'a du taff...
Apparament, si on a un doctype qui n'hexistait pas à l'époque de IE7, IE8 aura un rendu standard. Voir [http://ejohn.org/blog/html5-doctype/] (via glazblog)
Donc pour tous les doctype actuels, on aura un rendu compatible IE7, sauf à mettre la balise meta, mais pour toutes les nouveaux doctypes on aura bien un rendu standard sans besoin de balise meta. C'est plutôt une bonne nouvelle.
[^] # Re: Eternité ?
Posté par Moonz . Évalué à 4.
> C'est quoi cette argumentation de merde,
Ça s'appelle du bon sens. Quand dans un script ruby la première ligne est:
#!/usr/bin/env python
l'interpréteur python me sort une erreur quand j'essaie d'exécuter ce script avec un ./script. Normal. Manquerait plus que l'OS détecte que c'est une syntaxe ruby et qu'il fasse un exec(ruby) pour "faciliter la vie au développeur"...
[^] # Re: Eternité ?
Posté par TImaniac (site web personnel) . Évalué à 1.
D'ailleur Firefox est aussi laxiste sur ce point là, et pour les mêmes raisons de compatibilité avec l'existant.
[^] # Re: Eternité ?
Posté par Moonz . Évalué à 3.
si tu envoies ton fichier via HTTP, le doctype ne suffit pas, il faut aussi envoyer le bon Content-type (le type donné par HTTP étant prioritaire). Tu peux mettre le doctype que tu veux, tant que tu envoies du text/html, ça reste de la soupe. Par contre, quand tu envoies du xml (plusieurs types mime possibles), là, tu dis "je fais du xhtml", et effectivement firefox te gueule dessus si tu fermes une balise de travers...
[^] # Re: Eternité ?
Posté par Antoine . Évalué à 2.
Et Firefox, ils ont cassé la compatibilité avec les sites pourris peut-être ?
[^] # Re: Eternité ?
Posté par CrEv (site web personnel) . Évalué à 2.
les sites pourris sont écris _à destination_ d'ie
Donc que firefox lise mal des sites pourris (ce qui est le cas) c'est une chose (donc la réponse à ta question est justement oui...)
Que ms refuse sous des raisons à la con que ie fasse la même chose dans le but de mettre en avant un web propre alors oui c'est comme d'hab ms qui a peur d'aller en avant et d'en assumer les bonnes et mauvaises conséquences.
[^] # Re: Eternité ?
Posté par Antoine . Évalué à 1.
Non, c'est la même chose.
C'est stérile de critiquer MS qui cherche à soigner ses utilisateurs, et de dédouaner Mozilla qui a exactement les mêmes pratiques (alors que justement il leur serait plus facile de dire "c'est pas nous, c'est l'autre, on ne veut pas supporter ses conneries").
[^] # Re: Eternité ?
Posté par Moonz . Évalué à 3.
- Si demain MS fait que IE ne lise plus que les pages standard -> tous les sites passent aux standards.
- Si demain Firefox ne fonctionne plus qu'avec les pages standards -> "Firefox sai dla merde" et firefox retombera à 1% de parts de marché (et encore...)
Sur la forme, je suis d'accord: deux poids, deux mesures, ça pue
[^] # Re: Eternité ?
Posté par IsNotGood . Évalué à 2.
On devrait dire document de travail. Le "brouillon" html5 est beaucoup mieux qu'un brouillon.
Les nouvelles normes doivent toujours être en avance sur les implémentations. Sinon les développeurs font des trucs non standard (il faut bien les occuper :-)). Les nouvelles normes doivent donc être le cahier des charges des développeurs. Ceci n'est possible que si les normes ne sont pas encore implémentées et qu'elles sont "sexy".
# API pour dessiner des graphiques en deux dimensions
Posté par nojhan (site web personnel, Mastodon) . Évalué à 4.
En parcourant rapidement les liens, je n'ai pas trouvé à quoi fait allusion cette remarque. S'agit-il de quelque chose en rapport avec le SVG ? Pourquoi une "API" et pas un "format" ?
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Boa Treize (site web personnel) . Évalué à 4.
L'élément en lui-même est un (grand) rectangle vide au départ. Il dispose d'une grosse API (à piloter en JavaScript ou équivalent) pour dessiner à l'intérieur, y mettre des images, y faire du vectoriel, faire des transformations, réagir aux clics de souris, etc. C'est un peu l'équivalent de l'API Java2D. On retrouve le concept dans de nombreuses autres API, par exemple le module Canvas de Qt.
Le but est de pouvoir réaliser des applications purement graphiques (pourquoi pas des jeux, ou des IHM étrangement complexes), quand les autres éléments HTML ne suffisent pas.
- Tutoriel Mozilla : http://developer.mozilla.org/en/docs/Canvas_tutorial
- Doc Mozilla : http://developer.mozilla.org/en/docs/HTML:Canvas
- Spec (bien épaisse) : http://www.whatwg.org/specs/web-apps/current-work/multipage/(...)
C'est à mon sens un des éléments les plus compliqués d'HTML 5, surtout s'il faut en faire une implémentation performante (et il le faut, bien sûr). Ce sera probablement le dernier truc que Microsoft implémentera. ;-)
(Et Adobe doit faire un peu la gueule, même si Flash a de beaux jours devant lui.)
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par M . Évalué à 5.
Oui ...
il faut attendre que le truc soit implementé dans les navigateurs, mais aussi qu'il y ai des editeurs corrects.
De plus pour le son/video il faut jouer avec d'autres bout de HTML 5.
Bref ca sera pas utilisable au moins avant 5 ans, alors que le flash tourne a plein regime actuelement.
C'est un peu l'équivalent de l'API Java2D.
Qu'est ce qui garanti que ce truc n'aura pas autant de succès que les applet java qui permette de faire la même chose...
Au fait le svg il devient quoi dans tout ça.
PS : html ou pdf : qui sera le truc qui sera le plus lourd ?
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Boa Treize (site web personnel) . Évalué à 1.
Rien ne dit qu'il rencontrera un grand succès, bien sûr. Rien ne dit non plus qu'il a besoin d'un grand succès : il doit pour moi rester un élément de secours, quand le reste d'HTML ne suffit plus.
Quant au SVG, il vit sa vie, il n'est pas dépendant d'HTML. Il y a plein d'autres endroits que le web où le SVG est utile (en solo pour stocker du vectoriel ; ou à l'intérieur de suites bureautiques, par exemple ; et les icônes de nos desktops favoris bien sûr).
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Et < canvas > est souvent utilisé pour les widgets MacOS X ou Opera.
Sinon, Java peut faire la même chose et plus mais charger une JVM en mémoire pour faire un petit graphique c'est lourd.
J'avais testé à l'époque et voilà ce que ça donne : http://shift-working-area.infernal-quack.net/web_lab/ . L'avantage c'est qu'il suffit d'afficher le source de la page pour voir comment ça marche et pas besoin d'un éditeur proprio ou d'un décompilateur :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par M . Évalué à 3.
Sinon, Java peut faire la même chose et plus mais charger une JVM en mémoire pour faire un petit graphique c'est lourd.
Par ce que tu crois que les nouveaux navigateurs ne vont pas être aussi lourd que les jvm java (il faudrait seulement charger la jvm a l'avance) ?
D'ailleurs certains pour avoir des perfs correct en java script comptent utiliser des VM (cf tamarin pour firefox)...
Et quand on parle de lourdeur, quand je vois les perfs des video en flash, ca rame a fond parce qu'ils n'utilisent pas les accélération video (XV) a cause de la transparence et autre effets. Et ben je dirais que les gens s'en foutent (sur les conseils des vendeurs ils achètent de nouveau PC).
Le support de la balise < canvas > est déjà effectif dans Safari, Opera et Firefox soient les meilleurs concurrents d'IE.
Quel pourcentage de navigateur en utilisateur ça représente (pour FF je suppose que c'est que les dernière versions) ?
Quel sont les outils pour générer simplement du code pour les canvas ?
Si tu veux faire des effets avancé (transparence) comme en flash, a tu déjà des libs toutes prêtes ?
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par kowalsky . Évalué à 0.
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Mildred (site web personnel) . Évalué à 1.
Alors que sinon, tu dois utiliser le DOM ou autre pour faire les dessins que tu veux, et ça m'a l'air plus lourd. Car ce n'est pas prévu pour, donc il y a beaucoup plus de code javascript.
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
(c'est pour le moment très expérimental toutefois, j'ai pas réussi à faire marcher)
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Infernal Quack (site web personnel) . Évalué à 1.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Boa Treize (site web personnel) . Évalué à 2.
En fait c'est pas tellement la JVM qui est lourde (1,5 Mo d'exécutable) que la bibliothèque Java standard (32 Mo de classes Java).
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Boa Treize (site web personnel) . Évalué à 2.
http://blobsallad.se/
Interaction : souris et touches G, H, J
Pur HTML + JavaScript :-)
[^] # Re: API pour dessiner des graphiques en deux dimensions
Posté par Mildred (site web personnel) . Évalué à 1.
# Perplexe ...
Posté par Miguel Moquillon (site web personnel) . Évalué à 6.
Ce sentiment est d'autant plus fort face à deux faits :
- ce sont des grosses sociétés qui sont derrière l'HTML 5 (Nokia, Microsoft, IBM, etc.) or lorsque l'on connaît la proportion naturelle de ces boites à créer du bloatware ...
- l'XHTML a été présenté comme le successeur du HTML. Que l'XHTML 2.0 soit considéré trop complexe, soit. Mais alors pourquoi ne pas avoir poussé l'XHTML vers une autre orientation ?
Sinon, soit dit en passant, ce qui semble plus gêner les concepteurs de pages web vis à vis du XHTML ne semblent pas être sa complexité à proprement parler, mais plutôt ses contraintes strictes qui empêchent d'écrire un document bancale. (Pour être méchant, ils ont la nostalgie de l'époque où ils pouvaient concevoir n'importe comment des pages Web en s'appuyant sur le laxisme d'un certain navigateur Web.)
[^] # Re: Perplexe ...
Posté par Folken Laëneck . Évalué à 6.
En même temps, comment faire en sorte que le web évolue sans devenir - rester ? - un patchwork de site au codage bancale où les navigateurs sont obligés de touiller la soupe de balise qu'on leur sert jusqu'à pouvoir écrire des textes avec le vermicelle qui flotte dedans, sinon en imposant des contraintes ?
Dans les premières années du web, pendant son expansion, je veux bien admettre que laisser une telle possibilité était envisageable. Tout simplement parce que cela rendait l'accès au média simple à une période où il avait besoin de s'étendre.
Mais maintenant que de plus en plus d'applications se développent pour être utilisée en conjonction avec ou directement sur internet, que le nombre d'utilisateur a explosé et que chacun d'entre eux s'attend à recevoir des pages élégantes, bourrées de fonctionnalités pratiques et sans bugs, une page HTML n'est plus un simple média dans lequel on pousse des données.
Aujourd'hui, développeur web est un métier à part entière - la preuve, je passe mes journées à faire du développement et on me paye pour :] -. La syntaxe xml du XHTML1.x était à mon sens une grande évolution parce que justement elle obligeait les développeurs web à préter un peu plus attention à ce qu'ils faisaient et à utiliser des bases solides pour faire grandir leurs applications. La faire disparaitre est à mon avis une erreur.
Et si certains sont trop fainéants pour prendre les bonnes habitudes aujourd'hui, au risque de paraitre extrémiste, je pense qu'ils peuvent changer de métier.
Un développeur qui ne se remet pas en question est perdu d'avance, alors pourquoi revenir en arrière pour contenter ceux qui refusent d'aller en avant ?
[^] # Re: Perplexe ...
Posté par Boa Treize (site web personnel) . Évalué à 6.
Visuellement la syntaxe HTML reste la "même" bien sûr, mais au lieu d'en référer à la très complexe spécification SGML pour ce qui est autorisé dans un flux HTML, la norme définit ses propres règles de parsing, nettement plus claires et plus strictes. Elle définit aussi clairement comment un navigateur doit réagir face à une syntaxe incorrecte, donc tous les navigateurs devraient se comporter de la même manière. Il ne devrait pas y avoir de "quirks mode" pour HTML 5.
- Comment parser du HTML 5 : http://www.whatwg.org/specs/web-apps/current-work/multipage/(...)
(Les navigateurs conserveront probablement leurs parsers existants pour lire HTML 4 et ses prédécesseurs.)
# Légèreté
Posté par Nerdiland de Fesseps . Évalué à 8.
Avec toutes les nouvelles API, la gestion du glisser-déposer, le stockage et l'interrogation locaux des données, la double syntaxe SGML/XML, les aspects asynchrones, etc... Quel avenir reste-t-il aux bons vieux navigateurs "légers", graphiques ou non ? Devra-t-on forcément se blinder de RAM pour afficher une page web à peu près correctement ?
[^] # Re: Légèreté
Posté par Nicolas Legrand (site web personnel) . Évalué à 10.
Personnelement, je trouve ça crade, j'ai l'impression qu'on a tellement tordu dans tous les sens HTTP et HTML, tellement rajouté de couches par dessus que le web ressemble à un conglomérat de trucs moches scotchés. Et je ne suis pas plus emballé que ça par les développements futur ou encore le web of data.
Cependant il y a certaines réalités dures à contourner. J'ai du mal à me passer d'un navigateur et du web. Et vu l'usage qui en est fait par tous je me résigne à regarder les navigateurs grossir encore et encore.
Et dire que certains se plaignaient d'emacs en le surnommant « Emacs OS » :-).
[^] # Re: Légèreté
Posté par Boa Treize (site web personnel) . Évalué à 4.
Tu veux dire que c'est une toile d'araignée, quoi. :-)
(Franchement, Internet en général et le web en particulier ont toujours été un assemblage hétéroclite que l'on aime détester. C'est sa grande faiblesse tout autant que sa grande force.)
(Et pour ce qui est d'Emacs, voici un extrait du code source de sa version 170, euh... no comment. :-)
(oui oui c'est bien le code source... http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/01/e(...) )
[^] # Re: Légèreté
Posté par Gniarf . Évalué à 4.
[^] # Re: Légèreté
Posté par lfmarante . Évalué à 2.
http://fr.wikipedia.org/wiki/Virus_informatique
# Et la sémantique dans tout ça ?
Posté par gege (site web personnel) . Évalué à 3.
* la balise figure qui permet d'associer une légende à un élément graphique
* ou les balises sections, aside, nav qui permettent de mieux structurer le document et de signaler ce qui est le contenu et ce qui est de l'aide à la navigation ou de la décoration)
D'autre part on rajoute des balises qui elle ne pourront être rendues correctement que sur le média pour lequel la page a été conçue (qu'est qu'un moteur de recherche peut faire du contenu de canvas ? comment afficher une vidéo sur un écran de 3x3 cm ?)
Est-ce que le HTML5 est toujours dans la philo de séparer le contenu de la présentation ?
[^] # Re: Et la sémantique dans tout ça ?
Posté par Boa Treize (site web personnel) . Évalué à 2.
Qu'est-ce qu'un moteur web fait du contenu Flash, actuellement ? Comment afficher une vidéo sur un écran de 3x3 cm, actuellement ? La norme ne rajoute rien qui ne pose déjà problème, et ne répond pas au problème, mais comment pourrait-elle ?
Elle a le mérite de standardiser la manière de décrire ces éléments, pour qu'au moins les clients qui ne peuvent assurer leur présentation sachent quoi faire.
[^] # Re: Et la sémantique dans tout ça ?
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Heu... oui. Je préfères largement télécharger une vidéos et la regarder avec mon lecteur favoris que le fait que subitement mon ordi ce mettre à ramer parcequ'une page à décidé d'ouvrir 30 vidéos.
Je n'ai jamais vu de canvas sur le net (mis à part les proof of concept vu en lien sur cette page), donc je ne peux pas dire si oui ou non j'en voudrais.
Bah il n'existe pas. :)
J'ai pas de lecteur flash sur mon ordi, donc je m'en fou.
Bah en lançant le lecteur vidéo adapté avec la vidéo en question?
Genre lancer le lecteur vidéo? La balise object ne fait pas déjà ça en fait?
Finalement le problème ne serait-il pas les entreprises qui tiennent à contrôler les utilisateurs des services qu'ils fournissent via le web?
[^] # Re: Et la sémantique dans tout ça ?
Posté par Mildred (site web personnel) . Évalué à 1.
Mais comme dans la spec, il n'est dit nulle part que le navigateur devrait implémenter certains types vidéos, et fournir un player adapté, et fournir une API javascript adaptée à la vidéo, au WhatWg, ils ont préféré faire une balise ideo a part.
Du moins c'est ce que j'ai compris.
[^] # Re: Et la sémantique dans tout ça ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Ba c'est comme qu'est qu'un moteur de recherche peut faire du contenu d'une image ou d'une photo ?
Faut voir canvas comme étant un truc pour faire une image dynamique. C'est pas plus et pas moins accessible qu'une video par exemple.
Si tu veux une image "accessible", tu fais du SVG.
# Et donc on le fait comment son site web?
Posté par Maclag . Évalué à 2.
Mais quand on développe son site en amateur à la mimine et qu'on aimerait ne pas avoir à changer TOUTES les pages une par une le jour où on veut rajouter les fonctions kikool des prochains standards, on fait quoi pour l'instant?
J'ai un site (ultra-moche) que je suis en train de reprendre depuis quasi 0 et je l'ai commencé en essayant de faire du XHTML (et même du XHTML+MathML sur certaines pages), parce que c'était l'avenir d'hier mais donc là ce n'est plus le futur de demain, et là j'aimerais bien savoir si je me casse le c.. pour rien parce que d'une:
- MathML mourrait-il avec l'HTML5 au profit d'un nouveau standard encore moins bien supporté (faut dire que MathML en dehors de Firefox, c'est quasi-inexistant...) pour l'instant: merci la réécriture des équations!
- Non, finalement mon truc ne colle pas avec la nouvelle logique HTML5 et là ça "juste marche si tu touches plus à rien sinon tu reprends tout!"
[^] # Re: Et donc on le fait comment son site web?
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Et donc on le fait comment son site web?
Posté par Maclag . Évalué à 2.
Merci pour cette réponse et celles qui suivent.
Le problème vu d'un petit amateur plus ou moins éclairé, c'est justement de décortiquer les standards pour savoir où ça pêchera plus tard et où ça ira tout seul sans problème, c'est que je voudrais passer plus de temps sur le site lui-même que sur les modifications à planifier en vue des futurs standards!
Je garde donc mon MathML, et si je comprends bien, si le site valide XHTML1.0 strict (voire 1.1+MathML), alors j'aurai très peu voire pas du tout de difficulté à le migrer en XHTML5 (HTML5 en xml, j'ai bien compris??).
Ce que je reproche à tout ce foutoir, c'est que l"utilisateur" final de ces spécifications, ce sera bien le développeur du site, et je trouve que c'est encore un peu confus!
En tout cas merci à vous d'avoir éclairé ma lanterne, et en espérant qu'il n'y aura pas d'autre bouleversement dans un futur proche...
[^] # Re: Et donc on le fait comment son site web?
Posté par Christophe Roland (site web personnel) . Évalué à 1.
J'ai lu sur ta page mathml que tu écrit le code mathml à la main (tu es courageux!) moi aussi j'ai été assez déçu des outils mathml et donc j'utilise un logiciel de conversion, respectueux des standards, que j'ai écrit moi même. En fait tu écris ton document dans une syntaxe très proche du xhtml, et tu obtiens après conversion une version pdf et une version xhtml+mathml.
Il faut encore faire quelque petites adaptations car il est prévu au départ uniquement pour mon site, mais si jamais ça t'intéresse je peux y travailler.
[^] # Re: Et donc on le fait comment son site web?
Posté par Christophe Roland (site web personnel) . Évalué à 1.
- Mathml ne mourra pas avec html 5 (faudra juste utiliser la "version" xml.)
- En dehors de firefox, webkit prévoit de pouvoir afficher le mathml:
http://webkit.org/projects/mathml/index.html
chez Opéra aussi on parle de plus en plus de mathml:
http://my.opera.com/mathml/blog/
et chez IE, il y a le plugin mathplayer.
- html5 est rétrocompatible: un site en html 4 ou xhtml 1 valide, pas ou peu de modifications suffisent pour en faire un site valide html5.
[^] # Re: Et donc on le fait comment son site web?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
# Plus que sceptique
Posté par rewind (Mastodon) . Évalué à 10.
Et là, patatras, HTML5 arrive et remet tout ça en cause. Alors oui, on "peut" faire du XML avec HTML5, mais il ne faut pas rêver, les concepteurs ne vont pas s'amuser à aller vérifier la validité XML de leurs pages s'ils n'y sont pas obligés. Les trucs que je trouvais sympa dans XHTML2 et qui ont disparu dans HTML5 :
- la balise h qui permettait de ne pas spécifier de nombre après et qui, en combinaison avec la balise section donnait des trucs vraiment bien structuré [1]
- la balise l qui permettait de spécifier une ligne sémantique [2]
Mais surtout, parmi les horreurs de HTML5, j'ai vu :
- le détournement du sens de dt et dl où le d pourra signifier definition (comme en (X)HTML) mais aussi maintenant dialog, des éléments schizophrène donc. Ça va être simple d'apprendre le HTML5 : ça veut dire quoi dt ? ben le d veut dire : ça Dépend...
- la redéfinition de balises anciennes qui aurait dû disparaître, ce qui ne va pas améliorer ni leur abandon, ni leur compréhension : b, i, small
- la floppée de nouvelles balises inutile dans 99% des cas (aussi appelé Docbookisation de HTML) : progress, meter, etc.
- la disparition de la balise acronym : c'est peut-être anecdotique mais bon, moi je l'aimais bien et je l'utilisais. DokuWiki aussi génère automatiquement des balises acronym aussi pour un certain nombre d'acronymes qu'il connaît (genre SQL, IRC, etc). C'est une balise sémantique que je regretterai.
- la disparition de l'attribut style qui était fort pratique pour un style ponctuel mais souvent mal utilisé, je le reconnais.
- la disparition de l'attribut align dans la balise table : faudra m'expliquer comment, en CSS, je centre un tableau sans mettre de balise div autour et sans centrer tout mon texte. Idem pour l'attribut valign.
- le meilleur pour la fin : le retour de la balise font où on nous dit qu'on n'a pas le droit de l'utiliser, sauf si on est un éditeur WYSIWYG (un peu dans le genre du CPE, c'est publié mais vous ne devez pas l'utiliser). vu le nombre de personne qui utilise des Frontpage ou même des Word pour générer du HTML, on n'est pas près de voir disparaître ce truc infâme. On nous dit que les outils ne savent pas faire autrement ; et bien qu'ils apprennent à faire autrement mais qu'on ne nous ressortent pas ce cadavre qui était en voie d'extinction !
Bref, je suis vraiment très très très très sceptique et les avancées de HTML5 (je les ai pas commentées, d'autres l'ont fait avant) comme canvas ou nav ou header/footer ou audio/video ou même les nouveaux type d'input ne feront pas oublier toutes les horreurs/erreurs présentes et qui ne favoriseront pas les bonnes pratiques du web, à mon avis.
[1] http://www.w3.org/TR/xhtml2/mod-structural.html#edef_structu(...)
[2] http://www.w3.org/TR/xhtml2/mod-text.html#sec_9.7.
[^] # Re: Plus que sceptique
Posté par rewind (Mastodon) . Évalué à 7.
Parce que, quand on fait un petit site statique et qu'on veut mettre un menu, il faut recopier ce menu partout, au risque de devoir tout recommencer si on changer le menu. Une simple balise include permettrait de résoudre ce problème et d'éviter de devoir utiliser un PHP pour pouvoir faire des choses proprement et simplement.
En XHTML, je pense qu'on pourrait utiliser XInclude [1] qui est justement fait pour ça (ça marche pour tous les documents XML). Mais je n'ai jamais vérifié si c'était implémenté par les navigateurs, je vérifierai à l'occasion mais j'ai vraiment des doutes.
Donc pas d'inclusion encore pour cette fois.
[1] http://www.w3.org/TR/xinclude/
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 2.
Les frames proposaient une solution (je ne dis pas la meilleure solution) mais je doute qu'elles fassent partie de la norme.
Mais malhereusement comme beaucoup de site utilise des outils comme PHP, ça ne dérange pas grand monde. Mais perso, je préfère un site statique (sauf si il y a vraiment un besoin) et j'aimerais que la norme prévoie plus de choses pour ces sites.
- Les includes
- Pourquoi pas un format de menu standard (HTML ?) qui pourrait être lié par une balise <link> et affiché dans la sidebar du navigateur
- Pourquoi pas un moyen standard de proposer des commentaires sur une page (une balise <link> qui donne l'adresse d'une page qui recevra le commentaire, et affichera les commentaires présents, avec affichage dans une zone séparée du navigateur par exemple)
- et on peut imaginer plein d'autres choses.
A mon avis beaucoup des pages dynamiques actuelles pourraient être remplacées par une norme qui va bien implémentée dans le navigateur. Par exemple a quoi servent les wiki actuels alors que la commande HTTP PUT existe depuis le début ? (et que les premiers navigateurs proposaient aussi un éditeur HTML en même temps).
A mon avis, ce serait moins confus pour l'utilisateur qui aurait toujours la même interface devant lui pour ajouter une commentaire sur la page, modifier la page d'un wiki, ...
[^] # Re: Plus que sceptique
Posté par CrEv (site web personnel) . Évalué à 2.
heu vi mais les wiki tentent aussi de rendre l'édition un peu plus facile qu'en html...
Pour ce qui est des includes et menu, pourquoi pas.
Mais je vois pas trop pour les commentaires.
A partir de là on est justement plus dans un site au contenu statique.
Et dans tous les cas il faut bien que le serveur recoive qq chose.
Dans un site statique, le serveur ne fait justement qur fournir.
Du moment qu'on rajoute des commentaires ou autre, il faut aussi réceptionner, enregistrer, ... les données
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 1.
Avec ce genre de système, on peut avoir un site complètement statique avec quelques petits scripts CGI dans un coin ... On peut même utiliser un prestataire extérieur pour le CGI et garder un site entièrement statique.
Et un site statique, ça consomme moins de ressources.
[^] # Re: Plus que sceptique
Posté par Infernal Quack (site web personnel) . Évalué à 1.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html [
<!ENTITY header SYSTEM "file:../build-common.inc">
]>
<html>
&header;
</html>
Si tu as le temps, tu peux essayer et nous donner tes conclusions ? :)
Merci.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 2.
Vous pouvez tester:
http://mildred632.free.fr/test/test.html
http://mildred632.free.fr/test/test.xhtml
http://mildred632.free.fr/test/test2.html
http://mildred632.free.fr/test/test2.xhtml
http://mildred632.free.fr/test/test3.html
http://mildred632.free.fr/test/test3.xhtml
[^] # Re: Plus que sceptique
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Plus que sceptique
Posté par lolop (site web personnel) . Évalué à 3.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Plus que sceptique
Posté par psychoslave__ (site web personnel) . Évalué à 3.
Ça m'a l'air de fonctionner, et en définissant la taille de l'object (attribut width) plutôt que celle du body du fichier que j'inclus, je n'ai pas eu d'assenceur. Bon je dis pas qu'il n'y pas de possibilité de problème sur d'autres navigateurs, où avec des styles un peu plus poussés, où peut être que je n'ai même pas compris le problème que tu voulais signaler avec cette solution, mais ça m'a l'air de fonctionner.
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: Plus que sceptique
Posté par psychoslave__ (site web personnel) . Évalué à 3.
En tout cas, preuve est faite qu'inclure des documents externes, c'est tout ça fait faisable. Attention, je ne dis pas que ça s'intégrera toujours bien toujours comme on s'y attend. Je ne dis pas le contraire non plus. Je n'ai jamais vraiment utilisé la balise object en production, parceque je n'en jamais eu besoin.
Mais je sais qu'elle existe si un jour j'en ai besoin. Le but ici était simplement de signaler à rewind que contrairement à ce qu'il pensais, inclure un document externe en HTML, c'est tout à fait possible. Cette solution à peut être des défauts (rien n'est parfait, donc on trouvera toujours à redire), mais elle à le mérite d'exister.
[^] # Re: Plus que sceptique
Posté par rewind (Mastodon) . Évalué à 2.
Je trouve la solution un peu bancale quand même, c'est du détournement de balises. Et à vrai dire, je préfèrerais nettement que les navigateurs implémentent la toute petite norme XInclude, ce serait nettement plus clair et plus simple.
[^] # Re: Plus que sceptique
Posté par psychoslave__ (site web personnel) . Évalué à 2.
* Qu'est ce que tu trouves obscur et difficile dans cette solution?
* En quoi un XInclude serait plus adéquate, clair et simple?
Je ne l'avais jamais fait avant et ça n'a pas du me prendre plus d'une vingtaine de minutes en tout, je ne pense pas qu'on puisse dire que cela relève d'une extrême diffulté.
J'ai demandé à un pote de tester sous IE et ça à l'air de passer d'après ce qu'il me dit.
Un vrai problème c'est si le navigateur ne gère pas l'inclusion de document par la balise object. Par exemple links/lynx. Une solution peut être alors de simplement placer un lien vers la page menu entre les balises object, de manière à afficher ce lien si le navigateur ne gère pas l'inclusion. Bref, y a un mode dégradé très facile à mettre en place.
Je vois pas ce qu'on pourrait demander de plus à une balise d'inclusion en fait.
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 1.
C'est comme une iframe (pas de différence a ce que je peux voir) ... Donc c'est un objet et cela ne s'intègre pas bien au flot de la page.
Pour mon site statique, j'utilise une astuce très intéressante pour les styles. Dans chaque répertoire, j'ai un fichier 'style.css'. Presque partout, mon fichier contient @import url(../style.css).
J'ai un style général (dans le répertoire racine) qui me définit mon style par défaut, et chaque répertoire peut alors dans son propre fichier de style, redéfinir des choses (comme les images pour la présentation).
Mes styles (c'est plus parlant):
http://mildred632.free.fr/who/style.css
http://mildred632.free.fr/wot/style.css
http://mildred632.free.fr/style.css
Et les différences de présentation:
http://mildred632.free.fr/wot/
http://mildred632.free.fr/
J'aimerais bien pouvoir faire pareil avec les menus, mais avec la balise <object>, j'ai deux problèmes:
- il faut spécifier dans chaque page la dimension du cadre (ou alors garder la valeur par défaut, mais qui n'est pas adaptée pour un menu)
- si je m'amuse a faire des inclusions comme ça en cascade, ça me rajoute une marge de environ 1em pour chaque niveau. Je suppose que je pourrais l'enlever complètement, mais cela implique ajouter encore des styles.
Et donc finalement l'opération d'inclusion devient très compliquée ... et tout l'interêt disparaît (car si on veut modifier quelques petites choses, il faudrait modifier tout les fichiers).
Ce serait bien une balise <include>, non ?
[^] # Re: Plus que sceptique
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Bah une première différence avec les iframes, c'est qu'elles ne font pas de mode dégradé comme je l'explique ci-dessus. Du moins tout les sites avec des frames que j'ai pu voir affiche "votre navigateur ne gère pas les frames, allez vous faire poutrer par un ours", quand on a pas de gestion des frames. Avec la balise object utilisé comme dis ci-dessus, le contenu principale de la page est affiché, et les contenus qui ne peuvent être inclus par manque de fonctionnalité du navigateur sont toujours accessibles en suivant un lien.
Je ne comprends pas bien ce que tu essais de me dire par le "intégration au flot de la page" :\
- Bah la dimension du cadre est spécifie en css (dans mes pages d'exemple c'est du css incrusté avec l'attribut style, mais le mettre dans un css à part reviendrais au même), donc je ne comprends pas où est ton problème à ce niveau là.
- dans ton css racine tu mets "object .menu {padding:0px;margin0px;}", en imagineant que tu utilises , ça te paraît si lourd que ça comme style à ajouter? Éventuellement tu peux utiliser un id="menu" si tu comptes n'avoir qu'un menu par page.
Bah ça prend moins de temps à faire que de te poster cette réponse, par exemple. :)
Je crois que je n'ai pas saisie ce que tu entendais pas ton "flot de la page", et donc je ne comprends pas l'intérêt supplémentaire que peu représenter une balise . Si tu pouvais me donner un exemple d'une application tel que tu la voudrais, ça m'aiderais sans doute à mieux saisir cet intérêt. :)
[^] # Re: Plus que sceptique
Posté par Moonz . Évalué à 2.
Comment peux tu manipuler l'arbre DOM du menu depuis la page ?
Comment fais tu si tu veux que les règles de style de ta page s'appliquent à ton menu ? (hors d'inclure le même fichier CSS à la fois dans le menu et dans la page)
Comment fais tu pour un menu dont la taille change dynamiquement (cas des menus "déroulants") ?
La balise object, ce n'est qu'une grosse boite. Ça peut suffire pour des choses basiques, mais c'est franchement limité par rapport au modèle d'une forêt de boites qui prévaut en XHTML/CSS.
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 1.
Tu ne peux pas t'amuser par exemple a inclure un fichier (pense aux #include du C) qui afficherait par exemple un titre en haut, un menu à droite et un bas de page (positionnés avec CSS position: absolute) dans un même fichier. Si tu veux le faire, tu dois include un fichier pour le titre, un autre pour le menu et un dernier pour le bas de page. Et encore, cela ne peux marcher que si ces 3 éléments ont la forme rectangulaire de la boîte <object>
De plus j'ai a rajouter que les iframes gèrent le mode dégradé aussi bien que la balise <object> ... De la même manière. Le texte est à mettre entre <iframe> et </iframe>
[^] # Re: Plus que sceptique
Posté par Folken Laëneck . Évalué à 1.
C'est pas vraiment ce qu'on peut appeler une balise HTML, au contraire, mais ca a l'air plutot sympa.
Je n'ai pas testé, c'est un collègue qui vient de me faire suivre ca ...
[^] # Re: Plus que sceptique
Posté par Boa Treize (site web personnel) . Évalué à 2.
Sauf que les seuls gens qui vont faire du XML avec du HTML 5 sont ceux qui seront intéressés par la création de pages XML valides. Les autres vont se contenter de faire du HTML 5, plus digeste (et mieux validé qu'avant).
faudra m'expliquer comment, en CSS, je centre un tableau sans mettre de balise div autour et sans centrer tout mon texte. Idem pour l'attribut valign
Euh sans tester comme ça là, par réflexe : si tu mets des marges auto à droite et à gauche (resp. en haut et en bas), ça ne centre pas ta table au sein de son élément père ?
[^] # Re: Plus que sceptique
Posté par rewind (Mastodon) . Évalué à 3.
C'est ça que je ne comprends pas. Avoir voulu oublier la syntaxe SGML est probablement une très bonne décision. Et si j'ai bien compris, maintenant, il y a des règles de parsing défini dans la norme. Mais pourquoi ne pas avoir dit alors : le parsing se fera selon la norme XML ?
Non, là on a un truc bâtard entre la soupe de balise et le XML, genre "vous pouvez faire de la soupe de balise mais il faut quand même certaines règles", et pourquoi pas les règles XML ? elles sont si contraignantes que ça ? moi je ne crois pas, elles sont surtout très logique ! Allez dire à des gens : "bon des fois vous pouvez fermer vos balises mais c'est pas obligé et des fois vous devez le faire absolument sinon, ça foire", ils vont vous prendre pour un fou. Alors que dans le cas de XML : fermez vos balise, point, pas de discussion.
Enfin voilà, il faut m'expliquer l'intérêt d'une soupe de balise "mieux validée" mais pas XML.
[^] # Re: Plus que sceptique
Posté par Boa Treize (site web personnel) . Évalué à 3.
Rien qu'avec l'intégration de code en provenance de régies publicitaires, on casse tout en général... Alors qu'un petit peu de souplesse du coté du parser peut résoudre beaucoup de situations « humainement » évidentes.
Et puis la plupart des gens ne sont pas des logiciens perfectionnistes. ;-)
Pour moi, il y a une place valable pour les deux.
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 2.
Si on regarde comment les pages sont faites en PHP, le XML est trop contraignant. A une époque (et c'est peut être encore le cas) PHP ajoutait automatiquement des identifiants de sessions à tous les liens, en ajoutant un caractère '&' dans les liens. Sauf que ce caractère est interdit en XML et gecko affichait une jolie erreur d'un vert fluo très joli.
Et en plus comme moi j'avais un cookie de session, php ne modifiait pas les liens pour moi, et je n'avais pas l'erreur (mais les autres l'avaient toujours :( ).
Cela demande une rigeur de programmation qui est bien souvent absente. (Utilisez-vous htmlspecialchars() a chaque fois que vous voulez afficher un texte sur une page avec php ?)
Je pense que XML a très bien sa place, mais ne doit pas être généré comme le HTML l'(est actuellement. je considère que la meilleure façon de le générer est soit en passant par XSLT, soit par d'autres outils spécialisés dans le XML. mais pas en collant des bouts de droite et de gauche. Sinon, fatalement, on aura des erreurs quelque part.
le problème c'est que les solutions comme XSLT sont très lourdes a mettre en place, donc peu utilisées.
[^] # Re: Plus que sceptique
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Idem en HTML. Le & est un caractère réservé qui introduit une entité. Donc que ce soit en HTML ou XML, il faut utiliser & si on veut utiliser le caractère &.
Le fait que les navigateurs tolèrent l'utilisation du & tout seul n'est que pour être tolérant face aux développeurs indélicats...
[^] # Re: Plus que sceptique
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Plus que sceptique
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Ouai, mais seulement ce genre de truc est un cauchemar à styler. Comment styler les titres de deuxième niveau par exemple, et uniquement de deuxième niveau ?
Et ce n'est pas un cauchemar seulement pour les développeurs web, mais aussi pour les implémenteurs des moteurs de rendu, d'après ce que j'avais lu. Cela apporte des problèmes mais je ne me rappel plus quoi.
http://www.w3.org/TR/2008/WD-html5-20080122/#dl
Le d veut dire description. Pour les dialogs, tu as maintenant une balise dialog. Pour les définitions, une balise dfn. Bref, je vois pas ce qu'il y a de schizophrène là dedans. C'est dans HTML4 que dl était schizo.
Je ne te comprend pas. Tu te plains que soit-disant on perd les avançées sémantiques de XHTML2, alors que ces balises justement, avec dialog et dfn par exemple que j'évoquais juste au dessus, apporte de la sémantique.
Bon sinon pour ton information, progress et meter peuvent être utilisé dans une interface d'application web. Et ça pourra être utile pour les applis qui prennent en charge le mode offline. Genre le mode online est de nouveau actif, l'appli va alors sauvegarder les infos modifiées pendant le offline, et donc pourra afficher simplement un progress pour indiquer à l'utilisateur qu'il est en cours de sauvegarde... (par exemple)
bah margin:auto sur la table...
Enfin bref. Il ne faut pas oublier que ce n'est qu'un brouillon. Des choses vont certainement disparaitre, ou réapparaitre, ou être modifié.
[^] # Re: Plus que sceptique
Posté par rewind (Mastodon) . Évalué à 2.
2) ce n'était pas dt et dl mais dt et dd. dl garde son sens (= Definition List). Mais dt et dd prennent des sens différents : respectivement Definition Term et Definition Description pour dl et Speaker et Quote pour dialog [1]. D'où la schizophrénie.
3) je ne critique pas les balises sémantiques, loin de là, je critique le trop de balises sémantiques. ma question est : va-t-on créer une balise sémantique pour chaque truc que l'on veut ajouter ? si oui, ça va donner DocBook, si non on peut très bien essayer de trouver des balises suffisamment généraliste pour faire plusieurs choses mais suffisamment précises pour ne pas couvrir la moitié du monde.
Et puis juste comme ça en passant, les "applications web", si ça ressemble à ce qu'on a en ce moment en pire, je préfère encore ma vraie application.
4) merci du tuyau, je vais essayer dès ce soir
[1] http://www.w3.org/TR/html5/#the-dialog
[^] # Re: Plus que sceptique
Posté par Moonz . Évalué à 2.
body > section > h {
...
}
Non ? (en tout cas, je trouve ça joli ;))
[^] # Re: Plus que sceptique
Posté par psychoslave__ (site web personnel) . Évalué à 1.
body section h,
body section h section h
{
...
}
Les virgules elles séparent les éléments auquels doit s'appliquer le style.
[^] # Re: Plus que sceptique
Posté par Moonz . Évalué à 3.
[h]Premier niveau, ne s'applique pas[/h]
[section]
[h]Second niveau, s'applique[/h]
[section]
[h]Troisième niveau, s'applique[/h]
[section]
[h]Quatrième niveau, s'applique[/h]
...
Soit dit en passant, ton "body" est inutile (tout section est un descendant de body). Le mien sert justement à déterminer le "section" de premier niveau.
(en xpath, mon expression serait //body/section/h, tandis que la tienne est //body//section//h,//body//section//h//section//h, qui ne répond absolument pas au problème...)
[^] # Re: Plus que sceptique
Posté par _p4_ . Évalué à 3.
Apparement la tendance est à revenir à ce qui a fait le succès de html: ca marche même si c'est écrit hyper porc.
[^] # Re: Plus que sceptique
Posté par Bruce Le Nain (site web personnel) . Évalué à 1.
http://blog.whatwg.org/2007/08
"- Est-il vrai que HTML 5 permettra l’utilisation de <font> ?
- Non, les développeurs ne pourront pas utiliser <font>. Cependant, les éditeurs WYSIWYG seront autorisés à émettre des balises <font>. Ils devront s’identifier avec une balise <meta>. Cette problématique a reçu beaucoup de feedback et pourrait être modifiée."
[^] # Re: Plus que sceptique
Posté par Antoine . Évalué à 2.
[^] # Re: Plus que sceptique
Posté par Mildred (site web personnel) . Évalué à 1.
De toute façon si tu développes à la main, c'est beaucoup plus simple d'utiliser CSS. Je ne vois pas pourquoi quelqu'un chercherait a utiliser <font> (sauf si il n'a pas encore réussi a se débarasser de ses mauvaises habitudes)
[^] # Re: Plus que sceptique
Posté par psychoslave__ (site web personnel) . Évalué à 2.
<!--Generation avec un éditeur WYCIWYG (What You Code Is What You Get) -->
...
<font ... >
Hahaha, parceque je suis méchant!
<!-- Finalement je ne mettrais pas de , parceque je suis super méchant -->
...
[^] # Re: Plus que sceptique
Posté par Epy . Évalué à 2.
entendu cette semaine justement quand je lui ai parlé du futur (éventuel) IE8.
Il code avec la suite A daube pour profiter des fonctionnalités (intégration des autres cochonneries, vidéo et compagnie) mais utilise surtout le code source à la mano .. sans CSS ..
Pas réussi à lui faire entendre raison, ils étaient deux à considérer qu'il fallait toujours coder POUR IE puisqu'il était majoritaire et qu'il le resterai toujours .. >_<
[^] # Re: Plus que sceptique
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
[^] # Re: Plus que sceptique
Posté par Epy . Évalué à 2.
"La masse saute de la falaise (forcée pour la plupart), alors JE saute de la falaise de mon plein gré (et j'aide les autres)"
[^] # Re: Plus que sceptique
Posté par Folken Laëneck . Évalué à 3.
Plus sérieusement, oui IE a encore la part belle sur le marché des navigateurs web, pour la simple et bonne raison que les gens ne connaissent pas autre chose.
Mais d'une part les particuliers s'éduquent petit à petit - merci les enfants qui ramènent les bonnes idées aux parents - et d'autre part, je suis peut-être utopiste - non, pour être franc, je suis utopiste. Utopessimiste même - mais j'attend beaucoup du procès lancé par Opera contre Microsoft pour abus de position dominante concernant l'intégration par défaut d'IE dans la fenêtre. Bien que le verdict ne sera surement pas rendu avant plusieurs années, comme d'habitude, et que son application prendra elle aussi du temps.
Toujours est-il que les mentalités évoluent et les logiciels aussi. Imaginez donc, il paraitrait qu'IE8 passe le test Acid2 ! Qui aurait cru que ca arriverait avant 2025 ? ...
Donc "coder pour IE", c'était "bien" il y a quelques années, aujourd'hui je pense que c'est une con****e.
Personnellement, je préfère de loin faire des sites valides, qui seront lus conformément aux spécifications par les navigateurs qui en sont capables, et jouer ensuite des coudes pour faire en sorte d'obtenir une dégradation élégante sous les navigateurs pourraves.
Et ca tombe bien, pour une fois M$ a à peu près pensé la chose puisqu'il existe les commentaires conditionnels, qui permettent d'éviter les hacks CSS douteux et d'adapter les styles mais aussi les scripts aux différentes versions d'IE. Histoire de leur faire comprendre ce qui leur passerait au dessus de la tête.
A première vu, on peut se dire que ça fait beaucoup de travail en plus, mais je suis régulièrement étonné du faible nombre de ligne de mes feuilles de styles spéciales IE à partir du moment où le design de base a été un minimum réfléchi et où les styles ont été fait à peu près intelligemment.
Au final, on assure une partie de l'avenir en utilisant des standards d'ores et déjà pérennisés et on s'économise du travail... M'enfin s'il y en a qui aime se faire mal ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.