It provide a good example: this semantic HTML

<button
  id="navbar-toggle"
  type="button"
  aria-label="Toggle menu"
  aria-controls="navbar-menu"
  aria-expanded="true"
></button>
<ul id="navbar-menu" aria-labelledby="navbar-toggle"></ul>

should be styled as follow in CSS

/* State: closed. Click to open. */
#navbar-toggle[aria-expanded="false"] {}

/* State: open. Click to close. */
#navbar-toggle[aria-expanded="true"] {}

Just as before, it turns out that the class name was completely redundant. In fact, because we reached for a class name prematurely, we forgot to communicate the right semantics at the markup level.

Everything that does not have to be JS anymore, and there is a lot !

I didn't know about the accesskey attribute :)

An ode to know HTML

Most of the time, your job with JavaScript to enhance components’ keyboard accessibility will be done with just a handful of tools, including the use of event listeners and certain JavaScript methods of a couple of Web APIs that can help us in this task.

• keydown event: Instead, the utility of the keydown event comes when you need to add functionality to other keys [than enter or space].
• blur event: most of the time, you’ll use it to reverse the possible changes you have made with the keydown event listener.
• focus event (rare), but instead the focus method!
• button.inert works and avoid a setAttribute.

#idea #project #vue: create a directive to handle keydown and blur event into one action that is reversible.

So now we can have a look at component patterns:

• toggletips
• tabs
• modals

A guide to primary navigation on the related HTML tags. About HTML, inert and tabindex are explained.

For CSS, an optimal focus indicator is explained. There are also :focus-within and :focus-visible.

Finally some patterns such as Accordion, Tooltips and skip links are explained.

A guide on how to write a custom HTML parser. There is a lot of stuff at stake.

Rename a .md file into .md.html with a reference to a js script, and this file is displayed properly in a webpage :)

How to make this better with little css.
Inherit font-size, line-height, word-spacing, border and padding.

There are also

• Under-Engineered Select Menus
• Under-Engineered Custom Radio Buttons and Checkboxen

Store content that should be accessible. If the content should be seen or read on a page, don’t only put them in data attributes, but make sure that content is in the HTML content somewhere.

A use case is to style components based on their data attribute values.

Data attributes can be accessed in JS with tag.dataset.attributeName. It can also store JSON.

An HTML and CSS only tree.
The final CSS-snippet is also available at the end.

It uses only <ul>, <li>,

Build HTML elements visually

Source code: https://github.com/components-ai/css.gui

Different loading hints:

• async resource is loaded when the browser can
• defer resource is loaded when the DOM is parsed (less priority than async)
• rel=preload load the resource before the parsing and everything else
• fetchpriority with value high, low and auto. They are hints.
• rel=preconnect indicates that a connexion has to be established ASAP.
• rel=dns-prefetch resolves the domain name without fetching the resource.
• loading attribute determine when an image is loaded depending of its value:
  • eager: the image is loaded immediately
  • lazy: the loading is delayed until the user scroll to it.

This is in large part because HTML is a limited hypertext. In particular:

• Only <a> and <form> can make HTTP requests
• Only click & submit events can trigger them
• Only GET & POST HTTP Methods are widely available
• A request must replace the entire screen, leading to a clunky and sometimes jarring user experience

To the last point: the transition API is on its way :)

Je suis twitter et exige ma carte pour chaque lien partageable.

Autant faire un standard !

It’s crazy to think how much bandwidth is being used by metadata tags.

and how much of these are used by the client...

About the <template> element.

More recently, the idea to treat attribute selectors on par with classes as first-class citizens has been proposed more widely. We’re no longer talking about edge cases, but challenging the very defaultness of classes, all while not giving up that sense of structure that many of us look for in CSS naming conventions.

👍‍

And think of aria-selectors too ! This promotes an a11y-first mindset — if there is no attribute or pseudo selector available to represent the state we wish to style, should we add one?

this is the principle that class selectors violate. An element’s classes are never guaranteed to reflect their state

Using data attributes instead seems a good idea to avoid impossible states!

And there’s a reason why

looks attractive — it’s mirroring the APIs we’re used to seeing in design systems and component libraries, but bringing it to vanilla HTML and CSS.
Indeed, it’s a small step from data attribute selectors to custom pseudo selectors or prop-based selectors when using Web Components (think ).

Styling based on ARIA attributes encourages more accessible markup, and styling based on custom data attributes makes it more robust and readable — a better experience for users and developers alike.