Balises inline vs block

Bonjour à tous
Une des choses qui restent de l'antiquité du web est le fait que les navigateurs vérifient plus ou moins que le code HTML respecte bien la nature des balises.
Par exemple si on écrit

<p>.......<div>.....</div>...</p>

Le navigateur, lors de l'analyse du HTML, remplace par

<p>...</p><div>....</div><p>...</p>

Mais depuis HTML5, on peut styler le <div> interne en display:inline ou display:inline-block et donc ce pourrait ne pas être une erreur, seulement l'analyse du HTML précède l'application du CSS, donc c'est toujours refusé.
Pour se sortir de cette situation, ou peut bien entendu remplacer <div> par <span>, mais le même problème va se poser à l'intérieur du <span>.
La solution est de mettre <div> à l'intérieur d'un <button>, car un <p> peut contenir un <button>. Noter que <button> est à ma connaissance la seule balise que le navigateur considère comme un inline-block (sans doute parce qu'originellement un <button> était inline)

Quand on utilise des balises nouvelles HTML5, on n'arrive plus très bien à s'y retrouver.
Par exemple:
1) que peut on mettre dans un <fieldset> ? Par exemple peut on écrire

<fieldset>
  <ul>
    <li><label...><input></li>
    <li><label...><input></li>
    ...
</fieldset>

a priori oui, mais je ne suis pas sûr que tous les navigateurs se comportent de la même façon.

Autre point: quelles vérifications sont appliquées lorsque l'on manipule le DOM ?
J'ai vu par exemple qu'on peut écrire

<p>......</p>
<aside>...</aside>

puis déplacer <aside> par manipulation du DOM
C'est ce que je faisais avant de découvrir que

<p>.....
  <button>.....
      <aside>....</aside>
  ....</button>
....</p>

marche fort bien.

Si l'essentiel du code HTML est généré dynamiquement en JavaScript, quelles sont les vérifications qui sont effectuées par le navigateur?

Connaissez vous un document clair sur ce sujet?
Merci de votre aide
Modifié par PapyJP (30 May 2020 - 17:48)

PapyJP a écrit :

Connaissez vous un document clair sur ce sujet?

Question pertinente. Depuis l'HTML5, je ne connais pas de document permettant de savoir quel/s parent, quel/s enfant.

Par contre, j'utilise encore ce document et j'affine en validant mon document.
Outil XHTML 1.1 Hiérarchie. Si un membre a un lien de ce type, je suis preneur. Bien sûr, sur le W3C, on va trouver quelque chose. Mais je cherche un document similaire au lien que je viens de filer.
Modifié par niuxe (31 May 2020 - 00:55)

Bonjour PapyJp,
bonjour nieuxe,
j'ai vécu le même prob' dernièrement qui portait sur une incohérence de liens
a
a:link
a:hover
et
a:visited
après (ou malgré) l'intervention d'un .js

Or, la solution que j'ai mise en œuvre et qui est performante semble être celle-ci, cross-browser par le simple .css de toute balise initialement déclarée :

x{display:inline-block !important}

Ou par leur .class spécifique :

.y{display:inline-block !important}

Bon ! je me trompe peut-être sur votre sujet ...

Cependant, j'ai résolu par cette voie un prob' de z-index pour un formulaire de contact en .php en <iframe src=""></iframe> de mon même domaine (!) qui devait se superposer utilement à diverses images en cours de .html

À +
Modifié par Arrival (06 Jul 2020 - 16:43)

Salut,

Attention à ne pas confondre la nature des balises et leur display.
Je te renvoie à cet article pour bouquiner un peu le sujet (qui est parfois touffu, faut avouer).

Alors j'arrive après la guerre, m'enfin.

a écrit :
La solution est de mettre <div> à l'intérieur d'un <button>, car un <p> peut contenir un <button>

Pas vraiment, parce que div n'est pas non plus un enfant valide de button.

niuxe a écrit :
Question pertinente. Depuis l'HTML5, je ne connais pas de document permettant de savoir quel/s parent, quel/s enfant.

La doc officielle? => https://html.spec.whatwg.org/multipage/grouping-content.html#the-p-element

a écrit :
que peut on mettre dans un <fieldset> ?

«Optionally a legend element, followed by flow content.» ( https://html.spec.whatwg.org/multipage/form-elements.html#the-fieldset-element )
«Flow content»: c'est à peu près toute les balises sauf celles qui nécessitent un parent particulier (li, td, tr, etc.) https://html.spec.whatwg.org/multipage/dom.html#flow-content-2

a écrit :
Si l'essentiel du code HTML est généré dynamiquement en JavaScript, quelles sont les vérifications qui sont effectuées par le navigateur?

Normalement il n'y a pas de différence. L'implémentation du DOM est généralement unique, qu'il soit créé par javascript ou en parsant du html. C'est justement l'avantage du DOM
Modifié par kustolovic (20 Aug 2020 - 13:43)

Ouais, ce n’est pas ce que je constate. Tous les navigateurs acceptent sans broncher n’importe quoi dans un <button>. De même je peux manipuler le DOM en JavaScript et mettre un <aside> à l’intérieur d’un <span>.
Qui a travaillé de près avec des Américains sait que la logique et la rigueur ne sont pas leur fort. Et depuis qu’ils sous-traitent aux Indiens ça ne doit pas s’être amélioré. Mais ça c’est une vue française. Anglais et Américains se moquent des Français qui mettent la logique au premier plan

Le fait que les navigateurs acceptent un code invalide ne le rend pas valide pour autant.

Ça dépend de ce que tu appelles "valide". Pour moi quelque chose qui marche est valide, ce qui ne marche pas est invalide. Suivre les standards est une façon performante d’obtenir des choses valides. Quelque chose conforme aux standards qui ne marche pas est invalide.
Tant que je n’ai pas d’utilisateurs qui se plaignent je ne modifie pas des solutions conçues pour marcher sous prétexte que leur conformité aux standards est discutable.
J’admets bien entendu que d’autres personnes aient un autre point de vue.

PapyJP a écrit :
Ça dépend de ce que tu appelles "valide". Pour moi quelque chose qui marche est valide, ce qui ne marche pas est invalide.

Hello, pour le coup je pense que Marvin s'en tenait à la définition basique de HTML et CSS : "est valide un code qui... passe avec succès le Validateur". Et j'avoue que je suis plutôt d'accord avec cette définition.
Pour moi, "ce qui marche" est Fonctionnel, pas forcément Valide (en terme de validateur). On peut donc être parfaitement valide et non fonctionnel, et inversement.

Désolé de n'avoir pu répondre plus tôt.
Si on regarde le style d'une balise <button> sur les outils de développement de FireFox ou de Google Chrome, on constate que la valeur par défaut de "display" est "inline-block", c'est ce qui m'a permis d'obtenir le résultat souhaité.
Je n'imagine pas que les producteurs de navigateurs internet décident de remettre cette valeur par défaut à "inine", car je ne dois pas être le seul à tirer parti de cette propriété. Cela serait considéré comme un bug par tous ces utilisateurs et serait rapidement corrigé, je pense.
S'il y a une différence entre le standard et ces implémentations, c'est plutôt le standard qui devrait être modifié.

PapyJP a écrit :
Or ce que je constate, c'est que CSS3 permet de donner des propriétés telles que display:inline-block mais que si on essaie de les utiliser, on constate que c'est extrêmement difficile car la vérification du code HTML se fait pratiquement comme si ces propriétés étaient non standard: les navigateurs commencent par valider le code HTML et à le compléter sur les bases du HTML d'il y a 25 ans sans tenir compte que le CSS permet d'ajouter les propriétés en question.

Etonnant... Sauf erreur, je n'ai pas constaté de difficulté particulière dans l'utilisation de l'attribut @display avec la valeur inline-block dans la construction de mes sites.
C'est un attribut qui existe depuis longtemps et semble être correctement intégré par les différents navigateurs (cf. caniuse.com).
Peux-tu nous donner plus de précisions à ce sujet ?

Le problème est que ce qui est autorisé ou non comme contenu des balises n'a rien à voir avec la propriété display.

Tout d'abord le code HTML est parsé pour le transformer en DOM, ce parsing rejette des déclarations et des structures invalides et ne les ajoute jamais dans le DOM. De ce fait, vu que jamais ajoutée au DOM, elles ne reçoivent jamais une propriété display.

Cette propriété display est une pure question d'affichage, ce n'est pas du CSS3, mais du CSS1 (CSS2 pour inline-block). Mais il n'a jamais été question de contourner les interdictions du HTML…

Pour ce qui est permis en HTML, tout est dans la doc: https://html.spec.whatwg.org/multipage
Les éléments ne sont pas regroupés en inline ou en block (ce concept n'existe pas en HTML) mais en Metadata content, Flow content, Sectioning content, Heading content, Phrasing content, Embedded content, Interactive content, Palpable content et Script-supporting elements selon le graphe suivant: