Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 61
Ещё пятый толком никто не увидел, а вы уже на шестой замахиваетесь…
Не хватает в вашем описании указания на возможность задавать пользовательские теги (и зачем тогда вообще нужны ваши 5?). Иначе верстка, увы и ах, снова превратится в ад. Уже не говоря о совместимости.
Итого, если исключить урезание тегов до 5ти, остается следующее:
— все теги «пользовательские», существуют только семантические рекомендации
— все стили регулируются CSS (включая интегрированные в браузер)
— вся активность регулируется javascript (включая интегрированный в браузер)
— регуляция «стандартного» поведения производится выбором браузером (по !doctype) набора «стандартных» js+css
Вроде туда и идем.
Итого, если исключить урезание тегов до 5ти, остается следующее:
— все теги «пользовательские», существуют только семантические рекомендации
— все стили регулируются CSS (включая интегрированные в браузер)
— вся активность регулируется javascript (включая интегрированный в браузер)
— регуляция «стандартного» поведения производится выбором браузером (по !doctype) набора «стандартных» js+css
Вроде туда и идем.
Вместо пользовательских тегов использовать уже существующие атрибуты id и class. Возможно, зря не указал это в статье.
Почему вёрстка без них превратиться в ад?
Урезание тегов до 5 — обусловлено желанием упростить некоторые моменты в вёрстке. (иначе можно было бы оставить один или не оставлять вообще ни одного, а перейти к xml).
<a> — не упрощает ничего. Это основной/базовый тег
<b> — чуть упрощает описание простых элементов страницы, ввиду отсутствия закрывающего тега.
Возможно <c /> и <d /> зря разделил. Вместе они упрощают описание различных оформительских и активируемых элементов.
<e /> — нужен что бы не заморачиваться с описанием технических элементов.
Главное, почему я выделил эти 5 — в современном html 5 основных «типов» тегов.
Почему вёрстка без них превратиться в ад?
Урезание тегов до 5 — обусловлено желанием упростить некоторые моменты в вёрстке. (иначе можно было бы оставить один или не оставлять вообще ни одного, а перейти к xml).
<a> — не упрощает ничего. Это основной/базовый тег
<b> — чуть упрощает описание простых элементов страницы, ввиду отсутствия закрывающего тега.
Возможно <c /> и <d /> зря разделил. Вместе они упрощают описание различных оформительских и активируемых элементов.
<e /> — нужен что бы не заморачиваться с описанием технических элементов.
Главное, почему я выделил эти 5 — в современном html 5 основных «типов» тегов.
Зачем вообще нужны эти теги? Зачем писать
Сыро, конечно, но идея понятна.
<a class="menu">, если можно просто написать <menu>? И вообще, xml — ужасен. Хотел бы видеть что-то типа такого:page{
head[
charset "utf-8"
js "static/js/jquery.js"
js "static/js/app.js"
less "static/styles.less"
]
body{
header{
logo
}
nav{
item[ url "contacts.html" ]{
Our contacts
}
item[ url "about.html" ]{
About strong{ us }
}
}
// And so on
}
}
Сыро, конечно, но идея понятна.
даже так:
page[
charset "utf-8"
js "static/js/jquery.js"
js "static/js/app.js"
less "static/styles.less"
]{
header{
logo
}
nav{
item[ url "contacts.html" ]{
Our contacts
}
item[ url "about.html" ]{
About strong{ us }
}
}
// And so on
}
<a class=«menu»></a> вместо <menu></menu>
ради того что бы можно было:
<a class=«menu»>
<b class=«item»>first
<b class=«item»>second
</a>
вместо
<menu>
<item>first</item>
<item>second</item>
</menu>
Потому что 1-ая конструкция, лично для меня, более интуитивна.
А ваш вариант очень даже интересен. Мне даже в голову не приходило что можно полностью отказаться от xml. И ведь на практике это применяется (json вместо xml).
С удовольствием бы плюсанул ваш комментарий. Можно сказать, только ради него всю статью и писал.
ради того что бы можно было:
<a class=«menu»>
<b class=«item»>first
<b class=«item»>second
</a>
вместо
<menu>
<item>first</item>
<item>second</item>
</menu>
Потому что 1-ая конструкция, лично для меня, более интуитивна.
А ваш вариант очень даже интересен. Мне даже в голову не приходило что можно полностью отказаться от xml. И ведь на практике это применяется (json вместо xml).
С удовольствием бы плюсанул ваш комментарий. Можно сказать, только ради него всю статью и писал.
QML в вебе =)
Кстати, подскажите кто знает, в CSS можно выразить отношение «тег footer наследует свои стили от тега div»?
Если есть, то это откроет мне глаза :)
А если нет, то почему?
Если есть, то это откроет мне глаза :)
А если нет, то почему?
То что вы хотите удобно с точки зрения вёрстки, с точки зрения отображения. Но абсолютно неверно с точки зрения семантики. Семантика подразумевается для того, чтобы звуковые браузеры для незрячих знали, где заголовок, а где текст статьи. Чтобы поисковые боты могли ориентироваться опять же между главной частью страницы, футером, хедером, навигационным меню, опять же между заголовками и текстом самой статьи. То, что вы просите, разрушит одну из главных основ современной веб-вёрстки.
P.S. Правда, увы, немногие соблюдают абсолютно семантически верную вёрстку.
P.S. Правда, увы, немногие соблюдают абсолютно семантически верную вёрстку.
Именно из-за того, что вы указали в «P.S.», у меня и начал складываться подобный образ языка разметки.
И я полностью согласен с тем, что этот образ полностью разрушит семантику. И именно в семантике я и вижу основную проблему для вёрстки. Семантика зачастую очень неоднозначна.
Обратите внимание на то, как статья разделена чертой. То, что над чертой — те яркие примеры неудобств, с которыми приходится сталкиваться при вёрстке. То, что под чертой — лишённый этих проблем и неудобств язык разметки, с которым мне бы хотелось работать.
Я и не пытался устраивать революцию, по этому над хабракатом предупредил, что бы читатель не ждал гениального решения всех проблем веба. У меня слишком мало опыта, и знаний что бы тягаться с целым w3c или сообществом основных браузеров. Всё чего я хотел — обратить внимание на то, к чему мы пришли, развивая html, и предложить читателю подумать о том, верен ли курс.
И я полностью согласен с тем, что этот образ полностью разрушит семантику. И именно в семантике я и вижу основную проблему для вёрстки. Семантика зачастую очень неоднозначна.
Обратите внимание на то, как статья разделена чертой. То, что над чертой — те яркие примеры неудобств, с которыми приходится сталкиваться при вёрстке. То, что под чертой — лишённый этих проблем и неудобств язык разметки, с которым мне бы хотелось работать.
Я и не пытался устраивать революцию, по этому над хабракатом предупредил, что бы читатель не ждал гениального решения всех проблем веба. У меня слишком мало опыта, и знаний что бы тягаться с целым w3c или сообществом основных браузеров. Всё чего я хотел — обратить внимание на то, к чему мы пришли, развивая html, и предложить читателю подумать о том, верен ли курс.
Еще один святоверующий, что table лишний? А по сути бред какой-то: чтение разметки затруднится, огромная куча css будет, к тому же пожалуйста — не нравится использовать кучу тегов, юзай div, например, эффект будет тот же.
Весь этот набор тегов специально сделан, чтобы показать, что опа вот тут у нас футтер, а вот тут хидер, а вот тут у нас какой-то список, вот тут у нас блочный элемент, а вот тут инлайновый, а здесь у нас мета информация, а вот это ссылка и т.д., не заглядывая в тонны css. И если кто-то юзает что-то через жопу, это не значит, что оно плохое и не нужное.
Весь этот набор тегов специально сделан, чтобы показать, что опа вот тут у нас футтер, а вот тут хидер, а вот тут у нас какой-то список, вот тут у нас блочный элемент, а вот тут инлайновый, а здесь у нас мета информация, а вот это ссылка и т.д., не заглядывая в тонны css. И если кто-то юзает что-то через жопу, это не значит, что оно плохое и не нужное.
синтаксический сахар…
Представляю себе вёрстку таблиц…
и в стилях:
<a>
<a>
<a>
</a>
<a>
</a>
</a>
<a>
<a>
</a>
<a>
</a>
</a>
</a>
и в стилях:
a{/* табличка */}
a a:first-child{/* header таблицы */}
a a:first-child a{/* столбец в header'е таблицы */}
a a{/* строка */}
a a a{/* столбец */}
для большинства таблиц хватило бы и
someddtext
other text
third text
не вижу в этом большой проблемы
someddtext
other text
third text
не вижу в этом большой проблемы
Ну перепишите, например, разметку и стили JQueryUI или dojo djijt и вы сразу все увидите.
эм… <source lang=«html»></source> не сработал…
для большинства таблиц хватило бы и
<a class=«table»>
<a class=«line»>
<b>sometext
<b>other text
</a>
<a class=«line»>
<b>third text
<b>last text
</a>
</a>
Что мне не кажется значительно более сложным чем
<table>
<tr>
<td>sometext</td>
<td>other text</td>
</tr>
<tr>
<td>third text</td>
<td>last text</td>
</tr>
</table>
для большинства таблиц хватило бы и
<a class=«table»>
<a class=«line»>
<b>sometext
<b>other text
</a>
<a class=«line»>
<b>third text
<b>last text
</a>
</a>
Что мне не кажется значительно более сложным чем
<table>
<tr>
<td>sometext</td>
<td>other text</td>
</tr>
<tr>
<td>third text</td>
<td>last text</td>
</tr>
</table>
Когда мы пишем тег <table> — нам не нужно задавать стилей, рендерер браузера уже сам знает, что это таблица и её нужно верстать так. В вашем же случае — для каждого элемента нужно задавать классы, ПОМНИТЬ все эти классы и т.д. Представьте себе проект, например гугл или яндекс, где все страницы будут свёрстаны 5ю тегами с различными классами — что мы получим? Тем более каждый проект будет иметь свои классы, верстальщикам и программистам теперь нужно будет знать не просто HTML, а вам HTML6, а также внутреннюю структуру каждого проекта, чтобы сверстать хоть какой-то кусок кода. К тому же — мы увеличим время на рендер страницы и размер кода, за счет огромных css-файлов.
Боюсь, при таком синтаксисе не будет обратной совместимости с предыдущими версиями html, а это чревато
Вместо <nobr> записывать <span style="white-space: nowrap;"> и так-то бесит, а тут ещё Вы с Вашей идеей.
Странно. А зачем вообще писать nobr или span style=«white-space: nowrap;»? Ведь оба кода не имеют смысла
Для того, чтобы предотвратить переход на новую строку (перенос на новую строку) внутри текста, обрамлённого <nobr>…</nobr>. То есть чтобы на новую строку при необходимости он был перенесён весь целиком, если на предыдущей строке не поместился.
Одной только замены обычных пробелов на символы неразрывного пробела для этого не достаточно, потому что некоторые браузеры совершают перенос также после дефисов, слэшей и некоторых других символов по своему усмотрению.
Одной только замены обычных пробелов на символы неразрывного пробела для этого не достаточно, потому что некоторые браузеры совершают перенос также после дефисов, слэшей и некоторых других символов по своему усмотрению.
А чтобы номер телефона не переносился как дерьмо +7 919 001-
01-01
01-01
<span class="phone">+7 919 001-01-01</span>
.phone { white-space: nowrap; }
И отныне все телефоны на странице не переносятся как дерьмо. А потом их и красненьким можно выделить
Я думаю, Мицгол не имел ввиду, что обязательно указать это в атрибуте style. Будем считать, что все друг-друга не поняли.
Есть же неразрывный дефис (‑).
Думаю, можно использовать HTML6 в гипертекстовом фидонете ;) простите… :)
Вот этого как раз никак нельзя: фидонетовский язык разметки гипертекста должен быть обратно совместимым с обычным текстом.
Такая совместимость необходима, чтобы (во время перехода к гипертекстовому Фидонету от догипертекстового) могли свободно сосуществовать догипертекстовые редакторы почты (например, GoldED+) и гипертекстовые браузеры Фидонета, а также догипертекстовые WebBBS (такие, как прежняя «FidoNet Online», ныне покойная) и гипертекстовые.
Такая совместимость достижима в легковесных языках разметки, хорошим примером которых служит Markdown, в настоящее время широко употребляемый на Гитхабе.
Такая совместимость необходима, чтобы (во время перехода к гипертекстовому Фидонету от догипертекстового) могли свободно сосуществовать догипертекстовые редакторы почты (например, GoldED+) и гипертекстовые браузеры Фидонета, а также догипертекстовые WebBBS (такие, как прежняя «FidoNet Online», ныне покойная) и гипертекстовые.
Такая совместимость достижима в легковесных языках разметки, хорошим примером которых служит Markdown, в настоящее время широко употребляемый на Гитхабе.
Фигню какую-то Вы хотите видеть. От полной порнографии и разброда html более-менее движется к семантической концепции, а тут на тебе, «всего 5 тегов».
Вон из профессии!
[sarcasm]
хочу в html7 site.create(), а больше ничего и не надо
[/sarcasm]
простите не удержался
хочу в html7 site.create(), а больше ничего и не надо
[/sarcasm]
простите не удержался
В HTML6 хочу семантической однозначности в какой ситуации применять тот или иной тег. В HTML5 как-то неочевидно многое.
Я просто оставлю эту ссылку здесь:
blog.whatwg.org/html6-plan
blog.whatwg.org/html6-plan
К чёрту лишний синтаксис.
Хочу объединение всего в один языковой формат вместе с серверным. Чтобы было макетное проектирование + написание алгоритмов.
Хочу объединение всего в один языковой формат вместе с серверным. Чтобы было макетное проектирование + написание алгоритмов.
Не хочу видеть HTML6 из пяти тэгов в алфавитном порядке. Бренфак и то читабельнее.
Жаль, что такие классные технологии как scss и haml так тяжко доходят до людей. А ведь они существенно облегчают жизнь, отстраняя от мысли о том, что «я хочу новый стандарт html».
Я вот Less юзаю и очень доволен, а haml меня смущает тем, что надо на сервере собирать
Они тяжко поддерживаются браузерами, cms и фреймворками. Их поддержку приходится вводить в проект «костылями» (по отношению к собственно к проекту).
Как может то, что предварительно компилируется в стандартные html и css, плохо поддерживаться браузерами?
В cms и фреймворки встраивать эти средства не так уж и сложно, и наверняка, если cms или фреймворк достаточно продвинутые — у них уже есть готовые плагины для использования scss и haml (ну или less). И даже если нету, то человек разбирающийся в структуре cms или фремворка, без особого труда сможет внедрить эти замечательные технологии в них.
Хотя конечно силами самого дизайнера — это сделать практически невозможно, и нужно прибегать к помощи программистов. Или сразу работать с нормальными фреймворками, априори поддерживающими данные технологии.
В cms и фреймворки встраивать эти средства не так уж и сложно, и наверняка, если cms или фреймворк достаточно продвинутые — у них уже есть готовые плагины для использования scss и haml (ну или less). И даже если нету, то человек разбирающийся в структуре cms или фремворка, без особого труда сможет внедрить эти замечательные технологии в них.
Хотя конечно силами самого дизайнера — это сделать практически невозможно, и нужно прибегать к помощи программистов. Или сразу работать с нормальными фреймворками, априори поддерживающими данные технологии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Каким я хочу видеть HTML6