web-dev-qa-db-fra.com

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

Dans le code ci-dessous, j'ai placé une feuille de style interne avec une balise body au lieu d'avoir en 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 -->
htmlcss
12
Saran

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

Pourtant, vous ne gagnez rien en utilisant la syntaxe invalide, contrairement à placer style dans 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 partie head.

Le problème de l'utilisation d'un élément style par rapport à une feuille de style externe via link est complètement orthogonal à cette question.

18
Jukka K. Korpela

(Puisque 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 balises STYLE (peut-être en raison d'une omission fortuite dans un filtre de balises) ... Le jour est sauvé, 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 d'une manière simple avec vos fragments HTML, simplement parce que la spécification le dit?

Ou, vous avez une seule page AJAX application.

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 n'utiliser que des attributs STYLE inline au lieu de simplement venir avec un élément STYLE incorporé.

De plus: vous pouvez a) déjà incorporer n'importe quel CSS n'importe où dans les attributs BODY, via STYLE, 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 à propos des éléments STYLE dans les BODY? Quelles sont ces implications négatives supplémentaires que cela ajouterait à notre vaste arsenal d'abus des 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 l'habitude d'avoir Java applets 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 stupide que le concepteur de sites Web moyen. En outre, Cher W3C, pas besoin de s'inquiéter: les troupeaux de bricoleurs HTML en colère se faisant tirer dessus avec des éléments STYLE dans les BODY ne peuvent toujours pas se venger du W3C. Ils ne connaissent pas l'adresse. Et ils n'ont pas de jambes.

Alors, s'il vous plaît: faites entendre votre voix pour que STYLE devienne légal dans BODY! Citer docilement le texte, mais ne pas fournir d'alternative viable qui est mieux que la situation actuelle ne sert à rien. C'est en fait une menace pour cette technique de contournement de dernier recours.

Rappelez-vous: la spécification HTML5 est appelée recommandation.

6
lunakid

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

2
crad

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 disposez de deux méthodes pour ajouter des 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.

1
pllee