HTML & Web Standards
Independent news and practical notes on HTML and HTML5, covering elements, attributes, semantic markup, forms, accessibility, browser implementation, and evolving work from WHATWG and W3C.
Updated by Ardan Michael Blum.
Independent news and practical notes on HTML and HTML5, covering elements, attributes, semantic markup, forms, accessibility, browser implementation, and evolving work from WHATWG and W3C.
Updated by Ardan Michael Blum.
Note: Line breaks and indentation in code examples are included to make the document structure easier to see. In HTML, this formatting is optional.
July 27, 2026
Opening a dialog on the web has traditionally required a small piece of JavaScript. An author would find the relevant <dialog> element, attach a click listener to a button, and call a method such as 'showModal()'. Closing the dialog required another listener and another method call.
Modern HTML provides a declarative alternative for several common interface actions. A <button> can use the 'commandfor' attribute to identify another element and the 'command' attribute to state what should happen to it. In supporting browsers, the browser performs the built-in action without author-written JavaScript.
The following button opens a modal dialog:
<button type="button" commandfor="information" command="show-modal">Open information</button>
<dialog id="information" aria-labelledby="information-title">
<h2 id="information-title">More information</h2>
<p>This dialog was opened through HTML attributes.</p>
<button type="button" commandfor="information" command="request-close">Close</button></dialog>
The value of 'commandfor'is the 'id' of the target element. Under the HTML standard, that target must be in the same document tree as the button. The value of 'command' names the operation. Here, 'show-modal' opens the target as a modal dialog.
The close button uses 'request-close'. Unlike the more immediate close command, a close request follows the dialog’s cancel behavior and can be prevented when an application has a legitimate reason to keep the dialog open—for example, while it asks the user to confirm the loss of unsaved work.
Using type="button" is a useful precaution. A button associated with a form can otherwise acquire form-submission behavior, depending on its attributes and context.
The command mechanism is not limited to dialogs. It can show, hide, or toggle an element with the 'popover' attribute:
<button type="button" commandfor="help-note" command="toggle-popover">Show help</button><div id="help-note" popover>
<p>This information appears as a browser-managed popover.</p></div>
The standard defines six built-in command values: 'show-modal', 'close', and 'request-close' for dialogs, plus 'show-popover', 'hide-popover', and 'toggle-popover' for popovers. Custom commands are also possible, but their names must begin with two hyphens and their behavior still has to be implemented with script.
This feature moves a familiar relationship into the markup itself. The source identifies the control, its target, and the requested action without hiding those connections in a separate event listener. That can reduce repetitive JavaScript and make a component’s basic behavior easier to inspect.
It also allows the browser to manage built-in behavior associated with native elements. A modal <dialog> opened with 'show-modal', for example, is placed in the browser’s top layer, and content outside it becomes inert while the dialog is open.
Declarative controls do not eliminate JavaScript. Applications still need script for validation, remote data, state synchronization, analytics, animation logic, and other behavior beyond the built-in commands. The useful change is narrower: authors no longer have to write script merely to express several actions the platform already understands.
Native elements provide a stronger starting point, but the attributes do not make a dialog automatically accessible. The opening button needs a meaningful label. The dialog needs an accessible name, supplied here by the visible heading and 'aria-labelledby'. Its content, initial focus, keyboard sequence, and closing behavior must suit the task.
For longer or more complex dialogs, authors should consider where focus should land when the dialog opens. When the dialog closes, focus should normally return to the control that opened it, unless the interaction has made another destination more logical. The W3C modal-dialog pattern describes these design considerations in more detail.
The Invoker Commands feature became broadly available in current browser versions during 2025, but older browsers may not recognize 'command' and 'commandfor'. A site should therefore test the browsers it supports and provide a fallback when opening the dialog is essential to completing a task.
The underlying <dialog> and Popover APIs can supply that fallback through a small script. This is a practical example of progressive enhancement: begin with clear, semantic HTML; use the newer declarative behavior where it is supported; and add only the compatibility code the audience actually needs.
The larger significance is not that a few click handlers disappear. It is that HTML continues to absorb common interface relationships into the language itself. A button can now declare not only that it is a control, but also which element it controls and which standard action it asks the browser to perform.
July 21, 2026
Chrome 148 extends a familiar HTML performance feature to media. Developers can now add loading="lazy" directly to <video> and <audio> elements.
<video controls loading="lazy" poster="preview.jpg">
<source src="film.mp4" type="video/mp4">
<track src="captions-en.vtt" kind="captions" srclang="en" label="English"></video>
When the media appears farther down a page, the browser can postpone fetching its resources until the element approaches the visible area. For video, this can also delay the loading of its poster image.
The loading attribute was already associated with the <img> element and the <iframe> element. Its addition to <video> and <audio> gives authors a consistent way to describe resources that do not need to load immediately.
This can be particularly useful on pages containing several interviews, lectures, demonstrations, podcasts or recorded performances. Media files are often much larger than images. Loading every recording during the initial page request can consume bandwidth and memory even when a visitor never scrolls far enough to play them.
Lazy Loading an Audio Recording
<audio controls loading="lazy">
<source src="interview.mp3" type="audio/mpeg">
<source src="interview.ogg" type="audio/ogg">
<p>Your browser does not support embedded audio.
<a href="interview.mp3">Download the recording</a>.</p></audio>
The browser can choose an appropriate source while delaying the initial request until the audio element is near the viewport. The fallback paragraph remains useful for browsers or other user agents that cannot play the supplied formats.
How It Differs from the Preload Attribute
HTML already provides a preload attribute for audio and video. Its common values are:
none — the author suggests that the browser should not preload the media;
metadata — the browser may load information such as the recording’s duration;
auto — the browser may download the media in advance.
The new loading attribute answers a different question: should loading be connected to the element’s position relative to the viewport?
According to the WHATWG HTML Living Standard, loading="lazy" takes precedence over the preload attribute while loading is being deferred. Once the element approaches the viewport, the browser can resume the normal media-loading process.
<video controls loading="lazy" preload="metadata" width="960" height="540" poster="lecture-preview.jpg">
<source src="lecture.webm" type="video/webm">
<source src="lecture.mp4" type="video/mp4">
</video>
Providing width and height can also help the browser reserve the correct amount of space before the video appears, reducing unexpected movement in the page layout.
The Browser Still Decides When to Load
The word “lazy” does not mean that the resource must remain unloaded until the exact moment it becomes visible. The browser may begin fetching it before it enters the viewport. That decision can depend on network speed, device conditions, scrolling behavior and the browser’s own loading strategy.
The HTMLMediaElement loading property reflects the attribute in the browser’s document model. Its recognized values are lazy and eager.
The HTML Standard also specifies that native lazy loading is not applied when scripting is disabled. This is an anti-tracking measure: otherwise, a site could place resources at different positions and infer how far someone had scrolled by observing when those resources were requested. The reasoning is described in the standard’s section on lazy-loading attributes.
Browser Support Should Still Be Checked
Chrome 148 is the first announced browser release to ship the feature. The addition is now represented in the HTML Living Standard, and WebKit has expressed support for adding lazy loading to video and audio. Implementation and release timing can still differ among browsers.
For now, developers should treat the attribute as a progressive enhancement rather than assume identical behavior everywhere. A browser that does not support media lazy loading will generally ignore the unrecognized attribute and continue loading the element according to its established behavior.
Performance Does Not Replace Accessibility
Lazy loading changes when media is requested. It does not make the media itself accessible. Videos may still require captions, audio descriptions or transcripts, while audio recordings may require a text alternative appropriate to their content.
The W3C Web Accessibility Initiative provides separate guidance on creating captions and making audio and video content accessible.
This is a modest HTML addition, but a practical one. Pages containing substantial media can reduce unnecessary initial downloads with one familiar attribute, without requiring a custom JavaScript lazy-loading system.
Sources and further reading: New in Chrome 148, the WHATWG media-element specification, MDN’s HTMLMediaElement loading documentation, the WHATWG development discussion, and the WebKit standards-position discussion.
July 20, 2026
Firefox 153 changes how the browser parses content placed inside an HTML <select> element. Previously, the parser retained only elements traditionally permitted there, such as <option>, <optgroup>, and <hr>. The updated parser can preserve other nested elements in the document structure.
This is groundwork for customizable select controls. Native dropdown menus have historically been difficult to style, leading developers to replace them with complicated custom widgets. Those replacements can introduce problems with keyboard navigation, accessibility, form submission, and behavior across different devices.
A more flexible native control could eventually give designers greater freedom while preserving the established behavior and semantics of HTML forms. That would be a meaningful improvement: presentation could change without requiring developers to reconstruct a basic interface component from the beginning.
The parsing update does not mean that fully customizable select menus are ready for unrestricted production use in Firefox. It establishes part of the necessary foundation. Developers should continue using conventional form markup and verify browser support before relying on the newer structure.
Sources: Mozilla Developer Network: Firefox 153 Release Notes and
July 17, 2026
Chrome has introduced a new <usermedia> element for requesting access to a device’s camera and microphone. Available from Chrome 151, it is part of Google’s developing family of Capability Elements.
Traditional camera and microphone access usually begins with a script-generated permission request. <usermedia> places the visible request inside an HTML control that the visitor activates deliberately.
<usermedia id="media-ctrl">
<button>Enable camera and microphone</button>
</usermedia>
Because the browser manages the control, it can provide a clearer indication of user intent and a more direct recovery path when access was previously denied.
This is an interesting direction for HTML: capabilities once handled mainly through application logic are becoming visible, declarative controls. However, <usermedia> is currently a Chrome feature rather than a universally supported HTML element, so production sites must consider browser compatibility and fallback behavior.
Source: Chrome for Developers — Introducing the <usermedia> HTML element
July 16, 2026
For many years, web developers expected HTML to progress through numbered editions. HTML 4 was followed by HTML5, creating the reasonable expectation that HTML6 would eventually arrive.
That is no longer how the standard develops. W3C and WHATWG agreed in 2019 to collaborate on a single version of HTML. The specification is developed principally through WHATWG as the HTML Living Standard, with W3C participating in the standards process.
The word “living” is important. HTML can be corrected and extended continuously instead of waiting for a large numbered release. Corrections and new features can be incorporated as the platform evolves and implementation experience develops.
“HTML5” remains a useful and widely understood description of modern HTML, particularly when distinguishing it from older versions. Technically, however, the current language is identified simply as HTML.
The modern doctype reflects that simplicity:
<!doctype html>
It contains no version number. The declaration tells the browser to process the document using the standards-oriented HTML mode.
Sources: W3C HTML information and the WHATWG HTML Living Standard.
July 15, 2026
A web page can be constructed almost entirely from div elements, but those elements say very little about the content they contain.
HTML provides semantic elements such as header, nav, main, article, section, aside, and footer. These identify the purpose of different parts of a document.
<header>
<h1>HTML.Events</h1>
</header>
<nav aria-label="Primary navigation"><a href="/">Home</a>
<a href="/standards/">Standards</a>
</nav>
<main>
<article>
<h2>Understanding Semantic HTML</h2>
<p>Article content begins here.</p>
</article>
</main>
<footer>
<p>Independent notes about HTML.</p>
</footer>
An article represents a self-contained composition. A section represents a thematic grouping, normally introduced by a heading. A nav element identifies an important collection of navigational links.
These elements do not determine the page’s appearance. Their first responsibility is meaning. That meaning can help browsers, search systems, reading tools, and assistive technologies understand the document’s structure.
A div remains useful when no more specific element accurately describes the content. Semantic HTML does not mean eliminating div; it means choosing a meaningful element when one exists.
Sources: WHATWG — HTML sections and semantic elements and W3C WAI — Page regions
July 14, 2026
HTML provides six heading levels, from h1 through h6. Their purpose is to describe the hierarchy of a document—not to select a convenient font size.
The principal page heading normally uses h1. Major sections use h2, while subsections within those sections use h3. Deeper levels continue the same pattern.
<h1>Guide to Modern HTML</h1>
<h2>Semantic Elements</h2>
<h3>The Article Element</h3>
<h3>The Section Element</h3>
<h2>HTML Forms</h2>
<h3>Input Types</h3>
A page should not jump from h2 to h4 merely because the fourth-level heading happens to look better. Visual appearance belongs in the style sheet; structural rank belongs in HTML.
Clear headings allow readers to scan a page quickly. They can also help screen-reader users navigate directly between sections and understand how those sections relate to one another.
Adding section or article elements does not remove the need for sensible heading ranks. The hierarchy should remain understandable from the headings themselves.
Source: W3C Web Accessibility Initiative — Headings
July 13, 2026
The details element represents information that a visitor can reveal or hide. Its first summary child provides the visible label for the control.
<details><summary>What is the HTML Living Standard?</summary>
<p>It is the continuously maintained specification defining the current HTML language.</p>
</details>
When the open attribute is absent, only the summary is initially displayed. Adding the attribute makes the additional content visible when the page loads.
<details open><summary>Browser support</summary>
<p>This information is initially visible.</p>
</details>
The current HTML standard also defines a name attribute for related details elements. Giving several disclosures the same name creates an exclusive group in which opening one closes the previously opened item.
<details name="html-topics">
<summary>Semantics</summary>
<p>Elements communicate the purpose of content.</p>
</details>
<details name="html-topics">
<summary>Accessibility</summary>
<p>Meaningful structure supports accessible navigation.</p></details>
The element should be used for genuine disclosure controls—not as a substitute for unrelated interface patterns such as tabs or navigation menus.
Source: The details and summary elements
July 12, 2026
Responsive images do not require every visitor to download the same file. HTML can provide several image candidates and allow the browser to choose an appropriate resource.
The picture element supports art direction, screen-size decisions, and alternative image formats. It contains one or more source elements followed by an img element.
<picture>
<source media="(min-width: 900px)" srcset="stanford-wide.webp">
<source media="(min-width: 500px)" srcset="stanford-medium.webp">
<img src="stanford-small.jpg" alt="Stanford Memorial Church viewed from the Main Quad">
</picture>
The picture element does not display an image by itself. It provides possible sources, while the required img element supplies the actual image and its alternative text.
Alternative text should communicate the image’s relevant content or function. A meaningful photograph needs a useful description. A purely decorative image should normally use an empty attribute: alt="".
The goal is not to insert keywords. Good alternative text allows someone who cannot see the image to understand why it appears in the document.
Sources: Embedded content and responsive images and Alternative-text decision tree
Please review the website's Privacy Policy, Disclaimer, and Further Terms.
For project inquiries, corrections, accessibility assistance, or general questions:
Ardan Michael Blum
A. Blum Localization Services
Palo Alto, California
Telephone: +1 (650) 427-9358
Online: Contact Form