А вы зачем на мобилке пытаетесь поймать пальцем скроллбар? Он для этого не предназначен.
На iOS предназначен. Ухватить и зажать добавляет фичу, с помощью которой можно одним свайпом пролистать 100% контента любой высоты. Придумали как раз для того, чтобы не листать сотней свайпов, если контента много.
Именно так. Статья этому не противоречит. Вариантов сверстать одно и то же довольно много. Однако, в статье я ищу вариант сделать это еще семантически верно + доступно.
Довольно мало, но это еще зависит от рода проекта. Полагаю, что на сайте посвященном инклюзивности, привлекающим людей с ограниченными возможностями, процент будет повыше, чем в рядовом интернет-магазине.
Целью является соответствие семантике. Вот выдержка из WAI-ARIA:
WAI-ARIA is intended to augment semantics in supporting languages like [HTML] and [SVG2], or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages.
It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of object. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it's better to use an h1 element in HTML than to use the heading role on a div element.
Не стоит использовать ARIA, если в этом нет необходимости. HTML5 предоставляет широкий спектр семантических элементов.
В начале статьи я сразу предупредил, что цель подушнить и разобраться "как правильно". Фактор разумности уже долгое время остаётся холиварным, хотя, на мой взгляд, здорово, когда разработчик задумывается о поддержке доступности.
Если стилизовать таблицу предложенным вами способом, то скринридер читает только значения, не повторяя необходимые ключи, так как их, по заданию задачи, не должно быть сверху (я добавил туда display: none). В инструментах отладки поддержки доступности предложенный вариант определяется как таблица со значениями. В итоге, мы не поймем, где написано про ИНН, а где про КПП и так далее.
Можно доработать таблицу старым хаком, который позволяет сжимать широкую таблицу до мобильных размеров. Но тогда встает вопрос о целесообразности таких изощренных методов с большим количеством DOM-узлов и повторящихся псевдоэлементов. Проще вернуться к варианту с <dl>, <dt>, <dd>
Атомарность еще со времен twitter bootstrap стала набирать популярность. До этого писали похожие классы самостоятельно, дабы облегчить себе работу. А также поддерживали (если поддерживали, конечно, но представим себе идеальный мир) документацию к UI-kit в актуальном состоянии.
По сути, приверженцы атомарности поняли, что это можно активно переиспользовать и это превратилось в подобие "оверинжениринга", когда нужно помнить всё, а в вакансии писать "опыт работы с tailwind/bootstrap/foundation/bulma/что_там_еще_было".
И теперь Ваша статья, в целом, сводится к нормально делай - нормально будет. Договаривайтесь о нейминге, подключайте линтер, попрактикуйтесь и поймете...
Кстати, а что с поддержкой @apply? Не является ли это чем-то сложно отлаживаемым на подобие bad practice с mixins? Сам не использовал, но звучит так, будто никакая IDE мне не подскажет о том, где сколько чего хранится в apply. Это так или есть рабочий инструмент для отладки?
Спасибо, статья занимательная и до сих пор актуальная! Что касается защиты, важно помнить о двусторонней безопасности. Да, можно накосячить на фронте, но у нас есть еще и бек. Подвожу к тому, что и рекомендуется в статье - использовать SameSite Cookies, но это обоюдная ответственность :)
Сейчас осуществляется полная поддержка в современных браузерах. Старые версии в расчет не берем (IE мне иногда снится и я вздрагиваю)
Тоже писал велосипед слайдер собственного сочинения, но на VanillaJS с поддержкой ES5. Прекрасный опыт. Целая гора новых знаний. И чувство удовлетворения от завершения процесса.
Однако, это должно оправдываться. Если вы делаете слайдер для себя — отлично. Если вы работаете над чужим проектом, то удорожаете разработку личным велосипедом. Так как на его создание уходит время, а еще его нужно будет поддерживать.
И все-таки не совсем понятно, зачем для этой цели выбирать jQuery. Если речь не стоит о поддержке старых браузеров, то чем плох современный JS? Если ради опыта и интереса, тогда понятно. А если нет, то нет.
Теперь с такими данными работать гораздо легче, чем на сайте. Можно, например, сравнить разные жилища и их особенности. Кроме того, эти данные удобно фильтровать. В моей семье 4 человека. Если мы соберёмся в Рим, то нам понадобится Airbnb-жильё с как минимум 2 кроватями, отличающееся адекватной ценой. Благодаря тому, что все данные собраны в удобном формате, в Excel, с ними можно весьма продуктивно работать. Как оказалось, моим нуждам удовлетворяют 7 результатов из 272.
Так себе пример, учитывая, что на Airbnb существуют удобные фильтры, в том числе и по количеству кроватей. Более того, можно смотреть фотографии не отходя от кассы не переходя в карточку, используя слайдер в результатах поиска.
А еще можно смотреть жилье в определенной части города, используя зум карты, чего уже нельзя сделать в excel. Особенно, когда важно, где именно проживать (центр или черта города).
Пример скрапинга понятен, но пример с Airbnb, увы, неудачный.
На iOS предназначен. Ухватить и зажать добавляет фичу, с помощью которой можно одним свайпом пролистать 100% контента любой высоты. Придумали как раз для того, чтобы не листать сотней свайпов, если контента много.
Я бы с удовольствием взглянул на компоненты таблиц и отдельные элементы дашбордов.
Вы правы, я дополню статью. Скринридер распознает это тоже "почти" удобно. Хорошее замечание, спасибо
Именно так. Статья этому не противоречит. Вариантов сверстать одно и то же довольно много. Однако, в статье я ищу вариант сделать это еще семантически верно + доступно.
Довольно мало, но это еще зависит от рода проекта. Полагаю, что на сайте посвященном инклюзивности, привлекающим людей с ограниченными возможностями, процент будет повыше, чем в рядовом интернет-магазине.
Да, спасибо! Пожалуй, добавлю информацию о возможности добавления
<div>в статью.Целью является соответствие семантике. Вот выдержка из WAI-ARIA:
Не стоит использовать ARIA, если в этом нет необходимости. HTML5 предоставляет широкий спектр семантических элементов.
В начале статьи я сразу предупредил, что цель подушнить и разобраться "как правильно". Фактор разумности уже долгое время остаётся холиварным, хотя, на мой взгляд, здорово, когда разработчик задумывается о поддержке доступности.
Если стилизовать таблицу предложенным вами способом, то скринридер читает только значения, не повторяя необходимые ключи, так как их, по заданию задачи, не должно быть сверху (я добавил туда
display: none). В инструментах отладки поддержки доступности предложенный вариант определяется как таблица со значениями. В итоге, мы не поймем, где написано про ИНН, а где про КПП и так далее.Можно доработать таблицу старым хаком, который позволяет сжимать широкую таблицу до мобильных размеров. Но тогда встает вопрос о целесообразности таких изощренных методов с большим количеством DOM-узлов и повторящихся псевдоэлементов. Проще вернуться к варианту с
<dl>,<dt>,<dd>FrontPage и Dreamweaver забыли упомянуть
Атомарность еще со времен twitter bootstrap стала набирать популярность. До этого писали похожие классы самостоятельно, дабы облегчить себе работу. А также поддерживали (если поддерживали, конечно, но представим себе идеальный мир) документацию к UI-kit в актуальном состоянии.
По сути, приверженцы атомарности поняли, что это можно активно переиспользовать и это превратилось в подобие "оверинжениринга", когда нужно помнить всё, а в вакансии писать "опыт работы с tailwind/bootstrap/foundation/bulma/что_там_еще_было".
И теперь Ваша статья, в целом, сводится к нормально делай - нормально будет. Договаривайтесь о нейминге, подключайте линтер, попрактикуйтесь и поймете...
Кстати, а что с поддержкой
@apply? Не является ли это чем-то сложно отлаживаемым на подобие bad practice с mixins? Сам не использовал, но звучит так, будто никакая IDE мне не подскажет о том, где сколько чего хранится в apply. Это так или есть рабочий инструмент для отладки?Верно :)
Так же верно и то, что его не всегда могут использовать (а надо бы)
Спасибо, статья занимательная и до сих пор актуальная!
Что касается защиты, важно помнить о двусторонней безопасности. Да, можно накосячить на фронте, но у нас есть еще и бек. Подвожу к тому, что и рекомендуется в статье - использовать
SameSite Cookies, но это обоюдная ответственность :)Сейчас осуществляется полная поддержка в современных браузерах. Старые версии в расчет не берем (
IE мне иногда снится и я вздрагиваю)Да, конечно. Спасибо, уже исправил
велосипедслайдер собственного сочинения, но на VanillaJS с поддержкой ES5. Прекрасный опыт. Целая гора новых знаний. И чувство удовлетворения от завершения процесса.Однако, это должно оправдываться. Если вы делаете слайдер для себя — отлично. Если вы работаете над чужим проектом, то удорожаете разработку личным велосипедом. Так как на его создание уходит время, а еще его нужно будет поддерживать.
И все-таки не совсем понятно, зачем для этой цели выбирать jQuery. Если речь не стоит о поддержке старых браузеров, то чем плох современный JS? Если ради опыта и интереса, тогда понятно. А если нет, то нет.
Так себе пример, учитывая, что на Airbnb существуют удобные фильтры, в том числе и по количеству кроватей. Более того, можно смотреть фотографии
не отходя от кассыне переходя в карточку, используя слайдер в результатах поиска.А еще можно смотреть жилье в определенной части города, используя зум карты, чего уже нельзя сделать в excel. Особенно, когда важно, где именно проживать (центр или черта города).
Пример скрапинга понятен, но пример с Airbnb, увы, неудачный.