HTML.next или идеи для HTML6

[@Keler]

Может я чего-то не понимаю, но почему бы это не добавить в HTML5?

[@Kotofey]

Думаю по той причине, что уже есть утвержденный список всех фич/возможностей HTML5, который не подлежит сильным изменениям. А до 2014 года возможны лишь небольшие коррекции.

[@TigranAM]

Да не важно в какой версии будут эти изменения, важен срок, если половина этих изменении будут внедрятся скажем в 2012-13 это будет второй революцией HTML :)))

[@philpirj]

Что именно будет революцией (кроме улучшений аудио-видео, которые всё-таки эволюция)?

[@TigranAM]

HTML5+CSS3+JS это по моему ревалюция в сфере веб дизайна, а с такими изменениями 6ой версии будет второй революцией HTML :))) location,decompress,code,wysiwyg

[@philpirj]

Увы, всего лишь эволюция в веб-вёрстке. JS не изменился, поэтому даже нельзя сказать, что это эволюция разработки веб-фронтенда.

[@TheShock]

Да и JS изменился предостаточно. Всякие аксессоры, let,destructing assignment и так далее…

[@VolCh]

Вы же понимаете, что на таком уровне его знают, а тем более используют, относительно малое число людей, среди тех, кто как бы пишет на JS, типа меня :)

[@aps]

> на таком уровне его знают, а тем более используют,
> относительно малое число людей
А что уже исчезли ie6-ie8, а оставшиеся безоговорочно поддерживают все фичи HTML5?

[@VolCh]

Вроде как JS позволяет проверить наличие того или иного API и/или узнать версию браузера.

[@TheShock]

Для меня — исчезли, я занимаюсь коммерческой разработкой только под современные браузеры. =)

[@TheShock]

Ну это ведь не значит, что JS не развивается. Просто значит, что его старая версия удовлетворяет потребности большинства людей

[@philpirj]

Так и я о том же.

[@stalkers]

Потому что, с учетом темпов утверждения и постоянным добавлением новых фич, HTML5 не выйдет из драфта вообще никогда.

[@jesustown]

потому что, колеса на ходу не меняют

[@Lorents]

На счет элемента <dеcompress>, идея конечно хорошая, но почему ZIP?
Как я понимаю, при этом будет использоваться алгоритм Deflate. Я знаю, ZIP до сих пор популярен (используется для упаковки данных многими программами и играми). Но поймите он уже сейчас устаревший (а если он выйдет лет через 7, это вообще будет катастрофа), почему не перейти на LZMA (хотя для текстовых файлов не самый лучший вариант, но лучше чем Deflate)? Как это сделал, если не ошибаюсь Flash.

[@Kotofey]

Спасибо, подправил статью.
Там в идеях ZIP предлагается в качестве основного формата наряду с другими.

[@kratkar]

Я думаю будут все форматы поддерживаемые браузерами/ОС.

[@kratkar]

Хм. Браузер превращается, браузер превращается… в ОС. Вот мне интерсно это все не google продвигает случайно для свой ОС?

[@dmitriid]

decompress? zip? Добро пожаловать в мир buffer overflow и т.п.? помнится, была история, как положили нахрен mail.ru, который распаковывал архивы для проверки антивирусом. Послали пару архив, распаковывающихся в нцать гигабайт — и привет.

остальные предложения на удивление внятные, даже странно, что они исходят от W3C

[@kratkar]

Распаковку не будет делать сервер. А браузер, вроде. Даже не распаковку, а получения файла из архива. Но вот как в примере рисунок в zip-е — глупо или плохой пример.

[@Stolov]

А если засунуть в архив файл из нулей размером терабайт эдак 10, чтоб наверняка?
Нет, если такое и делать, нужно хорошо обезопасить, иначе кранты

[@bolk]

У нормальных распаковщиков теперь проверяется коэффициент сжатия. Если он превышает допустимый, распаковка не производится.

[@dmitriid]

> Распаковку не будет делать сервер. А браузер, вроде.

Какая разница? Правильно упкакованый zip — и все, компьютеру легкий писец

[@kratkar]

Правильно упкакованый zip

Смысле

Послали пару архив, распаковывающихся в нцать гигабайт

То это да.
Лучше какой-нибудь mount: и можно иметь доступ к отдельным файлам внутри zip: Едро

[@kratkar]

парсер

<mount src="/resultaty-vyborov/2011.zip">
<a href="/resultaty-vyborov/2011.zip/edro.xls">Едро</a>

[@ivanzoid]

Разница — будет ли склеивать ласты сервер, или только браузеры клиентов

[@philpirj]

А разве сейчас HTTP не использует для сжатия передаваемого трафика gzip, и этот эксплоит нельзя использовать уже и сейчас?

[@dmitriid]

Это, кстати, хороший вопрос. Интересно бы попробовать :)

[@philpirj]

Доходит до смешного.

[@azproduction]

2 запроса (html + zip архив со всем контентом сайта) или 50 запросов(html + jqeury+css+css+js+js+пара десятков картин)?

[@student_ivan]

Первый раз 50 запросов, второй раз 1 запрос (expired)
Не нужно портить язык разметки, работа с архивом вообще не нужна, а если и нужна, то это задача для javascript, но никак не html

[@azproduction]

кэш не резиновый

[@undead_ekb]

Возможно лучше уменьшить сами запросы?

[@philpirj]

Истина!
Да поможет нам HTTP Keep-Alive для снижения влияния количества запросов на задержки.

[@resurection]

Что бы избавить верстальщиков: от спрайтов, от минификации js, от обфускации и склеивания css-файлов.
Этого мало?

[@azproduction]

<tеxtarea type="wysiwyg">

Эти 25 байт — убийцы дясятков wysiwyg редакторов…

С каждым днем браузер становится все более толстым клиентом html-документов.

[@mr_avi]

50 в юникоде) Хотя всё же не ясно, как например будет работать загрузка картинок, в FCKEditor-е есть соответственные коллбеки и настройки для загрузки.

[@Borro]

25 в UTF-8. А изображения можно как сейчас с файлами. Все выбираются, а потом отправляются на сервер вместе с самой textarea.

[@mr_avi]

Ну например вставка картинки в текст, часто обработанной (обрезаной, etc.), в таком случае этот элемент, как минимум, должен будет иметь доступ к ФС компьютера для вывода картинки

[@bes_internal]

wysiwyg — ну наконец-то исчезнет этот заопарк из костылей под каждый браузера и что печально под каждую версию браузера

[@Vladiator]

Закрывайте теги, для которых не нужен отдельный закрывающий тег. Это особенно актуально, когда видишь его первый раз и ждёшь закрытия.

[@kekekeks]

Преимущества такого подхода: доступ веб-браузера к файлам из ZIP, уменьшение требований к пропускной способности канала

Возможно, для вас это окажется откровением, но веб-сервера уже много-много лет умеют отдавать сжатый контент. Причём сжатый этим самым DEFLATE. А чтобы веб-браузер его на лету разжимал, достаточно всего-лишь выдать соответствующее значение заголовка Content-Encoding.

[@VolCh]

Может ли сервер отдать несколько файлов в ответ на один запрос? Поймет ли его браузер? Можно ли в HTML ссылаться на эти файлы?

[@kekekeks]

Javascript вам в руки, всё реализуемо

[@VolCh]

Прозрачно для верстальщика, чтоб он ссылался в, например, img на картинку в zip архиве также как на обычную? Сомневаюсь.

[@nsinreal]

Который может быть заблочен NoScriptом или какой-то банерорезалкой.

[@kekekeks]

И вообще, есть такая штука как MHTML.

[@VolCh]

Громоздкая очень и требует поддержку со стороны сервера.

[@kekekeks]

У меня такое впечатление, что вы RFC прочитать даже не попытались.

[@VolCh]

Не скажу, что прочел от корки до корки, но общий принцип, кажется, уловил. И, вроде, ни Apache, ни nginx, ни IIS этот стандарт не поддерживают. В популярных фремйворках тоже что-то не встречал, чтоб хотя бы динамически такие multipart ответы формировать. Да и расширением HTML назвать сложно, на уровне ниже он лежит в основном.

[@kekekeks]

Этот формат — те самые mht-шки, в которые умеют сохранять целиковые страницы Opera и Internet Explorer. Их можно грузить прямо из файловой системы, не то что с веб-сервера.

[@VolCh]

Не пользуюсь ни тем, ни другим, так что про «те самые» не в курсе. Но поддержка со стороны сервера же всё равно нужна. Не оперу же использовать для их формирования.

[@kekekeks]

Их формировать можно в веб-приложении на уровне шаблонизатора, не вижу в этом никакой сложности.

[@VolCh]

Всё равно это будет не HTML.

[@kekekeks]

Ну да, у нас половина браузеров не понимает RFC, датированный 1999-ым годом (если уж на то пошло, тот же хром даже HTML 3.2 полностью никогда не поддерживал). Сейчас же предлагается ввести новый стандарт, реализующий то же самое. Просто гениальный план.

[@VolCh]

То же самое, но, имхо, более удобным путём, пускай и менее универсальным.

[@philpirj]

История умалчивает. В электронной почте это можно. В HTTP это можно при отправке клиент-сервер. Почему бы не сделать и при получении (типа «берите, эти файлы вам пригодятся)?

[@VolCh]

Как мне кажется не очень юзабельно это будет прежде всего для серверов, вернее разработчиков. Как вспомню мучения с этими multipart что при отправке почты, что при разборе форм на сервере. А тут всё прозрачно — выложил архив со статикой и только ссылайся на него в src.

[@philpirj]

Ну, стоит предположить, что если отдачей будет заниматься сервер, зная, что клиент ещё файлы, упомянутые в запрашиваемом HTML не получал, то для разработчика сайта всё просто, усложняется только логика сервера. В самом HTML можно прописывать всё точно так же, как если бы файлы запрашивались следующими запросами. Браузер и так вроде бы должен понимать, что раз сервер прислал HTML, а с ним кучу файлов, то файлы нужно закешировать, и в это обращение их обновления не спрашивать (предположу, что должен помочь заголовок Expires, но для самой страницы и для статики он должен бы быть разным).

[@kafeman]

<tеxtarea type="wysiwyg">

Не забудьте ещё про его стилизацию, а то опять кастыли придётся делать типа прозрачного инпута и картинок сверху.
Или пусть хотя бы одинаково выглядит во всех браузерах.

[@azproduction]

одинаково выглядит во всех браузерах

Не дождетесь (посмотрите, что сейчас с html5-инпутами). Если этот тег одобрят, то будет война wysiwyg редакторов на ряду с войной браузеров.

[@kafeman]

Ну тогда стилизация. Вот тег , к примеру, совершенно по-разному выглядит в разных браузерах, но его хотя бы можно настроить как нравится. Пример — html5 проигрыватель на YouTube.

[@kafeman]

Тег

<video>

(исчез из-за парсера)

[@azproduction]

Главное, чтобы для одинаковых выделений текста в wysiwyg использовались одинаковые теги, а не как сейчас с вендорными префиксами CSS3:

textarea -moz-strong, 
textarea -webkit-strong, 
textarea b, 
textarea strong
/*еще десяток*/ 
{
    color:#333;
}

а дальше разберемся :)

[@dmitriid]

*в этом месте должен быть комикс из xkcd про 15 разных стандартов*
:)

[@usgleb]

Шестерка в логотипе ужасна.

[@shambho]

Восьмёрка будет хорошо смотреться

[@Kotofey]

Раз уж такое дело, то пришлось открыть Paint и немного ее причесать )

[@kekekeks]

Указав тег autocapitalize=«words», браузер каждое новое слово будет писать с заглавной буквы. Актуально для полей указания ФИО, напр. «Вася Пупкин».

Автору этой идеи надо выдать премию за идиотизм и познакомить с особенностями написания имён представителей различных европейских и азиатских национальностей.

[@kafeman]

Да, идея заставить писать каждое слово с большой буквы похожа на идиотизм.
Но, наверное, автор топика просто привёл неудачный пример, т.к. идея оформлять как-то вводимые значения сама по себе не плоха.

[@Nerten]

Пользователя никто не будет заставлять. Это всего лишь автокоррекция.

[@delicious]

… которая запорет мое имя Эркюль Савиньен Сирано де Бержерак.

[@Kotofey]

> text-transform: capitalize в CSS 2.1

В отличие от css, в случае с тегом autocapitalize, браузер сможет выполнять заранее заданные действия, к примеру блокировать кнопку submit или помечать поле как ошибочно заполненное.

Вот что пишет автор идеи:

Automatically enable or disable a «shift» key, or make some other
behavioral or content change to a software keyboard to more easily
input capital or non-capital letters.

[@Aux]

Чем-то не тем ребята страдают… Давным-давно требуется сделать нормальную работу с лейаутами в режиме софта и в режиме печати, но никто не чешется. А ведь до сих пор ни нормального позиционирования, ни нормального вывода на принтер. Ни один драфт типа флексбокса не только никем толком не реализован, но и вообще по-человечески не продуман и представляет собою не более, чем корявый костыль.

Беспросветный ужас…

[@Kotofey]

Я так думаю, что до чего-то серьезного дело просто пока не дошло. Сейчас надо бы с HTML5 закончить.

[@Aux]

Я пытался участвовать в работе WHATWG и понял одну вещь — до серьёзного никогда не дойдёт. Неудивительно, что у каждого разработчика браузеров куча проприетарщины внутрях, от собственных CSS префиксов, до расширений JS/DOM — в W3C и связаных организациях творится бардак и детский сад и всё развитие HTML5/CSS3/JS — это по сути жёсткий пушинг со стороны вендоров. Opera засставила принять тег VIDEO, Apple запушила всякие CSS эффекты ну и т.д.

Фактически, мы имеем ситуацию времён Netscape VS IE. W3C и тогда была и точно также ничего не делала, а вендоры творили чад и угар. Разница лишь в том, что тогда все бегали под двумя флагами и кидались во флаги противников какашками, а сейчас все бегают под одним флагом и кидаются какашками непосредственно друг в друга.

[@Kotofey]

Если все действительно обстоит именно так как вы описываете — а сомнений на этот счет почему-то и нет — то это просто феерический пи пушной зверь.

И таки получается что вот она — невидимая рука рынка.

[@LexL]

Зачем нужен HTML5, когда есть SL? Правильно, чтобы слезть с иглы Микрософта.
Слезая с одной, незаметно залазим на другую…

[@azproduction]

Подсветка синтаксиса для элементов <cоde>

Мне вот интересно как они будут отбирать те языки, которые нужно подсвечивать по стандарту, а какие нет? Внедрят список в стандарт? А если мне нужен мой-экзотический-язык — писать прошение на добавление в w3c?
А если список языков оставят на усмотрение вендорам браузеров, то будет еще хуже:
MS IE — я не буду подсвечивать .dart файлы!
Chrome — тогда я не буду подсвечивать C# файлы!
Firefox — а я не буду посвечивать Objective-C файлы!

И в любом случае нам придется писать костыли:

if (!navigator.sourceHightlightSupported('dart')) {
 // fallback...
}

Учитывая тот факт, что браузеры уже имеют средства парсинга HTML, JS и CSS, было бы неплохо иметь нативную поддержку подсветки синтаксиса без необходимости парсинга кода на стороне клиента средствами JavaScript'а.

Те мы подсвечиваем только html, js, css или встраиваем сотню «парсеров по стандарту» под все языки?!

[@mr_avi]

MS IE — «Подсвечивать? Не, не слышал»

[@kolyuchii]

Первая партия говна в комментах готова)

[@naething]

<rant> Я далек от веб-разработки, но у меня такое ощущение, что все движется в не том направлении. В HTML не хватает нормальных средств для определения макета страницы. В былые времена, когда все делалось на таблицах, можно было без особых проблем, скажем, разбить страницу на три колонки и поставить height=100%, чтобы прибить футер к низу страницы. Таблицы были не особо универсальны, нарушали семантику, но работали достаточно надежно. Теперь все принято делать на DIV и CSS, якобы с целью отделения представления от семантики. Задумка хорошая, но модель позиционирования в HTML/CSS оставляет желать лучшего, не говоря уже про особенности ее интерпретации в различных браузерах. В результате появляется необходимость в каких-то вспомогательных элементах DIV, которые к семантике документа не имеют никакого отношения, и всяких невообразимых CSS-костылях. Сделать, например, более-менее приличную трехколоночную верстку, выглядящую одинаково хорошо во всех браузерах, представляется мне неоправданно трудной задачей. Работа HTML-верстальщиков — это, должно быть, настоящий кошмар. Стандарту HTML/CSS очень нужен какой-то более простой и гибкий способ задания макета страницы. </rant>

[@vitvad]

Мне как HTML-верстальщику — возвращение к табличной верстке кажется Адом. Для меня не составляет проблем
в Div-ой верстке прибить к низу футтер. Я знаю наверняка как поведет себя див в отличии от таблицы.
и 99% верстки на дивах будет меньше по коду (HTML) и ИМХО понятнее, и 1% там где дизайнеры придумали что контент должен магическим образом тянуться в разных местах по разному — там за частую и без JS не разберешься.

Кстати насчет CSS костылей css1k.com — это сайт — своего рода конкурс — где с помощью CSS делают разный дизайн для одного и того же HTML кода при этом нужно уложиться в 1кб.
И я заявляю, ХРЕН вы сделаете столько разных «дизайнов» для одного и того же кода на таблицах.
Просто разметка страницы стала немного сложнее в вашем понимании. И станет еще сложнее с введением в жизнь переменных в css и прочих плюшек.
А Семантика это и есть использование таблиц для табличных данных а дивов как контейнеров для блоков на сайте.
В прочем я боюсь нарваться на холивар, я только хотел сказать что у меня нет проблем с использованием дивов вместо таблиц.

Добавление кучи тегов для «семантики» — делает просто больше тем для холиваров, этак мы прийдем к XML :)

PS. Мне одному мозолит глаза этот пример:

<teaser>
	<header>
		<h1><a href="http://www.myserver.com/myFirstCoolArticle.html">My First Cool Article</a></h1>
	</header>
	<p>This is my first article on the page, and it's really cool.</p>
	<footer>
		<time>3 Days Ago</time>
		<div><a href="http://www.myserver.com/myFirstCoolArticle.html"
		>http://www.myserver.com/myFirstCoolArticle.html</a></div>
	</footer> 
</teaser>

где теги footer и header вобще не не в тему используются?

[@VolCh]

Почем не в тему? Есть тизер с заголовком, содержанием и футером. Меня смущают больше h1 и div.

[@vitvad]

Хотел написать то что выше, что данные теги предназначены для разметки именно header'a и footer'a документа, но решил лишний раз залезть в спецификацию — оказалось что был не прав. Такое использование как раз является правильным.

[@bolk]

Есть несколько стандартов на эту тему. Они обкатываются.

[@nsinreal]

Можно ответить неверстальщику, а почему нельзя ввести спец. тег для таблиц, что-то вроде nonsemantic=true?

[@Finom]

Я бы хотел увидеть вещи, перечисленные здесь: habrahabr.ru/qa/13675/

[@voicer]

<tеxtarea type=''wysiwyg''>

Ну, как человек, своими руками написавший два визивига, очень хотел бы надеяться, что это действительно будет выходом из ада несоответствий между браузерными реализациями contentEditable, TextRange и т.п., но ведь этого не будет, да? Будет ведь только хуже :(

include(''url'');

Они бы там определились, что ли. Одной рукой через deflate уменьшают количество запросов, другой рукой увеличивают их через include'ы.
Вообще, конечно, лучше бы уже от HTTP 1.1 отошли в сторону какого-нибудь SPDY, тогда и инклуды на стороне клиента можно безболезненно будет делать.

«behaviors» или динамические подклассы элементов DOM

Вот это, кстати, шоколадно. Можно будет крайне красивые библиотеки виджетов создавать. Только представьте, насколько красивее и прямее станут YUI, Dojo, jQuery UI и т.п.

[@bolk]

Фактически behaviors воссоздают стандарт, который когда-то придумали в IE. Те же самые bahaviors, даже называются так же.

[@voicer]

Подпишусь.
Я даже больше скажу, они в IE вообще молодцы — и фильтры придумали, и ajax, и dhtml, и contentEditable.
Да и TextRange у них значительно прямее реализован, чем Range в W3C. Не говоря уж о том, что у них нет event propagation, только bubbling.
И это только если начать перечислять, там много всего.

Правда, нынешнему поколению веб-разработчиков ничего из этого неизвестно и неинтересно, им интересно «микрософт отстой! долой корпорацию зла!».

[@TheShock]

Вы подменяете понятия. Нынешнее поколение разработчиков критикуют МС и IE6 не за то, что они придумали кучу клёвых штук, а за политику, из-за которой до сих пор большинство людей сидит на ужасно устаревших браузерах.

[@voicer]

С этого места поподробнее, пожалуйста :)
Насколько я знаю, большое количество IE6 в счетчиках нам обеспечивают следующие факторы:
1) IE6 дооолго не обновлялся.
2) В корпоративных сетях админы вообще не любят что-нибудь или апгрейдить. Работали с IE6 столько времени? Ну вот и еще столько же поработают.
3) Общая неграмотность пользователей, которые, имея XP, не в курсе о существовании других браузеров и возможности обновления XP.

Но с первым пунктом они борются, как могут — насколько я знаю, сейчас даже апдейт выпустили, который принудительно будет обновлять IE6 до IE8.
Со вторым пунктом вообще непонятно, что они могут сделать — разве что рассказать этим админам, в чем прелесть новых браузеров, но MS и так постоянно рассказывает это.
С третьим пунктом тоже непонятно, в чем вина именно MS.

С моей точки зрения, MS виновата только в том, что долго не обновляла браузер, это раз, и, во вторых (что куда сильнее в данный отрезок времени сказывается) сделала настолько хорошую Windows XP sp1, что многие до сих пор не видят смысла обновляться.

[@VolCh]

>Они бы там определились, что ли. Одной рукой через deflate уменьшают количество запросов, другой рукой увеличивают их через include'ы.

Инклудить из архива? По-моему, интересный вариант. Что-то вроде SSI

[@voicer]

Не, как я понял, include работает как import, т.е. вставка осуществляется на стороне клиента, что означает дополнительный HTTP-запрос.
Что как бы плохо.
А deflate, наоборот, призван заставить браузер скачать кучку ресурсов в один поток и потом уже на месте разбирать.

[@VolCh]

Что-то вроде SSI на стороне клиента, CSI :) Ведь ничто не должно мешать указать в include(''url''); урл типа megalib.zip/jquery.js, раз его даже img будет понимать. Да и в @import наверное тоже.

[@voicer]

Если действительно так будет работать — соглашусь, крайне красиво выглядит.

[@TigranAM]

Можно например добавить

вместо js кода для шифрования пароля скажем md5 или sha

[@TigranAM]

input type=password encrypt=md5
парсер :(

[@dasm32]

Хеширования пароля, хеширования.
А как вы пароли будете хранить на сервере, в каком виде?

[@TigranAM]

шифрование на стороне клиента для безопасности, а как будет хранится сам пароль в базе, это дело php…

[@dasm32]

Т.е. вы будете каким-то образом разрабатывать клиентскую браузерную часть веб-проекта никоим образом не согласовывая ее с серверной, я правильно вас понял? :)

[@caffeinum]

А в чем проблема в той же Опере исправить исходный код страницы и отправить незашифрованный пароль? Все равно придется шифровать на сервере)

[@TigranAM]

для безопасности пароля в пути к серверу от разных снифферов :)

[@VolCh]

Чтобы снифферы (вернее их владельцы) слали сразу хэш, даже не зная пароля?

[@zim32]

Веб технологии растут как на дрожжах прям

[@bolk]

Кстати, в FF есть протокол jar, которые делает почти то же самое, что предложенный тег decompress.

[@azproduction]

Есть такое www.gnucitizen.org/blog/web-mayhem-firefoxs-jar-protocol-issues/ и выглядит элегантней предложенного враппера.

Залил для теста: jar:http://dl.dropbox.com/u/2899751/fflogo.jar!/fflogo.png
К сожалению хабрапарсер не понимает протокол jar:, поэтому вставить картинку напрямую не могу, но это работает.

[@nolled]

Для HTML 6 достаточно всего-лишь одного, нормальные layout элементы, а не то уныние что есть сейчас. Под нормальными подразумеваю подобие того что реализовано для Android и Silverlight.

[@AntonDiaz]

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

Ну и конечно есть вопросы и к самой идеи размещения данных в архивах. Действительно ли здесь будет экономия трафика? А что если пользователю понадобится из нескольких десятков ссылок на странице открыть лишь одну из них? Браузеру ради одной ссылки придется скачать и распаковать весь архив для этого?

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

Почему должна быть именно псевдо-разметка? Почему бы не сделать нормальные семантические элементы?

Элемент <editоr>
Данный элемент позволит сохранять набранный текст при переходе по ссылкам.

Непонятно.

А вообще соглашусь с некоторыми ораторами. Лучше бы сейчас всем сосредоточить силы на допиливание и реализацию CSS Layout-ов (Grid, Flexbox, Templates)

[@AntonDiaz]

Извиняйте за этот бардак. Сделал бы все нормально, если бы предпросмотр не глючил так ужасно. В первом абзаце речь шла про тег decompress.

Ну и конечно корневой blockquote там по ошибке.