Как стать автором
Обновить

Комментарии 41

Хотя разработчики могли использовать rem'ы, и у меня не было бы неудобств.
Можете поподробнее объяснить этот пункт? Rem'ы это ведь те же пиксели.
НЛО прилетело и опубликовало эту надпись здесь
Rem зависит от html тега, но это я прекрасно понимаю, не понимаю в чем отличие для автора, когда это те же пиксели, и что одно, что другое можно легко изменить.

Rem зависит от настроек браузера. Если там размер шрифта выставлен не дефолтный в 16px, то размер в rem тоже будет другим, пропорционально шрифту, тогда как размер в пикселях можно изменить только зумом.

Тогда я бы указал что нельзя устанавливать font-size для html, так как в итоге настройки браузера будут просто игнорироваться.

font-size тоже можно через rem задавать.

Не до конца понял о чем вы, rem зависит от значения font-size в теге html, и только от этого значения, в настройках браузера можно менять стандартный font-size в html, но он лишь изменяет стандартное значение, и если задать конкретное значение:

html {
  font-size: 10px;
}

то один rem будет всегда равняться 10 пикселям, и никакие настройки браузера вам не помогут, а так как много кто устанавливает значения font-size именно в теге html, то не понятно в чем смысл менять px на rem.
Есть смысл. Необходимо установить размер шрифта в 100% на тэг html.
html {
    font-size: 100%;
}

Тогда все значения в rem будут высчитываться от html, который равен настройкам браузера (что [в большинстве случаев] будет равняться 16px).
это происходит без вашего участия. Свойство font-size наследуемое, поэтому указывать 100% или inherit не нужно.
Да, но есть один нюанс — многие CSS–фреймворки имеют обычай данное правило переопределять. Например, UIKit по-умолчанию устанавливает 16px на тег html (это было месяца 3 назад, текущую ситуацию не знаю).
Мой комментарий скорее о том, что необходимо убедиться, что font-size на html элементе установлен в значение, которое будет равняться браузерному. Лучше всего его явно переопределять (font-size: 100%), как я и показал выше.
Ну так, кто выбирает инструменты для решения задач?
НЛО прилетело и опубликовало эту надпись здесь
Не могу согласится на 100%. Если пользователь сожмёт окно браузера до 20% от ширины монитора, то кто будет виноват в том, что у пользователя интерфейс отображается «неверно»? Если пользователь устанавливает нестандартное значение шрифта по-умолчанию в браузере, то (вероятнее всего) он делает это осознанно.
НЛО прилетело и опубликовало эту надпись здесь

Совершенно согласен с этим замечанием. Во-первых, rem'ы отсчитываются от значения, которое всё равно скорее всего будет переопределено на конкретной странице, а, во-вторых, чтобы было покрупнее, люди обычно меняют плотность пикселей или используют масштабирование на уровне всей системы, а не меняют размер базового шрифта в браузере, поэтому задавайте размеры в пикселях и не парьтесь. Времена, когда относительные единицы реально имели большое значение, прошли лет десять назад.

Хотел бы добавить.
Ошибка не использовать position:fixed внутри блока с position:absolut
Таким образом можно растянуть внутренний блок (top:0;bottom:0) по высоте внешнего, а содержимое выровнять по вертикали (vertical-align:top).
Это полезно, например, для создания бокового меню, чтобы блоки выпадали вправо и вверх на полную высоту родителя.

Нужно использовать следующую конструкцию (к дополнению к уже имеющейся):
ul.parent {position:absolut;}
ul.parent li ul.child{position:fixed;top:0;bottom:0}
ul.parent li ul.child li{vertical-align:top;}


Это позволит не загромождать экран выпадающим вертикально лаптем из десятков пунктов меню, а аккуратно и красиво позиционировать их справа.

image
Я использую монитор, который находится примерно в метре от меня, поэтому у меня стоит режим с увеличенным размером текста в Google Chrome.

в настройках браузера лучше увеличивать масштаб, а не размер текста. не будет проблем со стилями. а еще лучше увеличивать масштаб в настройках ОС.

Не используете специальные типы email и tel для тега input

А ещё отдельно на кол сажать тех кто до сих пор размещает номер телефона как картинку и даже не в виде ссылки (и почту тоже встречал такую, жесть)

НЛО прилетело и опубликовало эту надпись здесь

Это у авито такая защита от спама тех кто выставляет свои лоты.

НЛО прилетело и опубликовало эту надпись здесь

Нене. Это как раз нормально. Я на разных сайтах госорганизаций (школы, вузы, поликлиники) часто встречал в шапке такое...

А так же поубивать тех кто мне на ipad 11 подсовывает мобильную версию сайта. При этом возможность переключиться на полноценную превращает в квест.
Многие не парятся и добавляют только один медиазапрос на максимальую ширину экрана в 768 пикселей.

Так вроде ж в Safari можно настроить по умолчанию открытие десктопных версий сайтов, разве нет?

Когда я читаю, как надо и не надо делать, не все советы кажутся заслуживающими внимания, и вызывают порой недоумение — выглядит, что автор просто не понял чего-то (пока), но однажды поймет, и будет жалеть о форме, в которую облек свои «хотелки и поучалки». Не надо так делать, да.

Я не совсем понял, есть ли у вас конкретная критика, или вам просто не понравилась форма подачи материала?

В интернете все чаще встречаются сайты, на которых разработчики добавляют role=”button” для тегов div или span. И, наверное, они думают, что все хорошо.

Но у меня плохие новости. Кнопки по-прежнему не доступны для меня, когда я хочу использовать свою клавиатуру. Я жму enter, и снова получаю разочарование. Приходится использовать тачпад.

Если к элементу div добавить role, tabindex и слушать события клика и клавиши enter, то div будет себя вести так же, как и button.

В 99% случаях можно и нужно использовать button, но встречались случаи, когда button конфликтовал с флексами, из-за чего его использование было неудобным.

А есть примеры?

Так надо было пример, когда оно флексам мешает. То что практически любой элемент в кнопку превратить можно это понятно

По поводу неверных типов инпутов. Советую better-mobile-inputs для правильного подбора соответсвующих аттрибутов
По-больше бы таких «вредных» советов. Новичку самое то!
Это такой сарказм? Так как все советы достаточно полезны и так или иначе улучшают доступность. Конечно, это всего лишь малая часть из всех возможных «улучшений» доступности, но даже такие простые действия (например, про label) часто игнорируются.

Никакого сарказма, практические советы очень кстати

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


Можно было просто написать статью про методы улучшения интерфейса и не пытаться изобразить, как «страдают» люди, у которых всё в порядке. Это было бы просто этичнее, что ли. А так впечатление смазано и как-то не очень.

По поводу outline: none находил, как по мне, интересное решение.
Отслеживаем нажатие клавиши Tab, по событию добавляем класс user-is-tabbing к body, ну и стилями убираем outline для всех, кроме детей этого класса.
Возможно, подводные камни какие-то есть, но пока это для меня самое толковое решение.
НЛО прилетело и опубликовало эту надпись здесь
5 строк кода — по-моему, это не куча. При том, что клиенты довольны отсутствием лишних по их мнению обводок, а возможность пользоваться сайтом с клавиатуры сохранена.

По мне так очень актуальная статья. Спасибо автору!

Сейчас учусь на hexlet, делаю задание, нашел у себя 4 ошибки из 6ти. Спасибо за статью!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории