Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 62
>>> «behaviors» или динамические подклассы DOM-элементов
Спустя много лет сообщество допёрло, что .htc — не такая уж плохая идея :D
Спустя много лет сообщество допёрло, что .htc — не такая уж плохая идея :D
Не так давно читал где-то (кстати, по-моему, на вашем ресурсе, psywalker), мол, HTML5 это живой стандарт и никаких HTML6 и HTML Next не будет, а будет «дополняться» существующий «стандарт». Это мнение подкрепляется чтением данного обзора: некоторые фичи клёвые, но в целом никак не тянут на революционность или некстген, скорее, разумное продолжение в развитии HTML5. Прав ли я, что термины HTML5/Next здесь чисто маркетинговые?
На самом деле существует "Живой стандарт WHATWG" и W3C-спецификации и + между ними есть отличия, типа таких. В этой же статье скорее говорится о следующем поколении именно «НЕживой» спеки (HTML5,6 и т.д.), т.е. спеки, которую сейчас намечает консорциум W3C.
Мне кажется, что следующее поколение HTML должно быть похоже на что-то вроде Ruby Slim.
Лучше бы что-то типа Grid Style Sheets запилили наконец нормально…
<a href="familyreunion.zip/html/activities.html">Деятельность нашего семейного воссоединения</a>
Наверно тогда лучше вот так:
<a href="zip://familyreunion.zip/html/activities.html">Деятельность нашего семейного воссоединения</a>
Вот пример того, как мы можем справиться с полным экраном и получением скриншотов
Если появится возможность делать скриншоты со страниц, то опасность XSS атак в очередной раз повысится.
Чтобы произошло обращение к зоне zip, нужно, чтобы URL начинался с «http://», "//" или тому подобных. В текущем состоянии эта ссылка ведет на что-то внутри папки с именем «familyreunion.zip», т.е. путь должен восприниматься относительно base URL текущей страницы. Тем не менее, это всё ещё неоднозначность. На мой взгляд, необходимо либо ввести отдельную схему (но непонятно, что делать, если доступно несколько одноименных архивов, так что вариант не очень), либо указывать путь в виде «httр://example.com/mobile/familyreunion.zip/html/activities.html» (если архив объявлен ранее, то никакой неопределенности тут не возникает). Путь к zip-файлу может быть относительным, тогда ссылка будет выглядеть менее страшно.
либо указывать путь в виде «httр://example.com/mobile/familyreunion.zip/html/activities.html»
Тут имеет смысл думать и об обратной совместимости: все-таки это не какой-нибудь border-radius, без которого вполне можно прожить. Такая ссылка, конечно, может работать, но только при условии, что веб-сервер настроен соответствующим образом.
Может быть имеет смысл добавить атрибут тегу <a> и в нем напрямую указывать, из какого именно архива мы хотим получить страницу? Например:
<decompress href="/mobile/archive.zip">
...
<a href="/path/to/some/page.html" zip-src="/mobile/archive.zip">Click!</a>
Таким образом получится сохранить возможность обратиться к page.html старым способом (что может быть также полезно в том случае, если архив по каким-то причинам недоступен), а в случае поддержки браузером данной спецификации просто получить страницу по тому же пути, но уже внутри архива.
PS. Теоретически, при таком подходе можно вообще избавиться от тега <decompress> и загружать архив тогда, когда браузер встречает этот zip-src (разумеется, если этот архив не загружен ранее).
PPS. По большому счету, все это можно упростить еще больше до указания где-нибудь в <head> ссылки на архив с сайтом: если браузер находит запрашиваемую с данного домена страницу в zip-архиве, то он использует ее, если нет — обращается непосредственно к веб-серверу (скажем, если страница динамическая).
Фактически это не сильно отличается от SPA, в котором весь сайт (по крайней мере статика) загружается одной страницей (запросом) и переключение между «страницами» происходит через JS и HistoryAPI.
вот в этом комментарии вроде бы приведен пример как сейчас можно обращаться к файлу из zip
deleted
deleted
Обновляйте комментарии перед отправкой.
Обновляйте комментарии перед отправкой.
>появится возможность делать скриншоты со страниц
так и сейчас можно
так и сейчас можно
Вангую, что из всего этого добра использоваться будут туевы хучи вложенных <div>'ов со стилями. Как сейчас.
Много лет прошло уже, одно время даже казалось, что вот-вот наступит счастье, но судя по всему мы обречены на вечное использование велосипедов и костылей, костылей для костылей и тд.
О, неужто я когда-нибудь доживу до WYSIWYG-редакторов и подсветки синтаксиса без подключения кошмарных библиотек циклопических размеров?
Жаль, что используется устаревший формат сжатия .zip (как и .jpeg для картинок), а не .7z например.
Почему-то я вспомнил про zip размером в килобайт, распаковывающийся в doc с миллиардом строк, вешающим любую машину при открытии.
autocapitalize надо вводить только вместе с dеcompress :)
А смысл в этой штуке с zip, если http итак поддерживает сжатие?
Ну это в принципе плюс. Но все-таки думаю, что это не очень необходимо. Это усложнит и сервер, и клиент. Да и грузить этот zip чтобы с ним работать нужно будет целиком. Думаю было бы оптимальней реализовать это на javascript.
А как же форматирование чисел? например, пробельчики «1 000 000»
Преимущества такого подхода: доступ браузера к файлам из ZIP, снижение требований к пропускной способности (что особенно важно для мобильных платформ).
Давно уже решили это все через Keep-Alive. К сожалению, маленькие файлы продолжают лететь с заголовками, но в целом gzip+keepAlive дают примерно тот же результат.
Семантика для описания заголовков и авторов
Есть уже семантика для указания авторов
<location lat=27.9 long=-71.3 altitude=-100>Бермудский треугольник</location>
Забыли указать геоид, например (а он отличается от страны к стране). Очень много вещей нужно будет учесть для географических штук, просто поверьте человеку, у которого диплом инженера-судоводителя на полочке лежит.
tеaser
Не понял зачем. Тэга section мало?
Автоматическое написание с заглавных букв в полях формы
Только что проверил на поле ввода хабра. Вот это работает:
<textarea style="text-transform: capitalize">
Полноэкранный режим и скриншоты
Через webGL можно делать скриншоты в хроме, как бы смешно не звучало.
Элемент editоr
Есть для этого на js уже решения. persistent.js называется, кажется
tеxtarea type=”wysiwyg”
ContentEditable
«behaviors» или динамические подклассы DOM-элементов
Только не в мозг.
Мееедленно задумайтесь все разом, какое быстродействие будет у этой балалайки.
И как это отлаживать.
document.registerElement достаточно сильная штука, надо ее использовать, если прям хочется.
include(‘url’);
Это как бы вообще к HTML не относится ни разу, даже комментировать не буду (хотя есть что сказать)
JavaScript: пространство имён и классы
Уберите свои грязные руки от моей функциональщины, пожалуйста.
Если человек не умеет готовить — это его проблема, нехрен жаловаться, что получилась гадость на выходе.
Это перевод, я понимаю, потому и не пытаюсь как-то оскорбить или унизить переводчика. Но вот автору хочется сломать пальцы, чтобы он не нес такую вот доброту в массы.
Дело в том, что HTML, CSS, JS — служат разным целям.
И их основная задача исконно выступать в качестве «платформы».
В случае с JS, например, наиболее корректно воспринимать вкладку-сайт как виртуальную машину. Если вспомнить, что JS в рамках этой виртуальной машины может быть достаточно низкоуровневым, аналогия становится еще более понятной. Соответственно, при загрузке подключаются какие-то модули ядра и какие-то клиентские модули.
Модули ядра служат для выполнения задач, которые сделать НЕЛЬЗЯ (например, Function.prototype.call) или делать СЛИШКОМ ДОЛГО(Function.prototype.bind — он дает прирост скорости) для клиентского кода.
HTML служит языком СЕМАНТИЧЕСКОЙ разметки. Он описывает разбивание данных на семантические (ну, если проще — логические) составляющие.
Поверх него можно строить языки-указатели (типа OpenGraph), служащие для как раз указания на авторов в том числе. Для этого есть специальный тэг meta.
Все несколько сложнее, просто поверьте. Я устану это объяснять, с навигацией всегда было очень много тонкостей. WGS-84 дает в некоторых точках земного шара (если не путаю, в Японии максимум) расхождение с геоидом 186, что ли, метров, что для многих ситуаций неоправданно. Более того — какое будет применение у этого тэга?
Тэг для времени ввели для того, чтобы не происходило расхождение: если где-то пишут «встреча произойдет ...15 января в 15:00...», такой элемент теоретически сможет автоматически ввести поправку на часовой пояс пользователя и автора и показать дополнительно скорректированное время. А у координат такой смысловой нагрузки нет.
При отображении имени и фамилии на клиенте тоже показывать через text-transform, какие проблемы.
Угу, только с нынешними селекторами и будущими можно будет нагородить конструкцию типа
main.formatted > .container:not(:last-child):not(:first-child) + *:has(section:not(:only-child)) > section
и при добавлении класса .formatted для main нужно будет это пересчитывать, например. Какова перспектива.
Да, нужно не уметь себе стрелять в ногу, но лучше помочь не делать этого.
document.createElement ввели потому что конструктор для неизменного тэга — это несложно и вообще весело, это в рамках выделения вообще всех элементов в потомки HTMLElement произошло.
Опять же возвращаемся к вопросу про полифиллы. С импортами очень много сложных вопросов (например, про контекст исполнения) есть, поэтому пока что их лучше не трогать, пусть отлежатся, тогда консорциум их и согласует, когда потребность будет.
Там много синтаксического сахара, не более. Компилируются примерно так же как классы в кофе или тайпскрипте. «Честные» классы на JS фундаментально нереально сделать.
И их основная задача исконно выступать в качестве «платформы».
В случае с JS, например, наиболее корректно воспринимать вкладку-сайт как виртуальную машину. Если вспомнить, что JS в рамках этой виртуальной машины может быть достаточно низкоуровневым, аналогия становится еще более понятной. Соответственно, при загрузке подключаются какие-то модули ядра и какие-то клиентские модули.
Модули ядра служат для выполнения задач, которые сделать НЕЛЬЗЯ (например, Function.prototype.call) или делать СЛИШКОМ ДОЛГО(Function.prototype.bind — он дает прирост скорости) для клиентского кода.
HTML служит языком СЕМАНТИЧЕСКОЙ разметки. Он описывает разбивание данных на семантические (ну, если проще — логические) составляющие.
Поверх него можно строить языки-указатели (типа OpenGraph), служащие для как раз указания на авторов в том числе. Для этого есть специальный тэг meta.
А гугловские/яндексовые карты и GPS в телефонах учитывают эти штуки? Насколько я понимаю, сейчас почти все используют WGS 84 + EGM96, полагаю, для типовых веб-задач этого хватит…
Все несколько сложнее, просто поверьте. Я устану это объяснять, с навигацией всегда было очень много тонкостей. WGS-84 дает в некоторых точках земного шара (если не путаю, в Японии максимум) расхождение с геоидом 186, что ли, метров, что для многих ситуаций неоправданно. Более того — какое будет применение у этого тэга?
Тэг для времени ввели для того, чтобы не происходило расхождение: если где-то пишут «встреча произойдет ...15 января в 15:00...», такой элемент теоретически сможет автоматически ввести поправку на часовой пояс пользователя и автора и показать дополнительно скорректированное время. А у координат такой смысловой нагрузки нет.
Вот это работает:… text-transform: capitalize
Но на сервер данные полетят с маленькими буквами. Что может дважды расстроить юзера — неуважением к его фамилии и фактом обмана. Не надо так:)
При отображении имени и фамилии на клиенте тоже показывать через text-transform, какие проблемы.
какое быстродействие будет у этой балалайки
По-моему, при хорошей реализации — не особо меньшее, чем у стандартных интерактивных элементов типа details (не считая разовых затрат на инициализацию). registerElement решает всё-таки немного другую задачу, определение совсем новых элементов и расширение поведения нескольких старых — разные вещи, но они могут неплохо друг друга дополнять.
Угу, только с нынешними селекторами и будущими можно будет нагородить конструкцию типа
main.formatted > .container:not(:last-child):not(:first-child) + *:has(section:not(:only-child)) > section
и при добавлении класса .formatted для main нужно будет это пересчитывать, например. Какова перспектива.
Да, нужно не уметь себе стрелять в ногу, но лучше помочь не делать этого.
document.createElement ввели потому что конструктор для неизменного тэга — это несложно и вообще весело, это в рамках выделения вообще всех элементов в потомки HTMLElement произошло.
Ну почему, HTML-импорты ведь появились. Правда, будущее у них несколько туманно. Возможно, новому предложению повезет больше, кто знает?..
Опять же возвращаемся к вопросу про полифиллы. С импортами очень много сложных вопросов (например, про контекст исполнения) есть, поэтому пока что их лучше не трогать, пусть отлежатся, тогда консорциум их и согласует, когда потребность будет.
Это вопрос скорее к авторам ES6, где как минимум классы уже ввели. Правда, тут уже я удивляюсь, как это относится к HTML:)
Там много синтаксического сахара, не более. Компилируются примерно так же как классы в кофе или тайпскрипте. «Честные» классы на JS фундаментально нереально сделать.
Да, можно, всякие schema.org и т.п. тоже этим занимаются. Но если семантика выносится в отдельный слой, что остается на основном уровне? Мне кажется, то, что в нашу соцсетевую эру в HTML нет стандартной штуки для указания на человека (которая «из коробки» могла бы интегрироваться с приложениями для контактов и т.п.) — это всё-таки недоработка языка. Не фатальная, конечно, но лишней такая штука бы точно не была)
Я еще раз говорю — HTML и OpenGraph это несколько уровней одной модели, как в OSI. HTML — структурирует, оперируя абстрактной информацией. OpenGraph — оперирует конкретными понятиями и сущностями. Я говорю об этой семантике, а не о истерии хомячков на тему того, что правильнее — section или article
Как это нет? А проложить/рассчитать маршрут до искомого места, а найти ближайшие к месту стоянку/гостиницу/кафешку, а в недалекой перспективе — указать пункт назначения для роботакси? По-моему, в нынешнем вебе, особенно мобильном, к геоданным что только ни привязывается…
Опять вспоминаем про уровни использования.
Время нужно, чтобы на уровне представления браузер мог показать актуальное для пользователя время. Координаты достаточно вынести в очередной метатэг.
Проблем куча:
На сервере будут некорректные данные, но юзер этого не поймет;
Когда юзер попытается зайти со старого компа, не понимающиего text-transform для textarea, и введет визуально тот же текст, сервер скажет ему «ты кто такой, давай до свидания», что будет для юзера выглядеть необъяснимой ошибкой;
Нельзя ввести фамилию «ван Бетховен», которая совсем не то же самое, что «Ван Бетховен» (CSS-отображение вручную никак не перебить, а от поля с автокапитализацией лично я жду поведения нынешней клавиатуры iOS после точки — по умолчанию большая буква, но это можно явно отменить);
Путаница из-за одинакового отображения разных (в т.ч. по смыслу) входных данных.
эмм. нет.
1. Ну, на сервере хранятся данные для машин. Время там тоже не в особо человеческом формате.
2. Насколько помню — text-transform — одно из самых первых свойств.
3. А в предложенном решении с принудительной трансформацией как это решается?
4. Где?
Я лично так не буду делать никогда в основном из-за третьего пункта. Но для тех, кто хочет вот так автоматически все превращать — лучше править на уровне отображения, чем принудительно что-то слать в базу.
Потребность у многих есть уже сейчас. И вполне нормально, имхо, прощупывать разные подходы — чтобы в итоге консорциуму было из чего выбрать лучший и довести до ума окончательно, и сделать это до 2022-го года:)
Еще раз: если работает в полифилле — это можно использовать. Консорциум будет смотреть, изучать, вносить правки, а когда уже отлежится и все поймут, что им реально надо — примут.
много синтаксического сахара
И разве это плохо? :)
И да и нет. Причем в основном нет. С одной стороны — классы — это хорошо для быстродействия. С другой — дело в том, что язык должен будет поддерживаться по сути бесконечноhttp://habrahabr.ru/post/249207/# долго (самые первые сайты до сих пор должны корректно отображаться). Из-за этого фичи и возможности продумываются достаточно долго, на это тратятся напряженные часы споров, тестов, изучения и проб. Для такого большого изменения, как классы — это сожрало туеву кучу времени. По факту из-за того, что куча набежавших хомячков затребовала классы, как у нормальных посонов на серверсайде, а то чо мы как лохи — меньше времени ушло на обсуждение тех фич, которые нельзя было бы реализовать без трансляторов на уровень JS. А классы — это реально огромное количество проделанной работы.
В итоге — из-за того, что пахали над классами — до сих пор, например, в фазе обсуждения находятся async/await functions.
Это абстрактный пример, я не слежу за происходящем в сообществе, но тем не менее.
Просто чтобы понимать уровень сложности принятия решений однозначности ради — объясню на примере arrow functions и destructing assignment.
У них вот такой синтаксис:
var fn1 = var1 => var1 + 1,
fn2 = ({var2}) => {return var2};
Это эквивалентно
var fn1 = function(var1){return var1 + 1},
fn2 = function(d){return d.var2};
То есть скобки не обязательны, если есть один аргумент. Если выполняется одна операция и нет фигурных скобок — ее результат возвращается.
Вопрос на засыпку: во что должен превратиться и должен ли во что-то превратиться вот такой код?
var fn3 = {var3} => {data: var3}
То есть по остальным пунктам убедил?
Дело не в этом, дело в том, что он (как и любой другой язык разметки, т.е. семантичного структурирования данных) позволяет на базе себя, как абстрактного языка, не имеющего дела с реальными понятиями, реализовывать структуры конкретных данных.
Условно, если HTML служит для описания деревьев (живых таких, зеленых) как абстрактного понятия — с листочками, веточками и так далее, то OpenGraph уже позволяет указывать точную породу древесины и ее возраст, а HTML предоставляет еще и табличку перед деревом, на котором можно написать в том числе это. Так понятнее?
Да, возможно, имелось ввиду указание для мобильных, нужно ли делать автокапитализацию каждого слова. С этим — ок, согласен, возможно, автор криво написал просто идею.
HTML как он сложился — увы, именно про «семантику-шмемантику для хомячков»
Дело не в этом, дело в том, что он (как и любой другой язык разметки, т.е. семантичного структурирования данных) позволяет на базе себя, как абстрактного языка, не имеющего дела с реальными понятиями, реализовывать структуры конкретных данных.
Условно, если HTML служит для описания деревьев (живых таких, зеленых) как абстрактного понятия — с листочками, веточками и так далее, то OpenGraph уже позволяет указывать точную породу древесины и ее возраст, а HTML предоставляет еще и табличку перед деревом, на котором можно написать в том числе это. Так понятнее?
Не маскировка, а честное авторедактирование.
Да, возможно, имелось ввиду указание для мобильных, нужно ли делать автокапитализацию каждого слова. С этим — ок, согласен, возможно, автор криво написал просто идею.
Сначала подумал, что внезапно пришла весна и настало время «нескучных html6» а нет, оказывается просто перевод.
Предлагаю вернуть теги marquee и blink, а font сделать рекомендованным к использованию.
Кстати, по теме))
Предлагаю верстку на table
Прочитала статью, решила записать интересное в свой блокнотик, но сначала полезла в поиск по хабру же. Ну как бы за 2011 год статья — вот.
Идеи для HTML6 можно брать также из XAML, полагаю оттуда много ещё чего можно подчерпнуть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеи для HTML6 или HTML.next