Коротко об HTML 5.2

Уважаемые коллеги, добрый день.

В связи с тем, что 14.12.2017 года W3C в блоге объявила о выходе новой редакции HTML 5, предлагаю Вашему вниманию краткое описания основных нововведений.

Новации


  1. Поддержка модульного JavaScript


    На мой взгляд, самая интересная и ожидаемая новация связана с поддержкой модульного синтаксиса последнего стандарта ECMA Script.

    Использование будет происходить следующим образом:

    <script type="module">
    	import { app } from './app';
    	app.run();
    </script>
    

    Для того, что бы обеспечить загрузку каждого импортируемого скрипта не более одного раза на документ или web воркер, реализована коллекция (module map), которая будет содержать ссылочные записи с одним из следующих значений:

    — непосредственно модульный скрипт (module script);
    — null, используемых для индикации неудавшихся загрузок;
    — fetching -временный плейсхолдер.

    Путь к файлу будет сначала пропущен через Парсер ссылки (URL parser), корректные значения будут использованы для разрешения пути. Повторяющиеся пути будут проигнорированы.

    Следует отметить, что если путь начинается не с символов "/", "./" или "../" будет возвращена ошибка. Это обусловлено планируемым в будущем внедрением «голого» импорта.

    Отдельно следует учесть, что некорректный MIME type, в отличие от обычных скриптов, в отношении модульного скрипта будет ошибкой.
  2. Элемент <dialog>


    Тэг <dialog> определяет окно или контейнер, предназначенный для создания всплывающих и модальных окон. Кроме стандартных html атрибутов, данному тегу будет доступен один булиевый атрибут open сообщающий о том, является ли элемент активным и доступным пользователю для взаимодействия. В качестве JavaScript объекта <dialog>, кроме стандартных свойст и методов, получил свойства:

    — open — геттер/сеттер — активен ли элемент;
    — returnValue — геттер/сеттер — значение возвращаемое элементом,
    а также методы:
    — close() — закрывает элемент;
    -open() — показывает элемент;
    -showModal() показывает элемент и делает его модальным элементов верхнего уровня.
  3. Атрибут nonce для <link>


    Элемент <link> получил атрибут nonce, представляющий собой криптографический nonce («специально для данного случая»), который может быть использован для определения будет ли внешний ресурс указанный в <link> загружен и применен к документу.
  4. Элемент <iframe>


    Элемент <iframe> получил сразу два изменения, новый атрибут allowpaymentrequest для интеграции с Payment Request API и новое значение для атрибута sandbox для интеграции с Presentation API.

Удалены из стандарта


  1. элементы <keygen>, <menu> и <menuitem>;
  2. атрибут inputmode для текстовых <input>, и dropzone атрибутов;
  3. метод showModalDialog.

Валидным с точки зрения стандарта стало


  • использования тега <style> внутри <body>;
  • — множественные <main> элементы в ДОМе, при условии, что только один видим для пользователя;
  • презентации для <img>;
  • пустой <option> для <datalist>.

Более не соответствует стандарту


  • role у элемента <caption>;
  • строгий HTML4 или XHTML1 Doctype.

Подробнее об изменениях можно почитать в параграфе Changes рекомендаций W3C.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 68

    –5
    По моему пункт 1 — это потенциальная чудовищная дыра в безопасности, которая, насколько я понимаю реализацию, помимо этого ещё и тормозов должна прибавить. Так ли это надо было?

    Хотя я не большой знаток внутренних особенностей работы браузеров, может я просто чего-то не понимаю и реализация проста и тривиальна?
      +5

      Чем он более дыра, чем <script src="">? Если я правильно понял, то это примерно то же самое, но с возможностью отложенной загрузки и проверкой на дублирование урла.

        –1
        Не уверен. Вопрос в реализации
        import { app }
        0

        Потому "пункт 1" так долго и вводили, чтобы рассмотреть максимум аспектов его введения, и безопасность — в первую очередь. В плане менеджмента зависимостей и структуры проекта — это крайне полезное нововведение, особенно если вы используете возможности HTTP/2.

          +4
          Хотя я не большой знаток внутренних особенностей работы браузеров

          То есть в теме не разбираетесь, но главное самым первым комментарием набросить про якобы проблемы производительности и безопасности?

            –3
            Я вообще-то вопрос задал. Если у вас есть идеи для чего ещё нужны комменты, можете их изложить, а я послушаю. Потому что покамест набрасываете тут вы один.
              –1
              Вообще-то в первом абзаце утверждение. А потом почему-то вопрос
                –1
                Что, два связанных предложения это уже слишком сложно для вас?
                +1

                Хорошим вопросом был бы "модульный Javascript позволяет сделать X, как быть с безопасностью?". А абстрактное высказывание


                По моему пункт 1 — это потенциальная чудовищная дыра в безопасности

                является набросом.

                  –9
                  Я понятия не имею что позволяет «модульный Javascript», поскольку считаю монструозные поделия, которые сейчас городят на фронтендах на JS, форменной дуростью. Но, заметьте, своего мнения на этот счёт я никому не навязываю.

                  Однако, я более-менее разбираюсь в языках, на которых пишутся движки вроде того же V8, и для меня вполне очевидно, что реализация нового ключевого слова, с такой сложной семантикой как у import это непаханное поле для целого вагона глюков. Опять же, конкретно в код движков браузера я не лез, потому и не писал конкретики. Мне, казалось что изложенных мною предположений вполне достаточно для того, чтобы люди, обладающие большими знаниями на этот счёт их изложили.

                  В изложенном нет ничего абстрактного, тогда как ваши неуместные «поддевки» это как раз натуральный наброс и не более — по теме ни слова, зато уж желчь льётся как из рога изобилия.
                    +2
                    Есть некоторые особенности работы человеческого мозга которые полезны для работы программиста, но вредны для коммуникации с людьми. Допустим вы действительно просто плохо выразились, так что давайте закончим это препирание и продолжим дальше дискуссию без эмоций.

                    Вы утверждаете что импорт потенциально опасная конструкция, что знаете как это пишется и все такое. Не могу сказать что у меня большой опыт в разработке интерпретируемых языков, но чуть чуть затрагивать приходилось (совсем немного, но тем не менее). И мне вот не кажется что подобная конструкция имеет какие-то опасные моменты.
                    На первый взгляд выглядит просто как сахар.
                    Что дает данная фича?
                    1) скачиваем файл с кодом.
                    2) парсим его в AST, дальше в код виртуальной машины
                    3) по отдельной команде добавляем этот код к текущему коду активного «приложения» и инициализируем его, выполняя код из загруженного файла
                    Теперь с точки зрения безопасности:
                    1) ну скачиваем и скачиваем. Этот этап вообще старше любого браузера, одна строчка вызова АПИ ядра — не считается.
                    2) распарс кода, его компиляция в байт-код… Звучит страшно, но по факту это вызов пары команд из стандартного АПИ жс-движка, ведь как-то мы обрабатываем тег скрипт, и ничего
                    3) Запуск скачанного кода. Извне. Звучит страшно и ужасно. Но… мы постоянно так делаем тегом script. Причем сразу после скачки. И что?

                    Могу ошибаться, JS не является сильной стороной моих скилсов, может что-то неверно понял, или не знаю нюансов реализации, но чисто с точки зрения человека который «более-менее разбирается в языках, на которых пишутся» интерпретируемые языки я не вижу тут проблем. Поясните мысль?
                      –3
                      Ну, начнём с того, что import это не просто «скачиваем файл с кодом», это целая команда со своим синтаксисом:
                      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";


                      Т.е. на первом этапе нам надо ещё как минимум добавить парсер самого запроса. Собственно, как на мой взгляд, это минимум ещё один модуль с дырами и ошибками, дальше можно и не обсуждать.
                        +2
                        Ну целая тут команда или половинка это несерьезно.
                        Так можно докатиться до того, что любое изменение опасно, давайте ничего не делать.
                        Новая конструкция которых десятки. Не сложнее любой сущности которых и так сотни и сотни.
                        Чем оно опаснее чем тоже самое только без него?
                          –5
                          Любое не обоснованное изменение действительно опасно.

                          Понятно что любой движок это уже не одна тысяча сущностей, только если вот так ради, фактически, синтаксического сахара, добавлять ещё лишние сущности, оно так и будет усложняться до того момента пока не перестанет нормально работать. Это тупиковый путь.
                            +1
                            Ну я большой сторонник упрощения.
                            Всегда на последних этапах разработки (пока еще можно) выкидываю порядка 20% функционала (если что-то действительно сложное) исключительно ради KISS.
                            И если бы вы писали «ой, ну сколько можно все усложнять, и добавлять новые фичи, давайте уже начнем удалять», то я бы наверное даже вас поддержал. Но вы ведь придрались к конкретной фиче сказав что конкретно она опасна. Так что низачет, простите.
                              –1
                              Любое не обоснованное изменение действительно опасно.
                              Не обоснованное — да.

                              Но потребности, реализуемые с помощью модулей — это не какая-то экзотика, они всё равно реализуются разнообразными JS-фреймворками. Вы можете считать «монструозные поделия» «форменной дуростью», но, увы и ах — эта «дурость» продаётся.

                              Вот очень наглядный пример: есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим.

                              Заметьте — это сказала не «Эллочка-людоедка», не «модный репер», а самый, что ни на есть «гик» обсуждающий тонкости работы Git'а!

                              А разе это всё равно нужно, то оно — где-то реальзовано. Причём, скорее всего, с большим количеством проблем, что то, что могут сделать разработчики браузеров…
                          0
                          Есть некоторые особенности работы человеческого мозга которые полезны для работы программиста, но вредны для коммуникации с людьми.
                          А можно поподробнее с этого места? Сам программист с довольно большим стажем и стеком технологий, однако частенько мое мнение не стыкуется с мнением большинства, поэтому возникают проблемы с кармой. Однако я все еще считаю, что каждый имеет право на собственное мнение, особенно если оно не нарушает норм этики и морали, иначе люди были бы просто стадом.
                            +1
                            На самом деле проблем целый спектр. Я не психиатр и не психолог, так что подробно не объясню, но если совсем по верхам:
                            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) но чтобы вы не обижались, я расскажу вам анекдот
                            – Сразу на меня кричишь.
                            – Так я не кричал. Я спокойно говорил.
                            – Я читала с интонацией. И мне. Твой тон. Не понравился.
                              0
                              Ахаха, ничего себе «лень», накатали такую простыню, еще и по пунктам все разбили. Вот все-таки Хабр еще торт, где еще в обсуждениях можно получить такие ответы?) И да, благодарю, это, пожалуй, многое объясняет, а-то я и думаю, вроде бы рублю правду-матку, не какие-то свои умозаключения, ибо программер, начитанный, все дела, а не какой-то местный юродивый. Да и люди могут быть просто не готовы к тому, что кто-то преподносит им какие-то убеждения, которые они пока не готовы принять, а правду надо аккуратно преподносить)

                              А с девушками да, такое дело, говоришь спокойно и размеренно, параллельно любуешься собой, какой ты спокойный и невозмутимый при этом, а преподносится как-будто бы ты на нее наорал :D
                0
                Удалены из стандарта

                Это нарушит совместимость с предыдущими версиями. Для HTML такое нарушение гораздо хуже, чем для компилируемых ЯП.
                  +3
                  Они были реализованы в очень небольшом количестве браузеров. Keygen — это вообще седая древность, кажется нигде, кроме Netscape 4.x он полноценно и не поддерживался, menu — поддерживает только Firefox, inputmode вообще нигде не поддерживается (в Firefox есть флаг, но он по умолчанию выключен), showModalDialog — тоже уже давно забыт.

                  Смысл иметь в стандарте фичи, которые реально использовать всё равно нельзя?
                    +1
                    Удаление из стандарта не означает, что поддержка моментально выпиливается из браузера. А в старых и не обновляемых версиях браузеров — все и подавно останется по прежнему.
                      +1
                      Плюс, на сколько мне известно, это коснётся только нового доктайпа. В старых всё будет по старому.
                        0

                        Нет никаких старых доктайпов. Браузеры всё равно их игнорируют, и начиная с сабжа вот и авторов начинают отучать от их использования:)

                          0
                          То-то смена доктайпа приводит иногда к разъезжанию сайта.
                            +1

                            Есть конкретный набор доктайпов (описанный, внезапно, в самом стандарте HTML5), при которых браузер переключается в режим старых глюков (каких именно — в принципе, на усмотрение браузера, но современные браузеры даже в этом пытаются соответствовать этому стандарту). Больше доктайп не влияет ни на что. Не стоит надеяться, например, что при доктайпе HTML4/XHTML1 браузеры внезапно начнут понимать атрибут charoff для таблиц:)


                            То, что старые валидаторы не ругаются на устаревшие атрибуты при устаревших доктайпах — не показатель. Для браузеров это всё равно будет неправильный HTML5, и хороший валидатор теперь прежде всего ругнётся на неправильный (т.е. не соответствующий реальности) доктайп.

                              0
                              То, что старые валидаторы не ругаются на устаревшие атрибуты при устаревших доктайпах — не показатель.

                              Не показатель чего?


                              Для браузеров это всё равно будет неправильный HTML5

                              Всё же, если браузер неправильно отображает старую страницу, которая раньше отображалась правильно, то неправильный тут всё-таки браузер. А страница — не "неправильный html5" а вообще не html5, а, может быть например, правильный html3.2.

                                0

                                Ну что поделать, нет в мире «правильных браузеров» в таком понимании, а есть реальные браузеры, понимающие один стандарт, известный нам как HTML5 (или просто HTML) и содержащий предписания для браузеров, как вести себя с любой разметкой (даже самой кривой), и советы для авторов, как писать разметку, чтобы она кривой не была. И написанный с максимальным прицелом на совместимость с прошлыми стандартами (в разумных пределах).


                                Убрали неприжившиеся фичи из той части, которая «для авторов» (т.е. писать так раньше было допустимо, а теперь моветон). Браузеры и дальше будут «понимать» их примерно так, как и раньше понимали реально.


                                А старые страницы, правильные или нет, браузеры понимали очень по-разному. Отчего авторам и приходилось писать неправильно, но чтоб браузеры поняли одинаково. Из-за этого во многом новый единый стандарт и появился.

                    +4

                    А почему вы посчитали «неосновным нововведением» новые правила внутри тега 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.
                      0
                      Ого, а вот это сильно.
                        0
                        Что-то я не понял, как они по инлайн-блокам собираются HTML валидировать. Это же просто оформление, нет? Странно.

                        Так хотели стили от разметки отделить и вот опять.
                          +4

                          Речь, как я понимаю, о назначении тегов по умолчанию. Понятно, что и тейбл можно инлайном сделать. Но тут по сути говорится о том, что параграф только доя текста, нефиг туда таблицы и оформление пихать. Перед или после — пожалуйста, внутри тега p — нельзя. Логично, чо.

                            +1

                            Никак не собираются, это баг:)

                            0

                            Потому что это полная чушь, нелепый баг и результат механической копипасты из описания самого тега. А там добавилась неуклюжая правка из гитхаба, в которой человек неуклюже пытался объяснить (видимо, в первую очередь самому себе), что в этот тег нельзя запихивать т.н. «блочные элементы», даже если их стили изменены на инлайн-что-то. В общем, хотел как лучше подчеркнуть, что стили не влияют на модель содержимого, а получилось как всегда наоборот...


                            Я уже ходил туда ругаться, надеюсь, в следующей редакции эту чушь уберут:)


                            P.S. Пожалуйста, перестаньте тянуть в HTML5 деление элементов на «блочные и строчные» из HTML4! Оно не добавляет ясности, лишь вносит путаницу с одноименными понятиями в CSS. Вот и наглядный пример этой путаницы...

                            0

                            Интересно, выкинут ли когда-нибудь самый известный тег <a> и сделают простой и понятный аттрибут href применимый ко всем элементам, типа <div href="./">smth</div>
                            Так иногда напрягает неоднозначность того где должен находиться тег <a>, то есть надо ли вкладывать <div> в <a>, наоборот, и как надо стилизовать сам тег. Сама по себе ссылка, это именно что аттрибут, такой же, как, например, title или alt.

                              +1
                              Зачем это нужно?

                              Вроде и нет никакой необнозначности где он должен находиться. А вот однозначно определить ссылку с ним как раз таки можно.
                                0
                                Никогда не выкинут.
                                HTML нужно в принципе полностью перепроектировать исходя из всего того во что он вырос.
                                Ход мысли я поддерживаю, но таких мест столько, что реально степень совместимости будет такая, что проще писать новый стандарт и не мучатся иллюзией частичной совместимости.
                                  0
                                  Ну если бы не закопали XHTML2 то это бы уже было, но его закопали в угоду HTML5.
                                  В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологию (а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массы). Есть потуги на WebGL но пока они выглядят мягко говоря не очень.
                                    +1
                                    В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологию
                                    Отважились. Microsoft планировал всех пересадить на XAML и C#. Но… «не шмогла я, не шмогла».

                                    а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массы
                                    Microsoft нетвёрдо стоит на ногах? Я вас умоляю.

                                    Этого недостаточно. Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия. Тогда вы можете «волевым усилием» старую технологию заморозить и заставить всех пользоваться новой. Так как альтернативы нет — то переход состоится. Если же монополия недостаточно жёсткая, то пользователи переползут к конкурентам. Microsoft эту возможность продолбал. Заморозка в 2001м прошла достаточно успешно, но… Longhorn… вместо планируемых 2-3 лет разработка растянулась на 6 лет, да и результат получится таким, что после его выхода люди долго держались за XP. Это дало возможность другим (Firefox, Opera, потом и Google Chrome) выпустить свой вариант, который был лучше и не ломал обратную совместимость.

                                    Сейчас такой монополии ни у кого нет, так что перехода ждать не стоит.
                                      0
                                      Отважились. Microsoft планировал всех пересадить на XAML и C#. Но… «не шмогла я, не шмогла».
                                      Как-то не заметил. Где можно почитать про их попытку? Я от них помню только Silverlight, но это была так себе попытка, у них тогда уже был подпорченный имидж.

                                      Microsoft нетвёрдо стоит на ногах? Я вас умоляю.
                                      Ну тут этим не ограничивается, ещё авторитет, а у Microsoft он спорный, только недавно начали отмываться. Ещё я помню было время когда они убивали свои технологии, кому охота переползать на то что возможно потом закопают? Как например было с XNA.

                                      Этого недостаточно. Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия.
                                      Монополия это самый простой вариант, но всегда есть вариант идти по обходному пути и заодно проталкивать свою технологию в другие продукты разными способами. В итоге можно создать такую ситуацию что не поддержка технологии = уход пользователей на платформу где технология поддерживается. Естественно технология должна быть желанной и решать многие современные трудности заметно лучше всех прочих альтернатив.
                                        +1
                                        Где можно почитать про их попытку?
                                        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 других технологий и постепенно так «расползаются» — такое видел. Но чтобы все, дружно, взяли и перешли — не знаю ни одного примера.
                                          0
                                          MSDN не подходит?
                                          Подходит.
                                          Понятно.

                                          Пример можно?
                                          С примерами сложно ибо не видел пока прямо удачных компаний.
                                          А так вспоминается: WebExtension, flexbox, CSS Grid, SPDY.
                                          + о чём уже сказал lexxpavlov
                                        0
                                        >Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия
                                        Можно сделать супер-пупер технологию, и к ней 100% работающий транспилер в html. Точно так же все браузеры умеют только js, но всё больше программистов переходят на typescript — потому что удобнее.
                                          0
                                          Не могу сказать, что это в принципе невозможно, но… маловероятно: если оно будет 100% транспилиться в HTML, то за счёт чего будет выигрыш? Почему люди перейдут на одну технологию, а не на 10 разных?
                                            +1
                                            Ну например писать на ней будет удобнее, плюс будут некоторые дополнительные фичи которые работают только в родном клиенте, при этом не слишком критичные, чтобы без них работа в браузере была чем-то ущемлена (незначительная деградация «красоты», падение скорости в сравнению с нативным клиентом).
                                            Могут и другие преимущества появиться.
                                            Например будучи свободным от обратной совместимости можно значительно повысить семантичность верстки и полноценно отделить оформление от содержимого. Что улучшит понимание роботами (в т.ч. краулерами), увеличит кросплатформенность, например альтернативно-вебовые приложения в телефонах будут пошустрее, и соизмеримы с нативными. Ну и натив для десктопа тоже сразу сюда.

                                            Вариантов много. Все зависит от того какую задачу себе поставит тот, кто решит заменить веб, от того какие проблемы он захочет решать этой альтернативой, и что важнее — насколько хорошо это у него получится.
                                        –1
                                        Ну если бы не закопали XHTML2

                                        Лично я рад что его закопали. Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.

                                          0
                                          Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.
                                          О чём речь?
                                          Да и какое вам до него дело, пользовались бы дальше костыльным HTML5.
                                          Эти два стандарта развивались не мешая друг другу.
                                          Одно в XHTML точно плохо это то что при нём обозреватель не рисует на лету разметку и пока документ не догрузится до конца страница не отобразится, отчего на больших страницах при плохой связности это большая проблема.
                                          XHTML2 вероятно бы эту модель унаследовал, но в целом XHTML2 заметно чище и продуманнее, он мог бы дать толчок к очистке от груза всех остальных устаревших технологий и архитектурных ошибок. Тем более учитывая куда идёт веб (одностраничные веб-приложения), эта особенность XHTML уже не столь ощутима.
                                            0

                                            О том, что задачу пытаются впихнуть в рамки какого-то "инструмента" общего назначения (не говоря уже о том, что этот "инструмент" сам по себе плохой).
                                            Парсер html хотят убрать и вставить вместо него парсер xml. Но xml-парсеры не знают о том, что тег <br> одиночный — давайте им в угоду его изуродуем в <br />. Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника — ничего, подождёте пока страница догрузится, инет ведь быстрый. Не надо таких "оптимизаций".
                                            Не раз видел аналогичные истоиии (но в локальном масштабе): а вот у нас тут супер модная технология, давайте её внедрим. Правда она не поддерживает некоторые удобные фичи (которые у нас УЖЕ есть), придётся их убрать, но это всё мелочи.

                                              +3
                                              тег <br> одиночный — давайте им в угоду его изуродуем в <br />

                                              И это хорошо и правильно! Явное лучше неявного, если тег одиночный — значит его и нужно записывать как одиночный, а не ходить в справочники заглядывать, какой же он. Всегда пишу <br/> и в HTML5 тоже, ибо нефиг.


                                              Xml-парсеры испытывают проблемы с инкрементальным парсингом исходника

                                              Не знаю, что там у браузеров, но когда я работал с xml-парсерами несколько лет назад, у меня всё прекрасно инкрементально парсилось. Надуманные проблемы какие-то, XHTML рулит, жаль что он умер в угоду говнокодерам

                                                +1
                                                ходить в справочники заглядывать

                                                Зачем? Если вам важен смысл этого тега то и так и так придётся узнавать о нём. Если вы его просто где-то увидели случайно — игнорируйте и его и его закрывающий вариант, как будто он там не написан (как и делают браузеры с неизвестными тегами).


                                                у меня всё прекрасно инкрементально парсилось

                                                Ну вот EvilFox утверждал обратное по сути, я ему поверил. Может быть это не проблема самого парсера а проблема его интеграции в браузер, но сути это не меняет.

                                                  –1

                                                  А зачем усложнять-то синтаксис? Сейчас синтаксис вида <тег> может иметь аж ТРИ разных значения: самозакрывающийся тег (<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 — интернет сильно похорошел бы.

                                                    0
                                                    в идеальном сферическом мире я бы с Вами безапеляционно согласился.
                                                    Но чертова обратная совместимость…
                                                    Вспомните сколько воя и нытья было когда вышел пхп7.
                                                    Причем основной вой был за конструкторы!
                                                    Прочие несовместимости людьми воспринимались более-менее терпимо, но самый громкий вой был за конструкторы-пхп4-стайл.
                                                    Для меня это было откровением. Я был уверен что в в 5.0 их сделали депрекейтет и где-то к 5.3-5.4 выпилили.
                                                    Но нет, на момент альфы семерки было еще полно софта который использовал данные конструкции.
                                                    Да и сейчас бы использовали, даже в новом коде, ведь «учебников», «уроков» и прочих статеек с примерами кода в сети полно.
                                                    С HTML тут еще хуже. Есть ведь огромное количество софта который на вот это вот всё заточен. Всякие редакторы (включая библиотеки конвертации бб-кодов) и куча всего.
                                                    Да, вы оставите обратную совместимость «временно». Но пока оно работает, и нет жестких сроков когда закончат, то кто будет переучиваться?
                                                    Нет, можно палкой загонять, как браузеры загоняют в https.
                                                    Но ради пары мелких корявостей так напрягаться никто не будет.
                                                    Так что придется тащить оба стандарта с собой «вечно».
                                                    А значит выигрыша от более «чистого» формата не будет.
                                                    Вот и отказались.
                                                      +1

                                                      Строго говоря, в HTML5 синтакисис вида <тег> как раз и имеет одно значние — открытие тега. Остальной «мудрёж головы» — правила построения дерева в зависимости от стека открытых тегов, включенные в единственный и единый для всех стандарт для парсеров. А вот у синтаксиса вида <тег/> бывает-таки три РАЗНЫХ значения — честный самозакрывающий XML-тег (напр., для SVG-элементов типа <use/>), открывающий тег с разрешенным лишним символов (пресловутая «имитация самозакрытия» для одиночных тегов, для совместимости с XHTML), и открывающий тег с ошибкой в виде лишнего атрибута (напр. <div/> — лишь незакрытый тег с ошибкой).


                                                      Если бы браузеры не следовали правилу Постела и отказывались отображать страницы с малейшей невеллформностью (т.е. любые страницы с оборвавшейся загрузкой, любые страницы, по которым прошлась не очень умелая баннерорезка — в середине 00-х этим любил злоупотреблять Agnitum Outpost, и т.д.), интернет, безусловно, был бы прекраснее. Как классическая музыка по сравнению с эстрадой. И его популярность — а следовательно, и «денежность» отрасли — была бы соответствующей..:)

                                                      0
                                                      Ну вот EvilFox утверждал обратное по сути, я ему поверил. Может быть это не проблема самого парсера а проблема его интеграции в браузер, но сути это не меняет.

                                                      Не знаю, какие там проблемы. Берёте SAX-парсер и получаете то же поведение, как при инкрементальном парсинге HTML.

                                                        0

                                                        ЕМНИП, баг в Firefox 2- был такой. В 3-м пофиксили, но у довольно многих «остался осадочек» разочарования в XML-могуществе...

                                                    0

                                                    Зато парсить html5 — так себе удовольствие.


                                                    И что важнее, экономия ресурса клавиши / или возможность более-менее адекватно работать с документом в (полу)автоматическом режиме (там где-то маячит semantic web ещё, но опустим это), мне вот сходу неочевидно. Мне лично хочется сказать, что второе важнее, потому что парсить HTML-странички мне приходится бесконечно чаще, чем их писать, но именно поэтому мой пример не сказать чтоб релевантен.

                                                      0

                                                      Всё-таки имхо чаще приходится работать с уже отпарсенной и построенной DOM, чем парсить неизвестную разметку в чем-то кроме браузера (поисковики и т.п., конечно, важная ниша, но всё-таки ниша). И в DOM важнее предсказуемость и однозначность (например, что td всегда будет 4-м потомком table, а не либо 3-м, либо 4-м по прихоти кодера), пусть даже парсеру для этого придётся «попотеть» чуть больше. В конце концов, в SGML с его уймой вариантов, где тоже злополучный слеш мог заменять закрывающий тег в одиночку, было ещё хуже..:)

                                                        0
                                                        Всё-таки имхо чаще приходится работать с уже отпарсенной и построенной DOM, чем парсить неизвестную разметку в чем-то кроме браузера (поисковики и т.п., конечно, важная ниша, но всё-таки ниша).

                                                        Тогда для вас никакой разницы.

                                                        А ниши нишами, но, опять же, тупо скрейпить странички нужно регулярно. Впрочем, к счастью, что всякие питоновые beautifulsoup'ы, что мой любимый наркоманский хаскелевский hxt более-менее умеют в html.

                                                        Просто, ну, с корректным xml'ом жизнь была бы, на мой взгляд, существенно прекраснее при очень небольших дополнительных требованиях к писателям html-документов.
                                                          0
                                                          А ниши нишами, но, опять же, тупо скрейпить странички нужно регулярно.

                                                          А конкретнее? Имеется ввиду с одобрения/заказа владельцев того сайта, но api они не дали?

                                                0
                                                Что вы подразумеваете под «потуги на WebGL»?
                                            • UFO just landed and posted this here
                                                0

                                                Пока что его, наоборот, вкинули ещё и в SVG:)

                                                0
                                                использования тега style внутри body;

                                                Давно мучает вопрос, осталась ли еще какае-то практическая польза от элемента head, вероятно в нем должна была содержаться метаинформация и контент не должен отображаться на странице, однако контент выводится, и хотя формально link нельзя использовать в body, браузеры его обрабатывают и иногда возможность вставить стили непосредственно перед выводом компонента необходима чтобы избежать подгрузки этих стилей на всех страницах.

                                                  0

                                                  Да в общем-то не осталась, вот такая страница абсолютно валидна:


                                                  <!DOCTYPE html>
                                                  <meta charset="utf-8" />
                                                  <title>yo</title>
                                                  <link rel="stylesheet" href="style.css" />
                                                  <div>yo</div>
                                                    0
                                                    А вообще, если я правильно понял стандарт, link rel="stylesheet" может быть где угодно в body, и валидатор на это тоже не ругается
                                                    0

                                                    Её и не было. Это всегда было семантическим выделением группы тегов, не рисующих ничего не странице, для удобства тех кто их пишет/читает (людей, не браузера). Браузеры его всегда, вроде бы, игнорировали, так же как и <html> и <body> (но не игнорировали аргументы этих тегов).

                                                  Only users with full accounts can post comments. Log in, please.