Est-il erroné de changer un élément de bloc en ligne avec CSS si elle contient un autre élément de bloc?

StackOverflow https://stackoverflow.com/questions/746531

  •  09-09-2019
  •  | 
  •  

Question

Je sais qu'il est erroné de mettre un élément de bloc à l'intérieur d'un élément en ligne, mais qu'en est-ce qui suit?

Imaginez cette balise valide:

<div><p>This is a paragraph</p></div>

Maintenant, ajoutez ce CSS:

div {
   display:inline;
}

Cela crée une situation dans laquelle un élément en ligne contient un élément de bloc (Le div est en ligne et le p est bloc par défaut)

Les éléments de la page toujours valide?

Comment et quand on juge si le HTML est valide - avant ou après les règles CSS sont appliquées

Mise à jour: J'ai appris depuis que HTML5, il est tout à fait valable de mettre des éléments de niveau de bloc à l'intérieur des balises de lien par exemple:

<a href="#">
      <h1>Heading</h1>
      <p>Paragraph.</p>
</a>

Il est en fait très utile si vous voulez un grand bloc de HTML pour être un lien.

Était-ce utile?

La solution

De la Spec:

  

Lorsqu'une boîte de ligne contient une la boîte en-ligne (et ses ancêtres en-ligne à l'intérieur de la même zone de ligne) sont réparties autour de la boîte au niveau du bloc (et tous les frères et sœurs de niveau de bloc qui sont consécutives boîte au niveau du bloc, à l'écoulement ou séparés uniquement par des espaces pliable et / ou hors de la circulation des éléments), diviser la boîte en-ligne en deux boîtes (même si chaque côté est vide), un de chaque côté du boîtier de type bloc (s). Les boîtes de ligne avant la pause et après la pause sont enfermés dans des boîtes de blocs anonymes, et la boîte de niveau bloc devient frères et soeurs de ces boîtes anonymes. Quand une telle boîte en-ligne est affectée par le positionnement relatif, la traduction résultante affecte également la boîte au niveau du bloc contenu dans la boîte en-ligne.

     

Ce modèle s'appliquerait dans l'exemple suivant si les règles suivantes:

     
p    { display: inline }
span { display: block }
     

ont été utilisés avec ce document HTML:

     
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HEAD>
  <TITLE>Anonymous text interrupted by a block</TITLE>
</HEAD>
  <BODY>
    <P>
      This is anonymous text before the SPAN.
      <SPAN>This is the content of SPAN.</SPAN>
      This is anonymous text after the SPAN.
    </P>
  </BODY>
     

L'élément P contient un morceau (C1) de texte anonyme suivi d'un élément de type bloc suivi d'un autre morceau (C2) du texte anonyme. Les boîtes résultant serait une boîte de bloc qui représente le corps, contenant une boîte de bloc anonyme autour de C1, la zone de bloc de SPAN, et une autre zone de bloc anonyme autour C2.

     

Les propriétés des boîtes anonymes sont hérités de la boîte enfermant non anonyme (par exemple, dans l'exemple juste en dessous de la sous-rubrique « boîtes de bloc anonyme », l'une pour DIV). propriétés non héritées ont leur valeur initiale. Par exemple, la police de la boîte anonyme est héritée de la DIV, mais les marges sera de 0.

     

Propriétés définies sur les éléments qui provoquent des boîtes de blocs anonymes à générer appliquent encore aux boîtes et le contenu de cet élément. Par exemple, si une frontière a été mis sur l'élément de P dans l'exemple ci-dessus, la frontière serait établie autour de C1 (ouvert à l'extrémité de la ligne) et C2 (ouvert au début de la ligne).

     

Certains agents utilisateurs ont mis en oeuvre des frontières sur inlines contenant des blocs d'une autre manière, par exemple, en enveloppant les blocs imbriqués à l'intérieur de « boîtes de ligne anonymes » et donc en tirant les frontières alignées autour de ces boîtes. Comme CSS1 et CSS2 ne définissait pas ce comportement, CSS1 seulement et les agents utilisateurs CSS2-ne peuvent mettre en œuvre ce modèle alternatif et encore revendiquer la conformité à cette partie de CSS 2.1. Cela ne concerne pas les UAs développées après cette spécification a été libéré.

Assurez-vous de ce que vous voulez. Il est clair que le comportement est spécifié dans CSS, bien que si elle couvre tous les cas, ou est appliquée de manière cohérente à travers le navigateur d'aujourd'hui est peu claire.

Autres conseils

Peu importe si elle est valide ou non, la structure de l'élément est erroné. La raison pour laquelle vous ne les éléments de bloc ne mettez pas à l'intérieur des éléments en ligne est donc que le navigateur peut rendre les éléments d'une manière facilement prévisible.

Même si elle ne touche pas les règles de HTML ou CSS, il crée encore des éléments qui ne peuvent pas être rendus comme prévu. Le navigateur doit gérer les éléments comme si le code HTML était invalide.

Le code HTML et CSS seront tous deux encore valables. Idéalement, vous ne devez faire quelque chose comme ça, mais ce bit particulier de CSS est en fait un moyen pratique (et syntaxiquement valide mais pas sémantiquement valide) pour obtenir deux bug de la marge d'Internet Explorer sans avoir recours à des feuilles de style conditionnel ou hacks qui invalidera votre CSS. (X) HTML a une valeur plus sémantique que le CSS, il est donc moins important que le CSS est sémantiquement valide. Dans mon esprit, il est acceptable, car il résout un problème de navigateur ennuyeux sans annuler votre code.

Le code HTML est validé indépendamment du CSS, de sorte que la page serait toujours valable. Je suis assez sûr que la spécification CSS ne dit rien non plus, mais ne me citez pas là-dessus. Cependant, je serais très prudent en utilisant une technique comme celui-ci, comme il pourrait alors rendre comme prévu dans certains navigateurs, vous auriez besoin de « tester les tous, je ne vois pas beaucoup de garanties en cours.

  

Les éléments de la page toujours valide?

« valide » dans un sens HTML, oui; HTML ne sait rien sur CSS.

Le rendu que vous obtenez dans le navigateur, cependant, est « non défini » par la spécification CSS, il pourrait ressembler à quoi que ce soit. Alors que vous pouvez inclure une telle règle dans hacks CSS visant à un navigateur particulier (où vous savez comment ce navigateur rend ce cas), il ne doit pas être servi aux navigateurs en général.

Non, ce n'est pas un mauvais choix. Nous pouvons utiliser selon les besoins.

S'il y a une logique que vous suivez et vous finissez par la mise en œuvre comme ça, il n'a pas tort. les choses de travail ne sont pas « mauvais » juste parce qu'ils sont bizarres. Oui, il est tout à fait inhabituel, mais il est utile et ce n'est pas une erreur. Il est intentionnel. HTML et CSS devraient vous servir, et non l'inverse, n'écoutez jamais aux commentaires que vous dire de ne pas le faire juste parce qu'il est laid.

Il est typique d'appeler une solution « invalide » et suggère un long chemin autour du bloc. Parfois, vous pouvez repenser ce que vous avez fait. Mais il peut y avoir plusieurs raisons pour ce que vous avez fait et ils ne les considèrent pas.

.

J'utilise des blocs à l'intérieur inline régulièrement Il est valide et il fonctionne - il est tout simplement pas nécessaire dans la plupart des cas. Et alors. Rappelez-vous quand XHTML nous a dit de toujours mettre des guillemets autour de propriétés (et tout le monde a crié à vous si vous ne l'avez pas!), Maintenant HTML5 permet de les omettre s'il n'y a pas d'espace à l'intérieur. Qu'est-il arrivé à cette dernière barre après balises singulières? "
"? Allons. modifier les normes. Mais les navigateurs supportant les choses continuent non standard ainsi. CENTRE est dépréciée; nous sommes en 2013 et il fonctionne encore. TABLE pour le centrage vertical? Parfois, il est la seule façon. DIV intérieur A pour le rendre le vol stationnaire comme vous prévu? Allez-y.

Focus sur les choses importantes.

Je pense, (x) html est valide, css est valide. Le résultat est-il valide? Oui, si elle est à la recherche dans le navigateur comme vous le souhaitez.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top