Soho Posté 24 Janvier 2005 Partager Posté 24 Janvier 2005 (modifié) Bonjour... Me voici de retour avec mes problèmes de validation. J'ai un script Xiti intégré dans les pages de mon site. Un Hubeur (LaurentDenis, il me semble..) m'avait (comme souvent) donné la syntaxe valide pour ce script. J'intègre ce script dans mes pages : no problemo, c'est valide (voir exemple validé ici - la page d'origine) Le même script (EXACTEMENT !) sur la page index du site : pas valide !!! Vous voyez pourquoi ? Merci d'avance ! Modifié 24 Janvier 2005 par Soho Lien vers le commentaire Partager sur d’autres sites More sharing options...
petit-ourson Posté 25 Janvier 2005 Partager Posté 25 Janvier 2005 Dans un des cas la balises <noscript> se trouvent dans une balise de type bloc (block - div/p), dans l'autre cas, elle se trouve dans une balise de type enligne (inline - h5). Tu as eu une promotion sur les balises hx ? Il y a plus de titres que de paragraphes sur la page qui ne fonctionne pas Lien vers le commentaire Partager sur d’autres sites More sharing options...
Soho Posté 25 Janvier 2005 Auteur Partager Posté 25 Janvier 2005 (modifié) Tu veux dire que si je mets le script entre <div> et </div> ca devrait marcher ? Merci ! PS : les balises <h...> c'est juste du provisoire (qui dure un peu) Je ne veux pas allourdir la css avec des "styles" dont je n'ai besoin que sur la page index... Il faut juste que je prenne le temps de faire une feuille de style spécial "home page" :ca ca va venir <edit> J 'ai testé, effectivement, c'est valide... Sauf que je souhaite que le logo Xiti soit en ligne Et franchement, je trouve un peu lourd d'etre obligée de définir un <div> "juste pour ca"... surtout que je sens que (vu comme je suis douée), je vais encore mettre des heures pour trouver la solution et le positionner correctement. Quelqu'un a-t-il une idée de la façon de rendre valide le code Xiti lorsqu'il est dans un élément inline ? Et surtout quelqu'un pourait-il m'expliquer pourquoi, aux yeux du W3C, le code est valide dans une balise de type block et non valide dans une balise inline ???? </edit> Modifié 26 Janvier 2005 par Soho Lien vers le commentaire Partager sur d’autres sites More sharing options...
Soho Posté 26 Janvier 2005 Auteur Partager Posté 26 Janvier 2005 Pas d'idée ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Dan Posté 26 Janvier 2005 Partager Posté 26 Janvier 2005 Salut Soho, le </a> entre le </script> et le </noscript> me gène un peu. Pourrais-tu le déplacer à l'intérieur du <script> ? Je sais qu'il se trouve sur les 2 pages... mais il peut faire "perdre pied au validateur". L'erreur est la même sur le validateur du Web Design Group. Lien vers le commentaire Partager sur d’autres sites More sharing options...
LaurentDenis Posté 26 Janvier 2005 Partager Posté 26 Janvier 2005 Ah... Pas simple, HTML4.01, sur ce coup là. Résumons: L'élément <script> est un élément de type%inline. Pour cette raison (et d'autres, mais passons sur les détails des DTD), il peut se placer, en HTML transitional comme en strict: - directement dans l'élément <body> - dans l'élément <head> - dans un élément %bloc - dans un élément %inline L'élément <noscript>, lui, est un élément de type %block. Il ne peut donc se placer (toujours en précisant qu'il y a d'autres raisons liés à des détails des DTD), que: - directement dans l'élément <body> - dans l'élément <head> - dans un élément %bloc La question est donc: pourquoi diable <noscript> est-il un élément %block et non %inline comme <script> ? A cause de leur contenu, qui est fondamentalement différent. En effet: - un <script> ne contient aucun élément HTML, mais ... du langage de script, c'est à dire d'une certaine manière du texte brut (en fait, c'est plus compliqué, car la présence d'un balisage HTML dans un script provoque un comportement spécifique du moteur HTML... mais passons. L'idée générale que c'est du texte est suffisante ici). - un <noscript>, lui, n'est pas destiné à contenir du texte brut, mais du balisage HTML qui devra être interprété directement par le navigateur comme n'importe quel autre balisage. Et ce balisage ne peut pas être restreint à des éléments %inline : il faut que <noscript> puisse comporter des éléments %block pour permettre d'afficher des titres, des paragraphes, des tableaux, des listes, etc. La plus grande permissivité du HTML4.01 transitional permet de placer dans <noscript> aussi bien du texte brut, des éléments %inline et des éléments %block. Ce n'est plus le cas en HTML4.01 strict, où il n'admet plus que des éléments %block. Mais l'important est là: dès lors que <noscript> contient des éléments %block... il ne peut pas être placé dans un élément %inline. Logique imparable, non ? Lien vers le commentaire Partager sur d’autres sites More sharing options...
Monique Posté 26 Janvier 2005 Partager Posté 26 Janvier 2005 Bonjour, Laurent, je me doutais bien que tu allais nous éclairer la-dessus J'étais en train d'essayer de comprendre ceci sur la page HTML 4.0 Block-Level Elements du WDG The following elements may be used as either block-level elements or inline elements. If used as inline elements (e.g., within another inline element or a P), these elements should not contain any block-level elements.liste dans laquelle figure l'élément script Enfin j'en comprends le sens mais je n'en trouve pas l'explication dans les spécifications. Lien vers le commentaire Partager sur d’autres sites More sharing options...
LaurentDenis Posté 26 Janvier 2005 Partager Posté 26 Janvier 2005 (modifié) Du danger des simplifications... Ce que dit le HTML 4.0 Block-Level Elements du WDG est un beau racourci... qui crée effectivement une certaine confusion. <script> n'est pas alternativement un élément %inline et un élément %bloc. C'est un élément %inline uniquement. En effet, la DTD HTML4.01 stricte déclare: <!-- %inline; covers inline or "text-level" elements --><!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;"> Où est <script> là-dedans ? Tout simplement dans %special : <!ENTITY % special "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO"> En d'autres termes, <script> appartient à la catégorie %special, laquelle appartient elle-même à la catégorie %inline. En revanche, <script> n'est pas un élément %block : <!ENTITY % block "P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT | BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS"> ... là, pas de SCRIPT directement ou indirectement mentionné. (En revanche, on y trouve bien <noscript>) Alors... Comment fait <script> pour pouvoir se mettre directement dans <head> et dans <body>, qui n'admettent pas d'éléments enfants %inline ? Tout simplement en vertu d'un cas d'exception : <!ELEMENT BODY O O (%block;|SCRIPT)+ +(INS|DEL) -- document body --><!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements --><!ELEMENT HEAD O O (%head.content;) +(%head.misc;) -- document head --> Autrement dit, <script> bénéficie ici d'un privilège qui l'autorise à figurer dans <body> et dans <head>. En HTML4.01 transitional, il en est de même, si ce n'est que <script> peut être mis directement dans <body> puisque l'une des particularités de transitional est d'y autoriser la présence d'un élément %inline. En revanche, on trouve la même règle d'exception pour <head> On est donc dans un cas très différents de <ins> et <del> qui eux, sont explicitement des éléments alternativement %inline et %block, selon les DTD. Maintenant, le problème reste entier : un <script> étant %inline... peut-il comporter des éléments %block ? Là, le WDG simplifie maladroitement : en effet, un <script> ne contient aucun élément HTML. La question ne se pose simplement pas. En revanche, il peut générer un élément HTML %block... qui n'invalidera pas le document, mais qui n'en sera pas moins problématique. C'est une des limites du HTML. XHTML résoud le problème, par exemple en faisant en sorte que document.write ne marche pas dans un script lorsque XHTML est traité comme du XML... Dans le même ordre d'idées, <script> peut permettre de générer la balise de fermeture d'un élément ouvert hors du script. Si javascript est désactivé... l'élément n'est plus fermé Là encore, ce n'est plus possible en "vrai" XHTML. Et puis, au fond, on le sait : javascript est intrinsèquement démoniaque Modifié 26 Janvier 2005 par LaurentDenis Lien vers le commentaire Partager sur d’autres sites More sharing options...
Soho Posté 26 Janvier 2005 Auteur Partager Posté 26 Janvier 2005 Ha la la ! Je savais bien qu'en postant ici je me coucherai moins ignorante Merci à vous et en particulier à toi LaurentDenis pour les longues explications que tu as la gentillesse de prendre le temps de donner. Maintenant, c'est clair.. ca ne résoud pas le fait qu'il faille revoir tout le code de ma page mais je sais pourquoi et cela, sincérement me va notoirement mieux que de copier betement un code sans explication.. ça m'évitera de réitérer de telles erreurs (sauf si, tête delinote comme je suis je l'oublie en codant un jour... ) Et puis, au fond, on le sait : javascript est intrinsèquement démoniaque Vi vi... je sais mais bon Xiti est efficace, gratuit, et son logo n'est pas envahissant.. donc pour l'instant "let's javascripting" Je me permet une dernière question (oui, oui, j'abuse je sais, mais c'est votre faute : vous répondez trop bien !) : honnêtement combien d'années d'apprentisage faut il pour connaitre toutes ces directives ? Merci encore ! Lien vers le commentaire Partager sur d’autres sites More sharing options...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant