[Chris]: Hey hey — it’s been about a week since we announced the ownership transition of this site to DigitalOcean. The outpouring of positivity and support has been overwhelming in the best sort of way. Even my comrades Geoff and Robin took a moment to write something marking the occasion. 🧡
Reminder! If you’d like to keep getting this newsletter going forward, you have to opt-in to that. 🙏
Let’s look at some 🔥 links I’ve been eyeing up this week.
Better Details
This is just an outstanding idea from Zach: make the already very useful <details> element even more useful! And the implementation is :chefs-kiss:! Just wrap it in a capital W Web Component (and load and instantiate the script).
<details-utils>
<details>…</details>
<!-- you can have one or more <details> elements in here -->
</details-utils>With that in place, you get five benefits that are all awesome:
- Force open/closed (e.g. leave open on desktop but force closed on mobile)
- Click outside to close (e.g. like most menus work)
- Close on
esc(e.g. like most menus and modals work) - Animate open/closed (e.g. to aid in interface understandability)
- Toggle root element
class(e.g. you can already style the details with[open], but this is for styling the entire page, likehtml.page-menu-is-open. Perhaps you want to darken the rest of the page?)
Zach was saying he uses <details> a lot, even for things like the main navigation on massively popular websites. Which got me thinking about the accessibility of all that. I know for sure that you can’t put anything you want your own semantics with inside the <summary> (see Dave’s post) (e.g. don’t think you’ll get a proper header out of <summary><h3>...</h3></summary>). But what about interactive elements inside the rest of the details area? I was talking to Melanie about that and she launched her own research about it. In the end, personally, I’m not that worried about. But Melanie did note at least one awkward moment. Like if you use details for a menu, there isn’t a lot of heads up for a screen reader use that they are headed for a list-of-links:
“User Menu button collapsed”
Once you press the button (technically here the summary element, although the entire elements stays focused), it will announce something like:
“User Menu button expanded”
You can then press TAB (or VO + TAB in Safari) to navigate to the next interactive element, which in this case would be the “Home” link and would be read (in most cases) like, “list with three items. home, link.”
Technically this works, even if it’s a bit confusing to use with a screen-reader. I expected a disclosure widget andnow I’m in a list with links?
Block Party
I’m sure there are plenty of holdouts still, but it’s exceedingly clear that the Block Editor is the future of WordPress. I don’t know if I was an early adopter, but got on board as quick as I could, and have really enjoyed this block-based approach to content-building. I admit it was building my own blocks that felt like the best part, despite the fact that it’s a little harder than I might want it to be. Alex Riviere documented his first journey into block building and it’s helpful. He found it easier than I did. I’d reach for @wordpress/scripts for sure.
Olympe mono
Olympe is a monospace font revived from an Olympia typewriter. Its interesting shapes come from combining writing with the mechanical process of a typewriter which can only provide monospaced signs. Olympe gives a cursive but sometimes broken flow to the text, she is clumsy and charming.
That’s just fun.
I was lost but now I’m found.
This is such a super weird explainer for a web platform hopeful. So we already have:
<div hidden>This is hidden content.</div>But hidden as an attribute isn’t all the popular, probably because as Monica says, it’s a lie. This idea expands it to:
<div hidden="until-found">This is hidden content.</div>Which feels like some kinda Christian folk song but ok. The idea is that the element is quite literally hidden until you use the browser’s find command and it finds text that the element contains. At a glance, I was like… is this just for easter eggs or maybe to help make Konomi code implementation easier or what. But I brought it up while chatting with Dave and he had a bunch of ideas. I also could probably read the article a little more closely as some of the ideas right in the document are pretty sweet.
Truth be told, it is kind of annoying that find-on-page in browsers doesn’t find text that just so happens to be in a temporarily hidden element. Say a menu that just isn’t open right now, now a collapsed accordion situation. I would suggest that they attempt to make this jive with <details> somehow (rather than thinking of it as an alternative).
The real added costs of accessibility
Accessibility is not expensive; inaccessibility is cheap.
Every element is an html
This seems important.
My favorite is iframe.
Don’t forget to re opt-in to this newsletter if you want to keep getting it, and keep in mind that DigitalOcean is offering $100 in credit, which should be awfully useful for the next server you need to spin up.
