В связи с тем, что 14.12.2017 года W3C в блоге объявила о выходе новой редакции HTML 5, предлагаю Вашему вниманию краткое описания основных нововведений.
Новации
Поддержка модульного JavaScript
На мой взгляд, самая интересная и ожидаемая новация связана с поддержкой модульного синтаксиса последнего стандарта ECMA Script.
Использование будет происходить следующим образом:
<script type="module"> import { app } from './app'; app.run(); </script>
Для того, что бы обеспечить загрузку каждого импортируемого скрипта не более одного раза на документ или web воркер, реализована коллекция (module map), которая будет содержать ссылочные записи с одним из следующих значений:
— непосредственно модульный скрипт (module script);
— null, используемых для индикации неудавшихся загрузок;
— fetching -временный плейсхолдер.
Путь к файлу будет сначала пропущен через Парсер ссылки (URL parser), корректные значения будут использованы для разрешения пути. Повторяющиеся пути будут проигнорированы.
Следует отметить, что если путь начинается не с символов "/", "./" или "../" будет возвращена ошибка. Это обусловлено планируемым в будущем внедрением «голого» импорта.
Отдельно следует учесть, что некорректный MIME type, в отличие от обычных скриптов, в отношении модульного скрипта будет ошибкой.
Элемент <dialog>
Тэг <dialog> определяет окно или контейнер, предназначенный для создания всплывающих и модальных окон. Кроме стандартных html атрибутов, данному тегу будет доступен один булиевый атрибут open сообщающий о том, является ли элемент активным и доступным пользователю для взаимодействия. В качестве JavaScript объекта <dialog>, кроме стандартных свойст и методов, получил свойства:
— open — геттер/сеттер — активен ли элемент;
— returnValue — геттер/сеттер — значение возвращаемое элементом,
а также методы:
— close() — закрывает элемент;
-open() — показывает элемент;
-showModal() показывает элемент и делает его модальным элементов верхнего уровня.
Атрибут nonce для <link>
Элемент <link> получил атрибут nonce, представляющий собой криптографический nonce («специально для данного случая»), который может быть использован для определения будет ли внешний ресурс указанный в <link> загружен и применен к документу.
Элемент <iframe>
Элемент <iframe> получил сразу два изменения, новый атрибут allowpaymentrequest для интеграции с Payment Request API и новое значение для атрибута sandbox для интеграции с Presentation API.
Удалены из стандарта
- элементы <keygen>, <menu> и <menuitem>;
- атрибут inputmode для текстовых <input>, и dropzone атрибутов;
- метод showModalDialog.
Валидным с точки зрения стандарта стало
- использования тега <style> внутри <body>;
- — множественные <main> элементы в ДОМе, при условии, что только один видим для пользователя;
- презентации для <img>;
- пустой <option> для <datalist>.
Более не соответствует стандарту
- role у элемента <caption>;
- строгий HTML4 или XHTML1 Doctype.
Подробнее об изменениях можно почитать в параграфе Changes рекомендаций W3C.
Комментарии (59)
third112
24.12.2017 08:32Удалены из стандарта
Это нарушит совместимость с предыдущими версиями. Для HTML такое нарушение гораздо хуже, чем для компилируемых ЯП.khim
24.12.2017 09:19Они были реализованы в очень небольшом количестве браузеров. Keygen — это вообще седая древность, кажется нигде, кроме Netscape 4.x он полноценно и не поддерживался, menu — поддерживает только Firefox, inputmode вообще нигде не поддерживается (в Firefox есть флаг, но он по умолчанию выключен), showModalDialog — тоже уже давно забыт.
Смысл иметь в стандарте фичи, которые реально использовать всё равно нельзя?
aliencash
24.12.2017 10:55Удаление из стандарта не означает, что поддержка моментально выпиливается из браузера. А в старых и не обновляемых версиях браузеров — все и подавно останется по прежнему.
Temtaime
24.12.2017 16:43Плюс, на сколько мне известно, это коснётся только нового доктайпа. В старых всё будет по старому.
SelenIT3
25.12.2017 15:04Нет никаких старых доктайпов. Браузеры всё равно их игнорируют, и начиная с сабжа вот и авторов начинают отучать от их использования:)
Temtaime
25.12.2017 18:49То-то смена доктайпа приводит иногда к разъезжанию сайта.
SelenIT3
25.12.2017 19:30+1Есть конкретный набор доктайпов (описанный, внезапно, в самом стандарте HTML5), при которых браузер переключается в режим старых глюков (каких именно — в принципе, на усмотрение браузера, но современные браузеры даже в этом пытаются соответствовать этому стандарту). Больше доктайп не влияет ни на что. Не стоит надеяться, например, что при доктайпе HTML4/XHTML1 браузеры внезапно начнут понимать атрибут charoff для таблиц:)
То, что старые валидаторы не ругаются на устаревшие атрибуты при устаревших доктайпах — не показатель. Для браузеров это всё равно будет неправильный HTML5, и хороший валидатор теперь прежде всего ругнётся на неправильный (т.е. не соответствующий реальности) доктайп.
firk
25.12.2017 22:10То, что старые валидаторы не ругаются на устаревшие атрибуты при устаревших доктайпах — не показатель.
Не показатель чего?
Для браузеров это всё равно будет неправильный HTML5
Всё же, если браузер неправильно отображает старую страницу, которая раньше отображалась правильно, то неправильный тут всё-таки браузер. А страница — не "неправильный html5" а вообще не html5, а, может быть например, правильный html3.2.
SelenIT3
25.12.2017 22:40Ну что поделать, нет в мире «правильных браузеров» в таком понимании, а есть реальные браузеры, понимающие один стандарт, известный нам как HTML5 (или просто HTML) и содержащий предписания для браузеров, как вести себя с любой разметкой (даже самой кривой), и советы для авторов, как писать разметку, чтобы она кривой не была. И написанный с максимальным прицелом на совместимость с прошлыми стандартами (в разумных пределах).
Убрали неприжившиеся фичи из той части, которая «для авторов» (т.е. писать так раньше было допустимо, а теперь моветон). Браузеры и дальше будут «понимать» их примерно так, как и раньше понимали реально.
А старые страницы, правильные или нет, браузеры понимали очень по-разному. Отчего авторам и приходилось писать неправильно, но чтоб браузеры поняли одинаково. Из-за этого во многом новый единый стандарт и появился.
BekoBou
24.12.2017 08:51А почему вы посчитали «неосновным нововведением» новые правила внутри тега
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.
everyonesdesign
24.12.2017 12:22Что-то я не понял, как они по инлайн-блокам собираются HTML валидировать. Это же просто оформление, нет? Странно.
Так хотели стили от разметки отделить и вот опять.
4orever
24.12.2017 15:53Речь, как я понимаю, о назначении тегов по умолчанию. Понятно, что и тейбл можно инлайном сделать. Но тут по сути говорится о том, что параграф только доя текста, нефиг туда таблицы и оформление пихать. Перед или после — пожалуйста, внутри тега p — нельзя. Логично, чо.
SelenIT3
25.12.2017 15:18Потому что это полная чушь, нелепый баг и результат механической копипасты из описания самого тега. А там добавилась неуклюжая правка из гитхаба, в которой человек неуклюже пытался объяснить (видимо, в первую очередь самому себе), что в этот тег нельзя запихивать т.н. «блочные элементы», даже если их стили изменены на инлайн-что-то. В общем, хотел
как лучшеподчеркнуть, что стили не влияют на модель содержимого, а получилоськак всегданаоборот...
Я уже ходил туда ругаться, надеюсь, в следующей редакции эту чушь уберут:)
P.S. Пожалуйста, перестаньте тянуть в HTML5 деление элементов на «блочные и строчные» из HTML4! Оно не добавляет ясности, лишь вносит путаницу с одноименными понятиями в CSS. Вот и наглядный пример этой путаницы...
Reey
24.12.2017 13:06Интересно, выкинут ли когда-нибудь самый известный тег
<a>и сделают простой и понятный аттрибутhrefприменимый ко всем элементам, типа<div href="./">smth</div>
Так иногда напрягает неоднозначность того где должен находиться тег<a>, то есть надо ли вкладывать<div>в<a>, наоборот, и как надо стилизовать сам тег. Сама по себе ссылка, это именно что аттрибут, такой же, как, например,titleилиalt.
Akuma
24.12.2017 13:26Зачем это нужно?
Вроде и нет никакой необнозначности где он должен находиться. А вот однозначно определить ссылку с ним как раз таки можно.
Mendel
24.12.2017 14:25Никогда не выкинут.
HTML нужно в принципе полностью перепроектировать исходя из всего того во что он вырос.
Ход мысли я поддерживаю, но таких мест столько, что реально степень совместимости будет такая, что проще писать новый стандарт и не мучатся иллюзией частичной совместимости.
EvilFox
24.12.2017 16:40Ну если бы не закопали XHTML2 то это бы уже было, но его закопали в угоду HTML5.
В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологию (а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массы). Есть потуги на WebGL но пока они выглядят мягко говоря не очень.khim
24.12.2017 17:08В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологию
Отважились. Microsoft планировал всех пересадить на XAML и C#. Но… «не шмогла я, не шмогла».
а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массы
Microsoft нетвёрдо стоит на ногах? Я вас умоляю.
Этого недостаточно. Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия. Тогда вы можете «волевым усилием» старую технологию заморозить и заставить всех пользоваться новой. Так как альтернативы нет — то переход состоится. Если же монополия недостаточно жёсткая, то пользователи переползут к конкурентам. Microsoft эту возможность продолбал. Заморозка в 2001м прошла достаточно успешно, но… Longhorn… вместо планируемых 2-3 лет разработка растянулась на 6 лет, да и результат получится таким, что после его выхода люди долго держались за XP. Это дало возможность другим (Firefox, Opera, потом и Google Chrome) выпустить свой вариант, который был лучше и не ломал обратную совместимость.
Сейчас такой монополии ни у кого нет, так что перехода ждать не стоит.EvilFox
24.12.2017 17:30Отважились. Microsoft планировал всех пересадить на XAML и C#. Но… «не шмогла я, не шмогла».
Как-то не заметил. Где можно почитать про их попытку? Я от них помню только Silverlight, но это была так себе попытка, у них тогда уже был подпорченный имидж.
Microsoft нетвёрдо стоит на ногах? Я вас умоляю.
Ну тут этим не ограничивается, ещё авторитет, а у Microsoft он спорный, только недавно начали отмываться. Ещё я помню было время когда они убивали свои технологии, кому охота переползать на то что возможно потом закопают? Как например было с XNA.
Этого недостаточно. Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия.
Монополия это самый простой вариант, но всегда есть вариант идти по обходному пути и заодно проталкивать свою технологию в другие продукты разными способами. В итоге можно создать такую ситуацию что не поддержка технологии = уход пользователей на платформу где технология поддерживается. Естественно технология должна быть желанной и решать многие современные трудности заметно лучше всех прочих альтернатив.khim
24.12.2017 19:12Где можно почитать про их попытку?
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 других технологий и постепенно так «расползаются» — такое видел. Но чтобы все, дружно, взяли и перешли — не знаю ни одного примера.EvilFox
24.12.2017 20:55MSDN не подходит?
Подходит.
Понятно.
Пример можно?
С примерами сложно ибо не видел пока прямо удачных компаний.
А так вспоминается: WebExtension, flexbox, CSS Grid, SPDY.
+ о чём уже сказал lexxpavlov
lexxpavlov
24.12.2017 19:07>Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия
Можно сделать супер-пупер технологию, и к ней 100% работающий транспилер в html. Точно так же все браузеры умеют только js, но всё больше программистов переходят на typescript — потому что удобнее.khim
24.12.2017 19:15Не могу сказать, что это в принципе невозможно, но… маловероятно: если оно будет 100% транспилиться в HTML, то за счёт чего будет выигрыш? Почему люди перейдут на одну технологию, а не на 10 разных?
Mendel
25.12.2017 10:52Ну например писать на ней будет удобнее, плюс будут некоторые дополнительные фичи которые работают только в родном клиенте, при этом не слишком критичные, чтобы без них работа в браузере была чем-то ущемлена (незначительная деградация «красоты», падение скорости в сравнению с нативным клиентом).
Могут и другие преимущества появиться.
Например будучи свободным от обратной совместимости можно значительно повысить семантичность верстки и полноценно отделить оформление от содержимого. Что улучшит понимание роботами (в т.ч. краулерами), увеличит кросплатформенность, например альтернативно-вебовые приложения в телефонах будут пошустрее, и соизмеримы с нативными. Ну и натив для десктопа тоже сразу сюда.
Вариантов много. Все зависит от того какую задачу себе поставит тот, кто решит заменить веб, от того какие проблемы он захочет решать этой альтернативой, и что важнее — насколько хорошо это у него получится.
firk
24.12.2017 17:22Ну если бы не закопали XHTML2
Лично я рад что его закопали. Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.
EvilFox
24.12.2017 18:01Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.
О чём речь?
Да и какое вам до него дело, пользовались бы дальше костыльным HTML5.
Эти два стандарта развивались не мешая друг другу.
Одно в XHTML точно плохо это то что при нём обозреватель не рисует на лету разметку и пока документ не догрузится до конца страница не отобразится, отчего на больших страницах при плохой связности это большая проблема.
XHTML2 вероятно бы эту модель унаследовал, но в целом XHTML2 заметно чище и продуманнее, он мог бы дать толчок к очистке от груза всех остальных устаревших технологий и архитектурных ошибок. Тем более учитывая куда идёт веб (одностраничные веб-приложения), эта особенность XHTML уже не столь ощутима.firk
24.12.2017 19:38О том, что задачу пытаются впихнуть в рамки какого-то "инструмента" общего назначения (не говоря уже о том, что этот "инструмент" сам по себе плохой).
Парсер html хотят убрать и вставить вместо него парсер xml. Но xml-парсеры не знают о том, что тег <br> одиночный — давайте им в угоду его изуродуем в <br />. Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника — ничего, подождёте пока страница догрузится, инет ведь быстрый. Не надо таких "оптимизаций".
Не раз видел аналогичные истоиии (но в локальном масштабе): а вот у нас тут супер модная технология, давайте её внедрим. Правда она не поддерживает некоторые удобные фичи (которые у нас УЖЕ есть), придётся их убрать, но это всё мелочи.
andreymal
24.12.2017 19:56+1тег <br> одиночный — давайте им в угоду его изуродуем в <br />
И это хорошо и правильно! Явное лучше неявного, если тег одиночный — значит его и нужно записывать как одиночный, а не ходить в справочники заглядывать, какой же он. Всегда пишу <br/> и в HTML5 тоже, ибо нефиг.
Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника
Не знаю, что там у браузеров, но когда я работал с xml-парсерами несколько лет назад, у меня всё прекрасно инкрементально парсилось. Надуманные проблемы какие-то, XHTML рулит, жаль что он умер в угоду говнокодерам
firk
24.12.2017 22:42ходить в справочники заглядывать
Зачем? Если вам важен смысл этого тега то и так и так придётся узнавать о нём. Если вы его просто где-то увидели случайно — игнорируйте и его и его закрывающий вариант, как будто он там не написан (как и делают браузеры с неизвестными тегами).
у меня всё прекрасно инкрементально парсилось
Ну вот EvilFox утверждал обратное по сути, я ему поверил. Может быть это не проблема самого парсера а проблема его интеграции в браузер, но сути это не меняет.
andreymal
24.12.2017 22:50А зачем усложнять-то синтаксис? Сейчас синтаксис вида
<тег>может иметь аж ТРИ разных значения: самозакрывающийся тег (<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 — интернет сильно похорошел бы.
Mendel
25.12.2017 11:08в идеальном сферическом мире я бы с Вами безапеляционно согласился.
Но чертова обратная совместимость…
Вспомните сколько воя и нытья было когда вышел пхп7.
Причем основной вой был за конструкторы!
Прочие несовместимости людьми воспринимались более-менее терпимо, но самый громкий вой был за конструкторы-пхп4-стайл.
Для меня это было откровением. Я был уверен что в в 5.0 их сделали депрекейтет и где-то к 5.3-5.4 выпилили.
Но нет, на момент альфы семерки было еще полно софта который использовал данные конструкции.
Да и сейчас бы использовали, даже в новом коде, ведь «учебников», «уроков» и прочих статеек с примерами кода в сети полно.
С HTML тут еще хуже. Есть ведь огромное количество софта который на вот это вот всё заточен. Всякие редакторы (включая библиотеки конвертации бб-кодов) и куча всего.
Да, вы оставите обратную совместимость «временно». Но пока оно работает, и нет жестких сроков когда закончат, то кто будет переучиваться?
Нет, можно палкой загонять, как браузеры загоняют в https.
Но ради пары мелких корявостей так напрягаться никто не будет.
Так что придется тащить оба стандарта с собой «вечно».
А значит выигрыша от более «чистого» формата не будет.
Вот и отказались.
SelenIT3
26.12.2017 20:33+1Строго говоря, в HTML5 синтакисис вида
<тег>как раз и имеет одно значние — открытие тега. Остальной «мудрёж головы» — правила построения дерева в зависимости от стека открытых тегов, включенные в единственный и единый для всех стандарт для парсеров. А вот у синтаксиса вида<тег/>бывает-таки три РАЗНЫХ значения — честный самозакрывающий XML-тег (напр., для SVG-элементов типа<use/>), открывающий тег с разрешенным лишним символов (пресловутая «имитация самозакрытия» для одиночных тегов, для совместимости с XHTML), и открывающий тег с ошибкой в виде лишнего атрибута (напр.<div/>— лишь незакрытый тег с ошибкой).
Если бы браузеры не следовали правилу Постела и отказывались отображать страницы с малейшей невеллформностью (т.е. любые страницы с оборвавшейся загрузкой, любые страницы, по которым прошлась не очень умелая баннерорезка — в середине 00-х этим любил злоупотреблять Agnitum Outpost, и т.д.), интернет, безусловно, был бы прекраснее. Как классическая музыка по сравнению с эстрадой. И его популярность — а следовательно, и «денежность» отрасли — была бы соответствующей..:)
0xd34df00d
26.12.2017 23:42Ну вот EvilFox утверждал обратное по сути, я ему поверил. Может быть это не проблема самого парсера а проблема его интеграции в браузер, но сути это не меняет.
Не знаю, какие там проблемы. Берёте SAX-парсер и получаете то же поведение, как при инкрементальном парсинге HTML.
SelenIT3
27.12.2017 01:02ЕМНИП, баг в Firefox 2- был такой. В 3-м пофиксили, но у довольно многих «остался осадочек» разочарования в XML-могуществе...
0xd34df00d
26.12.2017 23:41Зато парсить html5 — так себе удовольствие.
И что важнее, экономия ресурса клавиши
/или возможность более-менее адекватно работать с документом в (полу)автоматическом режиме (там где-то маячит semantic web ещё, но опустим это), мне вот сходу неочевидно. Мне лично хочется сказать, что второе важнее, потому что парсить HTML-странички мне приходится бесконечно чаще, чем их писать, но именно поэтому мой пример не сказать чтоб релевантен.SelenIT3
27.12.2017 00:56Всё-таки имхо чаще приходится работать с уже отпарсенной и построенной DOM, чем парсить неизвестную разметку в чем-то кроме браузера (поисковики и т.п., конечно, важная ниша, но всё-таки ниша). И в DOM важнее предсказуемость и однозначность (например, что td всегда будет 4-м потомком table, а не либо 3-м, либо 4-м по прихоти кодера), пусть даже парсеру для этого придётся «попотеть» чуть больше. В конце концов, в SGML с его уймой вариантов, где тоже злополучный слеш мог заменять закрывающий тег в одиночку, было ещё хуже..:)
Aingis
24.12.2017 18:41А зачем? В тегах
<a>...</a>можно заключать всё что угодно кроме других ссылок и активных элементов вроде кнопок или инпутов. Оформлять можно тоже как угодно (но лучше не забыть блочное представлениеdisplay: block, если есть блочные потомки). Не вижу никакой проблемы. Кроме того, с точки зрения семантики лучше, когда есть отдельный элемент, чем менять её через атрибут.
Psychosynthesis
По моему пункт 1 — это потенциальная чудовищная дыра в безопасности, которая, насколько я понимаю реализацию, помимо этого ещё и тормозов должна прибавить. Так ли это надо было?
Хотя я не большой знаток внутренних особенностей работы браузеров, может я просто чего-то не понимаю и реализация проста и тривиальна?
firk
Чем он более дыра, чем <script src="">? Если я правильно понял, то это примерно то же самое, но с возможностью отложенной загрузки и проверкой на дублирование урла.
Psychosynthesis
Не уверен. Вопрос в реализации
import { app }i360u
Потому "пункт 1" так долго и вводили, чтобы рассмотреть максимум аспектов его введения, и безопасность — в первую очередь. В плане менеджмента зависимостей и структуры проекта — это крайне полезное нововведение, особенно если вы используете возможности HTTP/2.
justboris
То есть в теме не разбираетесь, но главное самым первым комментарием набросить про якобы проблемы производительности и безопасности?
Psychosynthesis
Я вообще-то вопрос задал. Если у вас есть идеи для чего ещё нужны комменты, можете их изложить, а я послушаю. Потому что покамест набрасываете тут вы один.
andrew911
Вообще-то в первом абзаце утверждение. А потом почему-то вопрос
Psychosynthesis
Что, два связанных предложения это уже слишком сложно для вас?
justboris
Хорошим вопросом был бы "модульный Javascript позволяет сделать X, как быть с безопасностью?". А абстрактное высказывание
является набросом.
Psychosynthesis
Я понятия не имею что позволяет «модульный Javascript», поскольку считаю монструозные поделия, которые сейчас городят на фронтендах на JS, форменной дуростью. Но, заметьте, своего мнения на этот счёт я никому не навязываю.
Однако, я более-менее разбираюсь в языках, на которых пишутся движки вроде того же V8, и для меня вполне очевидно, что реализация нового ключевого слова, с такой сложной семантикой как у import это непаханное поле для целого вагона глюков. Опять же, конкретно в код движков браузера я не лез, потому и не писал конкретики. Мне, казалось что изложенных мною предположений вполне достаточно для того, чтобы люди, обладающие большими знаниями на этот счёт их изложили.
В изложенном нет ничего абстрактного, тогда как ваши неуместные «поддевки» это как раз натуральный наброс и не более — по теме ни слова, зато уж желчь льётся как из рога изобилия.
Mendel
Есть некоторые особенности работы человеческого мозга которые полезны для работы программиста, но вредны для коммуникации с людьми. Допустим вы действительно просто плохо выразились, так что давайте закончим это препирание и продолжим дальше дискуссию без эмоций.
Вы утверждаете что импорт потенциально опасная конструкция, что знаете как это пишется и все такое. Не могу сказать что у меня большой опыт в разработке интерпретируемых языков, но чуть чуть затрагивать приходилось (совсем немного, но тем не менее). И мне вот не кажется что подобная конструкция имеет какие-то опасные моменты.
На первый взгляд выглядит просто как сахар.
Что дает данная фича?
1) скачиваем файл с кодом.
2) парсим его в AST, дальше в код виртуальной машины
3) по отдельной команде добавляем этот код к текущему коду активного «приложения» и инициализируем его, выполняя код из загруженного файла
Теперь с точки зрения безопасности:
1) ну скачиваем и скачиваем. Этот этап вообще старше любого браузера, одна строчка вызова АПИ ядра — не считается.
2) распарс кода, его компиляция в байт-код… Звучит страшно, но по факту это вызов пары команд из стандартного АПИ жс-движка, ведь как-то мы обрабатываем тег скрипт, и ничего
3) Запуск скачанного кода. Извне. Звучит страшно и ужасно. Но… мы постоянно так делаем тегом script. Причем сразу после скачки. И что?
Могу ошибаться, JS не является сильной стороной моих скилсов, может что-то неверно понял, или не знаю нюансов реализации, но чисто с точки зрения человека который «более-менее разбирается в языках, на которых пишутся» интерпретируемые языки я не вижу тут проблем. Поясните мысль?
Psychosynthesis
Ну, начнём с того, что import это не просто «скачиваем файл с кодом», это целая команда со своим синтаксисом:
Т.е. на первом этапе нам надо ещё как минимум добавить парсер самого запроса. Собственно, как на мой взгляд, это минимум ещё один модуль с дырами и ошибками, дальше можно и не обсуждать.
Mendel
Ну целая тут команда или половинка это несерьезно.
Так можно докатиться до того, что любое изменение опасно, давайте ничего не делать.
Новая конструкция которых десятки. Не сложнее любой сущности которых и так сотни и сотни.
Чем оно опаснее чем тоже самое только без него?
Psychosynthesis
Любое не обоснованное изменение действительно опасно.
Понятно что любой движок это уже не одна тысяча сущностей, только если вот так ради, фактически, синтаксического сахара, добавлять ещё лишние сущности, оно так и будет усложняться до того момента пока не перестанет нормально работать. Это тупиковый путь.
Mendel
Ну я большой сторонник упрощения.
Всегда на последних этапах разработки (пока еще можно) выкидываю порядка 20% функционала (если что-то действительно сложное) исключительно ради KISS.
И если бы вы писали «ой, ну сколько можно все усложнять, и добавлять новые фичи, давайте уже начнем удалять», то я бы наверное даже вас поддержал. Но вы ведь придрались к конкретной фиче сказав что конкретно она опасна. Так что низачет, простите.
khim
Но потребности, реализуемые с помощью модулей — это не какая-то экзотика, они всё равно реализуются разнообразными JS-фреймворками. Вы можете считать «монструозные поделия» «форменной дуростью», но, увы и ах — эта «дурость» продаётся.
Вот очень наглядный пример: есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.
Заметьте — это сказала не «Эллочка-людоедка», не «модный репер», а самый, что ни на есть «гик» обсуждающий тонкости работы Git'а!
А разе это всё равно нужно, то оно — где-то реальзовано. Причём, скорее всего, с большим количеством проблем, что то, что могут сделать разработчики браузеров…
Acuna