Il existe deux grands groupes de structures pour les éléments HTML version 4.x , et XHTML 1.x : les éléments de niveau bloc et les éléments en-ligne.
En règle générale, un bloc peut contenir des éléments en-ligne mais aussi d'autres blocs. De leur côté, les éléments en-ligne ne peuvent contenir que d'autres balises en-ligne.
Cette règle générale est sujette à quelques exceptions pas toujours bien connues...
1) Éléments de niveau bloc
ADDRESS
En HTML (et XHTML) Strict, la balise ADDRESS ne peut contenir que des éléments en-ligne. En transitionnel, elle peut contenir également la balise P. Parents possibles pour cette balise : BLOCKQUOTE, BODY, BUTTON, DD, DEL, DIV, FIELDSET, FORM, INS, LI, MAP, NOSCRIPT, OBJECT, TD, TH
BODY
Ne peut pas être parent direct de caractères ou d'éléments de type En-ligne.
BLOCKQUOTE
En HTML (et XHTML) Strict, la balise BLOCKQUOTE ne peut être parente que d'éléments de type Bloc. En transitionnel, elle peut également être parente d'éléments de type En-ligne.
DL
Ne peut être parent direct que des éléments DT et/ou DD
DT
Ne peut pas contenir d'éléments blocs
FIELDSET
Doit contenir en premier l'élément LEGEND.
FORM
Ne peut être parent direct que d'éléments blocs. Ne peut pas contenir d'autres éléments FORM
H1, H2,... H6
Ne peut être parent que d'éléments en-ligne.
HR
Ne peut pas contenir d'éléments.
NOSCRIPT
Ne peut contenir directement que des éléments de type bloc.
OL et UL
Ne peut contenir directement que des éléments de liste LI.
P
Ne peut être parent que d'éléments en-ligne.
PRE
Ne peut être parent que d'éléments en-ligne, sauf IMG, OBJECT, APPLET, SUB, SUP.
TABLE
Peut être parent direct des balises suivantes : TR, CAPTION, THEAD, TFOOT, TBODY, COL, COLGROUP.
2) Éléments en-ligne (inline)
A
Ne peut pas contenir d'autres éléments A.
BR
Ne peut pas contenir d'éléments.
IMG
Ne peut pas contenir d'éléments. Ne peut pas être contenu dans un élément PRE.
INPUT
Ne peut pas contenir d'éléments. Ne peut pas être contenu dans un élément BUTTON.
LABEL
Ne peut pas contenir d'autres éléments LABEL. Ne peut pas être contenu dans un élément BUTTON.
SELECT
Peut être parent direct des éléments OPTGROUP ou OPTION . 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.
Commentaires
Excellente chose !
Une suggestion : une typo plus différenciée pour le titre de l'article (juste un text-align:center, par exemple) ?
Ah... une question aussi : pourquoi ce bouton "imprimer l'article" qui fait double emploi avec la commande native du navigateur (en moins bien : pas d'aperçu avant impression), qui ne fonctionne qu'avec javascript, et qui fait plutôt penser le lecteur averti que tu as mis en ligne une "version imprimable" de tes tutos ?
(Ce n'est pas pour le principe de râler : je trouve que les documents Web ont un peu tendance à engraisser, en s'encombrant de bien des choses que le navigateur gère / devrait gérer par ailleurs. )
@Laurent >
- typo du titre : oui pourquoi pas, je vais la modifier.
- bouton "imprimer" : en fait, il n'était pas prévu au départ.
J'ai demandé à plusieurs personnes de tester l'impression et la réponse majoritaire que j'ai eu est ... "ben on peut pas", "comment on fait", "ah, il faut aller dans le menu du navigateur?".
J'ai donc pris l'initiative de faire un bouton pour faire mieux comprendre aux gens que l'article est fait pour être imprimé... c'est aussi un peu ça l'accessibilité.
Je suppose que ce bouton (en js en effet) ne devrait pas poser de problèmes puisqu'il reste la solution de laisser faire la fonction native du navigateur.
C'est intéressant : dans une discussion sur OpQuast, ce n'était pas la fonction imprimer du navigateur qui était jugée déroutante pour des utilisateurs, c'était qu'une page avec une CSS print se s'imprimait pas du tout comme à l'écran (pas de menus...). Certains proposaient de donner des explications à ce propos sur la page d'aide du site.
Je crois que la réponse est la même ici : l'utilisateur a lui aussi quelques petits pas à faire pour améliorer son utilisation du Web. Des pas modestes, bien-sûr. Je pense qu'une petite phrase en fin d'article du genre "Vous pouvez imprimer cet article directement à l'aide de la fonction d'Impression de votre navigateur..." serait plus utile et pédagogique que le lien actuel.
@Laurent : "Vous pouvez imprimer cet article directement à l'aide de la fonction d'Impression de votre navigateur..." serait plus utile et pédagogique que le lien actuel.
>> hummf, oui et non.
- Les utilisateurs (en tout cas ceux à qui j'en ai parlé), ont plutôt tendance à cliquer sur un bouton "précédent" que d'utiliser la fonction "page précédente" du navigateur. D'ailleurs je n'utilise moi-même jamais cette fonction (elle est en bouton sur ma souris mais c'est un autre sujet)
Je trouve que c'est un peu la même chose.
Idem pour les tailles de polices : les navigateurs permettent d'augmenter la taille de police, mais il est souvent mieux perçu de voir cette option sur le document.
Le navigateur fait souvent plein de choses... que les utilisateurs ne connaissent pas.
Doit-on à chaque fois leur signifier qu'ils peuvent utiliser leur navigateur pour imprimer le document, agrandir la police, mettre le site en signet, etc. ?
Je ne sais pas si c'est une bonne idée (s'il change de navigateur, que va-t-il devenir, le pauvre ?)... tout autant que je ne sais pas s'il est mieux de lui mâcher le travail.
Et s'il existait des navigateurs qui n'avaient PAS cette fonction d'impression ? (je dis ça au hasard, bien sûr, mais ça vaut aussi pour d'autres fonctions).
Heu... ton javascript d'impression aurait un peu de mal à marcher dans un navigateur n'ayant pas de fonction d'impression, je crois ;)
Plus sérieusement, ce n'est pas un choix évident :
- faut-il privilégier une ergonomie "immédiate" qui conduit en effet à dupliquer dans les pages Web des fonctions natives des navigateurs ?
- ou faut-il privilégier une ergonomie plus pédagogique ?
Le première me semble peu productive, car elle conforte l'utilisateur dans une utilisation partielle et erronée de son outil. La seconde pose le problème : "où et comment faire passer l'info ?" La page d'aide, surtout. Dans le document, peut-être parfois.
Quand on voit tout ce qu'un navigateur est déjà en fait capable de gérer "hors page" : impression, zoom, menu de navigation (liens relatifs), styles... avec évidemment des implémentations variées et plus ou moins heureuses... je me prends à rêver de navigateurs plus mûrs, permettant au document Web de se débarrasser de ce qui, finalement, encombre leur contenu propre. Cela passe aussi par des utilisateurs plus mûrs.
"Heu... ton javascript d'impression aurait un peu de mal à marcher dans un navigateur n'ayant pas de fonction d'impression, je crois"
> Hé, même pas drôle.
@Raphael> Lorsque tu as parlé "d'impression dans le navigateur" avec certaine personne, était-ce des utilisateurs lambda, avertis, ou autre ? En général, je comprend parfaitement qu'il ne savent pas que Imprimer se trouve dans le menu Fichier (si le butineur est en français bien évidemment) etc. mais dans les barres d'outils, il est bien présent par défaut d'une imprimante (dans la majorité des navigateurs connus) ; de ce fait, est-ce simplement un manque de connaissance des logiciels utilisés ?
@Laurent> Concernant les fonctions natives des navigateurs dupliquées dans les pages, il est parfois nécessaire de le faire, pour le confort du visiteur. La productivité peut en être réduite... Mais généralement ce sont des fonctions bien connues, que tout le monde dispose en fichier texte dans un dossier et qu'il soit prêt a être utilisé.
Mais cela rejoint l'avis de Raphael. Les personnes utilisant un logiciel ne vont pas chercher plus "loin que le bout de leur nez" ! Et s'arrete là ou la bordure du 'browser' commence !
Allez, je vais oser : ce n'est pas seulement la productivité qui est réduite par ces fonctions dupliquées. Ce sont des utilisateurs que l'on maintient dans une sorte de "sous-culture" à l'égard de leurs propres outils... et dans une certaine dépendance envers le bon vouloir des auteurs ;)
Tout bêtement, les fonctions élémentaires d'un navigateur Web sont maintenant officiellement enseignées à partir de l'école primaire en France.
Eh bien... le gamin qui a pris l'habitude de chercher un lien "imprimer la page", ça lui complique drôlement les choses quand il ne trouve pas le lien, et qu'il doit se souvenir qu'il faut aller dans Fichier>Imprimer... S'il ne s'attendrait pas à trouver ce lien (certes agréable), il mémoriserait plus facilement la fonction du navigateur.
@Laurent > Sous ce point là je n'ai jammais dit le contraire. Je suis entièrement d'accord. "Ne pas chercher plus loin que le bout du nez".
Bonjour,
Ma face éducatrice est alertée ;-)
Je rejoins la position de Laurent. Nous vivons dans l'ère du "sans effort", est-ce une raison pour suivre le courant ?
Quand j'ai mis en ligne mes premières pages sur l'athlétisme il y a 4 ans, j'en avais ajouté une "initiation à l'utilisation d'Internet"...
j'ai constaté avec surprise qu'elle était souvent visitée...
Amicalement,
Monique
Personnellement, je suis tout à fait d'accord sur le principe de l'éducation à l'internet.
Ce qui me dérange est le fait de se référer uniquement au navigateur... or cela suppose que tous les navigateurs offrent cette possibilité (ici en l'occurence l'impression).
Même si c'est souvent le cas, je trouve un peu réducteur de "forcer" à utiliser le navigateur plutôt que de laisser le choix...
Sur ce point, c'est justement ça le problème que visait ma remarque amusée ci-dessus : tous les navigateurs et toutes les configurations utilisateurs ne permettront pas à ton lien "Imprimer cette page" de fonctionner. Alors que dans tous les navigateurs dotés d'une fonction native d'impression, celle-ci fonctionnera, avec ou sans CSS. Et dans un navigateur non doté de fonction d'impression, de toute façon rien ne fonctionnera ;)
Bref, tu ne proposes pas de véritable "choix":
- ou le navigateur le fait, et c'est à l'utilisateur d'apprendre à utiliser cette fonction basique (on peut l'y aider).
- ou le navigateur ne le fait pas, et tout ceci est hors-sujet.
Et de plus (excuser du manque d'intelligence de cette remarque, mais la fatigue l'emporte sur ma journée), si ton lien "Imprimer le tuto" ne fonctionne pas, tu risques encore TOI de te faire "traiter de con !" car ton "imbécile d'internaute" aura désactivé on ne sait comment ni pourquoi le JS ...
Hum ... Désolé des propos un peu spéciaux ...
@Groumphy > ta remarque n'est pas, comme tu l'affirmes, dénuée d'intelligence. Elle rejoint ce que dit justement Laurent.
Mais malgré tout, je reste réticent sur le principe de se reposer entièrement sur un navigateur, un outil qui peut varier selon les gens et les périodes. Je n'aime pas être dépendant de ça.
C'est bien sûr une question de principe, car on l'a compris ça ne change rien en pratique comme le dit si justement Laurent.
PS : Je vais parler de mon expérience personnelle (le cas s'est présenté hier). Je sais utiliser la fonction print du navigateur (si, si). Pourtant, lorsque je vois un document ou un article qui m'indique clairement qu'il est imprimable (par un bouton adéquat), j'ai tendance à me dire "tiens, pourquoi pas, ça m'évitera une longue lecture à l'écran"... sans ce bouton, il ne me serait peut-être pas venu à l'idée d'imprimer ce document.
Bien sûr, on en revient au débat : faire un bouton ou "indiquer la voie au visiteur" ?
Personnellement, je trouve assez curieux de tout indiquer aux visiteurs : "vous pouvez imprimer cette page en allant dans fichier/imprimer", "vous pouvez mettre cette page en favoris en allant dans fichier/favoris", "vous pouvez voir la date du jour en allant en bas à droite de l'écran sur windows", "vous pouvez faire un tennis en décrochant votre téléphone et en appelant un(e) ami(e)", etc. :-)
@Groumphy > Le bouton Imprimer n'est pas présent par défaut dans mon Firefox 1.0PR (et je ne me rappelle pas l'avoir supprimé). Maintenant, peut-être que pour toi Firefox n'est pas un "navigateur connu"? ;)
@Raphael> Mon commentaire initial était peut-être peu clair là-dessus : il ne s'agit pas de truffer sa page de recommandations du type "Vou pouvez imprimer en allant dans..." et autres. Tout au plus, dans certains cas, de mettre 1 message de ce type, temporairement (Tout comme on met quelques explications dans un style switcher, si on est sympa ;) )
En revanche, ça peut très bien figurer durablement dans la page d'aide du site.
Maintenant : "Mais malgré tout, je reste réticent sur le principe de se reposer entièrement sur un navigateur, un outil qui peut varier selon les gens et les périodes."
- Reposer sur le support javascript te semble plus fiable ?
- Et encore une fois, si le navigateur n'a pas de commande imprimer dans son menu, ton javascript n'imprimera rien du tout. Je me répète, mais je ne vois pas ce qu'apporte ce lien de ce point de vue ?
Si ca asservi l'utilisateur ;p
Plutot que de bouger ses gros yeux fatigués vers le haut du navigateur (c'est quand même super haut, je me fait mal à la tête en levant les yeux sur mon écran) et faire 1 clic de plus (s'il n'as pas mis le racourci vers la fonction imprimer). Là au moins il reste dans son truc il n'a aucun effort à faire, il clique tout en poursuivant sa lecture.
Je dis ça un peu bêtement, mais c'est tout de même bien sympa quand on est en train de lire et qu'on veux imprimer vite fait en même temps de simplement cliquer sur la page où l'on est. C'est un peu le système "partisant du moindre effort avec une poutre dans la main" mais c'est tout de même sympathique au final. Le webmestre est là aussi pour rendre l'expérience utilisateur plus agréable. Par ailleur la désactivation du JS ne gène pas outre mesure, l'utilisateur ayant desactivé sont JS connait généralement son navigateur et sait qu'il peut imprimer.
La meilleure solution est donc de faire une petite phrase du style "pensez à imprimer cet article pour l'avoir sous la main" et de la remplacer via JS par un texte du style "imprimer cet article" avec une petite icone eventuellement et au click sur ce texte on lance l'impression. Comme ça tout le monde est content, sans JS on indique gentiement que c possible, avec JS on facilite la vie de l'utilisateur.
Et comme ça pas de JS dans la page, juste un appel de fonction dans le head qui réécri le texte et qui gère le onclick.
Ca parait plutot cool comme méthode.
En passant, ça me fait penser à un billet intéressant de Fred Cavazza :
www.fredcavazza.net/index...