Комментарии 41
Можно посмотреть на избыточные свойства и с другой стороны. Они не создают побочные эффекты. Они делают их явными. Помогают писать тупой и непробиваемый код.
Сказал block - значит block. И точка. Никаких связей с чем-то, что где-то там у родителя может когда-то поменяться каким-то модификатором пойди еще пойми где.
Стандартный набор отступов у компонента? Вот такой. Как написано, так и читать. Никаких связей с чем-то, что мы откуда-то унаследуем и расширим, а может и не будем, а может будем, но где-то потом. Нет. По умолчанию все явно. А если где-то магия и происходит, то ее сразу видно по неполным наборам свойств.
Я бы не сказал, что такой код становится однозначно плохим из-за своей формальной избыточности. Можно постоянно помнить скрытую логику в CSS, адаптироваться к ней, а можно перебивать ее, и продавливать свою систему мышления. Такой подход вполне имеет право на жизнь, если его целенаправленно везде применять.
Да, я тоже именно из таких соображений явно пишу display: block
В примере с background ровно то же самое. Если бы автор хотел установить только цвет, наследуя что-то ещё, он бы так и написал. В данном примере он явно отменяет всякие картинки и прочее, что там может вылезти из наследования.
Тоже себе интересный момент себе подметил про атрибуты alt, думаю не следует его оставляться пустым:
1) как минимум никогда нельзя исключать того факта что ссылка перестанет работать, и что тогда у пользователей будет? Ничего. Поэтому если даже писать плохой alt - то это лучше, чем если у пользователей при ситуации когда не будет картинки, будет пустой блок.
2) если рассматривать с точки зрения seo, если мы пропустим на картинке допустим атрибут alt, то w3c - будет не соблюдено и будет ругаться
Вы говорите о контентных изображения. В статье пример декоративных. Для них принятая практика оставлять пустой alt
Названный вами валидатор не будет ругаться на пустой alt
Да вы правы в целом.
Для джунов думаю полезнее было бы:
1) Сохранять Семантику header, footer, section
2) Сохранять структуру БЭМ - оооочень много кто это упускает и пишет нейминг для class или id, как ему в голову взбредет
3) Не трать время на выписывание всех возможных атрибутов куда-нибудь в блокнот(я так делал мне стыдно), соблюдай семантику и БЭМ, а корректность и валидность проверяй валидатором (validator.w3.org)
-----
Все что стоит запомнить Семантика + БЭМ + элементарная стилизация с адаптивом, не стой долго на HTML + CSS, максимум недели 3-4 не более, все нужны теги или атрибуты придут со временем. Вот что я бы посоветовал джунчикам
вот сколько ни пытаюсь писать бэм, никак до конца понять его не могу. Вроде бы и пишу теги, как мне строго говорят в правилах и думаю, а вдруг другой человек пишет совсем по-другому, может бэм - бэму рознь?..
Имхо - БЭМ уже давно устарел и не особо нужен. И я даже не про новомодных подход атомарного CSS, а про фронтовые фреймворки с компонентным подходом. Все они позволяют писать CSS, не опираясь на глобальные стили. Лично я стараюсь даже классы не писать, просто пишу div {} и поехали стилизовать
просто пишу div {} и поехали стилизовать
То есть вы фактически наделяете div свойствами id, потому что второго в разметке появиться не может? Понятно, что только в пределах компонента, но тем не менее. Прэлэстно! (голосом вороны из мультика про Кешу)
А что насчёт проектов, которые не используют фронтовые фреймворки с компонентным подходом? Мир ими не ограничивается, есть огромное количество альтернативный технологических стеков. БЭМ ни разу не устарел и всё ещё отличный способ общаться на одном языке, писать консистентный и понятный код.
Я джун и я так и не понял, почему в примере указание alt «аватар пользователя» это хуже, чем без указания. Особенно в условиях читалки для слепых.
аватар пользователя не декоративный элемент. в данном случае альт заполнять нужно было. даже если это иконка.
Полностью согласен. Раздражает, когда на сайте не отображается картинка, и на её месте или стандартная заглушка, или вообще нет текста. Лучше будет коротко, но ясно.
Автор сам походу Джун
Первым элементом, на который я попаду клавишей Tab, будет кнопка «Закрыть». Так получится, потому что в разметке она находится первым интерактивным элементом. Потом уже идут элементы input и другие.
А почему сразу фокус в input не установить при показе модалки, чтобы вам вообще Tab нажимать не нужно было?
Да, так надо сделать. Это поможет при открытии окна в первый раз. Но также нужен и порядок элементов.
1. Если перенос по какой-то причине не сработал
2. Он помогает, когда прошелся по всем элементам формы и еще раз заходишь "на круг"
Зачем чинить то, что не сломано?
Я читаю контент, всплывает модальное окно "подпишитесь на новостную рассылку" или "зарегистрируйтесь". Я по табу попадаю на кнопку "закрыть", жму в нее и читаю дальше. Что не так? Идеальный флоу, ничего не сломано
Вы говорите о другом примере. В целом поднимаете непростой вопрос. У меня в черновиках есть статья на эту тему. В будущем постараюсь написать.
Если отвечать на ваш вопрос, то все зависит от конкретного примера, потому что паттерны поведения в них разные. Следовательно и перенос фокуса будет разный. Где-то нужно поле ввода, где-то кнопка.
В случае модальных окон, я всегда рекомендую придерживаться подхода, описанного в гайдах carbon design system:
Tab order
First interactive element in the body area.
Proceed left to right and top to bottom through the rest of the body elements.
Primary action
Secondary action
Close icon
Это относиться к модальным окнам, содержащим интерактивные элементы (за исключением ссылок). Если у вас в модальном нет никаких элементов форм, то да, фокус в таком случае ставите просто на кнопку «закрыть»
Но почему многие разработчики так делают? Да, потому что они не знают, что вписать в атрибут alt
Странная проблема. А сами картинки ои где берут? Может там возьмут и то, что вписать?
В первом примере autofocus?
Товарищи верстальщики, будьте уважительны к пользователям - не замусоривайте неудаляемыми ни с помощью uBlock, ни с Adnauseam графическими элементами, замусоривающими текст. Даже рекламные поля зачастую скрыть оказывается легче, чем эти бессмысленные картиночки ни о чём посреди текста. Даже когда удаляется скрыть саму картинку - зачастую остается просто пустое пятно.
Рекламодатели уже усвоили, что если чел не хочет смотреть рекламу он в любом случае либо заблокирует ее, либо при невозможности скрыть - просто уйдет. Это приучило их основную массу хоть к какой-то адекватности. Но вот владельцы сайтов и верстальщики еще не уяснили этой просто истины.
В первом примере и вообще во всех формах tabindex="0" и т.д.
Это must have атрибут для инпутов и прочего.
В этом случае я попаду на первый элемент input после нажатия клавиши Tab. Сразу смогу ввести номер телефона и авторизоваться. Красота!
А кто-то скажет, что у него уже сохранен номер телефона в браузере, и первым должен идти Submit ;-)
По общению с незрячими людьми я понял, что основная потребность в атрибуте
altу них возникает в контентных частях приложений. Например, когда мы выбираем одежду, то смотрим на её фотографии.Пользователи скринридера тоже так хотят делать. Здесь как раз уместно альтернативное описание, передающее недостающую информацию, которую зрячие люди получают глазами.
и каким же образом разраб должен знать, что будет на картинке очередного товара тысячного продавца из маркетплейса?
в альте? да просто вывод переменной названия товара в нужном сео шаблоне, который утвердил в проекте сеошник.
Не знаю, как происходит заполнение в маркетплейсах, но например в CMS зачастую есть специальное поле, куда уже менеджер контента и должен вписывать такой текст.
Разрабы никак не смогут учесть все варианты текстов для картинок в интернет-магазинах.
Так же можно подключить ИИ, который сам сгенерирует описание картинки по содержимому
Мой любимый кейс, вместо всевозможных тэгов использовать один только dvi, как кнопку, картинку, поле ввода и прочее.
Точно все вот это для джунов?
Лично я считаю тут прочитал очень много вкусовщины и субъективной информации.
Не буду писать кучу текста, загрловками:
<dialog>, tabindex
alt - хочется спросить, что ты такое несешь и что тв вообще знаешь про семантический веб, но вот как слепые получают эту информацию, я на самом деле не знаю.
:hover, :focus - чистая вкусовщина.
background - в целом, хороший тон, задавать те свойства которые необходимы.
добавляйте, блять, свойство display, когда вам это нужно! Оно поможет вам задать более предсказуемое поведение элементов, кроме тех случаев, когда у вас в е элементы div div div, в этом случае почитайте про семантическую верстку 🙏🏻
Мое заключение: все что написано в статье, НИЧЕГО нету про ошибки джунов (о боже как так можнА делаДь).
Поменяйте название на: «Особенности верстки для слабовидящих» и мой комментарий можно выкинуть.
Андрей, 15 лет во фронте, имхо
Дорогие джуны, не делайте так. Коллекция плохих привычек в HTML и CSS