Independent news and practical notes on HTML and web standards, covering elements, attributes, semantic markup, forms, accessibility, browser implementation, and evolving work from WHATWG and W3C.
Updated by Ardan Michael Blum in Palo Alto.
August 17, 2026
A familiar web interface can conceal a small chain of machinery: HTML creates a button, JavaScript locates another element, and an event listener connects the two. Invoker commands move that relationship into the markup. For a limited group of actions, the button can identify its target and state the requested behavior itself.
In a January 28, 2026 article for InfoQ, Daniel Curtis reports that HTML Invoker Commands had reached Baseline Newly available status. Safari 26.2 completed support following earlier implementations in Chrome 135 and Firefox 144.
The feature adds two attributes to the HTML <button> element. The commandfor attribute identifies the controlled element by its ID. The command attribute states the action that the button requests. When the button is activated by a pointer or keyboard, the browser can perform a recognized action without a JavaScript click handler.
The current WHATWG HTML Standard defines six built-in commands. A button can use show-modal, close, or request-close with a dialog. The last command allows the closing request to be cancelled before the dialog disappears. For an element with the popover attribute, the available commands are show-popover, hide-popover, and toggle-popover.
This is a genuine change, but a narrow one. For those built-in operations, the author no longer needs a selector, an event listener, and an explicit method call such as showModal(). Because the target and action are present in the HTML, the browser can make the control usable without waiting for application JavaScript to download and execute.
The phrase “without JavaScript” nevertheless requires qualification. Authors can create custom commands whose names begin with two hyphens, such as --rotate-image, but a custom command only dispatches an event. JavaScript must still listen for that event and implement the requested behavior. The native, script-free operations are currently limited to the predefined dialog and popover commands.
Native behavior also does not make an interface automatically accessible. A modal <dialog> gives the browser responsibility for important behavior such as making the rest of the page inert and managing keyboard focus. Authors must still provide understandable labels, useful content structure, sensible initial focus, and appropriate testing. The popover attribute supplies behavior rather than a complete semantic meaning, so the element and its accessibility information must still be chosen carefully.
Baseline status needs similar care. “Newly available” means that the feature works across recent versions of the browsers included in the Baseline project. It does not mean that every visitor has upgraded to those versions, and it is not the same as “Widely available.” Essential interactions may still require progressive enhancement or fallback behavior for older browsers.
The article is worth reading because it illustrates a larger pattern in HTML’s development. The language is not becoming a replacement for general-purpose programming. Instead, it is absorbing recurring interface conventions that browsers can implement more consistently than individual scripts. The durable lesson is simple: before rebuilding a familiar interaction in JavaScript, check whether HTML can now describe it directly.
Read: “HTML Invoker Commands Achieve Baseline Support across All Major Browsers”, by Daniel Curtis, InfoQ, January 28, 2026.
Note: This note is an independent interpretation and summary of the article. Readers should consult the original for the author’s complete reporting and sources.
August 9, 2026
A label gives a form control its own name. In a group of choices, however, the individual names may not state the question they answer. "Email" and "Telephone" are clear labels, but without a shared prompt, they do not say whether the form is asking for a preferred contact method, an available method, or something else.
When several controls collectively answer one question, group them in a fieldset and state that question in a legend that is the fieldset's first child.
<fieldset>
<legend>Preferred contact method</legend><label>
<input type="radio" name="contact" value="email">Email</label><label><input type="radio" name="contact" value="phone">Telephone</label>
</fieldset>
The legend does not replace the labels. It names the question; each label names one possible answer. Together they preserve a distinction that visual spacing alone cannot reliably express.
This pattern is particularly useful for radio-button and checkbox groups. It can also distinguish shipping and billing address sections whose individual field labels would otherwise be identical. Assistive technology can announce the legend with the controls, keeping the shared question attached to its possible answers.
The fieldset border is only a browser default. CSS can restyle or remove it without changing the group in the document.
Further reading: WHATWG HTML: The fieldset element and W3C WAI: Grouping Controls.
August 7, 2026
For much of HTML’s history, major editions were identified by version numbers. HTML 4 was followed by HTML5, encouraging the reasonable expectation that an HTML6 specification would eventually replace it.
The development of HTML took a different course. WHATWG maintained a continuously updated HTML specification, while W3C published numbered recommendations and snapshots. For a period, this left the Web with two specifications that both claimed normative authority.
In 2019, W3C and WHATWG agreed to collaborate on a single version of HTML and the Document Object Model. Under that arrangement, the work takes place in the WHATWG repositories, WHATWG maintains the Living Standards, and W3C contributes through community participation, issue development, testing, review, and its Recommendation process.
W3C now identifies the WHATWG HTML Living Standard as the current HTML standard and states that it supersedes previously published HTML specifications.
A Living Standard is maintained continuously. Corrections can be made, ambiguities clarified, and new features incorporated as browser implementation and experience with the platform develop. Changes do not have to wait for the publication of another large numbered edition.
“Living” does not mean that stable parts of HTML change unpredictably. Web standards must preserve compatibility with an enormous collection of existing pages, browsers, applications, and authoring tools. WHATWG describes mature parts of its standards as changing cautiously, with an emphasis on bringing specifications and implementations into agreement.
The name “HTML5” remains common and useful when distinguishing modern HTML from older generations of the language. It no longer identifies the latest edition in a sequence, however. The actively maintained language is now generally called simply HTML.
The short modern doctype reflects this change:
<!doctype html>
It contains no version number because it does not declare that a document uses HTML5, HTML 5.1, or another numbered edition. It is a required preamble retained for compatibility with browser behavior.
If a doctype is omitted or malformed, browsers may enter a legacy rendering mode designed to reproduce the behavior of older web pages. Including <!doctype html> tells the browser to make its best effort to follow the relevant modern specifications.
The doctype therefore does not select a numbered version of HTML. Its practical purpose is to prevent legacy rendering behavior and place the document in the browser’s standards-oriented mode.
WHATWG HTML Living Standard — The current specification for HTML.
WHATWG FAQ: What does “Living Standard” mean? — Explains why the specification is continuously maintained rather than replaced by numbered editions.
W3C: HTML — W3C’s current information page for HTML and its relationship to the WHATWG standard.
W3C and WHATWG to Work Together to Advance the Open Web Platform — The 2019 announcement establishing cooperation on a single version of HTML.
Memorandum of Understanding Between W3C and WHATWG — Describes how the organizations cooperate on the development and review of HTML and DOM.
WHATWG Review Drafts Endorsed as W3C Recommendations — A later example of the standards relationship operating in practice.
HTML5: W3C Recommendation, 28 October 2014 — The historical HTML5 Recommendation and a useful record of the numbered-release period.
HTML 4.01 Specification — The superseded 1999 W3C Recommendation that preceded HTML5.
WHATWG HTML Standard: The DOCTYPE — Defines the modern <!doctype html> declaration and explains its purpose.
July 27, 2026
Some of HTML’s most important elements do their work without calling attention to themselves. The <label> element is a good example. It does not usually create a dramatic visual change, yet it can make the difference between a form that is merely visible and one that is genuinely understandable.
A label gives a form control a clear caption. It tells a person what information belongs in a text box, what a checkbox means, or what choice a radio button represents. When the label is correctly associated with its control, browsers and assistive technologies can recognize that relationship as part of the document’s structure.
HTML provides two principal ways to create this association. The first uses a for attribute whose value exactly matches the control’s id:
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email">
The id must be unique within the page. The matching for and id values establish the relationship between the visible caption and the input.
The second method places the control inside the <label> element:
<label>
<input type="checkbox" name="updates">
Send me occasional updates
</label>
Both methods are valid HTML. W3C accessibility guidance generally recommends the explicit method, using matching for and id values, when it is practical to do so.
These associations matter for reasons that go beyond appearance. They create a programmatically identifiable relationship between the words and the control. Assistive technology can present the label when a person reaches the field, removing the need to infer which nearby words belong to which control.
Labels also improve ordinary mouse and touchscreen use. Depending on the browser and platform, clicking or tapping a label may activate or focus its associated control. In ordinary browser use, this makes the text beside a checkbox or radio button part of the control’s usable activation area.
Placeholder text performs a different job. It may provide a short hint or example, such as name@example.com, but it should not replace a proper label:
<label for="contact-email">Email address</label>
<input type="email" id="contact-email" name="email"
placeholder="name@example.com">
Placeholder text is shown only while the control has no value. It disappears when the user enters information and is often displayed with less contrast than ordinary text. If it contains the only explanation of a field, the user may have to remember that explanation while reviewing or correcting an answer.
A visible label remains available before, during, and after entry. The HTML Standard therefore states directly that the placeholder attribute should not be used as an alternative to a label.
Not every form-related element needs a separate <label>. A <button> normally receives its accessible name from its own text:
<button type="submit">Send message</button>
When several controls form a related group, HTML provides the <fieldset> and <legend> elements. The legend identifies the group, while each individual control still receives its own label:
<fieldset>
<legend>Preferred contact method</legend>
<input type="radio" id="contact-email-option" name="contact" value="email" >
<label for="contact-email-option">Email</label>
<input type="radio" id="contact-phone" name="contact" value="phone">
<label for="contact-phone">Telephone</label>
</fieldset>
In unusual situations, attributes such as aria-label or aria-labelledby can provide a control with an accessible name. These techniques do not automatically provide a visible caption or the larger activation area created by a native label.
For ordinary text fields, selection controls, checkboxes, and radio buttons, a properly associated visible label is usually the clearest solution.
This is the kind of work semantic HTML does best. The relationship between a caption and a control is stored in the document itself rather than being suggested only by spacing, color, or position. The form therefore remains more understandable when its layout changes, when it is read aloud, or when it is operated with a keyboard, touchscreen, voice-control system, or other assistive technology.
Good HTML is often built from decisions this small. A well-labeled form allows each control to answer a simple question immediately:
What am I being asked to provide or choose?
When the answer is clear to the browser as well as to the person using it, the page is doing more than displaying a form. It is communicating its meaning.
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 inside an HTML <select> element. Previously, Firefox preserved only the elements traditionally accepted there, principally <option>, <optgroup>, and <hr>. The updated parser can preserve other nested elements in the document object model, or DOM.
This change lays groundwork for customizable select menus. Native dropdowns provide familiar keyboard behavior, accessibility semantics, and form integration, but their appearance has historically been difficult to customize. Developers have therefore often replaced them with complex scripted components that attempt to reproduce behavior browsers already provide.
More flexible native controls could allow designers greater visual freedom without rebuilding selection, keyboard navigation, form submission, and accessibility behavior from the beginning.
An important distinction remains: parsing an element into the DOM does not automatically make every possible arrangement conforming HTML. Nor does this parser change mean that complete customizable-select support is ready for unrestricted use in Firefox. It supplies part of the required foundation; associated styling and interface features remain separate implementation work.
Developers should continue using conventional <select>, <option>, and <optgroup> markup for production forms unless they have tested the newer customizable-select features in every browser they intend to support.
Sources: MDN: Firefox 153 Release Notes and WHATWG HTML Living Standard: The Select Element.
July 17, 2026 | Revised July 28, 2026
Chrome 151 introduces a new <usermedia> element for requesting access to a device’s camera and microphone. It is part of Chrome’s developing family of Capability Elements: browser-controlled interface elements intended to connect access to sensitive device features with a clear action by the user.
Websites traditionally request camera and microphone access through the JavaScript method navigator.mediaDevices.getUserMedia(). That method remains the underlying programmatic foundation for media capture. When permission has not already been granted, calling it may cause the browser to display a camera or microphone prompt.
The <usermedia> element approaches the interaction differently. Instead of having page script initiate the request independently, the website places a visible control in the document. The visitor activates that control, giving the browser a direct signal that camera and microphone access is being requested intentionally.
<usermedia id="media-control"><button type="button">Enable camera and microphone</button></usermedia>
In a supporting version of Chrome, selecting the control begins the permission and media-acquisition process. The browser manages the prompt and, after permission is granted, places the resulting MediaStream in the element’s read-only stream property.
The element reduces the amount of permission-handling code a website may need, but it does not eliminate JavaScript. A page must still listen for the stream event and decide what to do with the acquired audio and video.
For example, a page could attach the stream to a video preview:
<usermedia id="media-control">
<button type="button">Enable camera and microphone</button> </usermedia> <video id="preview" autoplay playsinline muted></video>
JAVASCRIPT (currently Chrome 151 and later)
const mediaControl = document.getElementById('media-control');
const preview = document.getElementById('preview');
mediaControl.setConstraints({
video: { width: 1280, height: 720 },
audio: { echoCancellation: true }
});
mediaControl.addEventListener('stream', () => {
preview.srcObject = mediaControl.stream;
});
A camera or microphone control cannot safely be treated like an ordinary decorative button. A deceptive website might otherwise disguise the control, cover it with another element, make it nearly transparent, or place it where a visitor could activate it without understanding what it does.
Chrome therefore restricts how Capability Elements can be styled. Its documentation describes enforced limits on opacity, contrast, dimensions, spacing, and visual transformations. The aim is to let a website integrate the control into its design without allowing the site to conceal or misrepresent its purpose.
This browser-managed presentation can also provide a more direct recovery path when access was previously denied. Instead of requiring the visitor to search through browser settings, Chrome may present an appropriate recovery flow when the visitor activates the element again.
The element does not silently bypass permission. A user action normally initiates the request.
The <usermedia> element is designed for combined camera and microphone capture. It exposes a complete MediaStream, which may contain both audio and video tracks.
The associated proposal also describes separate <camera> and <microphone> elements. Those controls could eventually manage individual media tracks, including enabling or disabling them after access has been granted. The combined <usermedia> element does not provide the same native per-track switching behavior because audio and video tracks can have different states and lifetimes.
The most important limitation is browser compatibility. Chrome 151 includes the <usermedia> element in its stable release, but that does not make it a universally supported HTML element. The underlying Media Capture Elements work is currently described as an unofficial proposal. Chrome’s implementation does not make <usermedia> an established W3C or WHATWG standard.
A website can use the following JavaScript to detect whether the browser supports the <usermedia> element:
if ('HTMLUserMediaElement' in window) {
// Use the <usermedia> implementation.
} else {
// Provide a getUserMedia() fallback.
}
A browser that does not recognize <usermedia> will generally treat it as an unknown HTML element and still render its child button. That graceful rendering is useful, but the button will not automatically request camera or microphone access. The website must attach conventional getUserMedia() behavior to it as a fallback.
For that reason, <usermedia> should currently be used as a progressive enhancement. It can improve the permission experience in supporting versions of Chrome, while a conventional JavaScript implementation continues to serve other browsers.
The larger significance is not that JavaScript has disappeared. It is that part of a sensitive interaction—expressing user intent, requesting permission, recovering from a previous denial, and acquiring the stream—is moving into a persistent browser-controlled interface. Whether that model becomes a broadly supported part of the Web will depend on further standards work and adoption by other browser engines.
Sources: Chrome 151 release notes, Chrome for Developers: Introducing the <usermedia> HTML Element, and Media Capture and Streams Extensions.
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
Modern HTML is maintained continuously rather than released as a sequence of numbered language editions. The standard, browser implementations and shared tests are developed toward interoperability, while frozen snapshots remain available when an exact historical reference is needed.
HTML Standard: Edition for Web Developers — WHATWG — Standard; best normative starting point. This edition omits material intended only for browser implementers while remaining synchronized with the full Living Standard. Use its definitions when a tutorial and a browser example appear to disagree.
HTML Living Standard — WHATWG — Full standard. Contains authoring rules, parsing algorithms, browser APIs, rendering requirements and implementation details. It is comprehensive rather than introductory, and a feature’s presence in the document does not by itself establish support in every browser version.
W3C HTML — Primary governance reference. W3C identifies the WHATWG Living Standard as the current HTML standard and explains the 2019 agreement to collaborate on one actively developed HTML and DOM specification. Older W3C HTML recommendations remain historical documents rather than competing current editions.
WHATWG FAQ — Primary source; standards model. Explains what “Living Standard” means, how carefully maintained standards can remain stable while changing, and how review drafts provide patent-review snapshots. Continuous maintenance is not permission to ignore compatibility or testing.
WHATWG Working Mode — Primary source; process and evidence. Describes the relationship among issues, proposed changes, implementer interest, specifications and tests. It is a useful corrective to announcements that call an early proposal a finished web standard.
DOM Standard — WHATWG — Related standard. Defines the document tree, nodes, events, mutation and core interfaces through which scripts work with HTML documents. HTML syntax creates a DOM, but the serialized source and the resulting tree are not always identical because the HTML parser can repair or rearrange markup.
HTML Tags — World Wide Web Project, 1992 — Historical primary document. Preserves an early description of the small HTML vocabulary used by the original Web. Read it as history, not current authoring guidance: HTML’s elements, parsing model and accessibility expectations have changed enormously.
Browsers are deliberately tolerant of malformed HTML, but predictable error recovery is not a reason to rely on mistakes. Good authoring uses the element whose defined purpose matches the content, maintains an understandable heading hierarchy and lets styling remain a separate concern.
The HTML Syntax — WHATWG — Standard. Defines start and end tags, attributes, comments, character references, raw-text elements and void elements. HTML is not XML: a slash before the closing angle bracket does not close a normal HTML element, and void elements must not have end tags.
Parsing HTML Documents — WHATWG — Standard; advanced. Specifies how bytes and tokens become the DOM, including error-recovery behavior, insertion modes and special handling for tables. Consult it when browser developer tools show a tree different from the source that was written.
Documents, Elements and Content Categories — WHATWG — Standard; conceptual foundation. Defines flow, phrasing, interactive, palpable and other content categories used throughout element rules. These categories describe where content fits and what it may contain; they are not CSS display modes.
Sections — WHATWG HTML Standard — Standard; document organization. Defines body, article, section, nav, aside, headings, header, footer, address and related elements. A section normally needs a heading, while article is intended for a self-contained composition rather than any visually boxed area.
Grouping Content — WHATWG HTML Standard — Standard. Covers paragraphs, lists, figures, block quotations, preformatted text and generic containers. Use div when no more specific element accurately expresses the grouping, not as the automatic answer to every structural problem.
Text-Level Semantics — WHATWG HTML Standard — Standard. Distinguishes elements such as em, strong, cite, code, data, time, bdi and span. Similar default styling does not make elements interchangeable: their defined meanings and processing can differ.
HTML Index of Elements, Attributes and Interfaces — WHATWG — Standard; quick lookup. Provides compact tables of elements, permitted contexts, content models, attributes and DOM interfaces. Use it to locate the relevant definition, then read that element’s full section before implementing an unfamiliar feature.
Obsolete Features — WHATWG — Standard; migration reference. Separates obsolete-but-conforming cases from non-conforming elements and attributes and often names the modern replacement. Browser rendering of an old feature does not mean authors should continue producing it.
Document Structure — Learn HTML — Practical guide. Walks through the doctype, root element, document head, metadata and body in a readable order. It is especially useful before moving to the standard’s more formal content-model language.
Links are relationships, not merely text with a click handler. Metadata describes the document or its relationship to other resources, while embedded data formats add machine-readable claims that must remain consistent with the visible page.
Links — WHATWG HTML Standard — Standard. Defines hyperlinks, external-resource links, link annotations and registered rel values. A real a href link preserves browser behaviors such as opening in a new tab, copying the address and keyboard activation that a scripted look-alike may lose.
URL Standard — WHATWG — Related standard. Defines URL parsing, serialization, origins and the behavior behind relative URL resolution. Use it when apparently simple addresses behave differently after a base URL, encoding or parser normalization is involved.
Document Metadata — WHATWG HTML Standard — Standard. Defines title, base, link, meta and style. The title supplies a document title, while meta is reserved for metadata that the other dedicated elements cannot express.
rel Attribute — MDN — Practical reference. Summarizes relationship values permitted on link, a, area and form, including stylesheet, canonical, license, noopener and resource hints. Availability and permitted elements vary by value.
Microdata — WHATWG HTML Standard — Standard. Defines itemscope, itemtype, itemprop and the extraction model for name-value data embedded in HTML. Vocabulary validity and support by a particular consumer remain separate questions.
Microformats2 — Microformats Wiki — Community specification. Documents class-based patterns for publishing people, events, articles and relationships in ordinary HTML. It is useful in IndieWeb and feed-processing contexts, but should not displace appropriate native elements or visible content.
Scripting, Templates, Slots and Canvas — WHATWG HTML Standard — Standard; advanced. Defines how script and noscript participate in HTML, the loading controls for classic and module scripts, inert template contents, slot in shadow trees and the canvas element. HTML governs how these features participate in a document, while the JavaScript language itself is specified separately.
Forms combine semantics, interaction, submission and error handling. Native controls provide valuable keyboard behavior, mobile input modes and platform integration, but authors still have to supply accurate labels, clear instructions, forgiving validation and server-side security checks.
Forms — WHATWG HTML Standard — Standard; primary route. Introduces the form model and defines form association, labels, submission and the relationship among type, autocomplete and inputmode. It also distinguishes requestSubmit(), which follows validation and submit-event behavior, from the lower-level submit() method.
The input Element — WHATWG — Standard. Documents each input state and exactly which attributes apply to it. Unsupported input types fall back to the text state, but presentation, picker quality and detailed behavior can still vary among browsers and operating systems.
Form-Control Infrastructure — WHATWG — Standard; advanced. Covers values, mutability, form owners, autofill, constraints, validation APIs and submission data. Client-side constraints improve interaction but are not a security boundary because requests can bypass the page.
Labeling Controls — W3C WAI — Accessibility guidance. Shows explicit for/id association and implicit nesting. A placeholder can offer an example, but it does not replace a persistent label that identifies the control’s purpose.
Grouping Controls — W3C WAI — Accessibility guidance. Explains fieldset and legend for related controls such as radio groups and checkboxes. Visual proximity alone may not communicate the relationship to assistive technology.
Form Instructions — W3C WAI — Accessibility guidance. Covers overall directions, required fields, accepted formats and programmatic descriptions. Instructions need to remain available while a person is entering and reviewing data, rather than disappearing with placeholder text.
Validating Input — W3C WAI — Accessibility guidance. Demonstrates native validation while emphasizing understandable error identification, accommodation of reasonable input formats and confirmation for consequential actions. It also states plainly that client-side validation must be backed by server-side validation.
Learn Forms — web.dev — Practical course. Moves from basic submission through labels, fields, validation, autofill, testing and usability. Use it to develop a working mental model, then consult the standard for exact requirements and current browser data for support.
HTML can let the browser select suitable image and media resources, but it cannot infer why an image matters or which information a recording needs to communicate nonvisually. File format, loading behavior, dimensions, text alternatives, captions and transcripts solve different parts of the problem.
Images — WHATWG HTML Standard — Standard. Defines img, picture, source, srcset, sizes, intrinsic dimensions and detailed alternative-text requirements. The browser selects among candidates; authors must still provide correct candidates, layout information and an alternative suited to the image’s function.
Images Tutorial — W3C WAI — Accessibility guidance. Separates informative, decorative, functional, text, complex and grouped images. The same file may need different alternative text in different contexts because purpose, not pixels alone, determines the replacement.
Alternative-Text Decision Tree — W3C WAI — Practical decision aid. Helps choose among meaningful alt text, an empty alt="", or a longer equivalent elsewhere. It is a disciplined starting point, not a substitute for understanding the surrounding content.
Media Elements — WHATWG HTML Standard — Standard. Defines audio, video, source, track, playback state, loading, text tracks and media APIs. The preload attribute is a hint, and actual fetching or autoplay can be affected by browser policy and user settings.
Making Audio and Video Media Accessible — W3C WAI — Accessibility guidance; planning hub. Connects different media situations to captions, transcripts, descriptions and accessible players. These are related deliverables, not interchangeable names for one text file.
Captions and Subtitles — W3C WAI — Accessibility guidance. Explains synchronized text for speech and meaningful non-speech audio. Captions serve people who cannot hear the audio and many others, but do not automatically provide the visual information needed in a transcript.
Transcripts — W3C WAI — Accessibility guidance. Explains why a useful transcript may need speaker identification and important visual information in addition to caption text. Requirements depend on whether the source is audio-only, video-only or synchronized media.
Media Types and Formats — MDN — Practical technical guide. Distinguishes file containers, codecs and MIME types and documents their compatibility considerations. A filename extension or generic video/mp4 label does not fully describe the encoded streams inside a media file.
Learn Images — web.dev — Practical course. Covers formats, compression, responsive candidates, performance, accessibility and delivery. It is particularly useful for deciding when srcset, sizes or picture solves the actual problem.
Scalable Vector Graphics (SVG) 2 — W3C Editor’s Draft — Related markup specification; draft. Defines the vector-graphics language that HTML permits inline in the SVG namespace. Inline SVG can expose shapes, text and links in the document tree, but authors must still supply an accessible name or text equivalent appropriate to the graphic and verify support for the particular SVG feature used.
MathML Core — W3C — Candidate Recommendation Snapshot, 24 June 2025. Defines the browser-oriented subset of MathML for mathematical notation, including its integration with HTML, SVG, CSS, the DOM and JavaScript. It aims for interoperable native math rendering; projects should test the needed notation and accessibility behavior in their supported browser and assistive-technology combinations.
A data table expresses relationships across rows and columns. HTML tables should represent genuinely tabular information rather than provide page layout, and complex structures need more explicit header associations than a simple visual grid reveals.
Tabular Data — WHATWG HTML Standard — Standard. Defines table, caption, row groups, rows, header cells, data cells and the table model. A table’s markup must form a coherent grid even when cells span rows or columns.
Tables Tutorial — W3C WAI — Accessibility guidance. Progresses from simple headers to irregular and multilevel structures using th, scope, id and headers. Its central concern is making relationships available without requiring someone to infer them visually.
HTML Table Accessibility — MDN — Practical guide. Explains captions, row and column groups, scoping and more explicit cell associations. It complements rather than replaces testing with the assistive technologies and table complexity relevant to the audience.
Native elements can supply focus behavior, keyboard operation, top-layer placement, form participation and other browser-managed behavior that is expensive to reproduce. New proposals and newly interoperable features require especially careful separation of specification status from one-browser availability.
Interactive Elements — WHATWG HTML Standard — Standard. Defines details, summary and dialog, including open state and close behavior. A disclosure is not automatically a tab interface, and a non-modal dialog opened with show() behaves differently from one opened with showModal().
The button Element and Invoker Commands — WHATWG — Standard. Defines button types plus built-in command/commandfor actions for dialogs and popovers. Declare type="button" when a button is not intended to submit its associated form.
Popover API — MDN — Practical reference. Covers declarative and scripted popovers, light dismissal, events and top-layer behavior. Popovers are non-modal; use an appropriate dialog pattern when interaction outside the surface must be blocked.
Invoker Commands API — MDN — Practical reference; newer feature. Explains how buttons declaratively invoke standard or custom commands on target elements. MDN classifies the core feature as newly available across current major browsers since December 2025, so projects supporting older versions still need a compatibility plan.
dialog Element — MDN — Practical reference. Documents modal and non-modal opening, return values, events, focus behavior and declarative commands. Merely adding the open attribute is not equivalent to invoking showModal().
Modal Dialog Pattern — W3C ARIA APG — Accessibility pattern. Describes labeling, initial focus, contained keyboard interaction, dismissal and focus return. The examples illustrate one implementation approach and must be adapted and tested for the real dialog’s content and workflow.
Customizable Select Explainer — Open UI — Standards-development explainer. Documents the goals and proposed markup behind richer native select controls. Parsing groundwork and partial implementations do not establish uniform production support, so verify the specific feature and browser set before deployment.
User Interaction — WHATWG HTML Standard — Standard; advanced. Defines focus, tabindex, access keys, inert, autofocus, editing hosts and drag-and-drop. These mechanisms can change keyboard order or suppress interaction across a subtree, so use them only with a clear focus model and test actual keyboard behavior.
Custom Elements — WHATWG HTML Standard — Standard; advanced. Defines autonomous and customized built-in custom elements, lifecycle callbacks and form-associated custom elements. A hyphenated name makes an autonomous element extensible; it does not automatically supply semantics, accessibility or useful behavior.
Introducing the usermedia Element — Chrome for Developers — Vendor source; experimental-platform caution. Documents Chrome 151’s browser-controlled camera and microphone capability element. It is a Chrome feature under continuing standards discussion, not a universally supported HTML element, so any production use needs compatibility checks and an appropriate fallback.
Native HTML usually provides the strongest starting semantics, but accessibility depends on the complete experience: names, relationships, source order, keyboard behavior, focus, instructions, alternatives and error recovery. ARIA can expose semantics to accessibility APIs; it does not create missing interaction or repair an unsuitable interface by itself.
Web Content Accessibility Guidelines 2.2 — W3C — Web standard. Defines testable success criteria at levels A, AA and AAA across perceivable, operable, understandable and robust content. Valid or semantic HTML contributes to conformance but is not a complete WCAG evaluation.
ARIA in HTML — W3C — Web standard; authoring rules. Maps native HTML semantics and defines which roles and aria-* attributes authors may apply. Some elements must not have their native roles overridden, and repeating an implicit role is generally unnecessary.
HTML Accessibility API Mappings — W3C — W3C Working Draft; advanced implementation reference. Describes how browsers map HTML elements and attributes into platform accessibility APIs. It helps explain browser and assistive-technology behavior, but it is not a substitute for the author-facing rules in HTML, ARIA in HTML and WCAG.
Read Me First — ARIA Authoring Practices Guide — Essential caution. Explains that using the wrong ARIA or incomplete keyboard behavior can make an experience worse and recommends native HTML where it supplies the needed semantics and behavior. APG examples are educational patterns, not drop-in compliance certificates.
Page Structure Tutorial — W3C WAI — Accessibility guidance. Brings together regions, labels, headings and content structure for navigation and orientation. It shows how HTML landmarks and carefully used ARIA can support keyboard and screen-reader users.
Headings — W3C WAI — Accessibility guidance. Recommends headings whose ranks reflect content organization and that label sections clearly. Heading choice should not be driven by the default font size.
Page Regions — W3C WAI — Accessibility guidance. Demonstrates header, nav, main, aside and footer as navigable regions. Repeated regions such as multiple navigation blocks need distinguishable labels.
HTML: A Good Basis for Accessibility — MDN — Practical guide. Connects element choice to built-in keyboard and accessibility behavior, meaningful links, alternatives, form labels, tables and source order. “Native first” is a foundation, not a promise that every native control or every use of it is accessible in context.
Language, character encoding and text direction are separate properties. Correct markup supports pronunciation, line breaking, font selection, form behavior and bidirectional display, while UTF-8 provides one encoding for the characters rather than identifying the language they express.
Declaring Language in HTML — W3C Internationalization — Standards guidance. Recommends lang on the root html element and additional declarations where the language changes. Neither a character encoding nor a Content-Language meta element replaces the language of the actual text.
Structural Markup and Right-to-Left Text — W3C Internationalization — Standards guidance. Explains dir="rtl", dir="auto", bidirectional structure and form input. Base direction belongs in HTML because it is part of the content’s meaning, even when CSS is unavailable.
Declaring Character Encodings in HTML — W3C Internationalization — Standards guidance. Recommends UTF-8 and an early <meta charset="utf-8"> declaration when the HTTP header does not already settle the encoding. The declaration must agree with the bytes actually sent.
Choosing a Language Tag — W3C Internationalization — Standards guidance. Explains BCP 47 language, script, region and variant subtags. Use the shortest tag that distinguishes the needed language variation rather than adding subtags merely because they are available.
HTML is an execution and embedding environment as well as a document format. Safe output depends on where untrusted data is inserted, which resources may load or execute, what an embedded document may do and how much cross-origin information a request discloses.
Cross-Site Scripting Prevention Cheat Sheet — OWASP — Security guidance. Distinguishes context-sensitive output encoding from HTML sanitization and unsafe escape hatches. Untrusted text, URLs, attribute values, CSS and JavaScript contexts require different handling; one generic “HTML escape” operation is not sufficient everywhere.
Content Security Policy Level 3 — W3C — W3C Working Draft; security specification. Defines policies that restrict resource loading, script execution, framing and other capabilities to reduce the impact of injection vulnerabilities. CSP is defense in depth, not a substitute for preventing unsafe content insertion.
Subresource Integrity — W3C — Current W3C Working Draft; security specification. Defines integrity metadata that lets a browser verify fetched resources such as scripts and styles before using them. Hashes must be maintained when the resource changes, and cross-origin use also depends on the appropriate CORS response.
Trusted Types — W3C — W3C Working Draft; advanced security specification. Defines typed values and policy enforcement for dangerous DOM injection sinks. It can substantially reduce DOM-XSS exposure, but browser support must be checked and applications still need well-reviewed policies and safe handling of untrusted data.
iframe Element — MDN — Practical security and embedding reference. Documents nested browsing contexts, sandbox, permissions, referrer policy, lazy loading and accessibility considerations. Combining allow-scripts and allow-same-origin for same-origin content can defeat important sandbox protections.
Same-Origin Policy — web.dev — Security foundation. Explains why documents and scripts from different origins have restricted access to one another and how embedding, reading and writing are treated differently. CORS relaxes selected network-reading restrictions; it does not disable the same-origin policy wholesale.
Referrer and Referrer-Policy Best Practices — web.dev — Privacy and security guidance. Explains how referrer information can leak URL details across origins and how policy changes that exposure. Referrer checks should not be used as the primary defense against cross-site request forgery.
HTML gives the browser early information about resources, candidates, dimensions and loading intent. These attributes are hints within a larger loading system, so indiscriminate preloading, priority inflation or lazy loading above-the-fold content can make a page slower rather than faster.
Lazy-Load Images and Iframes — web.dev — Practical guide. Explains loading="lazy" for offscreen images and frames and why initially visible content generally should not be deferred. The loading attribute changes deferral behavior, not the network priority assigned after a fetch begins.
Video Performance — web.dev — Practical guide; current media loading. Covers posters, formats, delivery and the newer loading="lazy" support for video and audio. Media lazy loading first shipped in Chrome 148; verify other browsers before treating it as a universal requirement.
Fetch Priority — web.dev — Practical guide. Explains the fetchpriority hint for images, links and scripts and common cases such as an important Largest Contentful Paint image. Raising every resource to high priority defeats the purpose of prioritization.
Resource Hints — web.dev — Practical guide. Distinguishes preconnect, dns-prefetch, preload and related hints by the work each asks the browser to begin. Every speculative connection or fetch consumes resources, so hints should be driven by measurement.
Preload Responsive Images — web.dev — Advanced practical guide. Shows imagesrcset and imagesizes on preload links when an important responsive image cannot be discovered early enough from normal markup. Ordinary images already present in initial HTML usually do not need a duplicate preload.
URLs, Fetching and Loading Attributes — WHATWG HTML Standard — Standard; advanced. Defines lazy-loading and fetch-priority attributes together with shared resource-fetching concepts used by HTML elements. Author hints influence browser decisions but do not require one exact scheduling algorithm.
Conformance, implementation support and usability are different questions. A checker can find structural mistakes; compatibility data can show whether browsers claim support; shared tests can reveal interoperability; and hands-on testing is still needed for the people, devices and assistive technologies a site actually supports.
Nu HTML Checker — Tool; current HTML conformance checking. Checks a URL, uploaded document or pasted source against current HTML and related rules. Fix errors deliberately rather than treating a zero-message result as proof of accessibility, security or identical browser rendering.
About the Nu HTML Checker — Primary tool documentation. Explains that the checker is intended to catch unintended mistakes and can gain new checks over time. It explicitly warns against treating its output as a permanent pass/fail certification.
Web Platform Tests — Shared test project. Provides cross-browser tests for web-platform specifications and infrastructure for running them. A feature name in a release note is less informative than the detailed behavior exercised by relevant tests across engines.
Web Platform Status — Tool; implementation evidence. Combines feature definitions, browser support and Web Platform Test data to show availability and interoperability. Inspect individual features and test coverage rather than reducing the platform to one browser score.
Baseline — web.dev — Compatibility framework. “Newly available” means a feature is supported in the current core browser set; “widely available” follows after 30 months. Baseline does not account for a project’s particular audience, older devices, embedded webviews or every accessibility defect.
Can I Use — Independent compatibility tool. Provides feature-support tables and usage data for desktop and mobile browsers. Read footnotes and partial-support details, then test complex or consequential behavior rather than relying only on a colored summary cell.
MDN Browser Compatibility Data — Open data source. Supplies machine-readable compatibility information used by MDN and other developer tools. Version numbers describe implementation history, while real support decisions also require audience data and knowledge of feature limitations.
WHATWG HTML Repository — GitHub — Primary development record. Contains the source, issues, pull requests and commit history behind the Living Standard. An open issue or pull request is discussion or proposed work, not yet a standard requirement or browser commitment.
WHATWG Blog — Primary standards commentary. Publishes occasional explanations and announcements from the standards community. Check the date and the current standard because old posts can describe an earlier stage of a feature or process.
This page was created independently of the individuals and organizations discussed, none of whom had editorial control over its contents. It contains no affiliate links, sponsored content, paid placements, or compensated endorsements. Neither the author nor this website received any payment, free or discounted product or service, preferential access, travel, hospitality, gift, or other material benefit connected with this page. Unless expressly disclosed otherwise, neither the author nor this website is affiliated with, sponsored by, endorsed by, or officially connected with any individual or organization mentioned. Names and trademarks are used only to identify the subjects discussed. A mention does not, by itself, constitute a recommendation or endorsement.
Please review the website's full Privacy Policy, Disclaimer, and Further Terms.
For project inquiries, corrections, accessibility assistance, or general questions:
Ardan Michael Blum
345 Forest Avenue
Palo Alto, 94301, California, United States
Telephone: +1 (650) 427-9358
Online: Contact Form