Forwarded from Defront — про фронтенд-разработку и не только (Alexander Myshov)
Вчера в блоге Google появилась новость о том, что Google Docs переходит на движок рендеринга, работающий поверх canvas, — "Google Docs will now use canvas based rendering: this may impact some Chrome extensions".
После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.
У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.
Обновление Google Docs будет раскатываться постепенно в течение двух ближайших месяцев. После обновления браузерные расширения, работающие с HTML-разметкой приложения, перестанут работать.
#architecture #announcement #google #a11y
https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)
После публикации в сети появились обсуждения насколько это оправдано. Своими мыслями поделился один из авторов оригинального Google Docs. Он говорит о том, что HTML-движки хороши для рендеринга обычных сайтов, но им не хватает фич для реализации полноценных WISWYG-редакторов. И о том, что кастомный движок рендеринга выигрывает по скорости у HTML-движков благодаря ограниченному набору функций.
У многих возникли вопросы по поводу доступности. Я немного потестил тестовый документ из статьи, и с доступностью там более менее всё ок. Озвучивание текста включается с помощью хоткея cmd+option+z — появится div с aria-live вне области просмотра с текстом документа текущей страницы. При перемещении по документу озвучивается текущая строка.
Обновление Google Docs будет раскатываться постепенно в течение двух ближайших месяцев. После обновления браузерные расширения, работающие с HTML-разметкой приложения, перестанут работать.
#architecture #announcement #google #a11y
https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html
https://news.ycombinator.com/item?id=27129858 (обсуждение на Hacker News)
Forwarded from Defront — про фронтенд-разработку и не только (Alexander Myshov)
Скотт О'Хара написал статью про деактивацию ссылок с учётом вопросов доступности — "Disabling a link".
Деактивация ссылок считается неудачным UX-паттерном, но иногда это приходится делать. Для корректного отключения ссылки нужно учитывать доступность и возможность открытия ссылки с помощью контекстного меню браузера.
Полностью отключить ссылку можно удалением атрибута
В коде деактивированная ссылка с учётом всех требований будет выглядеть так:
#a11y #html
https://www.scottohara.me/blog/2021/05/28/disabled-links.html
Деактивация ссылок считается неудачным UX-паттерном, но иногда это приходится делать. Для корректного отключения ссылки нужно учитывать доступность и возможность открытия ссылки с помощью контекстного меню браузера.
Полностью отключить ссылку можно удалением атрибута
href
. После удаления href
скринридеры не будут считать ссылку ссылкой, поэтому нужно добавить role="link"
. Чтобы скринридеры анонсировали неактивный статус, нужно добавить aria-disabled="true"
.В коде деактивированная ссылка с учётом всех требований будет выглядеть так:
<a role="link" aria-disabled="true">
Learn something!
</a>
#a11y #html
https://www.scottohara.me/blog/2021/05/28/disabled-links.html
www.scottohara.me
Disabling a link | scottohara.me
With HTML alone there is no way to disable a hyperlink (an <a href> element), and have it be both exposed as a “link” and as “disabled”. Now, setting ...
Forwarded from Defront — про фронтенд-разработку и не только (Alexander Myshov)
Использование focus-visible с обратной совместимостью
Патрик Лаук поделился своим подходом для управления стилями фокуса — ":focus-visible and backwards compatibility".
По умолчанию браузеры отображают фокус только там, где нужно. Например, фокус не устанавливается при клике на кнопку с помощью мыши, но появляется при переходе к кнопке с помощью клавиатуры. Для пользователей это логичное поведение. Когда фокус кастомизируется с помощью псевдокласса
Для кастомизации фокуса во всех браузерах с учётом
На данный момент
#css #a11y
https://www.tpgi.com/focus-visible-and-backwards-compatibility/
Патрик Лаук поделился своим подходом для управления стилями фокуса — ":focus-visible and backwards compatibility".
По умолчанию браузеры отображают фокус только там, где нужно. Например, фокус не устанавливается при клике на кнопку с помощью мыши, но появляется при переходе к кнопке с помощью клавиатуры. Для пользователей это логичное поведение. Когда фокус кастомизируется с помощью псевдокласса
:focus
, он начинает отображаться во всех ситуациях, вызывая замешательство у пользователей и дизайнеров. Для решения этой проблемы в стандарт был добавлен псевдокласс :focus-visible
, с помощью которого можно кастомизировать фокус, не ломая его стандартное поведение.Для кастомизации фокуса во всех браузерах с учётом
:focus-visible
Патрик советует использовать следующий подход:
/* стилизация фокуса */
/* в устаревших браузерах */
button:focus {
outline: dotted 5px teal;
}
/* отключение стилей `:focus` */
/* в современных браузерах */
*:focus:not(:focus-visible) {
outline: none !important;
}
/* стилизация фокуса */
/* в современных браузерах */
button:focus-visible {
outline: dotted 5px teal;
}
На данный момент
:focus-visible
поддерживается во всех браузерах (в Safari за экспериментальным флагом).#css #a11y
https://www.tpgi.com/focus-visible-and-backwards-compatibility/
TPGi
:focus-visible and backwards compatibility - TPGi
Updated March 2023 Clearly visible focus styles are important for sighted keyboard users. However, these focus styles can often be undesirable when they are applied as a result of a...
Forwarded from Defront — про фронтенд-разработку и не только (Alexander Myshov)
В поиске лучшего способа балансировки переносов слов
Попробовал сегодня по-быстрому сделать удобочитаемые переносы слов заголовков статей на сайте defront. Оказалось, что не всё так просто.
Зачем нужна балансировка переносов. Браузеры не заботятся о читаемости текста при переносе слов, поэтому в блогах зачастую можно встретить такие переносы заголовков статей:
хотелось бы, чтобы текст выглядел так:
В последнем варианте текст сбалансирован и не отвлекает внимание.
Для решения этой проблемы можно воспользоваться готовыми балансировщиками переноса слов. Есть две популярные реализации: от New York Times и от Adobe. Реализация от Adobe для меня слишком тяжёлая, реализация от New York Times полегче, но она хорошо работает только с небольшими объёмами текста.
Реализация New York Times для небольших заголовков подходит идеально также она работает быстрее балансировщика Adobe благодаря использованию простого алгоритма на базе бинарного поиска. Но у неё есть проблема с видимым сдвигом позиции слов. Дениэл Александерсен в статье про форк балансеровщика от New York Times предлагает скрывать текст заголовка до тех пор, пока не сработает балансировка, но мне это кажется очень хрупким решением. Если по каким-то причинам скрипт окажется сломан, то пользователь не увидит заголовка статьи. Также есть сомнения, что все скринридеры будут хорошо интерпретировать появляющийся из ниоткуда заголовок статьи.
Ещё можно сделать автоматическую вставку
Также в стандарте CSS Text Level 4 есть упоминание CSS-свойства
Сначала хотел использовать форк балансировщика New York Times, но его недостатки перевешивают все преимущества. Возможно, что потом попробую покопать в сторону варианта с
#html #ux #a11y
https://defront.ru/posts/2022/01-january/11-in-search-of-best-line-wrap-balance/
Попробовал сегодня по-быстрому сделать удобочитаемые переносы слов заголовков статей на сайте defront. Оказалось, что не всё так просто.
Зачем нужна балансировка переносов. Браузеры не заботятся о читаемости текста при переносе слов, поэтому в блогах зачастую можно встретить такие переносы заголовков статей:
Причины отсутствия поддержки AVIF в
Safari
хотелось бы, чтобы текст выглядел так:
Причины отсутствия
поддержки AVIF в Safari
В последнем варианте текст сбалансирован и не отвлекает внимание.
Для решения этой проблемы можно воспользоваться готовыми балансировщиками переноса слов. Есть две популярные реализации: от New York Times и от Adobe. Реализация от Adobe для меня слишком тяжёлая, реализация от New York Times полегче, но она хорошо работает только с небольшими объёмами текста.
Реализация New York Times для небольших заголовков подходит идеально также она работает быстрее балансировщика Adobe благодаря использованию простого алгоритма на базе бинарного поиска. Но у неё есть проблема с видимым сдвигом позиции слов. Дениэл Александерсен в статье про форк балансеровщика от New York Times предлагает скрывать текст заголовка до тех пор, пока не сработает балансировка, но мне это кажется очень хрупким решением. Если по каким-то причинам скрипт окажется сломан, то пользователь не увидит заголовка статьи. Также есть сомнения, что все скринридеры будут хорошо интерпретировать появляющийся из ниоткуда заголовок статьи.
Ещё можно сделать автоматическую вставку
<br>
в нужном месте разрыва заголовка. На больших экранах заголовки будут выглядеть хорошо, на маленьких экранах в редких случаях перенос будет выглядеть странно:
Использование
SomeNewApi
и
OtherNewApi
в Node.js
Также в стандарте CSS Text Level 4 есть упоминание CSS-свойства
text-wrap: balance
. Оно было предложено Adobe в 2013 году, и его поддержки до сих пор нет ни в одном браузере.Сначала хотел использовать форк балансировщика New York Times, но его недостатки перевешивают все преимущества. Возможно, что потом попробую покопать в сторону варианта с
<br>
, но пока оставлю всё без изменений. Балансировка переноса слов — это коварная штука. #html #ux #a11y
https://defront.ru/posts/2022/01-january/11-in-search-of-best-line-wrap-balance/
www.ctrl.blog
Improving the New York Times’ line wrap balancer
Web browsers don’t yet support (text-wrap: balance). Adobe and the NY Times have offer free JavaScript alternatives. I improved the latter to suit my needs.