Será uma idéia errada ter <style> em <body>?

12

No código abaixo, eu coloquei a folha de estilo interna com a tag body, em vez de ter na cabeça. Para aplicativos de página única, estou pensando em fazer isso apenas para estilos aplicáveis apenas a essa página, em vez de ter um arquivo pagespecific.css separado.

Existe um cenário em que isso tem desvantagem, pois eu não estou colocando o mesmo na seção principal?

<!-- 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
fonte

18

Um styleelemento dentro do bodyelemento viola as regras de sintaxe HTML. (Exceto pelo fato de que, de acordo com os rascunhos do HTML5, é permitido em algumas condições, se os scopedatributos estiverem presentes; esse atributo é suportado por alguns navegadores.) Por outro lado, os navegadores não se importam. A divisão em heade bodyelementos é teórica.

No entanto, você não ganha nada usando a sintaxe inválida, ao contrário de colocar styledentro head. A única desculpa seria limitações técnicas, em alguns ambientes de autoria, que podem impedir que você coloque algo na headpeça.

A questão do uso de um styleelemento versus uma folha de estilo externa linké completamente ortogonal a essa pergunta.

— Jukka K. Korpela
fonte

1

A primeira parte da sua resposta não é necessariamente verdadeira .

— patricksweeney

1

@patricksweeney, acho que é um pouco teórico nesse contexto, mas uma observação correta; resposta atualizada.

— Jukka K. Korpela

Considero que "os navegadores não se importam" como positivos para minha abordagem. Como minhas páginas são parciais (aplicativo de página única), não posso ter a seção <head>, a razão pela qual estou tentando colocar elementos internos <body> ou internos no corpo.

— Saran

2

@ Galaxy, não vejo por que um aplicativo de página única careceria de um headelemento. Uma página HTML sempre tem uma.

— Jukka K. Korpela

@ JukkaK.Korpela, atualizei parte do código na minha pergunta para responder à sua pergunta.

— Saran

6

(Como estamos no SE.SX, uma abordagem mais estratégica pode ser um aumento valioso das considerações técnicas usuais.)

[preâmbulo] A especificação do HTML5 é um alvo em constante movimento e eles têm uma política para acompanhar as práticas comuns estabelecidas. Eles obsoletos e ressuscitaram recursos no passado, mudaram o significado dos outros, mudaram o foco das recomendações metódicas, etc. Não está escrito por toda a eternidade, com toda a sabedoria da humanidade disponível de uma só vez. A especificação não é uma fonte sagrada da verdade. É natural que às vezes os navegadores estejam certos. [/preâmbulo]

A situação do OP é esmagadoramente comum e válida.

Você tem um CMS, com o tema projetado e instalado, todo o CSS carregado corretamente a partir do HEAD, e aí está, o editor de páginas, deixado com uma caixa WYSIWYG moderna que você pode (graças a Deus!) Alternar para o "modo de origem" e digite (cole) na marcação HTML (criada anteriormente em outro lugar, com as ferramentas mais adequadas). Felizmente, você pode até incluir STYLEtags (talvez devido a uma omissão acidental em um filtro de tags) ... O dia é salvo, devido a muito trabalho repetitivo que destrói a alma. Mas você ainda não tem meios de interferir com o elemento HEAD do sistema em um cenário de edição de página.

Isso deve impedir você de usar seu CSS de maneira direta com seus fragmentos HTML, apenas porque a especificação o diz?

Ou você tem um aplicativo AJAX de página única.

Ele está sendo executado sem recarga por uma longa sessão e há conteúdo sindicalizado vindo de várias fontes aleatórias, todas com estilo arbitrário e independente. Exigir que eles sejam primeiro convertidos para usar apenas STYLEatributos inline, em vez de apenas virem com um STYLEelemento incorporado , seria absurdo.

Além disso: você pode: a) já incorporar qualquer CSS em qualquer lugar nos atributos, BODYvia STYLE, para que o CSS seja "teoricamente" legal lá; eb) você já pode fazer o que quiser com praticamente qualquer estilo, sempre que quiser (e muito mais) do Javascript, para que o CSS também já seja possível usar indevidamente de maneiras patologicamente não-performáticas. E nenhum de nós jamais objetaria esses recursos. O W3C também não.

Então, o que exatamente há de tão mau nos STYLEelementos do BODY? Quais são as implicações adversas extras que isso adicionaria ao nosso amplo arsenal de abuso de construções HTML? Mais desempenho ruim? Provavelmente. As vezes.

Esse é um motivo válido para abolir essa prática incrivelmente útil, suportada por todos os navegadores por um motivo? Não em um milhão de milhas!

Nós não somos idiotas. Bem, nem todas, ou nem sempre ...;) Técnicas com risco de baixo desempenho poderiam simplesmente ser documentadas , e não apenas proibidas. Costumávamos ter applets Java nos primeiros dias da Web e sobrevivíamos. Os carros podem ser mal utilizados, causando miséria, até os alimentos podem ser usados de maneiras perturbadoras e ineficientes, e os motoristas que podem comer podem ser, em média, ainda mais estúpidos do que os web designers comuns. Além disso, Prezado W3C, não precisa se preocupar: os rebanhos furiosos de mexilhões em HTML com suas pernas disparadas com STYLEelementos no BODYainda não podem ir atrás do W3C e se vingar. Eles não sabem o endereço. E eles não têm pernas.

Então, por favor: faça sua voz ser ouvida por STYLEse tornar legal BODY! Citar o texto obedientemente, mas não fornecer uma alternativa viável melhor do que a situação atual não ajuda. Na verdade, é uma ameaça para essa técnica de solução alternativa de último recurso.

Lembre-se: a especificação HTML5 é chamada de recomendação .

— lunakid
fonte

Update: as especificações finalmente apanhado: STYLEé agora válido em BODY! ;)

— lunakid 13/03/19

1

Atualização 2: as especificações não foram atualizadas porque mudaram de idéia (clique no link do lunakid, ele foi atualizado).

— Maximillian Laumeister

2

A especificação html afirma que

Um elemento de estilo sem um atributo com escopo restrito a aparecer no cabeçalho do documento.

O atributo com escopo definido é um valor booleano, indicando que deve ser aplicado apenas à subárvore enraizada no elemento pai do elemento de estilo.

No momento, apenas o Firefox suporta o atributo com escopo. http://www.w3schools.com/tags/att_style_scoped.asp

— berço
fonte

5

O site w3schools não deve ser citado como referência, ou de todo; Veja w3fools.com

— Jukka K. Korpela

2

E isso não responde à pergunta.

— Jukka K. Korpela

1

Obrigado @ JukkaK.Korpela, foi o primeiro link que encontrei citando o suporte ao navegador de atributos com escopo definido. O outro comentário fornece uma citação muito melhor. Marque com +1 sua resposta -1 com seus comentários menos construtivos.

— crad

+1 para apontar para a especificação, além de observar a falta de suporte ao escopo (que é necessário para aderir à especificação). Eu acho que você deveria ter lido a resposta antes de pular a arma lá @ JukkaK.Korpela, muito pobre. Você não pode realmente ser mais confiável do que as especificações, e isso responde perfeitamente à pergunta. " Será uma idéia errada ter estilo no corpo " - de acordo com a especificação " Sim, será. "

— Fergus In London

1

Existem algumas razões técnicas para ter seu css em um arquivo x uma tag de estilo:

A capacidade de usar um minificador de css (não acredito que minificadores funcionem em tags de estilo)
Para que o arquivo css possa ser armazenado em cache pelo navegador.

Alguns motivos de opinião para usar um arquivo:

Você pode usar um maravilhoso pré-processador css como Sass (Compass) ou Less.
Você está mantendo duas maneiras de adicionar css ao seu aplicativo.

Minha preferência pessoal é usar o Compass para manter arquivos separados para cada página e depois usá-lo para compilá-los todos em um arquivo. Esse arquivo único seria incluído em todas as páginas. Se, no futuro, os arquivos precisarem ser separados por qualquer motivo, sempre poderão ser, mas, entretanto, não vale a pena.

— reclamar
fonte