1. casa
  2. Domanda e risposta
  3. tag di stile e di script nel corpo HTML ... perché no?

tag di stile e di script nel corpo HTML ... perché no?

2009-09-01 11 views
43

[Questo è legato al this question, ma non perché non si tratta di e-mail.]tag di stile e di script nel corpo HTML ... perché no?

In molti casi - soprattutto quando si lavora con un CMS o qualcun quadro di un altro, è molto più facile da incorporare <style> tag e <script> tag nello <body> rispetto allo <head>. Questo sembra funzionare in IE6, IE7 (Windows), Firefox 3.xe Safari (OS X).

A rigor di termini, è sbagliato? E se lo è, quali conseguenze negative potrebbe causare ... oltre ad essere completamente ignorato in alcuni clienti?

Nota: Felice di voler parlare di stili ASCIUTTI e centralizzati. Immagina per un secondo che voglio usare i tag di stile all'interno di un documento perché NON SONO GLOBALI e che NON HO ACCESSO ALLA TESTA SU UNA BASE PER-PAGINA. Per qualsiasi ragione, sia che il sito differisca su base pagina per pagina, o in base al paragrafo o qualsiasi altra cosa. Non mi interessa che sia difficile rintracciare e cambiare. Sono preoccupato per le possibili conseguenze dell'uso dello stile nel corpo.

Si centralizza ciò che è centrale. Tutto il resto è gonfio nei fogli di lavoro centrali.

fonte

2009-09-01 Dan Rosenstark

+1

Vedere http://stackoverflow.com/questions/1213281/does-javascript-have-to-be-in-the-head-tags – Gumbo

risposta

26

Anche se le specifiche esplicitamente tag di stile statali non sono ammessi nel tag body, le specifiche non sono tutto ciò che conta. I tag di stile sono supportati nel corpo da tutti i principali browser, e questo è in definitiva il modo in cui gli utenti vedono il tuo sito. * Anche se c'è da tempo una spinta verso standard migliori e supporto agli standard nel settore dei browser, c'è anche da tempo una spinta generale per renderizzare documenti così come possono essere.

Google, che guida l'impegno con le specifiche HTML5, mantiene contemporaneamente google.com che viola le specifiche per salvare byte, lasciando le virgolette fuori dai valori degli attributi, utilizzando gli hack dei selettori contro le specifiche CSS, inclusi i tag di script senza tipo o lingua e link tag senza tipo. Un purista potrebbe obiettare che uno dei siti più utilizzati su Internet sta violando le specifiche e rischia seriamente di essere orribilmente tradito. Oppure, possiamo ragione che nessun browser entrerà nell'uso popolare che non può rendere questi hack largamente usati sulle specifiche.

Quindi, la domanda è più in che modo l'industria del browser sta andando - che è ancora una delle due specifiche migliori, ma anche facendo del proprio meglio per onorare l'intento delle pagine che violano tali specifiche. La mia scommessa è che i tag di stile continueranno a funzionare nel corpo per molto tempo a venire.

* Al momento della stesura, i tag di stile nel corpo sono supportati con un doctype HTML5 in Firefox 3+, IE6 +, Safari 2+, Chrome 12+. Il supporto probabilmente torna più indietro, ma quei browser sono raramente visti sul web.

fonte

2012-06-12 01:53:39

+7

Mentre sono d'accordo, questa è la risposta più pertinente, penso che valga la pena sottolineare che le quotazioni sono facoltative su tutti gli attributi purché il valore non contenga spazi bianchi/caratteri non validi. – Sleavely

+0

Buon punto: le specifiche prev non lo permettevano. Ci sono voluti un sacco di scavi (perché aspettano fino alla Sezione 8 per definire cosa sia un attributo?), Ma qui è nelle specifiche: http://www.w3.org/html/wg/drafts/html/ master/syntax.html # non quotato Significato che anche nelle specifiche ora questo è perfettamente legale: –

+1

Le specifiche precedenti lo consentivano, solo non XHTML: [W3 spiega le differenze tra XHTML1 e HTML4] (http://www.w3.org/TR/xhtml1/diffs.html#h-4.4) – Sleavely

15

I contesti in cui è possibile utilizzare i tag <script> e <style> dipendono dal doctype che si sta utilizzando. Per esempio, io suppone che si sta utilizzando il DOCTYPE HTML5:

<!DOCTYPE html>

Il script tag ha tre contesti sotto il DOCTYPE HTML5:

  1. in cui è previsto metadata content.
  2. Dove è previsto phrasing content.
  3. Dove sono previsti script-supporting elements.

Il style tag ha una leggermente più complicato contesto struttura sotto il doctype HTML5:

  1. Se il scoped attribute è assente: dove è previsto metadata content.
  2. Se lo scoped attribute è assente: in un elemento noscript figlio di un elemento head.
  3. Se è presente lo scoped attribute: dove è previsto flow content, ma prima di qualsiasi altro contenuto di flusso diverso da spazi vuoti tra elementi e elementi di stile, e non come figlio di un elemento il cui modello di contenuto è trasparente.

In sostanza, questo indica che è possibile posizionare il tag di stile e il tag di script nel corpo, poiché il corpo è il punto in cui posizioniamo il contenuto del flusso e il contenuto di frasi.

Come sempre, consultare le specifiche per il doctype che si sta utilizzando.

fonte

2009-09-01 11:50:05 Sampson

2

Bene, avete il problema di incorporare direttamente stili e script nei vostri contenuti. Il mantra principale qui è il principio DRY (Do not Repeat Yourself). Puoi usare uno script o uno stile particolare in più posti.Quando lo stile o lo script richiedono modifiche, ora puoi andare in una caccia al tesoro per tutti i luoghi in cui esiste quel codice. Mantenere i tuoi stili e script in un posto comune è l'ideale.

D'altra parte, se si tratta di un problema di stile minore (pixel spinto o qualcosa relativo a quella sola vista), probabilmente è ok.

fonte

2009-09-01 11:53:02 Scott

+1

true, ovviamente stiamo parlando di one-off. Le cose che sono usate in più di un posto sono centralizzate. –

0

Il problema più grande, a mio parere, è la convenienza. Se si desidera modificare lo stile di una pagina, è molto più semplice farlo se tutte le informazioni sullo stile e sullo script si trovano in un'area. È possibile che le informazioni di stile/script siano in un nodo <style>, nell'attributo style di un nodo (ad esempio <body style='...'>) o in un file esterno (ad esempio <link rel='stylesheet' type='text/css' href='style.css' />). È molto più facile usare una posizione coerente piuttosto che cercare di dare la caccia a tutti i luoghi in cui potrebbe verificarsi uno stile.

E 'anche interessante notare che dicendo, "oltre ad essere completamente ignorato in alcuni clienti" è simile a dire "a parte che esplode quando lo ha colpito da dietro" o "parte di volare fuori-corso e l'atterraggio in un quartiere civile ". Questo è già abbastanza grave da giustificare l'utilizzo della pratica standard.

fonte

2009-09-01 11:57:09 Imagist

+0

Non sono d'accordo, ri: ultimo punto. HTML e CSS sono così imprevedibili, IMO, che se non conosco un determinato cliente, ignorare il mio stile potrebbe essere molto più sicuro che rispettarlo in un modo sconosciuto. –

1

Ma perché dovresti avere style -tags nel corpo? Gli stili sono comunque globali, quindi non riesco a trovare alcun motivo logico per farlo.

Per semplificare e separare le cose, è necessario utilizzare anche fogli di stile esterni.

Gli script sono consentiti e sono disponibili per un motivo: potrebbero fornire output, devono essere eseguiti in orari specifici e altri motivi.

fonte

2009-09-01 11:57:10

+1

Alcuni sviluppatori MVC caricano fogli di stile specifici nel contenuto delle loro viste, che possono essere posizionati da qualche parte nel mezzo di un modello, e quindi nel corpo. – Sampson

+1

Quindi è necessario inserire tutto in un unico foglio di stile (o un set di fogli di stile) che è sempre incluso o generare un foglio di stile a seconda della vista in cui ci si trova. Se hai bisogno di fogli di stile separati per ogni vista, hai appena frainteso uno dei principi di base del CSS. È sempre stato fatto con un (i) foglio (i) fisso (i): perché non è possibile farlo ora? –

+1

Dovremmo limitare questa conversazione a se puoi farlo o no, penso. Potrei, a un certo punto, avere stili particolari che NON sono globali ma piuttosto su base per paragrafo o per pagina.L'uso dello stile è in qualche modo più leggibile rispetto all'utilizzo dell'attributo style = "". –

9

La risposta breve:

La risposta dettagliata:

STYLE è definito per essere in head.misc:

<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK|OBJECT" -- repeatable head elements -->

ed elementi di head.misc sono ammessi solo di essere figli della HEAD elemento. Quindi STYLE è l'unico elemento figlio dell'elemento HEAD.

SCRIPT è definito per essere in head.misc e in special:

<!ENTITY % special 
    "A | IMG | OBJECT | BR | SCRIPT | MAP | Q | SUB | SUP | SPAN | BDO">

E speciale è definito come in inline:

<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; | %formctrl;">

Inoltre SCRIPT è anche permesso di essere figlio dell'elemento BODY.Quindi SCRIPT è consentito nell'elemento HEAD, ovunque sia in linea in linea.

fonte

2009-09-01 12:21:39 Gumbo

+0

quindi cosa significa che la maggior parte dei browser viene analizzata nel corpo? Che non dovrebbe essere usato comunque? –

+0

@yar: Sì, non fa parte dello standard e quindi non dovrebbe essere usato sebbene possa funzionare nella maggior parte dei browser. – Gumbo

+0

Nota questa risposta fa riferimento alla specifica HTML4 mentre @ Sampson fa riferimento alle specifiche HTML5 --- quindi le piccole differenze. –

3

Due risposte possibili per lo stile nel corpo:

  1. Usa styling in linea. È vero, perderai i vantaggi dello stile interno ed esterno, ma se non hai accesso all'intestazione, non avrai accesso all'intestazione.

  2. Utilizzare l'attributo con ambito nell'elemento di stile. Questo è nuovo per HTML5, ma l'idea è di limitare l'ambito del CSS a una parte di una pagina, ad esempio a un singolo div. La cattiva notizia è che non è ancora supportata (a partire da luglio 2011), né è retrocompatibile. Ma c'è (presumibilmente) un plugin JQuery che può aiutare. Per maggiori informazioni:

fonte

2011-07-15 13:40:06

+0

+1 futuro! –

+0

Stavo piangendo quando ho visto "L'attributo è stato rimosso dalle specifiche attuali" - vedi http://caniuse.com/#search=scoped - quindi apparentemente non saranno introdotte ufficialmente in tempi brevi. ANCORA, dal momento che ogni browser si stava preparando per questo a venire, è perfettamente sicuro usare i tag