Sera-ce une mauvaise idée d'avoir <style> dans <body>?

12

Dans le code ci-dessous, j'ai placé une feuille de style interne avec une balise dans le corps, au lieu d'avoir dans la tête. Pour une application à page unique, j'envisage de le faire pour les styles qui ne s'appliquent qu'à cette page seule, plutôt que d'avoir un fichier pagespecific.css distinct.

Y a-t-il un scénario où cela a un inconvénient car je ne mets pas le même dans la section tête?

<!-- myPartial.html starts here --> 
<!-- Like to keep styles unique to this html right here in this file --> 
<div>
  <style>
    body { background-color: red; }
    #myText { color: white; }
  </style>

  <span id='myText'>Hello</span>
</div>
<!-- myPartial.html ends here -->

html css

— Saran
source

18

Un styleélément à l'intérieur de l' bodyélément viole les règles de syntaxe HTML. (Sauf que selon les brouillons HTML5, il est autorisé dans certaines conditions, si les scopedattributs sont présents; cet attribut est pris en charge par certains navigateurs.) En revanche, les navigateurs s'en moquent. La division en headet bodyéléments est théorique.

Pourtant, vous ne gagnez rien en utilisant la syntaxe invalide, par opposition à un placement à l' styleintérieur head. La seule excuse serait des limitations techniques, dans certains environnements de création, qui pourraient vous empêcher de mettre quoi que ce soit dans la headpièce.

La question de l'utilisation d'un styleélément par rapport à une feuille de style externe via linkest complètement orthogonale à cette question.

— Jukka K. Korpela
source

1

La première partie de votre réponse n'est pas nécessairement vraie .

— patricksweeney

1

@patricksweeney, je pense que c'est quelque peu théorique dans ce contexte, mais une observation correcte; réponse mise à jour.

— Jukka K. Korpela

Je prends "les navigateurs ne se soucient pas" comme positif pour mon approche. Comme mes pages sont partielles (Single-Page-Application), je ne peux pas avoir de section <head>, la raison pour laquelle j'essaye de mettre à l'intérieur <body> ou à l'intérieur des éléments dans body.

— Saran

2

@Galaxy, je ne vois pas pourquoi une application d'une seule page n'aurait pas d' headélément. Une page HTML en a toujours un.

— Jukka K. Korpela

@ JukkaK.Korpela, j'ai mis à jour la partie de code dans ma question pour répondre à votre question.

— Saran

6

(Étant donné que nous sommes ici à SE.SX, une approche plus stratégique peut être une augmentation précieuse des considérations techniques habituelles.)

[préambule] La spécification HTML5 est une cible en constante évolution et elle a une politique de suivi des pratiques courantes établies. Ils ont obsolète et ressuscité des caractéristiques dans le passé, changé le sens des autres, déplacé le centre des recommandations méthodiques, etc. Ce n'est pas écrit pour l'éternité avec toute la sagesse de l'humanité disponible à la fois. La spécification n'est pas une source sacrée de vérité. Il est naturel que les navigateurs aient parfois raison. [/préambule]

La situation du PO est extrêmement courante et valable.

Vous avez un CMS, avec son thème conçu et installé, tout le CSS correctement chargé à partir de HEAD, puis vous voilà, l'éditeur de page, laissé avec une boîte WYSIWYG à la mode que vous pouvez (Dieu merci!) Passer en "mode source" et taper (coller) dans le balisage HTML (précédemment créé ailleurs, avec des outils plus adaptés). Heureusement, vous pouvez même inclure des STYLEbalises (peut-être en raison d'une omission fortuite dans un filtre de balises) ... La journée est sauvée, grâce à de nombreux travaux répétés de destruction de l'âme. Mais vous n'avez toujours aucun moyen d'interférer avec l'élément HEAD du système à partir d'un scénario d'édition de page.

Cela devrait-il vous empêcher d'utiliser votre CSS de manière simple avec vos fragments HTML, simplement parce que la spécification le dit?

Ou, vous avez une application AJAX d'une seule page.

Il fonctionne sans rechargement pendant une longue session, et il existe du contenu syndiqué provenant de diverses sources aléatoires, toutes de style arbitraire et indépendant. Il serait absurde d' exiger qu'ils soient d'abord convertis pour utiliser uniquement des STYLEattributs en ligne au lieu de simplement venir avec un STYLEélément incorporé .

De plus: vous pouvez a) déjà intégrer n'importe quel CSS n'importe où dans le BODY, via des STYLEattributs, donc le CSS est "théoriquement" légal de toute façon; et b) vous pouvez déjà faire tout ce que vous voulez avec à peu près n'importe quel style, quand vous voulez (et plus) à partir de Javascript, donc CSS est également déjà possible de mal utiliser de manière pathologiquement non performante. Et aucun de nous ne s'opposerait jamais à ces caractéristiques. Le W3C non plus.

Alors, qu'est-ce qui est si mauvais dans les STYLEéléments du BODY? Quelles sont ces implications négatives supplémentaires que cela ajouterait à notre vaste arsenal d'abus dans les constructions HTML? Plus de mauvaises performances? Probablement. Quelquefois.

Est-ce une raison valable pour abolir cette pratique incroyablement utile, prise en charge par tous les navigateurs pour une raison? Pas dans un million de kilomètres!

Nous ne sommes pas des idiots. Eh bien, pas tous, ou pas toujours ...;) Les techniques avec le risque de mauvaises performances pourraient simplement être documentées , plutôt que simplement interdites. Nous avions des applets Java dans les premiers jours du Web et nous avons survécu. Les voitures peuvent être utilisées à mauvais escient, provoquant la misère, même la nourriture peut être utilisée de manière dérangeante et inefficace, et les conducteurs qui peuvent manger peuvent être, en moyenne, encore plus stupides que le concepteur de sites Web moyen. D'ailleurs, cher W3C, pas d'inquiétude: les troupeaux en colère de bricoleurs HTML se faisant tirer les pattes avec des STYLEéléments dans l' BODYalambic ne peuvent pas aller après le W3C et se venger. Ils ne connaissent pas l'adresse. Et ils n'ont pas de jambes.

Alors, s'il vous plaît: faites entendre votre voix pour STYLEdevenir légal en BODY! Citer docilement le texte, mais ne pas fournir d'alternative viable qui soit meilleure que la situation actuelle n'est d'aucune utilité. C'est en fait une menace pour cette technique de contournement de dernier recours.

N'oubliez pas: la spécification HTML5 est appelée une recommandation .

— lunakid
source

Mise à jour: le cahier des charges enfin rattrapé: STYLEest désormais valable en BODY! ;)

— lunakid

1

Mise à jour 2: Les spécifications n'ont pas été rattrapées car elles ont changé d'avis (cliquez sur le lien de lunakid, il a été mis à jour).

— Maximillian Laumeister

2

La spécification html indique que

Un élément de style sans attribut de portée est limité à apparaître dans l'en-tête du document.

L'attribut scoped est une valeur booléenne indiquant qu'il doit être appliqué uniquement à la sous-arborescence enracinée dans l'élément parent de l'élément style.

À l'heure actuelle, seul Firefox prend en charge l'attribut de portée. http://www.w3schools.com/tags/att_style_scoped.asp

— crad
source

5

Le site w3schools ne doit pas être cité comme référence, ou pas du tout; voir w3fools.com

— Jukka K. Korpela

2

Et cela ne répond pas à la question.

— Jukka K. Korpela

1

Merci @ JukkaK.Korpela, c'était le premier lien que j'ai trouvé citant la prise en charge du navigateur d'attributs étendus. L'autre commentaire fournit une bien meilleure citation. +1 votre réponse -1 vos commentaires moins que constructifs.

— crad

+1 pour pointer vers la spécification ainsi que pour noter le manque de prise en charge de la portée (qui est nécessaire pour respecter la spécification). Je pense que vous auriez dû lire la réponse avant de sauter l'arme à feu @ JukkaK.Korpela, très pauvre. Vous ne pouvez pas vraiment être plus fiable que la spécification, et cela répond parfaitement à la question. " Ce sera une mauvaise idée d'avoir du style dans le corps " - selon la spécification " Oui, ce sera. ".

— Fergus à Londres le

1

Il y a quelques raisons techniques pour avoir votre css dans un fichier vs une balise de style:

La possibilité d'utiliser un minificateur CSS (je ne pense pas que les minificateurs fonctionnent sur les balises de style)
Pour que le fichier css puisse être mis en cache par le navigateur.

Quelques raisons basées sur l'opinion d'utiliser un fichier:

Vous pouvez utiliser un merveilleux préprocesseur CSS comme Sass (Compass) ou Less.
Vous maintenez deux façons d'ajouter css à votre application.

Ma préférence personnelle est d'utiliser Compass pour conserver des fichiers séparés pour chaque page, puis l'utiliser pour les compiler tous dans un seul fichier. Ce fichier unique serait inclus par chaque page. Si en cours de route, les fichiers doivent être séparés pour une raison quelconque, ils peuvent toujours l'être, mais cela ne vaut pas la peine en attendant.

— implorer
source