Комментарии 68
Хотя я не большой знаток внутренних особенностей работы браузеров, может я просто чего-то не понимаю и реализация проста и тривиальна?
Чем он более дыра, чем <script src="">? Если я правильно понял, то это примерно то же самое, но с возможностью отложенной загрузки и проверкой на дублирование урла.
Потому "пункт 1" так долго и вводили, чтобы рассмотреть максимум аспектов его введения, и безопасность — в первую очередь. В плане менеджмента зависимостей и структуры проекта — это крайне полезное нововведение, особенно если вы используете возможности HTTP/2.
Хотя я не большой знаток внутренних особенностей работы браузеров
То есть в теме не разбираетесь, но главное самым первым комментарием набросить про якобы проблемы производительности и безопасности?
Хорошим вопросом был бы "модульный Javascript позволяет сделать X, как быть с безопасностью?". А абстрактное высказывание
По моему пункт 1 — это потенциальная чудовищная дыра в безопасности
является набросом.
Однако, я более-менее разбираюсь в языках, на которых пишутся движки вроде того же V8, и для меня вполне очевидно, что реализация нового ключевого слова, с такой сложной семантикой как у import это непаханное поле для целого вагона глюков. Опять же, конкретно в код движков браузера я не лез, потому и не писал конкретики. Мне, казалось что изложенных мною предположений вполне достаточно для того, чтобы люди, обладающие большими знаниями на этот счёт их изложили.
В изложенном нет ничего абстрактного, тогда как ваши неуместные «поддевки» это как раз натуральный наброс и не более — по теме ни слова, зато уж желчь льётся как из рога изобилия.
Вы утверждаете что импорт потенциально опасная конструкция, что знаете как это пишется и все такое. Не могу сказать что у меня большой опыт в разработке интерпретируемых языков, но чуть чуть затрагивать приходилось (совсем немного, но тем не менее). И мне вот не кажется что подобная конструкция имеет какие-то опасные моменты.
На первый взгляд выглядит просто как сахар.
Что дает данная фича?
1) скачиваем файл с кодом.
2) парсим его в AST, дальше в код виртуальной машины
3) по отдельной команде добавляем этот код к текущему коду активного «приложения» и инициализируем его, выполняя код из загруженного файла
Теперь с точки зрения безопасности:
1) ну скачиваем и скачиваем. Этот этап вообще старше любого браузера, одна строчка вызова АПИ ядра — не считается.
2) распарс кода, его компиляция в байт-код… Звучит страшно, но по факту это вызов пары команд из стандартного АПИ жс-движка, ведь как-то мы обрабатываем тег скрипт, и ничего
3) Запуск скачанного кода. Извне. Звучит страшно и ужасно. Но… мы постоянно так делаем тегом script. Причем сразу после скачки. И что?
Могу ошибаться, JS не является сильной стороной моих скилсов, может что-то неверно понял, или не знаю нюансов реализации, но чисто с точки зрения человека который «более-менее разбирается в языках, на которых пишутся» интерпретируемые языки я не вижу тут проблем. Поясните мысль?
import defaultExport from "module-name";
import * as name from "module-name";
import { export } from "module-name";
import { export as alias } from "module-name";
import { export1 , export2 } from "module-name";
import { export1 , export2 as alias2 , [...] } from "module-name";
import defaultExport, { export [ , [...] ] } from "module-name";
import defaultExport, * as name from "module-name";
import "module-name";Т.е. на первом этапе нам надо ещё как минимум добавить парсер самого запроса. Собственно, как на мой взгляд, это минимум ещё один модуль с дырами и ошибками, дальше можно и не обсуждать.
Так можно докатиться до того, что любое изменение опасно, давайте ничего не делать.
Новая конструкция которых десятки. Не сложнее любой сущности которых и так сотни и сотни.
Чем оно опаснее чем тоже самое только без него?
Понятно что любой движок это уже не одна тысяча сущностей, только если вот так ради, фактически, синтаксического сахара, добавлять ещё лишние сущности, оно так и будет усложняться до того момента пока не перестанет нормально работать. Это тупиковый путь.
Всегда на последних этапах разработки (пока еще можно) выкидываю порядка 20% функционала (если что-то действительно сложное) исключительно ради KISS.
И если бы вы писали «ой, ну сколько можно все усложнять, и добавлять новые фичи, давайте уже начнем удалять», то я бы наверное даже вас поддержал. Но вы ведь придрались к конкретной фиче сказав что конкретно она опасна. Так что низачет, простите.
Любое не обоснованное изменение действительно опасно.Не обоснованное — да.
Но потребности, реализуемые с помощью модулей — это не какая-то экзотика, они всё равно реализуются разнообразными JS-фреймворками. Вы можете считать «монструозные поделия» «форменной дуростью», но, увы и ах — эта «дурость» продаётся.
Вот очень наглядный пример: есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.
Заметьте — это сказала не «Эллочка-людоедка», не «модный репер», а самый, что ни на есть «гик» обсуждающий тонкости работы Git'а!
А разе это всё равно нужно, то оно — где-то реальзовано. Причём, скорее всего, с большим количеством проблем, что то, что могут сделать разработчики браузеров…
Есть некоторые особенности работы человеческого мозга которые полезны для работы программиста, но вредны для коммуникации с людьми.А можно поподробнее с этого места? Сам программист с довольно большим стажем и стеком технологий, однако частенько мое мнение не стыкуется с мнением большинства, поэтому возникают проблемы с кармой. Однако я все еще считаю, что каждый имеет право на собственное мнение, особенно если оно не нарушает норм этики и морали, иначе люди были бы просто стадом.
1.1) коммуникация между людьми во многом базируется не только на смысле фразы но и на эмоциональном контексте. Зачастую эмоциональный контекст превышает вербальный.
1.2) компьютеры эмоциональный контекст не понимают. Им только вербальное подавай.
1.3) человек который мыслит как компьютер лучше понимает компьютер.
2.1) когда мы говорим на языке который нам знаком слабо, мы упускаем значительный пласт смысла заложенного в коннотациях. Помню когда-то на вопрос о том насколько хорошо я знаю инглиш я ответил very easy поскольку знал что изи это самый легкий уровень в играх, и имел ввиду что могу разговаривать только с легкими, простыми фразами и контекстами. Ну а поняли меня наоборот, потом смеялись.
2.2) люди которые ориентируются на коннотации которых мы не видим (эмоциональный контекст) не «истерички», просто они разговаривают на том языке который нам непонятен или понятен плохо. Мы можем сказать просто то, что подумали, а они услышат еще и то, что мы их не уважаем, что считаем что они говно и вообще! (вообще здесь ключевое).
3.1) несогласие с оппонентом (особенно если оппонент отстаивает «классическое», общепринятое), высказывание критической позиции — по определению несут в себе негативную коннотацию. Мы ее не слышим когда говорим, но «они» ее слышат.
3.2) нам кажется, что мы просто высказываем свое мнение. Им кажется, что мы говорим: Вы все говно, а мы тут такие все в белом.
4.1) Есть определенные органические особенности, например особенности «аутического спектра».
4.2) начиная от синдрома Аспергера
4.3) заканчивая полными Шелдонами
5.1) на самом деле этот список можно продолжать до бесконечности
5.2) но мне лень
5.3) и это не потому что мне на вас плевать
5.4) хотя нет, именно поэтому
5.6) но чтобы вы не обижались, я расскажу вам анекдот
– Сразу на меня кричишь.
– Так я не кричал. Я спокойно говорил.
– Я читала с интонацией. И мне. Твой тон. Не понравился.
А с девушками да, такое дело, говоришь спокойно и размеренно, параллельно любуешься собой, какой ты спокойный и невозмутимый при этом, а преподносится как-будто бы ты на нее наорал :D
Удалены из стандарта
Это нарушит совместимость с предыдущими версиями. Для HTML такое нарушение гораздо хуже, чем для компилируемых ЯП.
Смысл иметь в стандарте фичи, которые реально использовать всё равно нельзя?
Нет никаких старых доктайпов. Браузеры всё равно их игнорируют, и начиная с сабжа вот и авторов начинают отучать от их использования:)
Есть конкретный набор доктайпов (описанный, внезапно, в самом стандарте HTML5), при которых браузер переключается в режим старых глюков (каких именно — в принципе, на усмотрение браузера, но современные браузеры даже в этом пытаются соответствовать этому стандарту). Больше доктайп не влияет ни на что. Не стоит надеяться, например, что при доктайпе HTML4/XHTML1 браузеры внезапно начнут понимать атрибут charoff для таблиц:)
То, что старые валидаторы не ругаются на устаревшие атрибуты при устаревших доктайпах — не показатель. Для браузеров это всё равно будет неправильный HTML5, и хороший валидатор теперь прежде всего ругнётся на неправильный (т.е. не соответствующий реальности) доктайп.
То, что старые валидаторы не ругаются на устаревшие атрибуты при устаревших доктайпах — не показатель.
Не показатель чего?
Для браузеров это всё равно будет неправильный HTML5
Всё же, если браузер неправильно отображает старую страницу, которая раньше отображалась правильно, то неправильный тут всё-таки браузер. А страница — не "неправильный html5" а вообще не html5, а, может быть например, правильный html3.2.
Ну что поделать, нет в мире «правильных браузеров» в таком понимании, а есть реальные браузеры, понимающие один стандарт, известный нам как HTML5 (или просто HTML) и содержащий предписания для браузеров, как вести себя с любой разметкой (даже самой кривой), и советы для авторов, как писать разметку, чтобы она кривой не была. И написанный с максимальным прицелом на совместимость с прошлыми стандартами (в разумных пределах).
Убрали неприжившиеся фичи из той части, которая «для авторов» (т.е. писать так раньше было допустимо, а теперь моветон). Браузеры и дальше будут «понимать» их примерно так, как и раньше понимали реально.
А старые страницы, правильные или нет, браузеры понимали очень по-разному. Отчего авторам и приходилось писать неправильно, но чтоб браузеры поняли одинаково. Из-за этого во многом новый единый стандарт и появился.
А почему вы посчитали «неосновным нововведением» новые правила внутри тега p?
The following constructions are no longer valid HTML:
Inline blocks, inline tables, or floated and positioned block-level elements as children of a p element.
Так хотели стили от разметки отделить и вот опять.
Речь, как я понимаю, о назначении тегов по умолчанию. Понятно, что и тейбл можно инлайном сделать. Но тут по сути говорится о том, что параграф только доя текста, нефиг туда таблицы и оформление пихать. Перед или после — пожалуйста, внутри тега p — нельзя. Логично, чо.
Никак не собираются, это баг:)
Потому что это полная чушь, нелепый баг и результат механической копипасты из описания самого тега. А там добавилась неуклюжая правка из гитхаба, в которой человек неуклюже пытался объяснить (видимо, в первую очередь самому себе), что в этот тег нельзя запихивать т.н. «блочные элементы», даже если их стили изменены на инлайн-что-то. В общем, хотел как лучше подчеркнуть, что стили не влияют на модель содержимого, а получилось как всегда наоборот...
Я уже ходил туда ругаться, надеюсь, в следующей редакции эту чушь уберут:)
P.S. Пожалуйста, перестаньте тянуть в HTML5 деление элементов на «блочные и строчные» из HTML4! Оно не добавляет ясности, лишь вносит путаницу с одноименными понятиями в CSS. Вот и наглядный пример этой путаницы...
Интересно, выкинут ли когда-нибудь самый известный тег <a> и сделают простой и понятный аттрибут href применимый ко всем элементам, типа <div href="./">smth</div>
Так иногда напрягает неоднозначность того где должен находиться тег <a>, то есть надо ли вкладывать <div> в <a>, наоборот, и как надо стилизовать сам тег. Сама по себе ссылка, это именно что аттрибут, такой же, как, например, title или alt.
Вроде и нет никакой необнозначности где он должен находиться. А вот однозначно определить ссылку с ним как раз таки можно.
HTML нужно в принципе полностью перепроектировать исходя из всего того во что он вырос.
Ход мысли я поддерживаю, но таких мест столько, что реально степень совместимости будет такая, что проще писать новый стандарт и не мучатся иллюзией частичной совместимости.
В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологию (а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массы). Есть потуги на WebGL но пока они выглядят мягко говоря не очень.
В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологиюОтважились. Microsoft планировал всех пересадить на XAML и C#. Но… «не шмогла я, не шмогла».
а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массыMicrosoft нетвёрдо стоит на ногах? Я вас умоляю.
Этого недостаточно. Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия. Тогда вы можете «волевым усилием» старую технологию заморозить и заставить всех пользоваться новой. Так как альтернативы нет — то переход состоится. Если же монополия недостаточно жёсткая, то пользователи переползут к конкурентам. Microsoft эту возможность продолбал. Заморозка в 2001м прошла достаточно успешно, но… Longhorn… вместо планируемых 2-3 лет разработка растянулась на 6 лет, да и результат получится таким, что после его выхода люди долго держались за XP. Это дало возможность другим (Firefox, Opera, потом и Google Chrome) выпустить свой вариант, который был лучше и не ломал обратную совместимость.
Сейчас такой монополии ни у кого нет, так что перехода ждать не стоит.
Отважились. Microsoft планировал всех пересадить на XAML и C#. Но… «не шмогла я, не шмогла».Как-то не заметил. Где можно почитать про их попытку? Я от них помню только Silverlight, но это была так себе попытка, у них тогда уже был подпорченный имидж.
Microsoft нетвёрдо стоит на ногах? Я вас умоляю.Ну тут этим не ограничивается, ещё авторитет, а у Microsoft он спорный, только недавно начали отмываться. Ещё я помню было время когда они убивали свои технологии, кому охота переползать на то что возможно потом закопают? Как например было с XNA.
Этого недостаточно. Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия.Монополия это самый простой вариант, но всегда есть вариант идти по обходному пути и заодно проталкивать свою технологию в другие продукты разными способами. В итоге можно создать такую ситуацию что не поддержка технологии = уход пользователей на платформу где технология поддерживается. Естественно технология должна быть желанной и решать многие современные трудности заметно лучше всех прочих альтернатив.
Где можно почитать про их попытку?MSDN не подходит?
Я от них помню только Silverlight, но это была так себе попытка, у них тогда уже был подпорченный имидж.Проблема не в «испорченном имидже». Проблема в GMail'е и Firefox'е. GMail не был первым HTML-приложением, которое обладало «богатым» интерфейсом. Но он был первым популярным приложением, которое показало, что «так тоже можно — и можно не ждать Avalon!». А потому к выходу Silverlight'а уже не было того «вау-эффекта».
Да и не планировал Microsoft выпускать Silverlight! Идея была в том, чтобы сделать то, что было сделано после Windows 10: выпускать новую версию Windows (и встроенную в неё новую версию MS IE!) ежегодно, а XAML и C# встроить в них — так, чтобы у пользователей даже не возникало вопросов: на чём написано приложение. И тогда, поскольку все (ну хорошо — 90%) пользователей используют MS IE с поддержкой «Web Browser Applications» (а разработка DHTML прекращена, не забываем) — разработчики перешли бы на эту новую модель.
Но… не получилось. Вместо этого красивого и светлого будущего появился уродец-Silverlight.
Монополия это самый простой вариант, но всегда есть вариант идти по обходному пути и заодно проталкивать свою технологию в другие продукты разными способами. В итоге можно создать такую ситуацию что не поддержка технологии = уход пользователей на платформу где технология поддерживается. Естественно технология должна быть желанной и решать многие современные трудности заметно лучше всех прочих альтернатив.Пример можно? Потому что примеры техологий, которые полностью контролировались одной фирмой и потому были успешно заменены — я знаю много. Технологий, которые бы не имели кого-то, кто контролировал 90% пользователей и притом заменённых «в плановом порядке» на что-то другое — не могу вспомнить ни одной.
Бывают ситуации, когда вместо одной технологии люди находят 2, 3, 10 других технологий и постепенно так «расползаются» — такое видел. Но чтобы все, дружно, взяли и перешли — не знаю ни одного примера.
MSDN не подходит?Подходит.
Понятно.
Пример можно?С примерами сложно ибо не видел пока прямо удачных компаний.
А так вспоминается: WebExtension, flexbox, CSS Grid, SPDY.
+ о чём уже сказал lexxpavlov
Можно сделать супер-пупер технологию, и к ней 100% работающий транспилер в html. Точно так же все браузеры умеют только js, но всё больше программистов переходят на typescript — потому что удобнее.
Могут и другие преимущества появиться.
Например будучи свободным от обратной совместимости можно значительно повысить семантичность верстки и полноценно отделить оформление от содержимого. Что улучшит понимание роботами (в т.ч. краулерами), увеличит кросплатформенность, например альтернативно-вебовые приложения в телефонах будут пошустрее, и соизмеримы с нативными. Ну и натив для десктопа тоже сразу сюда.
Вариантов много. Все зависит от того какую задачу себе поставит тот, кто решит заменить веб, от того какие проблемы он захочет решать этой альтернативой, и что важнее — насколько хорошо это у него получится.
Ну если бы не закопали XHTML2
Лично я рад что его закопали. Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.
Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.О чём речь?
Да и какое вам до него дело, пользовались бы дальше костыльным HTML5.
Эти два стандарта развивались не мешая друг другу.
Одно в XHTML точно плохо это то что при нём обозреватель не рисует на лету разметку и пока документ не догрузится до конца страница не отобразится, отчего на больших страницах при плохой связности это большая проблема.
XHTML2 вероятно бы эту модель унаследовал, но в целом XHTML2 заметно чище и продуманнее, он мог бы дать толчок к очистке от груза всех остальных устаревших технологий и архитектурных ошибок. Тем более учитывая куда идёт веб (одностраничные веб-приложения), эта особенность XHTML уже не столь ощутима.
О том, что задачу пытаются впихнуть в рамки какого-то "инструмента" общего назначения (не говоря уже о том, что этот "инструмент" сам по себе плохой).
Парсер html хотят убрать и вставить вместо него парсер xml. Но xml-парсеры не знают о том, что тег <br> одиночный — давайте им в угоду его изуродуем в <br />. Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника — ничего, подождёте пока страница догрузится, инет ведь быстрый. Не надо таких "оптимизаций".
Не раз видел аналогичные истоиии (но в локальном масштабе): а вот у нас тут супер модная технология, давайте её внедрим. Правда она не поддерживает некоторые удобные фичи (которые у нас УЖЕ есть), придётся их убрать, но это всё мелочи.
тег <br> одиночный — давайте им в угоду его изуродуем в <br />
И это хорошо и правильно! Явное лучше неявного, если тег одиночный — значит его и нужно записывать как одиночный, а не ходить в справочники заглядывать, какой же он. Всегда пишу <br/> и в HTML5 тоже, ибо нефиг.
Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника
Не знаю, что там у браузеров, но когда я работал с xml-парсерами несколько лет назад, у меня всё прекрасно инкрементально парсилось. Надуманные проблемы какие-то, XHTML рулит, жаль что он умер в угоду говнокодерам
ходить в справочники заглядывать
Зачем? Если вам важен смысл этого тега то и так и так придётся узнавать о нём. Если вы его просто где-то увидели случайно — игнорируйте и его и его закрывающий вариант, как будто он там не написан (как и делают браузеры с неизвестными тегами).
у меня всё прекрасно инкрементально парсилось
Ну вот EvilFox утверждал обратное по сути, я ему поверил. Может быть это не проблема самого парсера а проблема его интеграции в браузер, но сути это не меняет.
А зачем усложнять-то синтаксис? Сейчас синтаксис вида <тег> может иметь аж ТРИ разных значения: самозакрывающийся тег (<br/>), открытие тега (<div>) или открытие тега с закрытием предыдущего тега (<p>1<p>2 эквивалентно <p>1</p><p>2</p>). Нахрена это всё, когда можно просто считать <тег> открытием тега и не мудрить мозги ни себе, ни разработчикам парсеров?
Кстати, с вот этим вот <p><p> связана ещё одна подстава: многие пишут что-то вроде <p>1<blockquote>2</blockquote>3</p>, но это парсится как <p>1</p><blockquote>2</blockquote><p>3</p>, отчего могут отвалиться некоторые CSS-селекторы — это одна из вещей, которая бесит меня больше всего в HTML. Здесь приходится неизбежно запасаться справочниками и зубрить все теги наизусть. На этом даже разработчики адмики Django попадались (в одной из версий заменили-таки все <p> на <div>).
Алсо, если бы браузеры вместо попыток исправить ошибки кривых исходников отказывались отображать сайт, как это было с XHTML — интернет сильно похорошел бы.
Но чертова обратная совместимость…
Вспомните сколько воя и нытья было когда вышел пхп7.
Причем основной вой был за конструкторы!
Прочие несовместимости людьми воспринимались более-менее терпимо, но самый громкий вой был за конструкторы-пхп4-стайл.
Для меня это было откровением. Я был уверен что в в 5.0 их сделали депрекейтет и где-то к 5.3-5.4 выпилили.
Но нет, на момент альфы семерки было еще полно софта который использовал данные конструкции.
Да и сейчас бы использовали, даже в новом коде, ведь «учебников», «уроков» и прочих статеек с примерами кода в сети полно.
С HTML тут еще хуже. Есть ведь огромное количество софта который на вот это вот всё заточен. Всякие редакторы (включая библиотеки конвертации бб-кодов) и куча всего.
Да, вы оставите обратную совместимость «временно». Но пока оно работает, и нет жестких сроков когда закончат, то кто будет переучиваться?
Нет, можно палкой загонять, как браузеры загоняют в https.
Но ради пары мелких корявостей так напрягаться никто не будет.
Так что придется тащить оба стандарта с собой «вечно».
А значит выигрыша от более «чистого» формата не будет.
Вот и отказались.
Строго говоря, в HTML5 синтакисис вида <тег> как раз и имеет одно значние — открытие тега. Остальной «мудрёж головы» — правила построения дерева в зависимости от стека открытых тегов, включенные в единственный и единый для всех стандарт для парсеров. А вот у синтаксиса вида <тег/> бывает-таки три РАЗНЫХ значения — честный самозакрывающий XML-тег (напр., для SVG-элементов типа <use/>), открывающий тег с разрешенным лишним символов (пресловутая «имитация самозакрытия» для одиночных тегов, для совместимости с XHTML), и открывающий тег с ошибкой в виде лишнего атрибута (напр. <div/> — лишь незакрытый тег с ошибкой).
Если бы браузеры не следовали правилу Постела и отказывались отображать страницы с малейшей невеллформностью (т.е. любые страницы с оборвавшейся загрузкой, любые страницы, по которым прошлась не очень умелая баннерорезка — в середине 00-х этим любил злоупотреблять Agnitum Outpost, и т.д.), интернет, безусловно, был бы прекраснее. Как классическая музыка по сравнению с эстрадой. И его популярность — а следовательно, и «денежность» отрасли — была бы соответствующей..:)
Всё-таки имхо чаще приходится работать с уже отпарсенной и построенной DOM, чем парсить неизвестную разметку в чем-то кроме браузера (поисковики и т.п., конечно, важная ниша, но всё-таки ниша). И в DOM важнее предсказуемость и однозначность (например, что td всегда будет 4-м потомком table, а не либо 3-м, либо 4-м по прихоти кодера), пусть даже парсеру для этого придётся «попотеть» чуть больше. В конце концов, в SGML с его уймой вариантов, где тоже злополучный слеш мог заменять закрывающий тег в одиночку, было ещё хуже..:)
Пока что его, наоборот, вкинули ещё и в SVG:)
использования тега style внутри body;
Давно мучает вопрос, осталась ли еще какае-то практическая польза от элемента head, вероятно в нем должна была содержаться метаинформация и контент не должен отображаться на странице, однако контент выводится, и хотя формально link нельзя использовать в body, браузеры его обрабатывают и иногда возможность вставить стили непосредственно перед выводом компонента необходима чтобы избежать подгрузки этих стилей на всех страницах.
Да в общем-то не осталась, вот такая страница абсолютно валидна:
<!DOCTYPE html>
<meta charset="utf-8" />
<title>yo</title>
<link rel="stylesheet" href="style.css" />
<div>yo</div>Её и не было. Это всегда было семантическим выделением группы тегов, не рисующих ничего не странице, для удобства тех кто их пишет/читает (людей, не браузера). Браузеры его всегда, вроде бы, игнорировали, так же как и <html> и <body> (но не игнорировали аргументы этих тегов).
Коротко об HTML 5.2