Sarà un'idea sbagliata avere <style> in <body>?

12

Nel codice seguente ho inserito un foglio di stile interno con tag body, anziché avere in testa. Per un'applicazione a pagina singola sto considerando di farlo per stili applicabili solo a quella pagina, anziché avere un file pagespecific.css separato.

C'è uno scenario in cui questo ha il rovescio della medaglia in quanto non sto mettendo lo stesso nella sezione principale?

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

Un styleelemento all'interno bodydell'elemento viola le regole di sintassi HTML. (Tranne che secondo le bozze HTML5, è consentito in alcune condizioni, se gli scopedattributi sono presenti; questo attributo è supportato da alcuni browser.) D'altra parte, ai browser non importa. La divisione in heade gli bodyelementi è teorica.

Tuttavia, non ottieni nulla utilizzando la sintassi non valida, al contrario del posizionamento styleall'interno head. L'unica scusa sarebbero le limitazioni tecniche, in alcuni ambienti di authoring, che potrebbero impedire di inserire qualcosa nella headparte.

Il problema dell'utilizzo di un styleelemento rispetto a un foglio di stile esterno linkè completamente ortogonale a questa domanda.

— Jukka K. Korpela
fonte

1

La prima parte della tua risposta non è necessariamente vera .

— patricksweeney,

1

@patricksweeney, penso che sia un po 'teorico in questo contesto, ma un'osservazione corretta; risposta aggiornata.

— Jukka K. Korpela,

Prendo "browser non importa" come positivo per il mio approccio. Dato che le mie pagine sono parziali (Applicazione a pagina singola), non posso avere la sezione <head>, il motivo per cui sto cercando di inserire <body> o elementi interni nel corpo.

— Saran,

2

@Galaxy, non vedo perché un'applicazione a pagina singola manchi di un headelemento. Una pagina HTML ne ha sempre una.

— Jukka K. Korpela,

@ JukkaK.Korpela, ho aggiornato la parte del codice nella mia domanda per rispondere alla tua domanda.

— Saran,

6

(Dal momento che siamo qui a SE.SX, un approccio più strategico può essere un valido potenziamento delle solite considerazioni tecniche.)

[preambolo] Le specifiche HTML5 sono un obiettivo in continuo movimento e hanno una politica da seguire su prassi comuni consolidate. Hanno obsoleto e resuscitato le caratteristiche del passato, hanno cambiato il significato degli altri, spostato il focus delle raccomandazioni metodiche ecc. Non è scritto per l'eternità con tutta la saggezza dell'umanità disponibile tutto in una volta. Le specifiche non sono una fonte sacra di verità. È naturale che a volte i browser abbiano ragione. [/preambolo]

La situazione di OP è straordinariamente comune e valida.

Hai un CMS, con il suo tema progettato e installato, tutto il CSS caricato correttamente da HEAD, quindi eccoti, l'editor di pagine, lasciato con un elegante box WYSIWYG che puoi (grazie a Dio!) Passare alla "modalità sorgente" e digitare (incolla) nel markup HTML (precedentemente realizzato altrove, con strumenti più adatti). Fortunatamente puoi anche includere i STYLEtag (forse a causa di un'omissione fortuita in un filtro tag) ... Il giorno è salvato, da un sacco di ripetitivi lavori grugniti che distruggono l'anima. Ma non hai ancora alcun mezzo per interferire con l'elemento HEAD del sistema da uno scenario di modifica della pagina.

Questo dovrebbe strapparti dall'uso del CSS in modo semplice con i tuoi frammenti HTML, solo perché lo dice la specifica?

Oppure, hai un'applicazione AJAX a pagina singola.

Funziona senza ricaricare per una lunga sessione e ci sono contenuti sindacati provenienti da varie fonti casuali, tutte in stile arbitrario e indipendente. Richiedere che vengano prima convertiti per usare solo gli STYLEattributi inline invece di venire semplicemente con un STYLEelemento incorporato sarebbe assurdo.

Inoltre: è possibile a) incorporare già qualsiasi CSS in qualsiasi punto BODY, tramite STYLEattributi, quindi CSS è "teoricamente" legale lì comunque; e b) puoi già fare quello che vuoi con qualsiasi stile, ogni volta che vuoi (e altro) da Javascript, quindi CSS è già possibile abusare in modi patologicamente non performanti. E nessuno di noi avrebbe mai contestato quelle caratteristiche. Né il W3C.

Quindi, che cosa è esattamente così male riguardo agli STYLEelementi nel BODY? Quali sono quelle implicazioni extra avverse che aggiungerebbe al nostro ampio arsenale di abusi ai costrutti HTML? Prestazioni più scadenti? Probabilmente. Qualche volta.

È un motivo valido per abolire questa pratica incredibilmente utile, supportata da ogni browser per un motivo? Non tra un milione di miglia!

Non siamo idioti. Bene, non tutte, o non sempre ...;) Le tecniche con il rischio di scarse prestazioni potrebbero essere semplicemente documentate , piuttosto che vietate. Avevamo applet Java nei primi giorni del web e sopravvivevamo. Le auto possono essere utilizzate in modo improprio, causando miseria, persino il cibo può essere utilizzato in modi inquietanti e inefficienti e i conducenti che possono mangiare possono essere, in media, anche più stupidi del web designer medio. Inoltre, Caro W3C, non c'è bisogno di preoccuparsi: le mandrie arrabbiate di armeggi HTML che hanno le gambe sparate con STYLEelementi nell'ancora BODYnon possono andare dopo il W3C e vendicarsi. Non conoscono l'indirizzo. E non hanno gambe.

Quindi, per favore: fai sentire la tua voce per STYLEdiventare legale BODY! Citare obbedientemente il testo, ma non riuscire a fornire una valida alternativa migliore della situazione attuale non è di alcun aiuto. In realtà è una minaccia a questa tecnica alternativa di ultima istanza.

Ricorda: le specifiche HTML5 sono chiamate raccomandazioni .

— lunakid
fonte

Aggiornamento: le specifiche finalmente raggiunte: oraSTYLE è valido in BODY! ;)

— lunakid,

1

Aggiornamento 2: le specifiche non sono state raggiunte perché hanno cambiato idea (fai clic sul link lunakid, è stato aggiornato).

— Maximillian Laumeister

2

Le specifiche HTML Stati che

Un elemento di stile senza un attributo con ambito è limitato alla visualizzazione nell'intestazione del documento.

L'attributo con ambito è un valore booleano che indica che dovrebbe essere applicato solo al sottoalbero radicato nell'elemento padre dell'elemento stile.

Al momento solo Firefox supporta l'attributo con ambito. http://www.w3schools.com/tags/att_style_scoped.asp

— CRAD
fonte

5

Il sito w3schools non dovrebbe essere citato come riferimento o affatto; vedi w3fools.com

— Jukka K. Korpela,

2

E questo non risponde alla domanda.

— Jukka K. Korpela,

1

Grazie @ JukkaK.Korpela è stato il primo link che ho trovato citando il supporto del browser degli attributi con ambito. L'altro commento fornisce una citazione molto migliore. +1 la tua risposta -1 i tuoi commenti meno che costruttivi.

— crad

+1 per indicare la specifica e notare la mancanza di supporto per l'ambito (che è necessario per aderire alla specifica). Penso che avresti dovuto leggere la risposta prima di saltare la pistola lì @ JukkaK.Korpela, molto povera. Non puoi davvero diventare più affidabile delle specifiche e risponde perfettamente alla domanda. " Sarà un'idea sbagliata avere stile nel corpo " - secondo le specifiche " Sì lo sarà ".

— Fergus A Londra,

1

Ci sono alcuni motivi tecnici per avere il tuo CSS in un file vs un tag di stile:

La possibilità di utilizzare un minificatore CSS (non credo che i minificatori funzionino sui tag di stile)
Per avere il file CSS in grado di essere memorizzato nella cache dal browser.

Alcuni motivi basati sull'opinione per usare un file:

Puoi usare un meraviglioso preprocessore CSS come Sass (Compass) o Less.
Stai mantenendo due modi per aggiungere CSS alla tua applicazione.

La mia preferenza personale è usare Compass per mantenere file separati per ogni pagina e poi usarlo per compilarli tutti in un unico file. Quel singolo file verrebbe incluso in ogni pagina. Se lungo la strada i file devono essere separati per qualsiasi motivo possano sempre essere, ma non vale la pena nel frattempo.

— pllee
fonte