Czy źle będzie mieć <style> w <body>?

12

W poniższym kodzie umieściłem wewnętrzny arkusz stylów ze znacznikiem w treści, zamiast mieć w głowie. W przypadku aplikacji do pojedynczej strony rozważam zrobienie tego dla stylów, które dotyczą tylko samej strony, zamiast posiadania osobnego pliku pagespecific.css.

Czy istnieje scenariusz, w którym ma to wadę, ponieważ nie umieszczam tego samego w nagłówku?

<!-- 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
źródło

18

styleElementem wewnątrz bodyelementu narusza zasady składnia HTML. (Z wyjątkiem tego, że zgodnie z wersjami roboczymi HTML5 jest dozwolone w niektórych warunkach, jeśli scopedatrybuty są obecne; ten atrybut jest obsługiwany przez niektóre przeglądarki). Z drugiej strony, przeglądarki nie dbają o to. Podział na headi bodyelementy jest teoretyczny.

Jednak nic nie zyskujesz, stosując niepoprawną składnię, w przeciwieństwie do umieszczania w styleśrodku head. Jedynym usprawiedliwieniem są ograniczenia techniczne w niektórych środowiskach tworzenia treści, które mogą uniemożliwić włożenie czegokolwiek w tę headczęść.

Kwestia używania styleelementu w porównaniu do zewnętrznego arkusza stylów za pośrednictwem linkjest całkowicie ortogonalna w stosunku do tego pytania.

— Jukka K. Korpela
źródło

1

Pierwsza część twojej odpowiedzi niekoniecznie jest prawdą .

— patricksweeney

1

@patricksweeney, myślę, że w tym kontekście jest to trochę teoretyczne, ale poprawna obserwacja; odpowiedź zaktualizowana.

— Jukka K. Korpela

Uważam, że „przeglądarki nie przejmują się” jako pozytywne dla mojego podejścia. Ponieważ moje strony są stronniczymi (aplikacja pojedynczej strony), nie mogę mieć sekcji <head>, dlatego próbuję umieścić wewnątrz <body> lub elementów wewnątrz ciała.

— Saran

2

@Galaxy, nie rozumiem, dlaczego na jednostronicowej aplikacji brakuje headelementu. Strona HTML zawsze ją ma.

— Jukka K. Korpela

@ JukkaK.Korpela, zaktualizowałem część kodu w moim pytaniu, aby odpowiedzieć na twoje pytanie.

— Saran

6

(Ponieważ jesteśmy tutaj w SE.SX, bardziej strategiczne podejście może być cennym uzupełnieniem zwykłych względów technicznych.)

[preambuła] Specyfikacja HTML5 jest ciągle zmieniającym się celem i mają one politykę, którą należy podjąć w związku z ustaloną powszechną praktyką. Przestarzałe i wskrzeszone cechy w przeszłości, zmieniły znaczenie innych, przestawiły się na zalecenia metodyczne itp. Nie jest napisane na całą wieczność, z całą mądrością ludzkości dostępną jednocześnie. Specyfikacja nie jest świętym źródłem prawdy. To naturalne, że czasami przeglądarki mają rację. [/preambuła]

Sytuacja OP jest przeważnie powszechna i ważna.

Masz CMS, z jego motywem zaprojektowanym i zainstalowanym, cały CSS załadowany poprawnie z HEAD, a potem jesteś, edytor stron, pozostawiony z modnym pudełkiem WYSIWYG, które możesz (dzięki Bogu!) Przełączyć na „tryb źródłowy” i wpisz (wklej) w znacznikach HTML (wcześniej spreparowanych gdzie indziej, z bardziej odpowiednimi narzędziami). Na szczęście możesz nawet dołączyć STYLEtagi (być może z powodu nieoczekiwanego pominięcia w filtrze tagów) ... Dzień jest uratowany, od wielu powtarzalnych, niszczących duszę chrząknięć. Ale nadal nie masz możliwości ingerowania w element HEAD systemu w scenariuszu edycji strony.

Czy powinno to pozbawić cię możliwości korzystania z CSS w prosty sposób z fragmentami HTML, tylko dlatego, że specyfikacja tak mówi?

Lub masz jednostronicową aplikację AJAX.

Działa bez przeładowywania przez długą sesję, a zawartość syndykowana pochodzi z różnych losowych źródeł, wszystkie dowolnie i niezależnie. Wymaganie, aby je najpierw przekonwertować, aby używały tylko STYLEatrybutów wbudowanych, zamiast samego STYLEelementu osadzonego , byłoby absurdalne.

Co więcej: możesz: a) już osadzić dowolny CSS w dowolnym miejscu BODY, poprzez STYLEatrybuty, więc CSS jest i tak „teoretycznie” legalny; i b) możesz już robić, co chcesz, z dowolnym stylem, kiedy tylko chcesz (i więcej) z Javascript, więc CSS jest już możliwe do niewłaściwego użycia w sposób patologicznie nieskuteczny. I nikt z nas nigdy nie sprzeciwiłby się tym cechom. Podobnie jest z W3C.

Więc co dokładnie jest takiego złego STYLEw elementach BODY? Jakie są te dodatkowe niekorzystne implikacje, które dodałoby to do naszego szerokiego arsenału nadużyć wobec konstrukcji HTML? Więcej słabej wydajności? Prawdopodobnie. Czasami.

Czy to uzasadniony powód do zniesienia tej niezwykle przydatnej praktyki, obsługiwanej przez każdą przeglądarkę z jakiegoś powodu? Nie za milion mil!

Nie jesteśmy idiotami. Cóż, nie wszystkie lub nie zawsze ...;) Techniki z ryzykiem słabej wydajności można po prostu udokumentować , a nie po prostu zabronić. Kiedyś mieliśmy aplety Java we wczesnych dniach Internetu i przetrwaliśmy. Samochody mogą być niewłaściwie wykorzystywane, powodując nieszczęście, a nawet żywność może być wykorzystywana w niepokojący, nieefektywny sposób, a kierowcy, którzy mogą jeść, mogą być średnio nawet bardziej głupi niż przeciętny projektant stron internetowych. Poza tym, Drogi W3C, nie musisz się martwić: wściekłe stada majsterkowiczów HTML, których nogi zostały postrzelone z STYLEelementami BODYwciąż nie mogą pójść za W3C i zemścić się. Nie znają adresu. I nie mają nóg.

Więc proszę: spraw, aby twój głos został usłyszany za STYLElegalność BODY! Posłuszne cytowanie tekstu, ale nie przedstawienie realnej alternatywy lepszej niż obecna sytuacja, nie jest pomocne. W rzeczywistości stanowi to zagrożenie dla tej ostatniej metody obejścia.

Pamiętaj: specyfikacja HTML5 nazywa się rekomendacją .

— lunakid
źródło

Aktualizacja: specyfikacje wreszcie nadrobiły zaległości: STYLEjest teraz ważne w BODY! ;)

— lunakid

1

Aktualizacja 2: Specyfikacje nie nadrobiły zaległości, ponieważ zmienili zdanie (kliknij link lunakida, został zaktualizowany).

— Maximillian Laumeister

2

Specyfikacja HTML mówi, że

Element stylu bez atrybutu o zasięgu ogranicza się do pojawienia się w nagłówku dokumentu.

Atrybut o zasięgu jest wartością logiczną wskazującą, że należy go zastosować tylko do poddrzewa zakorzenionego w elemencie nadrzędnym elementu stylu.

W tej chwili tylko Firefox obsługuje atrybut o zasięgu. http://www.w3schools.com/tags/att_style_scoped.asp

— crad
źródło

5

Witryna w3schools nie powinna być cytowana jako odniesienie lub w ogóle; patrz w3fools.com

— Jukka K. Korpela

2

I to nie odpowiada na pytanie.

— Jukka K. Korpela

1

Dzięki @ JukkaK.Korpela był to pierwszy link, który znalazłem, cytując obsługę przeglądarki atrybutów o zasięgu. Drugi komentarz zawiera znacznie lepsze cytowanie. +1 twoja odpowiedź -1 twoje mniej niż konstruktywne komentarze.

— crad

+1 za wskazanie w kierunku specyfikacji oraz zauważenie braku wsparcia dla zakresu (który jest wymagany do przestrzegania specyfikacji). Myślę, że powinieneś przeczytać odpowiedź przed wskoczeniem tam na broń @ JukkaK.Korpela, bardzo biedny. Naprawdę nie można stać się bardziej wiarygodnym niż specyfikacja, a to doskonale odpowiada na pytanie. „ Czy posiadanie stylu w ciele będzie złym pomysłem ” - zgodnie ze specyfikacją „ Tak, będzie ”.

— Fergus In London

1

Istnieje kilka technicznych powodów, dla których Twój plik css znajduje się w pliku w porównaniu ze znacznikiem stylu:

Możliwość użycia minimalizatora css (nie sądzę, że minimizery działają na tagach stylu)
Aby plik css mógł być buforowany przez przeglądarkę.

Niektóre powody, dla których warto użyć pliku:

Możesz użyć wspaniałego preprocesora css, takiego jak Sass (kompas) lub mniej.
Utrzymujesz dwa sposoby dodawania css do swojej aplikacji.

Osobiście wolę używać Kompasu do przechowywania osobnych plików dla każdej strony, a następnie używać go do kompilacji ich wszystkich w jednym pliku. Ten pojedynczy plik byłby zawarty na każdej stronie. Jeśli w przyszłości pliki muszą zostać rozdzielone z jakiegokolwiek powodu, zawsze mogą być, ale tymczasem nie jest to kłopotliwe.

— pllee
źródło