`/` is a well-known vi/vim key-binding for search. It is supported by
Firefox for a 'quick find' feature in addition to the main find feature
available with the Ctrl+F key combination. DuckDuckGo also supports the
key to focus the search bar as well.
Signed-off-by: shine <4771718+shinenelson@users.noreply.github.com>
After thinking about it, I do not believe the scrollbar is that distracting. But for prefers-reduced-motion we should be careful about the scrollbar growing so quickly.
On the Nexus 5 especially, this ensures we no longer have nearly so many
"long tasks" (i.e. responsiveness is better). It moves html-to-txt
calculation to the same step as blurhash decoding, where it can be done
in requestIdleCallback (heck, maybe someday it could just be done in a
worker thread as well).
* perf: make timeline rendering less janky
1. Ensures all statuses are rendered from top to bottom (no more shuffling-card-effect rendering)
2. Wraps all individual status renders in their own requestIdleCallback to improve input responsiveness especially only slow devices like Nexus 5.
* fix focus restoration
* only do rIC on mobile
* fix: improve autosuggest a11y
some progress on #1629
- works in Chrome on NVDA now
- works in Chrome on VoiceOver now
- shorter aria-labels, don't repeat information like "1 of 3", because
it causes the screen reader to speak too frequently, e.g. when the
selected result hasn't changed but the number of results has. Also both
NVDA and VoiceOver already speak this information
- stop doing a fancy fade animation, just show and hide the input
instantly. I worry it confuses screen readers to have the aria-hidden
attribute in there at all
- stop using a single id to identify the active descendant - give
immutable IDs and then update the aria-activedescendant instead. I think
this is what fixed Chrome.
* fix test
The `.card-title` element carries `text-overflow: ellipsis`, (and
`white-space: nowrap`), resulting in the last part of long article
titles not being visible. By adding it to the `title` attribute,
one can see the full title on hovering without having to visit the
article first.
The main concern I had was that the text is now technically
duplicated in the source code, and for short titles, also in the
UI. The primary concern there, however, was screen reader users
getting duplicate announcements. However, I believe the title
attribute is not announced by screen readers, which this (old)
article seems to confirm:
https://developer.paciellogroup.com/blog/2010/11/using-the-html-title-attribute/
That leaves the following two disadvantages:
- This doesn't solve anything for mobile users, who will still
have to follow the link to see the full title.
- Desktop users can however a (non-truncated) title to see the same
title again.
