Tagged: html

tabindex="-1" (or any negative value) makes an element focusable if it isn’t already, and removes it from the tab order. It can still receive focus programmatically or by click, but not via the Tab key.

Today I learned that modal <dialog>s opened with showModal() can have their own <h1>.

I discovered this while reading Modern Web Guidance’s HTML guide. I was skeptical at first because it’s bad practice to have multiple <h1>s on a single web page.

But this exception for modal dialogs made sense when I learned what showModal() does. It makes the rest of the page inert and as mentioned on MDN, inert HTML elements and their flat tree descendants are hidden from assistive technologies as they are excluded from the accessibility tree. So while the modal dialog is open there is no other <h1> to compete with.

I’m not sure if there is consensus on this because I have seen many examples where an <h2> was used instead.

Here’s the one-liner Chris Coyier uses:

<link
	rel="icon"
	href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>🎯</text></svg>"
/>

Today I learned, adding tabindex="-1" to skip link targets is likely no longer necessary in modern browsers.

Manuel Matuzović tested skip links without tabindex="-1" on targets across major browsers and screen readers on macOS, Windows and Android, concluding it is safe to remove in most setups, thanks to sequential focus navigation starting point.

Furthermore, adding tabindex="-1" to skip link targets also introduces a regression in usability. With tabindex="-1" on main, clicking on any non-interactive area inside main makes main itself the focus starting point. So, the next tab press sends focus to the first focusable element in main, not the next one after where the user clicked. The gov.uk team removed tabindex from main for this reason.

Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them.

Today I learned that setting type="reset" on a <button> element in HTML creates a reset button that, when activated, immediately clears all form data, resetting it to its initial state.

This could have been useful in the context of a search form. But <input type="search"> already provides a native clear button for that single field.

Mandy Michael uses a brilliant analogy to explain why developers must get to know the HTML elements available to them and use the appropriate one for their content.

In TypeScript, we have the concept of an any type. When you assign a type of any it means the content can be anything. […] But if everything is typed as any then you lose the benefits of the language.

This is the same with HTML. If you use the <div> everywhere, you aren’t making the most of language. Because of this it’s important that you actively choose what the right element is and don’t just use the default <div>.

This reminded me of the following quote by Jen Simmons from their HTML course:

HTML syntax itself is fairly simple. The trickier part is knowing which tags to use when.

Images on the web are hard. After trying and failing so many times before, now I finally understand how to configure srcset and sizes attributes to serve differently sized images for different viewports.

Also worth checking out: Image Display Elements by Stephanie Eckles.

The <meta name="theme-color"> tag is no longer supported in Safari 26 on macOS and iOS.

If a fixed or sticky element touches the top or bottom edge of the window, then and only then, Safari extends that element’s background color into the corresponding top or bottom bar. Otherwise, on iOS, the bars remain translucent and have no solid color background.

As Wenson Hseih explained on WebKit Bugzilla:

A solid background color extension (“top bar tint”) is only needed in cases where there’s a viewport-constrained (fixed or sticky) element near one of the edges of the viewport that borders an obscured content inset (such as the top toolbar on macOS, or compact tab bar on iOS), in order to avoid a gap above or below fixed elements in the page that would otherwise appear when scrolling. This color extension behaviour is more critical on iPhone, where there’s a much “softer” blur effect underneath the browser UI (and so more of the page underneath is otherwise directly visible).

Nic Chan on how they overcame the hurdle of getting the signs to refresh on a page in a signage browser with no JavaScript. The solution was using a <meta> tag that tells the browser to refresh the page after the given number of seconds.

<meta http-equiv="refresh" content="3600" />

A great resource to understand how to use the alt attribute in various situations.

I keep forgetting, but the alt attribute of the <img> element is not just useful for users who are visually impaired. It is also useful when the image is not displayed in the browser for whatever reason. For example: the src attribute does not contain a valid path to an image.

I re-read Heydon Pickering’s post on the HTML article element in the middle of writing the markup for a new website.

Heydon’s writing is so sharp and funny. Unmistakably theirs. No one else writes quite like them, and I’m here for it.

I was reading Manuel Matuzovic’s article on meta theme color and came across this snippet:

<style>
	:root {
		--theme: blue;
	}
</style>
<meta name="theme-color" content="var(--theme)" />

I wish it was possible to access custom properties outside the <style> tag in the <head>. It would keep things DRY.

Wow! Who knew you could use modern CSS to test HTML? Well, Heydon certainly did!