Чи буде неправильною ідеєю мати <style> в <body>?

12

Внизу коду я розмістив внутрішній аркуш стилю з тегом body, а не в голові. Для програми з однією сторінкою я вважаю це зробити для стилів, застосовних лише до цієї сторінки, а не для того, щоб мати окремий файл pagespecific.css.

Чи є сценарій, коли це має зворотний бік, оскільки я не ставлю те саме в головному розділі?

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

— Саран
джерело

18

styleЕлемент всередині bodyелемента порушує HTML синтаксис правил. (За винятком того, що згідно з проектами HTML5 це дозволено в деяких умовах, якщо scopedатрибути є; цей атрибут підтримується деякими браузерами.) З іншого боку, браузери не хвилюються. Розподіл на headі bodyелементи є теоретичним.

Тим не менш, ви нічого не отримуєте, використовуючи недійсний синтаксис, як протилежне розміщенню styleвсередині head. Єдиним приводом можуть бути технічні обмеження в деяких авторських середовищах, які можуть заважати вам нічого не вносити в цю headчастину.

Проблема використання styleелемента проти зовнішньої таблиці стилів linkє повністю ортогональною для цього питання.

— Юкка К. Корпела
джерело

1

Перша частина вашої відповіді не обов'язково відповідає дійсності .

— patricksweeney

1

@patricksweeney, я думаю, що це дещо теоретично в цьому контексті, але правильне спостереження; відповідь оновлена.

— Jukka K. Korpela

Я вважаю, що "браузери не хвилюються" як позитив для мого підходу. Оскільки мої сторінки є частковими (Single-Page-Application), я не можу мати розділ <head>, тому я намагаюся вкласти тело <body> або всередині тіла.

— Саран

2

@Galaxy, я не бачу, чому в додатку для однієї сторінки не буде headелемента. Сторінка HTML завжди має її.

— Юкка К. Корпела

@ JukkaK.Korpela, я оновив кодову частину свого запитання, щоб відповісти на ваше запитання.

— Саран

6

(Оскільки ми тут у SE.SX, більш стратегічний підхід може бути цінним доповненням до звичайних технічних міркувань.)

[преамбула] Специфікація HTML5 - це ціль, що постійно рухається, і вони мають політику подальшого контролю за усталеною загальною практикою. Вони застаріли і воскресили риси в минулому, змінили значення інших, змінили фокус методичних рекомендацій і т. Д. Це не написано на вічність з усією мудрістю людства, доступною всім відразу. Специфікація не є священним джерелом істини. Цілком природно, що іноді браузери мають рацію. [/ преамбула]

Ситуація в ОП надзвичайно поширена і справедлива.

У вас є CMS з розробленою та встановленою темою, всі CSS завантажуються належним чином з HEAD, тоді ви, редактор сторінки, залишені модною коробкою WYSIWYG, за допомогою якої ви можете (слава Богу!) Перейти у "вихідний режим" та введіть (вставте) у розмітку HTML (раніше створений в іншому місці, з більш підходящими інструментами). На щастя, ви навіть можете включити STYLEтеги (можливо, через неоднозначне упущення у фільтр тегів) ... День врятується від безлічі повторюваних бурхливих робіт, що руйнують душу. Але у вас все ще немає ніяких засобів втручатися в елемент HEAD системи за сценарієм редагування сторінки.

Чи повинно це позбавити вас від прямого використання CSS з фрагментами HTML, лише тому, що специфікація так говорить?

Або у вас є односторінковий додаток AJAX.

Він працює без перезавантаження протягом тривалого сеансу, і є синдикований вміст, що надходить з різних випадкових джерел, усі вони довільно та незалежно стилізовані. Вимагати їх першої конверсії використовувати лише вбудовані STYLEатрибути замість того, щоб просто надходити із вбудованим STYLEелементом, було б абсурдом.

Більше того: ви можете: а) вже вбудовувати будь-який CSS в будь-яку точку за BODYдопомогою STYLEатрибутів, тому CSS в будь-якому випадку "теоретично" легальний; і б) ви вже можете робити все, що завгодно, з будь-яким стилем, коли завгодно (і більше) з Javascript, тому CSS також вже можна неправильно використовувати в патологічно неефективних способах. І ніхто з нас ніколи не буде заперечувати проти цих рис. Також не W3C.

Отже, що саме такого зла в STYLEелементах BODY? Які ті додаткові несприятливі наслідки вони могли б додати до нашого широкого арсеналу зловживань конструкціями HTML? Більш низька продуктивність? Мабуть. Іноді.

Це вагома причина скасувати цю неймовірно корисну практику, яку підтримує кожен браузер чомусь? Не в мільйон миль!

Ми не ідіоти. Ну, не всі, чи не завжди ...;) Техніки з ризиком поганої роботи можуть бути просто задокументовані , а не просто заборонені. Раніше у нас в Інтернеті були аплети Java, і вижили. Автомобілі можуть зловживати, викликаючи нещастя, навіть їжу можна вживати в тривожні, неефективні способи, а водії, які їдять, можуть бути в середньому навіть дурнішими, ніж середній веб-дизайнер. Крім того, Шановний W3C, не потрібно хвилюватися: озлоблені стада металошукачів, що мають ноги, відбиті STYLEелементами, BODYвсе ще не можуть піти за W3C і помститися. Вони не знають адреси. І ніг у них немає.

Отже, будь ласка: зробіть так, щоб ваш голос був почутий за те, щоб STYLEстати законним BODY! Покірно цитуючи текст, але якщо не забезпечити життєздатну альтернативу, яка краща, ніж нинішня ситуація, не допоможе. Це насправді загроза цій методиці останнього вирішення проблеми.

Пам'ятайте: специфікація HTML5 називається рекомендацією .

— лунакід
джерело

Оновлення: специфікації , нарешті , наздогнали: STYLEв даний діє в BODY! ;)

— лунакід

1

Оновлення 2: Технічні характеристики не наздогнали, оскільки вони передумали (натисніть на посилання lunakid, воно було оновлено).

— Maximillian Laumeister

2

Специфікація html стверджує, що

Елемент стилю без обмеженого атрибута обмежується появою в заголовку документа.

Атрибут scoped є булевим значенням, яке вказує на те, що його слід застосовувати лише до піддерева, вкоріненого в батьківському елементі стилю.

На даний момент лише Firefox підтримує атрибут масштабу. http://www.w3schools.com/tags/att_style_scoped.asp

— колиска
джерело

5

Сайт w3schools не повинен цитуватися як посилання або взагалі; дивіться w3fools.com

— Jukka K. Korpela

2

І це не відповідає на питання.

— Юкка К. Корпела

1

Дякуємо @ JukkaK.Korpela, це було перше посилання, яке я знайшов, посилаючись на підтримку браузера атрибутів з атрибутами. Інший коментар забезпечує набагато кращу цитування. Ставте +1 своєю відповіддю -1 ваші менш ніж конструктивні коментарі.

— crad

+1 для вказівки на специфікацію, а також за відсутності підтримки для проведення масштабування (яка необхідна для дотримання специфікації). Я думаю, ви повинні прочитати відповідь, перш ніж стрибати з пістолета @ JukkaK.Korpela, дуже бідно. Ви дійсно не можете отримати більше довіри, ніж специфікація, і це прекрасно відповідає на питання. " Чи буде неправильною ідеєю мати стиль у тілі " - згідно зі специфікацією " Так, так буде ".

— Фергюс в Лондоні

1

Існує кілька технічних причин того, що ваш css у файлі та тезі стилю:

Можливість використовувати міні-інструмент css (я не вірю, що міні-фіфірми працюють над тегами стилів)
Щоб браузер міг кешувати файл css.

Деякі причини на основі думки використовувати файл:

Ви можете використовувати прекрасний препроцесор css, як Sass (Compass) або Less.
Ви підтримуєте два способи додати css до своєї програми.

Мої особисті переваги - використовувати компас для зберігання окремих файлів для кожної сторінки, а потім використовувати їх для компіляції всіх в один файл. Цей єдиний файл буде включений до кожної сторінки. Якщо вниз по дорозі файли потрібно відокремлювати з будь-якої причини, якою вони завжди можуть бути, але тим часом не варто клопотуватися.

— заклик
джерело