Послушайте мистер php разраб, вы не оборзели? Я же просил вас вот в этом комментарии перестать говорить свысока типа я какой-то стажер, а вы умудренный опытом сеньер-помидор. Вы зачем говорите про "отсутствие навыков с веб фреймворками " и что мне нужно подтягиваться до какого-то уровня? Вы верстку своего сайта https://manytomany.ru/ до современного уровня подтяните.
Вот мое резюме - https://career.habr.com/a-l-e-x-s-t-e-p я работал в том числе в известных "проверенных" так сказать, компаниях в том числе делал фронт приложений которыми пользуются и сейчас сотни людей, когда-то работал лидом и руководил такими вот сайто-делами. Писал на angular, vue, react , но сейчас больше react . Но нет, наверно во всех компаниях подряд на всех собеседованиях все эти годы люди ошибались я то оказывается и фреймворки их знать не знаю и верстать не умею )
Зачем вы упорно тыкаете в мою вымышленную вами некомпетентность и незнание современного стека разработки под веб?
Вы отходите от стандарта т.к. все теги регламентированы по своей семантике и существуют соглашения о именовании тегов
Если использовать имена тегов без черточек - да. Это уход от стандарта, но - можно именовать теги как my-tag в таком случае стандарт соблюден
+ из-за нарушения стандарта в случае с именованием тегов - не наступает никаких последствий - то есть да правило нарушено - но ничего плохого из-за этого не происходит.
Вы упираетесь в сугубо личное понятие лаконичности и читаемости в место того, чтобы соответствовать стандартам. Люди знающие стандарты HTML будут все равно с трудом читать вашу разметку и без ваших пояснений никак не обойтись
Нормально люди будут читать такие теги, будут видеть говорящее имя. Да любое восприятие личное, нет же какого-то общественного восприятия? Это какая-то философия а не аргумент.
У вас будут проблемы с SEO
Не будет проблем с SEO. Еще раз - мы продолжаем использовать теги h1-h6, strong, article, form и так далее - а отказываемся только от div - который не несет в сеюе никакой семантики.
И я как раз и призываю вкладывать смысл в названия тегов, английскими словами. Опять же размечать списки с помощью <li> параграфы <p> а меню выносить в <nav> То есть моя верстка - семантичная , а div class - не семантично
У вас будут проблемы со скринридером
У всех будут проблемы со скринридером кто не оптимизировал свой сайт под него, особенно если это electron приложение с доской задач а-ля trello
Вы не экономите количество символов т.к. для каждого элемента вновь приходится писать вам display:block
Да нет цели эконоить символы я прошу вместо </div> писать </person> это конечно больше символов - чтобы явно видеть какие теги закрываются и да оучше писать в css свойство display чтобы по css коду явно было видно как этот элемент отображается. Я за наглядность, а не за экономию символов.
В итоге больше бойлерплейта пишите т.к. люди использующие классы в CSS переиспользуют куски стилей. Взгляните как пример на tailwind
Бойлерплейта в итоге не больше. Я же не говорю отказываться от css классов, так же их можно переиспользовать. Но если оформление какого-то блока индивидуально - то его можно записать в сили тега а не в класс который иначе бы использовался в проекте только один раз
Вы можете напороться на то, что выйдет новый HTML6 тег, а он у вас уже в проекте под другим соусом и все сломается
Если использовать теги с черточками то нет.
Шанс что повится тег с таким же вот прям именем очень низкий.
То есть чисто теоретически - могу, а могу и не напороться. Мы недавно все напоролись на то что докер образы перестали пулиться - фигня случается, адаптируемся.
Что случится если появится новый тег? Браузер для него свои стили допишет? Обычно я использую некое подобие reset.css , но может, действительно может где-то чутка поеет верстка - поправить дело 5 минут. В вебе постоянно что-то обновляется и меняется, потому мы и занимаемся поддержкой.
Но все эе вы понимаете насколько низкий шанс такого случая?
Ваш подход допускает использование deprecated тегов которые выходят из обихода
Допускает - но это на совести разработчика - не надо именовать свои теги названиями существующих пусть и в прошлом тегов, хоть на работе сайта это никак и не отразится.
Вы игнорируете доступные форматы микроразметки типа open graph мечтая о том, что когда-нибудь примут ваши теги (к счастью никогда не примут)
Я их не игнорирую - они просто за рамками этой статьи и никак не связаны с именованием тегов. Opengraph остается opengraph'ом и так же пишется, микроразметка - так же добавляется. Я не мечтаю и это не мои теги ... даже не знаю что на это сказать сказать... я же не новый стандарт вам втюхиваю - это ваши теги - ваши названия тегов которые вы придумаете сами так же как придумываете названия переменным.
Игнорируете факт, что современные веб-фреймворки уже позволяют писать в таком стиле, о каком вы пишите, компилируя все в итоге в православный div элемент и позволяя избежать проблем из всех пунктов выше.
Вот именно что фреймворки - синтаксический сахар и в нем все равно внутри "православный" div. Блин ощущение что я с верующим спорю о боге ))) нет проблем в пунктах выше - нечего избегать.
Поддержка устройств у вас получится на выходе тоже ограниченная.
Тому нет доказательств. Я проверял, на телевизорах, смарт-часах, разумеется телефонах, старых iphone 4,5 , дополнительно на сайте browserstack смотрел с разных устройств.
Могу сказать что это не работает в IE6. ну и в терминальных браузерах типа links , вот эти теги всегда отображаются как строчные элементы.
Текстовый контент в RSS лентах будет некорректно оформлен при применении кастомной разметки
Я не понял что вы имеете ввиду... RSS это отдельный XML формат , для генерации rss пишут отдельные скрипты которые берут контент из БД и отдают xml
Ну не нужно размечать текст ВЕЗДЕ своими тегами. Но опять же если текстовый контент в RSS ленте разметить через дивы с классами - тоже ерунда получится.
Ну и в целом я предлагаю повысить читаемость кода именно веб-приложений, онлайн игр, приложений кинотеатра для смарт-тв(они тоже на html написаны), калькуляторов всяких, интерактивных карт, почтовых клиентов, crm, админок, ПРИЛОЖЕНИЙ - которые чтобы увидеть надо пароль ввести - которые не индексируются, в которых нет контента для запуска screen reader, приложений которые пишется под свою webview / electron / cordova , таких как slack , как веб-версия телеграм или whatsapp , а не чисто контентных/новостных сайтов где самое главное не просесть в поисковике и добится максимально быстрой индексации и ранжирования.
Третий аргумент — утилитарные классы и микроформаты. Даже если заменить <div class="card"> на <app-card>, может возникнуть желание использовать микроформаты на основе классов. Или размечать классами-модификаторами разные варианты карточек. Или использовать утилитарные классы для текста. Во всех случаях добавляется один или несколько классов. Получаем <app-card class="text-italic color-secondary">. Вернулся к атрибуту class. Сильно ли это отличается по объёму от <div class="card text-italic color-secondary"> и стоит ли оно того?
Дело в объеме кода как такового, а в объеме бессмысленного ничего не говорящего бойлерплейт кода. И даже если в общем символов больше - то типовых, ничего не значащих символов всё равно меньше.
Если мы захотим использовать микроразметку или добавлять классы своим тегам - мы да так и напишем <app-card class="text-italic color-secondary"> но в коде ниже у нас будет говорящий закрывающий тег </app-card> а не безликий </div>
И есть логическое разделение сущностей , согласитесь что css класс .card это вот что-то совсем не то же самое по своему назначению, что .color-secondary , а в случае использования div мы ставим их на один уровень. Когда тже мы используем app-card - мы в своем коде разделяем эти понятия, что вот есть карточка и у нее есть свои или внешние доп классы
По поводу Reader Mode - пожалуйста уточните вы имеете ввиду режим чтения когда браузер меняет внешний вид страницы? или режим озвучивания для слабовидящих?
Если вы про вытаскивание текста из страницы - то это и сейчас не работает даже если использовать div Попробуйте открыть в таком режиме интерфейс почты или календаря или вот вам пример из safari для новой главной страницы яндекса
Hidden text
Для корректной работы таких читалок сайт в большинстве случаев нужно специально адаптировать и название используемых тегов там не играют роли. Все равно нужно написать стили для печатной версии @media print {} а в них так же можно задать стили кастомным тегам как и классам. + остаются веб-приложения где такой режим как-бы не нужен - в доске trello например или в интерфейсе github как вы считаете reader mode имеет смысл ?
Если же вы говорите о программах которые озвучивают текст - то что для div что для my-tag-name - нужно писать aria атрибуты тут тоже нет разницы
что касается дописывания display:block - во первых gzip сжатие =) ну и тут уже вкусовщина - я за явное определение в css того как элемент должен отображаться вот допустим у вас в css класс .wallet - допустим он применен к div - я за то чтобы в нем однозначно было написано что он блочный, хотя на практике все чаще flex или grid или inline-block то есть в css все равно даже если использовать div - стоит указывать display
вам нужно спорить не со мной нарциссом, а с текстом статьи, кто бы не был ее автором, приводя и подкрепляя весомые аргументы, не переходя на личности, вы же так или иначе все сводите к обсуждению автора материала, его энтузиазму опыту и психологическим особенностям
Вот дело как раз в том, что уже давно, такая опция, by desing, есть и в html Но разработчики её не используют... продолжая верстать интерфейс приложений как будто это текст книги
нет это вы используете назидательный тон по отношению ко мне, почти в каждом своем сообщении, вот цитаты: - "Ваш бы энтузиазм да в правильное русло направить" - "Попробуйте изучить реакт, вьюжс или ангуляр, там как раз" - "если хотите вменяемо конкурировать на рынке с другими опытными фронтенд специалистами" из-за этого у читателя в голове формируется образ как взрослый опытный дядя говорит какому-то новичку что нельзя писать так как ему вздумается. Тем самым в глазах читателя вы понижаете авторитет автора - просто говоря с ним свысока, за счет чего у невнимательного читателя срабатывает когнитивное искажение - что раз источник "плохой" - то и информация которую он сообщает ложна.
понимаете? А это я собеседую этих фронтенд специалистов и вот кто про такие теги даже не слышал - у меня собес не пройдет )
Предлагаю вернуться к тегам. Где это не работает? Вы же видите что код однозначно читабельнее , что тег это просто <></> а его имя можно придумывать так же как имя переменной. И развитие стандарта html привело к тому что они сделали возможным создавать свои теги на случай если не достаточно имеющихся , но разработчики продолжили все оборачивать в div и span, даже нишевые решения, аппки для webview приложения заточенные только под одну платформу smartTV например.
"а пока вы напоминаете мне меня же 10 лет назад" - ну вот это что? я старше вас, мне 36 лет, вам полагаю около 32, и разработкой занимаюсь дольше. Комплимент что я не растерял энтузиазм за годы в айти и продолжаю смотреть на привычные вещи свежим взглядом?
А вот чтобы миллионы разработчиков по всему миру согласовали непонятное количество имен тегов - утопия.
я же не говорю о том чтобы в разных проектах использовали одинаковые согласованные имена "новые" имена тегов. - это будут примерно английские слова - которые поисковики научаться анализировать.
вообще не понимаю чего вы так прицепились когда сами пишете статьи про веб-компоненты? c точки зрения семантики я делаю почти то же самое только говорю что еще не всегда обязательно этот тег регестирировать.
вам куча народа об этом сказала и рейтинг вашей статьи тоже намекет.
нет уж простите - говорите об этом только вы и еще пара человек в комментариях и постоянно пытаетесь выставить лично меня не компетентным, что-то про мою конкуренцию с другими фронтенд разработчиками. Не нужно пожалуйста критиковать описанный в статье подход через понижения авторитета его автора в глазах аудитории ok? И рейтинг статьи положительный и много кто добавил ее в закладки - сравните это с другими публикациями за последние сутки - так что ни на что он не намекает.
Что касается "скринридеров" и иже с ними - ну допустим есть какие-то программы которые это не обработают, но html например для electron приложения так можно писать? или для веб версии crm / мессенджера? Если посмотреть на современные SPA , дашборд в админке или интерфейс конструктора сайтов , там каким боком вообще нужны стандарты seo и скринридеры?
Опять же если эта практика станет больше распространена то и seo / поисковики подстроятся, выработают новые эрвистики на основе имен тегов. И то что google вводил новый формат разметки для amp страниц, яндекс так же для своих быстрых страниц, а telegram устраивал конкурс с разметкой популярных сайтов для корректной работы своего instantview говорит о том что текущая верстка сайтов не особо им помогает разбирать контент.
Вы можете мне ответить на этот вопрос что-то кроме "так нельзя" / "иди учи реакт" / "верстать" и тому подобное?
Но то что emmet упрощает генерацию бойлерплейта - он же все равно его генерирует и далее этот код существует и отправляется на клиент, а можно вообще жить без это кода. Я надеялся что кто-то такой же дотошливый как и я сможет скинуть ссылку на программу которая текст из div class=text может прочитать, а из тега text или my-text не может. Но с таким я пока не сталкивался, отсюда и вывод что это код, пусть его и AI генерирует, не нужен никому, ни на каком этапе.
Специальным браузерам точно так же, что прост div что кастомный тег, нет разницы и для div нужно прописывать aria чтобы придать ему смысл и для кастомного тега так же
То есть вы тот описанный в статье человек, который боится что где-то, когда-то , "на умном холодильнике" что-то пойдет не так
Если какие-то парсеры всё-таки споткнутся о кастомный тег - значит и веб-компоненты нельзя использовать? Ну давайте тогда будем их использовать хотя бы в приложениях которые не предназначены для парсинга, онлайн играх, этих вот телеграмм ботов со встроенным web-app , закрытых админках и crm?
Ну если никак не учите то будете так же читать доки по дизайн системе. Что там внутри кастомное не кастомное имя на уровень абстракции выше не попадет.
Но опять же, вы апеллируете к своему личному опыту и своей персональной насмотренности, к субъективному восприятию чужого кода которое коротко можно описать одной фразой - "так сложилось что я привык по другому и лень переучиваться"
А с инженерной точки зрения есть что сказать по поводу качества работы такого кода? Если например представить что вам не нужно его писать, а вы только пользователь, на комп которого загружается такой вот код. Ведь в конце концов программирование создано не для вашего удобства чтобы вам на работе было комфортно сидеть, а для того чтобы решать задачи пользователей программных продуктов и если вы как разработчик давно не замечаете трёх сущностей в коде, то может как пользователь видите что на некоторых сайтах устройство нет-нет да залагает от парсинга всего этого энтерпрайза?
Когда я вижу кастомный тег, я в первую очередь думаю про наличие веб-компонента
Всё бывает в первый раз, это как раз таки из-за того что такой подход в новинку, а это из-за того что его мало кто использует.
Но если это веб-компонент то это как-то по другому видно, потому что есть такой файл например и он где-то импортируется выше, ну у меня vscode по клику перекидывает в него.
В принципе можно договориться что если тег из нескольких частей через чёрточки - то веб-компонент, а если всё слитно - то просто тег.
То что вы сейчас испытываете называется когнитивное сопротивление, это нормально когда встречаешься с чем-то новым.
А вот то что возможность языка которая в нем уже кучу лет для опытных разработчиков является чем-то новым не нормально
Вы даёте мне странные советы. Посмотрите мой профиль что ли.
Я написал на angular ни одно приложение. Знаю реакт лучше многих, это пожалуй основной фреймворк на котором я пишу на работе, ну и было несколько проектов на vue. А ещё в прошлом riotjs , meteor, backbone.
Я прекрасно знаю как в каком фронтенд фреймворке делается вёрстка и все нюансы со стилизацией и организацией как компонент так и вообще ui китов.
Надеюсь мне не доведётся работать на проектах, где надо учить собственные хтмл теги, которые ничего кроме кастомного имени под собой не имеют
Ну свои собственные переменные и имена классов в новом проекте вы же как-то учите? Имя тега в данном случае призвано заменить название одного из его css классов не более того
На счет копирастов - нуу интереная мысль с одной стороны... с другой - это только фронтенд - обычно есть же еще остальная немаловажная часть проекта - бэк и обсуфицированный js код . Думаю эта результирующая верстка все равно не являющаяся исходным кодом а лишь сгенерированная им, мало чего даст желающим скопировать проект.
и то и другое - это html код календарей - там нет особо тегов для разметки текста это datepicker'ы, только в одном случае все на одних только div и span а в другом с именованными тегами
тегов с осмысленными названиями толком не было и нет до сих пор на сайтах
в стать об этом написано - читайте внимательно - в частности про заголовки заменять в первую очередь я как раз предлагаю абстрактные div и span
но если вы замените h1 н
а я не заменю h1 потому что это нецелесообразно, но если мне по каким-то другим причинам(которых я пока не придумал) понадобится сделать кастомный тег для заголовка то я пропишу ему role="heading" aria-level="1" так что семантика будет сохранена.
Практический смысл как раз таки есть в моем подходе, а вот практического смысла писать div вместе с атрубутом class - нет В практическом смысле в памяти браузера объект с установленным атрибутом занимает больше места , ну если совсем грубо то как-то так:
<div class="test"></div>
// в памяти браузера это
HTMLElement {
...
nodeName: 'div'
attributes: [ class ]
classNames: ['test']
...
}
<test></text>
// в памяти браузера это
HTMLElement {
...
nodeName: 'test'
...
}
при прочих равных и одинаковой функциональности этот тег меньше жрет всех ресурсов, с одной стороны это мелочи, с другой - тегов тысячи ... но если уж вообще рассуждать о некотором практическом смысле - то все же - чем меньше свойств тем быстрее работает. Да компы быстрые не играет роли свой тег или блок с классомб по скорости там тысячные доли миллисекунды разницы, но это все равно просто не имеет смысла, тому нет причин больше печатать чтобы оно потом дольше грузилось.
Послушайте мистер php разраб, вы не оборзели? Я же просил вас вот в этом комментарии перестать говорить свысока типа я какой-то стажер, а вы умудренный опытом сеньер-помидор.
Вы зачем говорите про "отсутствие навыков с веб фреймворками " и что мне нужно подтягиваться до какого-то уровня?
Вы верстку своего сайта https://manytomany.ru/ до современного уровня подтяните.
Вот мое резюме - https://career.habr.com/a-l-e-x-s-t-e-p я работал в том числе в известных "проверенных" так сказать, компаниях в том числе делал фронт приложений которыми пользуются и сейчас сотни людей, когда-то работал лидом и руководил такими вот сайто-делами. Писал на angular, vue, react , но сейчас больше react . Но нет, наверно во всех компаниях подряд на всех собеседованиях все эти годы люди ошибались я то оказывается и фреймворки их знать не знаю и верстать не умею )
Зачем вы упорно тыкаете в мою вымышленную вами некомпетентность и незнание современного стека разработки под веб?
Если использовать имена тегов без черточек - да. Это уход от стандарта, но - можно именовать теги как
my-tagв таком случае стандарт соблюден+ из-за нарушения стандарта в случае с именованием тегов - не наступает никаких последствий - то есть да правило нарушено - но ничего плохого из-за этого не происходит.
Нормально люди будут читать такие теги, будут видеть говорящее имя. Да любое восприятие личное, нет же какого-то общественного восприятия? Это какая-то философия а не аргумент.
Не будет проблем с SEO. Еще раз - мы продолжаем использовать теги h1-h6, strong, article, form и так далее - а отказываемся только от div - который не несет в сеюе никакой семантики.
Семантика - https://ru.wikipedia.org/wiki/Семантика - это буквально смысл.
И я как раз и призываю вкладывать смысл в названия тегов, английскими словами. Опять же размечать списки с помощью <li> параграфы <p> а меню выносить в <nav>
То есть моя верстка - семантичная , а div class - не семантично
У всех будут проблемы со скринридером кто не оптимизировал свой сайт под него, особенно если это electron приложение с доской задач а-ля trello
Да нет цели эконоить символы я прошу вместо </div> писать </person> это конечно больше символов - чтобы явно видеть какие теги закрываются и да оучше писать в css свойство display чтобы по css коду явно было видно как этот элемент отображается. Я за наглядность, а не за экономию символов.
Бойлерплейта в итоге не больше. Я же не говорю отказываться от css классов, так же их можно переиспользовать. Но если оформление какого-то блока индивидуально - то его можно записать в сили тега а не в класс который иначе бы использовался в проекте только один раз
В ответе на другой комментарий я разобрал этот вопрос - не не хуже а так же или лучше.
Да и блин, вы серьезно будете парится из-за пары килобайт разницы в сжатии на всю html страницу?
Результаты сжатия gzip
Вот папка с примерами файлов и сжатыми их версиями
Если использовать теги с черточками то нет.
Шанс что повится тег с таким же вот прям именем очень низкий.
То есть чисто теоретически - могу, а могу и не напороться. Мы недавно все напоролись на то что докер образы перестали пулиться - фигня случается, адаптируемся.
Что случится если появится новый тег? Браузер для него свои стили допишет? Обычно я использую некое подобие reset.css , но может, действительно может где-то чутка поеет верстка - поправить дело 5 минут. В вебе постоянно что-то обновляется и меняется, потому мы и занимаемся поддержкой.
Но все эе вы понимаете насколько низкий шанс такого случая?
Допускает - но это на совести разработчика - не надо именовать свои теги названиями существующих пусть и в прошлом тегов, хоть на работе сайта это никак и не отразится.
Я их не игнорирую - они просто за рамками этой статьи и никак не связаны с именованием тегов. Opengraph остается opengraph'ом и так же пишется, микроразметка - так же добавляется.
Я не мечтаю и это не мои теги ... даже не знаю что на это сказать сказать... я же не новый стандарт вам втюхиваю - это ваши теги - ваши названия тегов которые вы придумаете сами так же как придумываете названия переменным.
Вот именно что фреймворки - синтаксический сахар и в нем все равно внутри "православный" div. Блин ощущение что я с верующим спорю о боге ))) нет проблем в пунктах выше - нечего избегать.
Тому нет доказательств. Я проверял, на телевизорах, смарт-часах, разумеется телефонах, старых iphone 4,5 , дополнительно на сайте browserstack смотрел с разных устройств.
Могу сказать что это не работает в IE6. ну и в терминальных браузерах типа links , вот эти теги всегда отображаются как строчные элементы.
Я не понял что вы имеете ввиду... RSS это отдельный XML формат , для генерации rss пишут отдельные скрипты которые берут контент из БД и отдают xml
Ну не нужно размечать текст ВЕЗДЕ своими тегами. Но опять же если текстовый контент в RSS ленте разметить через дивы с классами - тоже ерунда получится.
Ну и в целом я предлагаю повысить читаемость кода именно веб-приложений, онлайн игр, приложений кинотеатра для смарт-тв(они тоже на html написаны), калькуляторов всяких, интерактивных карт, почтовых клиентов, crm, админок, ПРИЛОЖЕНИЙ - которые чтобы увидеть надо пароль ввести - которые не индексируются, в которых нет контента для запуска screen reader, приложений которые пишется под свою webview / electron / cordova , таких как slack , как веб-версия телеграм или whatsapp , а не чисто контентных/новостных сайтов где самое главное не просесть в поисковике и добится максимально быстрой индексации и ранжирования.
ну и про микроформаты...
Дело в объеме кода как такового, а в объеме бессмысленного ничего не говорящего бойлерплейт кода. И даже если в общем символов больше - то типовых, ничего не значащих символов всё равно меньше.
Если мы захотим использовать микроразметку или добавлять классы своим тегам - мы да так и напишем
<app-card class="text-italic color-secondary">но в коде ниже у нас будет говорящий закрывающий тег</app-card>а не безликий</div>И есть логическое разделение сущностей , согласитесь что css класс
.cardэто вот что-то совсем не то же самое по своему назначению, что.color-secondary, а в случае использования div мы ставим их на один уровень. Когда тже мы используемapp-card- мы в своем коде разделяем эти понятия, что вот есть карточка и у нее есть свои или внешние доп классыКлассы и атрибуты микроразметки продолжают работать, говорящее имя тега им не мешает , можете проверить - https://webmaster.yandex.ru/tools/microtest/
Картинка с валидацией микроразметки
По поводу Reader Mode - пожалуйста уточните вы имеете ввиду режим чтения когда браузер меняет внешний вид страницы? или режим озвучивания для слабовидящих?
Если вы про вытаскивание текста из страницы - то это и сейчас не работает даже если использовать div
Попробуйте открыть в таком режиме интерфейс почты или календаря или вот вам пример из safari для новой главной страницы яндекса
Hidden text
Для корректной работы таких читалок сайт в большинстве случаев нужно специально адаптировать и название используемых тегов там не играют роли. Все равно нужно написать стили для печатной версии
@media print {}а в них так же можно задать стили кастомным тегам как и классам.+ остаются веб-приложения где такой режим как-бы не нужен - в доске trello например или в интерфейсе github как вы считаете reader mode имеет смысл ?
Если же вы говорите о программах которые озвучивают текст - то что для div что для my-tag-name - нужно писать aria атрибуты тут тоже нет разницы
что касается дописывания display:block - во первых gzip сжатие =)
ну и тут уже вкусовщина - я за явное определение в css того как элемент должен отображаться
вот допустим у вас в css класс .wallet - допустим он применен к div - я за то чтобы в нем однозначно было написано что он блочный, хотя на практике все чаще flex или grid или inline-block
то есть в css все равно даже если использовать div - стоит указывать display
Спасибо! Мне нравится ваш серьезный вдумчивый подход.
Но на счет сжатия хоть это и звучит на первый взгляд правдоподобно, там как минимум нет разницы - количество токенов идентично.
Вот примеры сжатых через gzip файлов - https://drive.google.com/drive/folders/1Uijwa_bV0ULh72T3jlZJtC5jj9_d96nW?usp=sharing
Может их открыть и сами убедиться в том что файлы идентичны
Если в файл custom.html добавить хоть один div - то размеры сжатых файлов будут одинаковые - этот пример лежит в папке two
вам нужно спорить не со мной нарциссом, а с текстом статьи, кто бы не был ее автором, приводя и подкрепляя весомые аргументы, не переходя на личности, вы же так или иначе все сводите к обсуждению автора материала, его энтузиазму опыту и психологическим особенностям
Вот дело как раз в том, что уже давно, такая опция, by desing, есть и в html
Но разработчики её не используют... продолжая верстать интерфейс приложений как будто это текст книги
нет это вы используете назидательный тон по отношению ко мне, почти в каждом своем сообщении, вот цитаты:
- "Ваш бы энтузиазм да в правильное русло направить"
- "Попробуйте изучить реакт, вьюжс или ангуляр, там как раз"
- "если хотите вменяемо конкурировать на рынке с другими опытными фронтенд специалистами"
из-за этого у читателя в голове формируется образ как взрослый опытный дядя говорит какому-то новичку что нельзя писать так как ему вздумается. Тем самым в глазах читателя вы понижаете авторитет автора - просто говоря с ним свысока, за счет чего у невнимательного читателя срабатывает когнитивное искажение - что раз источник "плохой" - то и информация которую он сообщает ложна.
понимаете? А это я собеседую этих фронтенд специалистов и вот кто про такие теги даже не слышал - у меня собес не пройдет )
Предлагаю вернуться к тегам. Где это не работает?
Вы же видите что код однозначно читабельнее , что тег это просто
<></>а его имя можно придумывать так же как имя переменной. И развитие стандарта html привело к тому что они сделали возможным создавать свои теги на случай если не достаточно имеющихся , но разработчики продолжили все оборачивать в div и span, даже нишевые решения, аппки для webview приложения заточенные только под одну платформу smartTV например."а пока вы напоминаете мне меня же 10 лет назад" - ну вот это что?
я старше вас, мне 36 лет, вам полагаю около 32, и разработкой занимаюсь дольше. Комплимент что я не растерял энтузиазм за годы в айти и продолжаю смотреть на привычные вещи свежим взглядом?
я же не говорю о том чтобы в разных проектах использовали одинаковые согласованные имена "новые" имена тегов. - это будут примерно английские слова - которые поисковики научаться анализировать.
вообще не понимаю чего вы так прицепились когда сами пишете статьи про веб-компоненты? c точки зрения семантики я делаю почти то же самое только говорю что еще не всегда обязательно этот тег регестирировать.
нет уж простите - говорите об этом только вы и еще пара человек в комментариях и постоянно пытаетесь выставить лично меня не компетентным, что-то про мою конкуренцию с другими фронтенд разработчиками. Не нужно пожалуйста критиковать описанный в статье подход через понижения авторитета его автора в глазах аудитории ok?
И рейтинг статьи положительный и много кто добавил ее в закладки - сравните это с другими публикациями за последние сутки - так что ни на что он не намекает.
Что касается "скринридеров" и иже с ними - ну допустим есть какие-то программы которые это не обработают, но html например для electron приложения так можно писать? или для веб версии crm / мессенджера? Если посмотреть на современные SPA , дашборд в админке или интерфейс конструктора сайтов , там каким боком вообще нужны стандарты seo и скринридеры?
Опять же если эта практика станет больше распространена то и seo / поисковики подстроятся, выработают новые эрвистики на основе имен тегов.
И то что google вводил новый формат разметки для amp страниц, яндекс так же для своих быстрых страниц, а telegram устраивал конкурс с разметкой популярных сайтов для корректной работы своего instantview говорит о том что текущая верстка сайтов не особо им помогает разбирать контент.
Вы можете мне ответить на этот вопрос что-то кроме "так нельзя" / "иди учи реакт" / "верстать" и тому подобное?
Хорошие доводы, спасибо!
Но то что emmet упрощает генерацию бойлерплейта - он же все равно его генерирует и далее этот код существует и отправляется на клиент, а можно вообще жить без это кода. Я надеялся что кто-то такой же дотошливый как и я сможет скинуть ссылку на программу которая текст из div class=text может прочитать, а из тега text или my-text не может. Но с таким я пока не сталкивался, отсюда и вывод что это код, пусть его и AI генерирует, не нужен никому, ни на каком этапе.
Специальным браузерам точно так же, что прост div что кастомный тег, нет разницы и для div нужно прописывать aria чтобы придать ему смысл и для кастомного тега так же
То есть вы тот описанный в статье человек, который боится что где-то, когда-то , "на умном холодильнике" что-то пойдет не так
Если какие-то парсеры всё-таки споткнутся о кастомный тег - значит и веб-компоненты нельзя использовать? Ну давайте тогда будем их использовать хотя бы в приложениях которые не предназначены для парсинга, онлайн играх, этих вот телеграмм ботов со встроенным web-app , закрытых админках и crm?
Ну если никак не учите то будете так же читать доки по дизайн системе. Что там внутри кастомное не кастомное имя на уровень абстракции выше не попадет.
Но опять же, вы апеллируете к своему личному опыту и своей персональной насмотренности, к субъективному восприятию чужого кода которое коротко можно описать одной фразой - "так сложилось что я привык по другому и лень переучиваться"
А с инженерной точки зрения есть что сказать по поводу качества работы такого кода? Если например представить что вам не нужно его писать, а вы только пользователь, на комп которого загружается такой вот код. Ведь в конце концов программирование создано не для вашего удобства чтобы вам на работе было комфортно сидеть, а для того чтобы решать задачи пользователей программных продуктов и если вы как разработчик давно не замечаете трёх сущностей в коде, то может как пользователь видите что на некоторых сайтах устройство нет-нет да залагает от парсинга всего этого энтерпрайза?
Всё бывает в первый раз, это как раз таки из-за того что такой подход в новинку, а это из-за того что его мало кто использует.
Но если это веб-компонент то это как-то по другому видно, потому что есть такой файл например и он где-то импортируется выше, ну у меня vscode по клику перекидывает в него.
В принципе можно договориться что если тег из нескольких частей через чёрточки - то веб-компонент, а если всё слитно - то просто тег.
То что вы сейчас испытываете называется когнитивное сопротивление, это нормально когда встречаешься с чем-то новым.
А вот то что возможность языка которая в нем уже кучу лет для опытных разработчиков является чем-то новым не нормально
Вы даёте мне странные советы. Посмотрите мой профиль что ли.
Я написал на angular ни одно приложение. Знаю реакт лучше многих, это пожалуй основной фреймворк на котором я пишу на работе, ну и было несколько проектов на vue. А ещё в прошлом riotjs , meteor, backbone.
Я прекрасно знаю как в каком фронтенд фреймворке делается вёрстка и все нюансы со стилизацией и организацией как компонент так и вообще ui китов.
Ну свои собственные переменные и имена классов в новом проекте вы же как-то учите? Имя тега в данном случае призвано заменить название одного из его css классов не более того
Вторая картинка это валидный именно html код который исполняют браузеры.
Я не хочу с вами спорить о том что есть xml а что html вот тут неплохо описали разницу - https://habr.com/ru/articles/810945/ и тут https://habr.com/ru/articles/252283/
На счет копирастов - нуу интереная мысль с одной стороны... с другой - это только фронтенд - обычно есть же еще остальная немаловажная часть проекта - бэк и обсуфицированный js код . Думаю эта результирующая верстка все равно не являющаяся исходным кодом а лишь сгенерированная им, мало чего даст желающим скопировать проект.
я в статье говорю что для заголовка лучше использовать h1
и про тег article так же сказал
про SEO говорится что нет разницы между ничего не значащим <div class="bar" и ничего не значащим <bar>
ну и в конце концов - вот в интерфейсе почты например или календаря для авторизованного юзера разве нужно SEO ? - посмотрите я тут примеры кода скинул - https://habr.com/ru/articles/819465/#comment_26899193
я предлагаю вместо вот такого кода
писать вот такой
и то и другое - это html код календарей - там нет особо тегов для разметки текста это datepicker'ы, только в одном случае все на одних только div и span а в другом с именованными тегами
тегов с осмысленными названиями толком не было и нет до сих пор на сайтах
в стать об этом написано - читайте внимательно - в частности про заголовки
заменять в первую очередь я как раз предлагаю абстрактные div и span
а я не заменю h1 потому что это нецелесообразно, но если мне по каким-то другим причинам(которых я пока не придумал) понадобится сделать кастомный тег для заголовка то я пропишу ему
role="heading" aria-level="1"так что семантика будет сохранена.Практический смысл как раз таки есть в моем подходе, а вот практического смысла писать div вместе с атрубутом class - нет
В практическом смысле в памяти браузера объект с установленным атрибутом занимает больше места , ну если совсем грубо то как-то так:
при прочих равных и одинаковой функциональности этот тег меньше жрет всех ресурсов, с одной стороны это мелочи, с другой - тегов тысячи ... но если уж вообще рассуждать о некотором практическом смысле - то все же - чем меньше свойств тем быстрее работает. Да компы быстрые не играет роли свой тег или блок с классомб по скорости там тысячные доли миллисекунды разницы, но это все равно просто не имеет смысла, тому нет причин больше печатать чтобы оно потом дольше грузилось.