5568 sujets

Sémantique web et HTML

Un peu de HTML 5 (brouillon) pour s'amuser ?

Pages :
(reprise du message précédent)

Lanza a écrit :

Mais en fait, je pense que si <section> et <header> ont été introduits dans HTML5, c'est juste pour faire enrager Daniel Glazman. (voir le point 7 de cet article) Smiley biggol


La réponse sur le fond s'appelle peut-être mapping et possibilité de styler non les header, mais spécifiquement les niveaux résultants.
Florent V. a écrit :
Ceci dit, la structure proposée par Lanza est courante dans différents textes structurés, notamment des travaux universitaires. En général, l'agencement des contenus dans ces documents étant pensé en partie en termes visuels, on joue sur l'espace à gauche pour indiquer la profondeur dans la démonstration, ou bien à la rigueur sur des sauts de ligne.


Les travaux universitaires sont assez souvent structurellement défectueux, en effet. Je crains qu'il n'y ait un inévitable effort à faire ce côté. Personne n'a vraiment mesure l'impact le jour où on a mis un traitement de texte wysiwyg entre les mains de nos chers intellectuels, par exemple... ah, l'ivresse de l'illusion structurelle ! Smiley ravi .

<edit>ça n'est pas si grave: les plates-formes de gestion de chaînes éditoriales commencent à pointer le bout de leur nez, sur une saine base XML qui nous ramène tout droit à la gestion des <header> </>
Modifié par Laurent Denis (19 Jun 2007 - 14:09)
QuentinC a écrit :

Cette structure me paraît complètement illogique et incohérente, justement parce que ce à quoi se rattage le paragraphe problématique n'est pas clair, si on lisait le texte à haute voix en ignorant le balisage par exemple.
Avec les titres <hn>, il est impossible de faire cette confusion : le paragraphe se rapporte au dernier titre, et point final.
Je n'arrive vraiment pas à comprendre dans quelles circonstances une telle structure peut être valable. Exemple ?


Tu as probablement raison et Laurent aussi. D'ailleurs, je ne parviens pas à trouver un exemple pertinent. Smiley lol . Peut-être que la DTD et/ou le schéma interdiront cette possibilité.

QuentinC a écrit :

Aïe la peinture rouge dégouline, tu m'as effectivement enduit d'erreur... PS : ne pas confondre "induire en erreur" et "enduire d'erreur".


L'erreur était volontaire, ça m'amusait. Mais bon, il est possible (et même probable) que ça n'amuse que moi. Smiley confused
Modifié par Lanza (19 Jun 2007 - 16:08)
Lanza a écrit :

Peut-être que la DTD et/ou le schéma interdiront cette possibilité.

Oui, il faudrait une règle du genre :
après </section>, vous pouvez soit ouvrir un nouveau <section>, soit fermer un <section> de niveau supérieur.

je ne sais pas si on peut coller ce genre de condition directement dans une DTD, mais on peut facilement programmer le validator pour qu'il le fasse.


Lanza a écrit :

L'erreur était volontaire, ça m'amusait. Mais bon, il est possible (et même probable) que ça n'amuse que moi. Smiley confused

Mais non, je n'aurais pas essayé d'enfoncer le clou sinon... mais de là à penser que c'était volontaire, il y a un pas ... les erreurs de paronymes sont des erreurs courantes, mais pas autant que les fautes de frappe quand même.

Une autre question qui m'est venu à l'esprit : quand HTML5 sortira et qu'on utilisera <!doctype html> (au passage beaucoup plus simple que les obscures lignes de DTD actuelles), que se passera-t-il sur les navigateurs actuels (IE6+) ? => Passage en mode de rendu quirk ?
QuentinC a écrit :
Une autre question qui m'est venu à l'esprit : quand HTML5 sortira et qu'on utilisera <!doctype html> (au passage beaucoup plus simple que les obscures lignes de DTD actuelles), que se passera-t-il sur les navigateurs actuels (IE6+) ? => Passage en mode de rendu quirk ?

En ce qui concerne IE 5.5 et versions antérieures, la réponse se devine. Pour IE 6, c'est fort probable. Pour IE 7, il faudra voir. Bref, Microsoft a intérêt à jeter à la corbeille son modèle de boîte pour IE 8 et versions supérieures. Smiley rolleyes
QuentinC a écrit :

Oui, il faudrait une règle du genre :
après </section>, vous pouvez soit ouvrir un nouveau <section>, soit fermer un <section> de niveau supérieur.

je ne sais pas si on peut coller ce genre de condition directement dans une DTD, mais on peut facilement programmer le validator pour qu'il le fasse.


Dans une DTD je ne sais plus, il faudrait que je vérifie, mais dans un schéma XML c'est très simple.

a écrit :
Mais non, je n'aurais pas essayé d'enfoncer le clou sinon... mais de là à penser que c'était volontaire, il y a un pas ... les erreurs de paronymes sont des erreurs courantes, mais pas autant que les fautes de frappe quand même.


Je me suis laissé dire que les fautes de frappes devaient être une vraie plaie avec un lecteur d'écran. Autant visuellement ça ne choque pas trop, autant la sonorité d'un mot peut changer du tout au tout.

En ce qui concerne les paronymes (je viens d'apprendre un nouveau mot, moi), j'adore ça. Je les utilise fréquemment à l'oral, et intentionnellement parce que ça m'amuse de dire une chose tout en utilisant des mots qui n'ont pas du tout le même sens. Enfin bon...

QuentinC a écrit :

Une autre question qui m'est venu à l'esprit : quand HTML5 sortira et qu'on utilisera <!doctype html> (au passage beaucoup plus simple que les obscures lignes de DTD actuelles), que se passera-t-il sur les navigateurs actuels (IE6+) ? => Passage en mode de rendu quirk ?


J'ai l'impression que <!doctype html> est surtout un raccourci provisoire en attendant la signature définitive. Vu que la DTD n'existe pas encore, que HTML 5 n'en est même pas à l'état de Working Draft, il était difficile de mettre le DOCTYPE définitif.
Lanza a écrit :

J'ai l'impression que <!doctype html> est surtout un raccourci provisoire en attendant la signature définitive. Vu que la DTD n'existe pas encore, que HTML 5 n'en est même pas à l'état de Working Draft, il était difficile de mettre le DOCTYPE définitif.


Non, il s'agit bien d'un changement radical dans ce domaine, puisque la DTD ne définit plus le format. Le doctype n'est d'ailleurs conservé que pour le doctype switching, et uniquement en mode text/html, puisqu'application/xhtml+xml induit obligatoirement le comportement strict.
Laurent Denis a écrit :
Le doctype n'est d'ailleurs conservé que pour le doctype switching

On peut d'ailleurs préciser que la DTD light de HTML5, à savoir 
<!doctype html>
fait bien passer IE6 en mode standard.

De même pour Firefox et Opera. Sous Konqueror, je n'ai pas vu de différence entre l'affichage avec ou sans doctype, et je n'ai pas d'outil à disposition pour savoir quel mode est utilisé pour un document donné avec ce navigateur.


Edit : en passant, le <meta charset="..." /> a l'air d'être bien supporté. Comme pour le doctype, cette simplification de syntaxe a l'air d'avoir été retenue notamment à cause de son support déjà existant dans les navigateurs.
Modifié par Florent V. (19 Jun 2007 - 19:14)
Lanza a écrit :

Je me suis laissé dire que les fautes de frappes devaient être une vraie plaie avec un lecteur d'écran. Autant visuellement ça ne choque pas trop, autant la sonorité d'un mot peut changer du tout au tout.

Je dirais que ça dépend. Avec l'habitude, on comprend certains mots mal orthographiés. Pas toujours, c'est selon la faute.

Inversément il y a à mon avis certains jeux orthographiques qui passent mieux à la synthèse qu'au visuel... à vous de juger la phrase suivante :
Aveg le vroid guile vait dehors, jaws a adrabé le rhube

Lanza a écrit :

En ce qui concerne les paronymes (je viens d'apprendre un nouveau mot, moi), j'adore ça. Je les utilise fréquemment à l'oral, et intentionnellement parce que ça m'amuse de dire une chose tout en utilisant des mots qui n'ont pas du tout le même sens. Enfin bon...

J'aime bien les jeux de mots aussi ... les calembours par exemple ...

tidaddam tadam dam *JINGLE*. Après cette page de publicité, la suite de nos programmes avec un débat sur HTML5.


Florent V. a écrit :

On peut d'ailleurs préciser que la DTD light de HTML5, à savoir 
<!doctype html>
fait bien passer IE6 en mode standard.
De même pour Firefox et Opera. Sous Konqueror, je n'ai pas vu de différence entre l'affichage avec ou sans doctype, et je n'ai pas d'outil à disposition pour savoir quel mode est utilisé pour un document donné avec ce navigateur.


Ah ça, c'est bon à savoir. Autrement dit on n'aura pas besoin d'attendre la mort d'IE6 et 7 avant de concevoir son site en HTML5, puisqu'il est compatible avec HTML4 pour la quasi-totalité des éléments.
A quand un « Afin de profiter des nouvelles fonctionnalités offertes par HTML 5.0, utilisez un autre navigateur qu'Internet Explorer »

Florent V. a écrit :

Edit : en passant, le <meta charset="..." /> a l'air d'être bien supporté. Comme pour le doctype, cette simplification de syntaxe a l'air d'avoir été retenue notamment à cause de son support déjà existant dans les navigateurs.


Etonnant qu'on ait encore jamais entendu parler de celle-là avant, par contre. En tout cas je n'avais jamais vu <meta charset="..." />
J'ai peur pour xHTML 2 avec tout ça...

La rétro-compatibilité, cela peut être une qualité mais aussi un défaut..
Modifié par JyuniX (19 Jun 2007 - 21:21)
JyuniX a écrit :
J'ai peur pour xHTML 2 avec tout ça...

La rétro-compatibilité, cela peut être une qualité mais aussi un défaut..


Dans ce post c'est de HTML 5 dont il est question, ne vient pas compliquer avec xHTML 2 Smiley lol (surtout un mardi).
JyuniX a écrit :
J'ai peur pour xHTML 2 avec tout ça...


XHTML poursuit un développement parallèle, répondant à des besoins différents, et intéresse très fortement d'autres branches de l'industrie. Inutile de mélanger torchons et serviettes: on va sans doute faire un mauvais remake du scenario HTML3.2, en effet, mais pas à ce point, tout de même Smiley cligne
Modifié par Laurent Denis (19 Jun 2007 - 21:56)
En fait ce qui m'échappe surtout, c'est la raison d'être de ce HTML5, alors que depuis des années on nous explique que le html c'est nul et qu'il faut utiliser le xhtml parceque c'est compatible avec le XML et que c'est vachement mieux.
Pourquoi continuer à développer html, et pas se contenter de xhtml, qui à ma connaissance n'a aucune limitation par rapport au html classique Smiley ohwell



Enfin sinon j'ai parcouru le document, et il a l'air d'y avoir des trucs assez pratique tout de même, comme les type="datetime", month, week, url etc. pour les <input>, l'attribut autofocus.
"The menu element is redefined to be useful for actual menus." on verra ce que ça donne.
Idem pour les balises <audio> et <video> qui à terme pourront être intéressante.
Au niveau du DOM j'ai pas tout compris, mais ptet des trucs intéressants aussi.

Bref, wait'n see =)


PS : Moi aussi ça m'amuse de dire "enduire d'erreur" Smiley cligne
BlueScreenJunky a écrit :
Pourquoi continuer à développer html, et pas se contenter de xhtml, qui à ma connaissance n'a aucune limitation par rapport au html classique Smiley ohwell

Oui, d'ailleurs XHTML est tellement peu problématique que... personne ne l'utilise.

Pour être précis : il y a beaucoup de sites en XHTML 1.0, mais pour la quasi-totalité servis en "text/html", donc interprétés comme du HTML par les navigateurs. Bref, le XHTML en "text/html" c'est... du bon vieux HTML, avec deux trois conventions d'écritures plus strictes (ce qui est pédagogiquement appréciable, d'ailleurs).
Pour XHTML 2... ils vont devoir lui trouver un autre nom, s'ils sortent un XHTML 5 d'abord. Smiley biggol

a écrit :
The draft:

1. Defines a single language called HTML5 which can be written in HTML (HTML5) and XML (XHTML5).
Florent V. a écrit :
il y a beaucoup de sites en XHTML 1.0, mais pour la quasi-totalité servis en "text/html"

Oui, mais il faut préciser qu'IE y est pour beaucoup; bon nombre d'intégrateurs n'attendent qu'une chose: le support généralisé de l'application/xhtml+xml...
Benjamin D.C. a écrit :

Oui, mais il faut préciser qu'IE y est pour beaucoup; bon nombre d'intégrateurs n'attendent qu'une chose: le support généralisé de l'application/xhtml+xml...


Waouh Smiley lol

a écrit :
bon nombre d'intégrateurs n'attendent qu'une chose: le support généralisé de l'application/xhtml+xml


Pour le "bon nombre" t'as des chiffres ?

J'ai encore jamais vu de manifs d'intégrateurs réclamant "le support généralisé de l'application/xhtml+xml". Smiley lol
a écrit :

J'ai peur pour xHTML 2 avec tout ça...

Si j'ai bien compris, il va être abandonné non ? A la place il y aura XHTML 5...

En fait la question HTML ou XHTML se pose déjà aujourd'hui entre HTML 4.01 et XHTML 1.0...

EDIT : Ah non, j'ai dit une bêtise, XHTML 2 ne sera pas remplacé par le 5... mais c'est bien deux concurrents, comme le démontre cet article http://xhtml.com/fr/future/x-html-5-versus-xhtml-2/
Modifié par QuentinC (20 Jun 2007 - 07:08)
Administrateur
QuentinC a écrit :

EDIT : Ah non, j'ai dit une bêtise, XHTML 2 ne sera pas remplacé par le 5... mais c'est bien deux concurrents

Concurrence ?
Je ne l'ai pas compris ainsi. Selon moi chacun correspondra à des besoins et medias différents.
Ah bon et pourquoi ils correspondront à des besoins différents ? Aujourd'hui, il y a bien des sites en xHTML et d'autres en HTML qui sont pourtant dans le même domaine d'activité. Supposons que l'xHTML 2 est une suite de l'xHTML 1 et l'HTML 5 une suite de l'HTML 4 , jne vois donc pas pourquoi ces deux nouvelles spec ne seront pas en concurrence.
Modifié par JyuniX (20 Jun 2007 - 09:30)
JyuniX a écrit :

Supposons que l'xHTML 2 est une suite de l'xHTML 1 et l'HTML 5 une suite de l'HTML 4

Je crois que c'est un peu plus compliqué que ça en fait.

Raphaël a écrit :

Selon moi chacun correspondra à des besoins et medias différents.

Pourrais-tu développer cette affirmation ? Je ne vois pas en quoi l'un serait destiné à un média différent de l'autre, ou que l'un réponde à certains besoins auxquels l'autre ne répondrait pas.

Pour le moment ce que je vois, c'est que l'un propose des choses intéressantes, d'autres moins, que l'autre fait pareil mais dans d'autres domaines, et qu'ils se contredisent sur certains points.
L'idéal serait donc de faire un mix !

Ce que je retiens comme bons points du (X)HTML5 :
- Toutes les extensions liés aux formulaires
- La différenciation des types de média via <audio>, <video>, tout en gardant <object> pour les trucs moins courants, et la mise en place d'une API de scripting commune pour gérer les tâches en rapport avec le multimédia (lecture/arrêt, positionnement, etc.)
- La possibilité de lier un texte de légende explicitement à une image ou un contenu multimédia via <figure>
- L'élément <dialog>
- Les extensions du DOM

Ce que je retiens comme points positifs du XHTML2 :
- L'élément <di> des listes de définition
- L'abandon total et définitif de <font> et autres balises obsolètes et totalement inutiles.
- La modularité du langage du à XML, ce qui donne la possibilité d'inclure directement des documents comme des formules mathématiques
- Un type de liste spécifique à la navigation <nl>. Cependant, <menu> a le même but.
Pages :
Sujet clos
Aller à