Blog Alsacréations

• mai 2008
• avril 2008
• mars 2008
• février 2008
• janvier 2008
• décembre 2007
• novembre 2007
• octobre 2007
• septembre 2007
• août 2007
• juillet 2007
• juin 2007
• mai 2007
• avril 2007
• mars 2007
• février 2007
• janvier 2007
• décembre 2006
• novembre 2006
• octobre 2006
• septembre 2006
• août 2006
• juillet 2006
• juin 2006
• mai 2006
• avril 2006
• mars 2006
• février 2006
• janvier 2006
• décembre 2005
• novembre 2005
• octobre 2005
• septembre 2005
• août 2005
• juillet 2005
• juin 2005
• mai 2005
• avril 2005
• mars 2005
• février 2005
• janvier 2005
• décembre 2004
• novembre 2004
• octobre 2004
• septembre 2004
• août 2004
• juillet 2004
• juin 2004
• mai 2004

Le jeudi 9 septembre 2004 à 17:55, par [ NikO ] :: site :: #

Il y a quelque chose qui m'etonne :
FIELDSET > Ne peut être parent direct que de l'élément LEGEND.

Le validateur ne bronche pas sur qq chose du genre :

<fieldset>
<label for="email">Exp&eacute;diteur :</label>
<input type="text" name="email" id="email" size="35"/>
</fieldset>

Le jeudi 9 septembre 2004 à 18:07, par Raphael Goetter :: site :: #

@Niko : humm, j'ai dû mal traduire les spec : www.w3.org/TR/REC-html40/...
L'exemple qu'ils donnent semble confirmer tes doutes.

Le jeudi 9 septembre 2004 à 18:07, par JMF :: site :: #

Raphael, tu as un petit doublon à la fin du billet.

>TEXTAREA
> Ne peut contenir que du texte simple et des entités.
> Ne peut pas être contenu dans un élément BUTTON.
>
>TEXTAREA
> Ne peut contenir que du texte simple et des entités.
> Ne peut pas être contenu dans un élément BUTTON.

Le jeudi 9 septembre 2004 à 18:09, par Raphael GOETTER :: #

EDIT : pour le fieldset, j'ai plus d'infos :

"The content of a FIELDSET element must begin with a LEGEND to provide a caption for the group of controls. Following the LEGEND, FIELDSET may contain any inline or block-level element, including another FIELDSET."

--> http://htmlhelp.com/reference/html40/forms/fieldset.html

@JMF : ok, je corrige. Merci

Le jeudi 9 septembre 2004 à 21:45, par Bobe :: #

pour l'élément pre, l'exclusion est:
IMG|OBJECT|BIG|SMALL|SUB|SUP

Et pour la table, tu as oublié <col> et <colgroup>

Le jeudi 9 septembre 2004 à 22:43, par Raphael Goetter :: site :: #

@Bobe : Merci pour ces précisions.
Pour PRE, j'ai volontairement supprimé les balises de présentation comme BIG, SMALL SUB et SUP car elles peuvent être avantageusement remplacées par les CSS de toute façon.

Le jeudi 9 septembre 2004 à 23:27, par Bobe :: #

Ok pour BIG et SMALL, par contre, SUB et SUP ne sont pas des balises de présentation.

Le vendredi 10 septembre 2004 à 00:47, par Navarro :: #

Raphael, il manque des p dans le blockquote de ton message 784 (bug de dotclear ?).

Sinon, il semblerait si j'ai bien compris ce que j'ai lu (en diagonal) dans cet article et dans la DTD HTML 4 :
developpeur.journaldunet....

que dans la DTD les signes +,-,?,*,pas de signe,... (?) permettent de savoir si un élément est obligatoire ou non et sa fréquence.
Ils sont appliqués avant (pour le -) ou après (les autres) les parenthèses ou sinon directement après les éléments entre parenthèses.

Pour : ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*)
Il n'y a pas de signes avant ou après les parenthèses donc ils doivent être dedans.
Il n'y a rien après #PCDATA et LEGEND donc ils sont obligatoire (cf lien) et * derrière (%flow;) qui correspond à 0 ou plusieurs balises bloc et en-ligne.

LEGEND est donc obligatoire mais qu'est ce qui indique qu'elle doit être en premier ?
La DTD indique-t-elle seulement une telle chose ?
Est-ce le fait que les entités soient séparées par des , et non des | qui indique un ordre ?
Vous me direz qu'il faut donc un #PCDATA en premier mais la DTD précise :
#PCDATA is to solve the mixed content problem, per specification only whitespace is allowed there!

C'est quoi le problème en question ? Un hack de DTD ?
Pour ou contre les hack de DT... à non, c'est pas ici ça...
Est ce qu'il y a un spécialiste en DTD dans le coin ?

Le vendredi 10 septembre 2004 à 05:20, par Laurent Denis :: #

Sans être un spécialiste en DTD :

Les virgules indiquent que l'ordre des éléments est significatif :l'élément <legend> doit effectivement précéder le reste du contenu du <fieldset>.

Le "mixed content problem" concerne la gestion des espaces (linebreak, tab, espace) non significatifs entre les éléments blocs, mais significatifs dans le contenu textuel et entre les éléments en ligne, pour les outils SGML. <fieldset> a justement ce type de contenu mixte, mais je n'arrive plus à mettre le doigt sur le problème exact...

Le vendredi 10 septembre 2004 à 05:32, par Laurent Denis :: #

Au fait, Raphael : il y a une erreur de syntaxe dans ton script Xiti qui provoque la disparition d'une bonne partie du contenu de la page dans Opera 7.5+
Le script génère également un balisage invalide avec un superbe border=0 et des ampersand non encodés

Le vendredi 10 septembre 2004 à 09:49, par Raphael Goetter :: site :: #

@Bobe : "SUB et SUP ne sont pas des balises de présentation" > Moi j'ai plutôt tendance à le voir comme ça. "sub" et "sup" renvoient à des notions visuelles (haut, bas, supérieur, inférieur) et on peut très bien le réaliser en CSS. Je suis partagé sur la question, je comprends aussi ton point de vue. Y'a t'il une doc précise à ce sujet ?

@LaurentDenis > Le tag Xiti n'est évidemment pas la panacée. Je l'ai installé avant-hier provisoirement pour comparer avec les (douteuses) stats Urchin de mon hébergeur.
J'ai bien essayé de modifier le code, mais Xiti n'a pas aimé :
" Le logo XiTi sur votre site n'est pas visible. Il a été modifié ou il est situé sur des pages avec accès sécurisé.

Ceci a été observé lors d'un passage de vérification sur votre site. Cela a entraîné une coupure immédiate et automatique de vos analyses Xiti."

D'ailleurs, si quelqu'un connait un bon systeme de stat valide que je pourrais installer temporairement, je suis preneur

Le vendredi 10 septembre 2004 à 10:07, par Bobe :: #

SUB et SUP permettent la présence d'indices et d'exposants dans le texte, c'est important pour des textes un peu technique (contenant des maths, des composition de molécules en chimie, etc). Il servent aussi pour satisfaire certaines règles typographiques (eg: 1er, Mlle, ...)

Le vendredi 10 septembre 2004 à 10:07, par [ NikO ] :: site :: #

www.mrunix.net/webalizer/
awstats.sourceforge.net/c...

les 2 meilleurs softs je trouve ...

Le vendredi 10 septembre 2004 à 10:16, par Raphael Goetter :: site :: #

@Bobe > ok je suis maintenant convaincu
@Niko > bien, je vais tester ça, parmi d'autres. De toute façon ça restera sans-doute temporaire.

Le vendredi 10 septembre 2004 à 10:18, par Raphael GOETTER :: #

@Navarro : "Raphael, il manque des p dans le blockquote de ton message 784 (bug de dotclear ?)."

Mon message 784 ?

Le vendredi 10 septembre 2004 à 13:08, par mEga :: #

www.alsacreations.com/blo... je vois que ca

Le vendredi 10 septembre 2004 à 13:12, par Raphael Goetter :: site :: #

@mega > ah ok je comprend... et je corrige

Le vendredi 10 septembre 2004 à 14:30, par snoop :: site :: #

"D'ailleurs, si quelqu'un connait un bon systeme de stat valide que je pourrais installer temporairement, je suis preneur"

>> dreamweaver.media-box.net...
>>testé et approuvé, aprés correction des trop nombreuses fautes d'orthographes.

Le vendredi 10 septembre 2004 à 18:55, par jp :: #

Juste pour completer l'info, ce lien au poil :
giminik.developpez.com/xh...

Le vendredi 10 septembre 2004 à 20:10, par ElMoustiko :: site :: #

Oui je rejoins Bobe, même si tu es convaincu, sup et sub sont très important. D'ailleur je me demande si par exemple la mise en exposant (ou indice) pour par exemple faire référence à une explication sur tel ou tel mot est une règle typographique ou non...

Le vendredi 10 septembre 2004 à 22:33, par Raphael Goetter :: site :: #

@ElMoustiko : "D'ailleur je me demande si par exemple la mise en exposant (ou indice) pour par exemple faire référence à une explication sur tel ou tel mot est une règle typographique ou non.."
>> Tu veux dire dans l'optique d'une note de bas de page. Non, je ne le vois pas comme une règle typographique (dans le sens "esthétique" du terme), mais comme une ancre spéciale.

Le vendredi 10 septembre 2004 à 23:09, par Laurent Denis :: #

Je vais faire tout simple pour <sup> ; l'expression d'une puissance, sans passer par MathMl... 10³, par exemple... Sémantique en diable, et pas simple du tout, ce bout de bidule

Le vendredi 10 septembre 2004 à 23:19, par Raphael Goetter :: site :: #

@Laurent > Oui je vois. Pour info, ça donnerait quoi avec MathML ?
Et au fait, MathML fait bien partie de XHTML, non ?

Le samedi 11 septembre 2004 à 00:00, par ElMoustiko :: site :: #

Euh non, MathML est une spec à part entière d'après ce que Denis Boudreau me disait il y a un petit moment déjà !
Par ailleur, MathML est très mal géré à l'heure actuelle il me semble. En tout cas MathML, j'ai vu un peu ce à quoi ça ressemblait, et ben c'est pas triste ! Mieux vaut avoir un outil qui vous code ça !

Le samedi 11 septembre 2004 à 00:01, par Bobe :: #

<math xmlns="www.w3.org/1998/Math/Math...
<msup>
<mi>10</mi>
<mn>3</mn>
</msup>
</math>



Mais de toute façon, MathML est à priori un méta-langage de description d'opérations mathématiques donc cet exemple en lui même est probablement incorrect d'une certaine façon (à moins qu'on considère ça comme une opération?), et puis il manque peut être des balises.

(Bon, je vous sors du mathML, mais c'est juste pour épater la galerie, en réalité, je ne connais pas du tout ;-))

Le samedi 11 septembre 2004 à 07:37, par Laurent Denis :: #

MathMl est un dialecte XML. La modularisation de XHTML ( www.w3.org/TR/xhtml-modul... ) permet de le combiner avec d'autres applications XML, dont MathMl ( www.yoyodesign.org/doc/w3... ), par exemple en utilisant la DTD "XHTML 1.1 plus MathML 2.0"
Concrètement, cela donne golem.ph.utexas.edu/~dist...

Le lundi 13 septembre 2004 à 14:44, par François Parmentier :: site :: #

Moi, j'aime utiliser un site comme giminik.developpez.com/xh... il permet de voir tout de suite ce qu'on a le droit de mettre à l'intérieur d'une balise ou non. Pas besoin de retenir les exceptions.

Le lundi 13 septembre 2004 à 14:57, par Raphael Goetter :: site :: #

@François > c'est un point de vue qui se défend, surtout que le site proposé est exhaustif.
Pour ma part, j'ai le raisonnement inverse : plutôt que d'aller voir chaque balise pour savoir si elle se comporte correctement ou non, je préfère connaître les exceptions (P et Hn principalement), ça me fait moins de choses à retenir !

Le mardi 2 novembre 2004 à 00:26, par Pierre Dureau :: #

BODY : Ne peut pas être parent direct d'éléments en ligne, sauf INS et DEL

Le mardi 2 novembre 2004 à 05:21, par Laurent Denis :: #

@Pierre> Pour être plus précis, INS et DEL sont des éléments très particuliers, puisqu'ils sont alternativement des éléments en ligne (dans un contenu de type %inline et %flow) et des éléments blocs (dans un contenu %block)...

Le mardi 15 février 2005 à 14:33, par HoPHP :: site :: #

"PRE
Ne peut être parent que d'éléments en-ligne, sauf IMG, (...)"

et

"IMG
(...) Ne peut pas être contenu dans un élément PRE. "

Il faut qu'on m'explique

Le mardi 15 février 2005 à 14:38, par Raphael :: site :: #

@HoPHP > Ben c'est simple :
- <pre> ne peut contenir que des éléments en-ligne (mais pas <img>, entre autres)
- <img> ne peut pas être contenu dans <pre> (c'est la même chose que la règle précédente)

Le mardi 15 février 2005 à 15:48, par HoPHP :: site :: #

Mouais, je tends (quand n tend vers l'infini) à la compréhension, mais le vocabulaire ne m'est pas encore très clair:

Pour moi, quand on dit: "PRE NE peut être parent que (...) SAUF IMG", ça signifie que PRE peut être parent d'IMG, non ? En fait, en y réfléchissant, je viens à ça en partant du principe que IMG est block. Alors que ce n'est pas le cas !

OK, OK, je sors :-p

@+, HoPHP

Le samedi 26 février 2005 à 14:28, par Normand Lamoureux :: site :: #

«En HTML (et XHTML) Strict, la balise BLOCKQUOTE ne peut contenir que des éléments de type Bloc.»

Je viens de vérifier et ce n'est pas le cas. Les éléments a, strong et em, par exemple, peuvent très bien se trouver à l'intérieur de blockquote. Or ce sont tous là des éléments de type en ligne.

Si on veut dire qu'en strict blockquote ne peut être *parent immédiat* que d'un élément de type bloc, alors là j'achète.

Le samedi 26 février 2005 à 18:41, par Raphael :: site :: #

@ Normand Lamoureux : "Si on veut dire qu'en strict blockquote ne peut être *parent immédiat* ..."
>> Oui, en fait, un "parent" est toujours immédiat, sinon il s'agit d'un "ancêtre" ("parent immédiat" est un pléonasme).
Par contre, tu as tout à fait raison, je n'ai pas été assez précis dans la règle. Je vais modifier cela.

Le samedi 26 février 2005 à 19:53, par Normand Lamoureux :: site :: #

Dis... on serait pas parents quelque part?

Le jeudi 17 mars 2005 à 20:59, par DSC :: #

Bonjour,

@Raphael : je crois que cet exemple n'est pas valide, malheureusement...

css.alsacreations.com/xme...