Le W3C met en route le premier brouillon de HTML 5

Posté par . Modéré par Florent Zara.
Tags :
0
23
jan.
2008
Internet
Le W3C annonce la prochaine norme du web : le HTML 5. Il s'agit d'une première ébauche publique, sorte de version bêta, à laquelle tout le monde est invité à contribuer et commenter. Cette norme sera axée sur les contenus (audio et vidéo) et les applications web pour les utilisateurs. À l'origine initiative d'Apple, Mozilla et Opera, le travail sur HTML 5 a reçu les contributions de centaines de participants dont ACCESS, AOL, Google, IBM, Microsoft et Nokia, entre autre.

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

  • # Une syntaxe non xml

    Posté par (page perso) . Évalué à 1.

    Je trouve dommage l'abandon d'une syntaxe de type xml obligatoire.

    <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 (page perso) . Évalué à 6.

      Ça ne l'interdit pas non plus :)
    • [^] # Re: Une syntaxe non xml

      Posté par . Évalué à 6.

      Je ne comprendre pas non plus, la syntaxe xml était une avancée pour tout ce qui concerne la génération automatique et la transformation de documents. Je ne vois absoluement pas ce qui gênait dans xhtml. Pour moi xhtml 1.0 était le successeur d'html 4 et la prochaine version devait un successeur de xhtml tout en gardant l'avantage obtenu par le passage a xml...

      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 . Évalué à 5.

      HTML 5 n'est pas le successeur de XHTML 1 mais de HTML 4, qui n'était pas un dialecte XML... Pas d'abandon donc, puisque HTML n'a jamais eu de syntaxe XML..

      Par contre, un nouveau XHTML qui prendrait les bonnes idées de HTML 5 serait le bienvenu...
      • [^] # Re: Une syntaxe non xml

        Posté par (page perso) . Évalué à 6.

        > un nouveau XHTML qui prendrait les bonnes idées de HTML 5 serait le bienvenu...


        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 (page perso) . Évalué à 3.

          Petite corrections pédantes :

          - 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 (page perso) . Évalué à 1.

      C'est un horrible retour en arrière:
      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 (page perso) . Évalué à 2.

        avec du xhtml, on pouvait faire un script avec n'importe quel langage fournissant un parser XML pour scanner une page

        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 (page perso) . Évalué à 1.

          Il y a des sites XHTML valides. Ce n'est pas compliqué à faire, il suffit de travailler proprement. Que ce soit http://chateausaintjean.com/ ou ma page perso, je m'applique et je ne suis pas le seul : http://www.lzi.ch/validation/ en trouve d'autres !
          • [^] # Re: Une syntaxe non xml

            Posté par (page perso) . Évalué à 1.

            D'après ton deuxième lien, 95 % des sites* ne sont pas valides, et encore on ne parle que de validité HTML !

            (* sur environ 2500 sites surveillés par ce site)
          • [^] # Re: Une syntaxe non xml

            Posté par . Évalué à 1.

            Non, ce site n'est pas un site XHTML valide ! Le contenu de la page l'est (ou tout du moins la première page, je ne suis pas allé plus loin), mais elle est diffusée comme du HTML. Mon Firebug me dit "Content-Type text/html"...

            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".
  • # XForms

    Posté par . Évalué à 1.

    Est-ce que l'on peut prédire la mort prochaine des XForms?
    • [^] # Re: XForms

      Posté par (page perso) . Évalué à 5.

      Bien que les formulaires dans HTML5 soient grandement amélioré (voir une présentation ici http://ljouanneau.com/blog/2006/08/30/587-web-forms-2 ), XForms reste, et de loin, bien plus riche (et plus complexe aussi, mais bon..), offrant plus de possibilité.

      XForms est beaucoup utilisé en dehors du web, ou coté serveur.
      • [^] # Re: XForms

        Posté par . Évalué à 2.

        Je suis totalement d'accord avec toi, mais dans la dépêche, on suppose l'abandon pur et simple de XHTML 2.0.

        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 (page perso) . Évalué à 2.

          Tu ne confonds pas XHTML 2 et XForms ?? Je ne vois pas le rapport entre les deux... C'est pas parce que XHTML 2 est abandonné que Xforms va l'être. Ou alors y a des raisons que je ne connais pas ?
          • [^] # Re: XForms

            Posté par . Évalué à 2.

            J'ai peut être raté un épisode, mais j'associe principalement la complexité du XHTML à la complexité des XForms. Or on nous dit que c'est justement à cause de la complexité du XHTML 2.0 qu'on tend vers son abandon...

            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 . Évalué à 9.

    concernant les balises <audio> et <video> et le refus de ces clochards de le supporter ?
  • # Eternité ?

    Posté par (page perso) . Évalué à 9.

    On parle d'une éternité en informatique, mais elle n'est pas prête d'être finie : pour que ce HTML 5 soit utilisé, il faut déjà :

    -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 (page perso) . Évalué à 3.

      C'est pas demain la veille que TOUTE la specification soit implémenté, mais les éditeurs de navigateurs l'implémente au fur et à mesure :

      - 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 . Évalué à 4.

        Justement, avec un doctype HTML5, IE8 passera en mode de rendu "super standard" sans ajout de meta, puisqu'il n'y a pas d'existant. Ouf ?

        http://ejohn.org/blog/html5-doctype/
      • [^] # Re: Eternité ?

        Posté par (page perso) . Évalué à 5.

        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.


        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 (page perso) . Évalué à 1.

          quand c'est pas du 5.5 sur du 2000...

          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 (page perso) . Évalué à 1.

          Tiens d'ailleur à ce propos, la team IE vient d'annoncer un chamboulement pour IE8 : va enfin y avoir un mode respectueux des standards. Le mode proposé par IE7 (à savoir améliorer le support des standards mais en cassant la compatibilité avec certains sites) n'ayant pas convaincu, il change de stratégie : l'ajout d'une balise meta particulière permettra au navigateur de passer dans un mode visant à respecter au mieux les standards du W3C. Bref, une bonne nouvelle.
          • [^] # Re: Eternité ?

            Posté par . Évalué à 5.

            On a déjà lu ça. http://ljouanneau.com/blog/2008/01/23/748-ie8-cassera-encore(...)

            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 (page perso) . Évalué à 1.

              Naïf de quoi ?
              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 (page perso) . Évalué à 3.

              je viens de lire le lien que tu pointes, c'est de la mauvaise foi total
              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 (page perso) . Évalué à 9.

                c'est surtout qu'en ne forçant pas à utiliser ce nouveau mode les sites pourris dégeux vont continuer.
                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 (page perso) . Évalué à 2.

                  pourquoi ne pas utiliser le doctype plutôt que meta ? ça résoudrait la plupart des problèmes non ?
                  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 (page perso) . Évalué à 10.

                    Bref tout le monde est content.

                    C'est zarb, c'est pas trop ce que j'avais ressenti...

                    C'était la solution choisie dans IE7, manque de bol les développeurs mettent leurs DOCTYPE n'importe comment[...]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

                    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 (page perso) . Évalué à 1.

                      Ben vi, c'est vrai au lieu de forcer les dev à faire correctement on rajoute encore une couche... pitoyable !
                      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 (page perso) . Évalué à 4.

                        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 ?

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

                        C'est quoi cette argumentation de merde

                        Etrange, il me semblait que tu avais écris :
                        C'était la solution choisie dans IE7, manque de bol les développeurs mettent leurs DOCTYPE n'importe comment


                        Quand tu comprendras que forcer les développeurs à migrer tous leurs sites existant

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

                        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)

                        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 !

                        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.

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

                        Pourquoi tu ne les critiques pas de la même manière ?

                        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 . É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 . Évalué à 4.

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

                        Ç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 (page perso) . Évalué à 1.

                          Mais je suis bien d'accord, IE est une merde et n'aurait jamais du "tolérer" ce genre de page web, mais le fait est que beaucoup de sites sont comme ca à l'heure actuelle. Et MS ne peut pas se permettre de casser la compatibilité comme ca pif paf poum de manière arbitraire.
                          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 . Évalué à 3.

                            Grrr, un mauvais C-z a dû traîner, une parenthèse de mon message a sauté:
                            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 . Évalué à 2.

                  Mais bon, comme d'hab, ms a systématiquement peur d'aller en avant, d'oser casser un peu la compatibilité.

                  Et Firefox, ils ont cassé la compatibilité avec les sites pourris peut-être ?
                  • [^] # Re: Eternité ?

                    Posté par (page perso) . Évalué à 2.

                    il y a là une énorme différence :
                    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 . Évalué à 1.

                      Donc que firefox lise mal des sites pourris (ce qui est le cas) c'est une chose

                      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 . Évalué à 3.

                        Sur le fond, la situation n'est pas vraiment la même:
                        - 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 . Évalué à 2.

      > -qu'il soit fini (c'est un brouillon !)

      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 (page perso) . Évalué à 4.

    API pour dessiner des graphiques en deux dimensions

    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 (page perso) . Évalué à 4.

      Fais des recherches sur l'élément <canvas> :-)

      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 . Évalué à 5.

        (Et Adobe doit faire un peu la gueule, même si Flash a de beaux jours devant lui.)
        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 (page perso) . Évalué à 1.

          J'aurais aussi dû dire que c'est l'élément le plus ambitieux de la norme. :-)

          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 (page perso) . Évalué à 3.

          Le support de la balise < canvas > est déjà effectif dans Safari, Opera et Firefox soient les meilleurs concurrents d'IE.

          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 . É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 . Évalué à 0.

              C'est juste un chiffre à mettre ( de tête ) pour dire le niveau de transparence.
            • [^] # Re: API pour dessiner des graphiques en deux dimensions

              Posté par (page perso) . Évalué à 1.

              A mon avis <canevas> permettra justement un allègement de ce qu'on peut voir actuellement. Car il propose (je suppose, je n'ai pas regardé de près) des primitives intéressantes codées en C pour faire plein de choses graphiques.

              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 (page perso) . Évalué à 2.

                tout à fait, d'autant plus que, de base, il y a un "context 2D", donc des primitives pour faire de la 3D. Mais il y a par exemple en expérimental dans firefox un "context 3D", donc des primitives permettant de faire de la 3D dans Canvas.

                (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 (page perso) . Évalué à 1.

              Oui, il y a (ou aura) des VM dans les navigateurs pour gérer le Javascript mais justement "canvas" est manipulable via du javascript donc c'est une VM de moins.

              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 (page perso) . Évalué à 2.

            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.

            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 (page perso) . Évalué à 2.

            Tiens, voilà un exemple de <canvas> très rigolo et qui donne envie d'en avoir plus :

            http://blobsallad.se/

            Interaction : souris et touches G, H, J

            Pur HTML + JavaScript :-)
  • # Perplexe ...

    Posté par (page perso) . Évalué à 6.

    Je suis perplexe quant à l'HTML 5. Il définit de nouveaux éléments HTML qui, en soit, à l'époque du multimédia, semblent pertinentes : canvas, video, audio, etc. Par contre, à côté, sont définis tout un tas de tags qui, à mes yeux, enrichi trop le HTML à s'y perdre ! Ainsi, j'ai peur que la force du HTML, sa simplicité et son jeu réduit mais souple d'élements qui ont fait, en partie, son succès, s'affaiblisse.

    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 . Évalué à 6.

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

      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 (page perso) . Évalué à 6.

        Une chose importante à ne pas perdre de vue, c'est d'une part que la syntaxe XML est maintenue, d'autre part que le SGML est abandonné !

        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 . Évalué à 8.

    Tout cela est bien intéressant, mais à terme, un navigateur est-il condamné à devenir une usine à gaz ?
    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 (page perso) . Évalué à 10.

      Pour moi un navigateur EST une usine à gaz. Ce logiciel s'est transformé en truc à tout faire, on l'utilise pour naviguer sur le Web, faire ses courses, écrire ses messages, regarder des vidéos, écouter de la musique...

      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 (page perso) . Évalué à 4.

        le web ressemble à un conglomérat de trucs moches scotchés

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

        >f]BBind'
        f~34u1
        q1"l
        (&20."'e)(q0-32"'n)"n
        q0-arfCR'"#oBarf''
        :i7q7u2'
        "#q3u7q1"n0,q1-1:g3u7'
        z,fq7:g7u2'
        q0-4-fq7"eq4u30u1''
        q0-32"e
        fq2"eq1"n
        0,0a-32"eoBarf'
        32iq8"n@ft %.4'oRead''


        (oui oui c'est bien le code source... http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/01/e(...) )
  • # Et la sémantique dans tout ça ?

    Posté par (page perso) . Évalué à 3.

    Je suis assez partagé, d'une part il y a quelques ajouts qui vont permettre de renforcer le fait qu'une page HTML devrait ne contenir que le contenu "sémantique" et le CSS devrait s'occuper que de la forme et de l'adaptation au média d'affichage, par exemple :
    * 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 (page perso) . Évalué à 2.

      Oui bien sûr, et la norme renforce cet aspect. Mais il faut rester pragmatique : tu voudrais d'un web sans vidéo et sans canvas ?

      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 (page perso) . Évalué à 2.


        Mais il faut rester pragmatique : tu voudrais d'un web sans vidéo et sans canvas ?


        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.


        Qu'est-ce qu'un moteur web fait du contenu Flash, actuellement ?

        Bah il n'existe pas. :)
        J'ai pas de lecteur flash sur mon ordi, donc je m'en fou.


        Comment afficher une vidéo sur un écran de 3x3 cm, actuellement ?

        Bah en lançant le lecteur vidéo adapté avec la vidéo en question?


        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.

        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 (page perso) . Évalué à 1.

          Si, la balise object est faite pour ça ... Et c'est le chemin pris par xhtml2.

          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 (page perso) . Évalué à 4.

      >qu'est qu'un moteur de recherche peut faire du contenu de canvas ?

      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 . Évalué à 2.

    Nan parce que c'est bien beau de changer les plans XHTML2/HTML5, de virer ou remettre des trucs.
    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 (page perso) . Évalué à 2.

      Je ne vois pas comment ton site, étant bien compatible HTML 4 Strict ou XHTML 1 Strict (n'est-ce pas ?), ne pourrait pas très rapidement (voire immédiatement) devenir bien compatible HTML 5 (ou sa variante XML).
      • [^] # Re: Et donc on le fait comment son site web?

        Posté par . Évalué à 2.


        Je ne vois pas comment ton site, étant bien compatible HTML 4 Strict ou XHTML 1 Strict (n'est-ce pas ?), ne pourrait pas très rapidement (voire immédiatement) devenir bien compatible HTML 5 (ou sa variante XML).


        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 (page perso) . Évalué à 1.

          À propos j'ai visité ton site il est pas mal mais il ne valide pas (mais bon il y a peu d'erreurs).

          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 (page perso) . Évalué à 1.

      Ne t'inquiète pas pour mathml moi même je l'utilise et je ne suis pas prêt de changer d'avis.

      - 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 (page perso) . Évalué à 2.

        Et dans Firefox 3, d'après ce que je vois dans les logs de commits, ils sont en train de corriger des bugs dans le support de MATHML. (bon maintenant n'ayant pas fait de Mathml, je peux pas te dire si ce sont des corrections de bugs importants ou non).
  • # Plus que sceptique

    Posté par . Évalué à 10.

    J'étais très enthousiaste la première fois où j'ai vu XHTML2, je me disais qu'enfin, on avait pris la bonne direction, en abandonnant plein de boulets de HTML : obligation de la syntaxe XML, uniquement des balises sémantiques, etc. Bref, ce qu'aurait du être HTML dès le départ. Et XHTML1 représentait une très bonne transition entre les deux, à mon sens, en conservant encore pour quelques temps des balises qui n'avait plus lieu d'exister.

    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 . Évalué à 7.

      J'avais juste oublié une petite chose que j'aurais aimé voir aussi en HTML5 : c'est l'inclusion de document externe.

      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 (page perso) . Évalué à 2.

        C'est un vrai manque.

        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 (page perso) . Évalué à 2.

          a quoi servent les wiki actuels

          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 (page perso) . Évalué à 1.

            On est dans le même cas qu'une page statique avec un formulaire renvoyant sur un script CGI.

            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 (page perso) . Évalué à 1.

        Sinon à la place de XInclude, peut-être qu'un truc du genre :

        <?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 (page perso) . Évalué à 2.

        La balise object dois pouvoir faire ça il me semble.
        • [^] # Re: Plus que sceptique

          Posté par (page perso) . Évalué à 3.

          Et ça fait un joli cadre de taille fixe avec des assenceurs pour présenter le contenu... ça ne rentre pas dans le flot de la page.
          • [^] # Re: Plus que sceptique

            Posté par (page perso) . Évalué à 3.

            http://psychoslave.free.fr/test/

            Ç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 (page perso) . Évalué à 1.

              Et est-ce que les liens du menu vont juste ouvrir une nouvelle page dans le cadre du menu ou dans la fenêtre entière ? De toute façon, comme je ne pense pas que ce soit standardisé (la manière de suivre les liens avec la balist object) ce n'est pas vraiment utilisable.
              • [^] # Re: Plus que sceptique

                Posté par (page perso) . Évalué à 3.

                Par défaut le lien s'ouvre dans le cadre courant, donc à l'intérieur de la balise object. Cependant il suffit d'ajouter un target="_top" à ton ancre et le tour est joué, ce qui est normalisé. Je t'ai mis à jour mon exemple pour montrer les différents comportements possibles pour un lien en fonction de la cible (target) définie.

                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 . Évalué à 2.

                  Merci pour cette démonstration.

                  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 (page perso) . Évalué à 2.

                    * En quoi trouves-tu que je détournes une balise?
                    * 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 (page perso) . Évalué à 1.

                  Enfin, ce n'est pas un vrai include ...
                  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 (page perso) . Évalué à 2.


                    Enfin, ce n'est pas un vrai include ...
                    C'est comme une iframe (pas de différence a ce que je peux voir) ...

                    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.


                    Donc c'est un objet et cela ne s'intègre pas bien au flot de la page.

                    Je ne comprends pas bien ce que tu essais de me dire par le "intégration au flot de la page" :\


                    J'aimerais bien pouvoir faire pareil avec les menus, mais avec la balise , 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.

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


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

                    Bah ça prend moins de temps à faire que de te poster cette réponse, par exemple. :)


                    Ce serait bien une balise , non ?

                    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 . Évalué à 2.

                      > Je crois que je n'ai pas saisie ce que tu entendais pas ton "flot de la page",
                      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 (page perso) . Évalué à 1.

                        Parfaitement ...
                        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 . Évalué à 1.

                          Et pourquoi pas utiliser ce qu'Apache met à disposition ?

                          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 (page perso) . Évalué à 2.

      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.

      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 . Évalué à 3.

        > Les autres vont se contenter de faire du HTML 5, plus digeste (et mieux validé qu'avant).

        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 (page perso) . Évalué à 3.

          Le XML est très strict, probablement trop strict pour la plupart des sites.

          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 (page perso) . Évalué à 2.

          Oui, le XML est très contraignant.

          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 (page perso) . Évalué à 3.

            >Sauf que ce caractère est interdit en XML

            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 (page perso) . Évalué à 5.

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


      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.

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


      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.

      la floppée de nouvelles balises inutile dans 99% des cas progress, meter, etc..


      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)

      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


      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 . Évalué à 2.

        1) je ne dis pas que la balise h est la panacée mais pour des gens qui ne veulent pas mettre des styles différents, c'est quand même utile et ça n'empêche pas d'utiliser h* pour des cas plus complexes.

        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 . Évalué à 2.

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


        body > section > h {
        ...
        }

        Non ? (en tout cas, je trouve ça joli ;))
        • [^] # Re: Plus que sceptique

          Posté par (page perso) . Évalué à 1.

          Tu enlèves les ">", et c'est ça.

          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 . Évalué à 3.

            Non, les ">" dont là pour dire "fils direct". En les enlevant, le style s'appliquera au h de niveau deux ou supérieur:
            [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 . Évalué à 3.

      Noooooon pas la balise font! Tout mais pas ca! b, i tu dis? Rhaa comme au bon vieux temps! Je sens le retour en force du code bien gruik...

      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 (page perso) . Évalué à 1.

        Oulah, vous vous emballez un peu vite :)

        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 . Évalué à 2.

          Donc il suffit de se faire passer pour un éditeur WYSIWYG en ajoutant une balise <meta> ;)
          • [^] # Re: Plus que sceptique

            Posté par (page perso) . Évalué à 1.

            Même pas ... comme le mode HTML est tolérant aux erreurs, je suppose que la balise <font> sera comprise dans tous les cas :(

            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 (page perso) . É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 (page perso) . Évalué à 2.

              Ca existe pourtant toujours, la raison est: "Parce qu'IE est le navigateur majoritaire, donc je code POUR IE et je fais quelques modifs pour que ça passe avec Firefox"
              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 (page perso) . Évalué à 5.

                ouai enfin, tu peux aussi leur dire que leur IE majoritaire baisse en europe, et que négliger les presque 30% de part de marché de Firefox en europe, c'est à dire ignorer presque un tiers des internautes, c'est complètement con. (source des chiffres : xitimonitor)
                • [^] # Re: Plus que sceptique

                  Posté par (page perso) . Évalué à 2.

                  J'ai essayé, mais je crois que le coté "mouton de panurge" était plus fort que ces arguments.
                  "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 . Évalué à 3.

                    Oui enfin on est pas tous obligé non plus d'avoir l'instinct de survie d'un lemmings :)

                    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.