Pull to refresh

Comments 12

С моей точки зрения верстка как явление уже давно должна была умереть. Если посмотреть на HTML как на набор строгих правил оформления контента в web, можно сделать вывод о возможности автоматизации этого процесса. Процесс верстки должен выглядеть примерно так Дизайн->Анализ изображения ИИ->Компиляция HTML->Код HTML. Вся семантика, доступность, адаптивность и т.д. нужна исключительно устройствам для корректного вывода контента, а не людям и делать ее должен ИИ

Есть огромное число сервисов которые "генерируют код", как с рисунка, так и даже с текстового описания, написанного обычным языком.

К сожалению чтобы описать обычным языком что-то сложное, придется объяснять нейросети детали. Она может их не понять и придется повторять другими словами или "договориться о терминах". Первое будет чем-то похоже на попытку управлять машиной с помощью голосового бота по мобильному телефону, а второе... приведет нас обратно к языку разметки)))

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

В общем нет, спасибо. Давайте пока мы ручками)))

можно ведь пойти ещё дальше. Зачем промежуточная компиляция в html? Html это для человеков. Пусть браузеры напрямую получают изображение и какое то строгое описание интерактива.
А вообще проблема в том что компьютеру нужно строгое ТЗ, а в мире вёрстки хорошо, если под 2 варианта разрешения экрана есть макет. Но со временем, думаю, автоматизации в вёрстке станет больше.
<div class="footer">

Не вижу ничего плохого в такой верстке. К сожалению при переводе на русский слова accessibility и availability переводятся как "доступность". На первый вариант, он как раз в статье, традиционно кладется болт. Бизнес беспокоит доступность контента для поисковых систем, а не то, чтоб кто-то со скрин-ридера прочел. Может быть для разработчиков муниципальных сайтов за бюджет accessibility и прописана в ТЗ, а всем остальным рекомендую не загоняться. Плохо это div внутри span и верстать таблицами :)

Accessibility в вебе — это не сложно на самом деле. И семантические интерактивные элементы — важная его часть. Иначе получится postman. Который из-за отсутствия семантики почти не юзабелен. А вот тег footer, действительно, не принципиален.

Может немного не в тему, но поделюсь своим опытом. Однажды на заре своей карьеры довелось мне вставить тег <div> внутрь тега <p>. Я уже тогда понимал, что это не правильно и должно быть наоборот, просто разметка была разбросана по шаблонам и я не заметил этого до тех пор пока не стали происходить очень странные глюки. Пришлось потратить несколько часов на поиск причины. С тех пор стараюсь везде использовать <div>.

Можно во всех ситуациях использовать div, кроме тех, где очевидно ломается что-то, или иногда ломается. Например, если у вас админка, в которой слепой человек не сможет работать, даже если всё будет доступным, то делать такую админку доступной - не имеет смысла. Или если в любом случае всё будет делаться мышкой, то перемещение табом можно вообще выкинуть. Если вы на таком проекте работаете, то доступностью вы просто потратите время и деньги, и будете зря что-то доказывать коллегам. Просто подумайте в каждом случае что вам нужно, а что нет, а не слушайте советы идеального мира.

Если бы была возможно писать теги вообще без указания их тег-имени, было бы ещё лучше. Потому что это был бы контейнер. А прочие особенности и назначения можно задавать в атрибутах. Плюс в том, что это опционально, и дробится на сколько угодно нюансов. Так когда-то поступили со style, так же можно поступить и с именем тега. Сейчас теги имеют как минимум 3 назначения, то есть являются контейнером, семантикой и имеют разный принцип работы. А как же разделение ответственности? Свалили всё в одну кучу, поэтому приходится писать статьи, чтобы как-то договориться как с этой кучей работать.

Частично согласен и с автором статьи и с коментами к ней. Разнообразие тегов HTML5 просто визуально более быстро помогает понять где гланый блок, а где колонка или конкретная статья, но если блочные теги перевести в div со своим классом, а также соблюдать отступы, то менее понятной верстка не станет. Новые теги HTML5 не несут в себе особых свойств, они по большому счету остаются просто блочными элементами. По этому не вижу ничего плохого в сипользовании <div> и никакого супа из них. Несколько ранее, например когда браузера не поддерживали css свойство border-radius и приходилось вкладывать кучу div-ов друг в друга, чтобы нарисовать рамку с закругленными углами, вот это был суп (блок под границы и по блоку на каждый угол, а если границы рисовал накуренный дизайнер, то по блоку на куждую сторону). И тогда при соблюдении табуляции не сожно было разобрать где что.

мне больше не зватает блочного тэга как <P> ну чтобы если рядом стоят не разделялись маргином

Проблема в том, что новые "html5 элементы" создавались для разметки основной части документа, но на практике чаще используются для разметки страницы. И Ваш пример с header, main и footer тому подтверждение.

Меня, наверное, закидают тапками, но всё-таки выскажусь. Не считаю полезным излишне скурпулёзный подход к семантике HTML при наличии множества других проблем. Стоит кому-то написать <div class='btn'>, как его тут же обвинят во всех смертных грехах - "Изверг! Да как ты посмел? Да ты ухудшаешь доступность и делаешь этот мир хуже! А мы, в отличие от тебя, делаем этот мир лучше - это даже на страничке нашей компании написано!". Но, при этом, считается совершенно нормальным для любой фигни использовать сверх-тяжёлые фреймворки и библиотеки, с которыми условный лендинг будет откровенно тормозить на слабых устройствах. Почему бы не считать излишнюю тяжеловесность сайтов чем-то, что ухудшает доступность? По-моему, было бы логично.

Также частенько дизайнеры забивают на десктопные версии и большие мониторы, фокусируясь только на мобильных устройствах. В результате, при просмотре страницы на большом мониторе, каждый элемент отрисовывается с отступами по 5-10см и пара абзацев текста растягивается на несколько экранов скролла. Но об этом тоже никто особо не говорит.

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

Или раздутие DOM десятками тысяч элементов - об этом, мне кажется, вообще мало кто запаривается.

Но, конечно же, это всё не так важно. Куда важнее полностью сфокусироваться на смертных казнях для всех использующих <div> вместо <span>, закрывая глаза на все остальные менее модные проблемы.

PS: Простите, накипело. Просто, в большинстве случаев, когда речь заходит о семантическом HTML, его приверженцы рассуждают так, будто не существует никаких других проблем в мире веб-разработки, и всем необходимо думать только о том, какой тег использовать вместо div.

К вёрстке имею опосредованное отношение, но осмелюсь предположить, почему сторонники семантичности себя так ведут.

Одна из важных технических задач — писать код, который не удивляет. Если есть <button>, зачем писать <div class='btn'>? Это было сделано специально? По незнанию? Артефакт слияния?

Это как писать let i = arr.length; while (i--) f(arr[i]) вместо map/forEach/for-of или на крайний случай for(let i = 0; i < arr.length; ++i) f(arr[i]). Видишь такое и сразу начинаешь искать повод, зачем именно так надо было делать, а не идиоматически.

Может, поборники семантики из тех же соображений исходят?

Sign up to leave a comment.