That would be awesome indeed: using @scope (.classname) to specify styles that only applies from this class.

In a form, the user gets the screen reader navigation capabilities. The tab key becomes the norm again, and all that helps without aria is then the <label for=""> each input.

A disabled link is not a link, its just text. You need to really need to rethink your design if it calls for disabling a link.

The href attribute on a and area elements is not required; when those elements do not have href attributes they do not create hyperlinks. - W3C, Hyperlink spec

and how to build a disabled link... the hard way

aria-label, aria-labelledby, and aria-describedby can all be used to bring extra clarity to a given element when it's exposed to assistive technology.

• aria-label overrides an element's name with contents you specify.
• aria-labelledby replaces an element's name with contents from another node on the page. You'd use this when you'd already have a visible label anyways.
• aria-describedby sets your element's description to the contents of another node on the page. This is great for noncritical, supplemental information.
• aria-description… is coming.

As always, avoid ARIA whenever possible.

Using a description list dl with description terms dt and their description detail dd: so basically a list of key - value pairs.

Advangtages for screen readers instead of divs:

1. The screenreader could tell the user how many name–value groups are in the list.
2. The screenreader could tell the user how far into the list they are.
3. he screenreader could treat the list as one block that the user could skip over if they're uninterested in it.

How class encapsulation or closure can reduce the bundle size

I wasn't aware of the mess on Windows. I also agree that it will be more confortable for users to follow XDG conventions on *nix. The article explains well why it is such a mess.

Solution?

On *nix, the answer is straightforward: get everyone to adhere to the XDG Base Directory specification.

A button style-reset in CSS:

button {
  display: inline-block;
  border: none;
  margin: 0;
  padding: 0;
  font-family: sans-serif;
  font-size: 1rem;
  line-height: 1;
  background: transparent;
  -webkit-appearance: none;
}

and again: link for content and button for actions!

In the meantime:

.visually-hidden:not(:focus):not(:active) {
  border: 0;
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

Using aliases are powerful to navigate in the terminal.

The author shares ad function to add... aliases on the fly

How to archive URLs and their content. It is a mine of tricks or information.

How to parse a programming language with typescript: here a small but working example

About 1.

1. DOM refs created inside composables need to be explicitly destructured in setup() and returned. Otherwise, they won't be mapped to their DOM element.

Yes... but it is also the point that the template refs must be declared in the vue component. I find it more explicit IHMO. Imagine if multiple components were referencing multiple template refs.... It would add mental burden and forces the developer to know which composable use which refs.

About 2.

2. Data inside refs isn't automatically usable by templates unless you wrap the composable invocation with reactive(), which conflicts with point 1 without even more destructuring.

Yes to get the value: const { myRef } = useComposable()
or
const r = reactive(useComposable())