Independent notes and articles about HTML and web standards, covering elements, attributes, semantic markup, forms, accessibility, browser behavior, and the continuing development of the Web through WHATWG and W3C.
A project by Ardan Michael Blum.
September 14, 2026
On November 13, 1992, Kevin Hoadley of Rutherford Appleton Laboratory sent a message titled “ISINDEX on documents” to the www-talk mailing list. The public archive is now maintained by the World Wide Web Consortium, although the exchange predates the founding of W3C in 1994. Hoadley’s message and the replies that followed preserve a moment when the basic form of online interaction was still unsettled.
At the time, <isindex> marked a document as searchable. A visitor supplied keywords, the browser constructed a request, and the server processed that request and returned a response. The element did not create an index or perform the search itself.
Hoadley’s objection had two parts. First, he saw little reason to restrict searching to specially tagged documents. He wanted searches to be able to begin from any document, with the client free to construct several queries and, when necessary, combine replies from different servers.
Second, <isindex> was already being used for purposes other than search, including “smart” documents and a page that calculated square roots. The page might ask the visitor to enter a number while the browser supplied its own instruction asking for search terms. The result was two conflicting explanations of the same input.
Hoadley proposed a general INPUT element containing a label, followed by a separate DONEINPUT control indicating that the visitor had finished. His example anticipated the idea of placing labeled fields directly within a document. It was not modern HTML form syntax, however, and the exchange does not establish that Hoadley invented today’s <input> element.
In his November 16 reply, Tim Berners-Lee defended the need to name the particular index being searched. A server might offer thousands of different virtual indexes, he argued, so indexes needed to be named just as documents were.
Berners-Lee’s proposal was more ambitious than a simple search field. He imagined retrievable query types and descriptions of supported query languages. A generic client could read that information and generate an appropriate form for the visitor.
In a later reply, Hoadley agreed that this was only “the tip of the iceberg,” but continued to distinguish searchable documents from other interactive documents. For general input, he said he was inclined to prefer an inline representation, with fields placed directly within the page.
There was no immediate winner. HTML 2.0, published in November 1995, included <isindex> alongside <form> and <input>. When a visitor supplied keywords through <isindex>, the user agent appended a question mark and the escaped keywords to the document’s base address, joining separate keywords with plus signs. The server remained responsible for processing the resulting request.
The current HTML Standard classifies <isindex> as entirely obsolete and tells authors to use an explicit form and text control instead. The old exchange remains valuable because it records two possible directions being considered in public. Browsers could generate interfaces from descriptions of queries, or authors could place the necessary controls directly within their documents.
Modern HTML forms largely follow the second approach. That outcome may now appear inevitable, but these messages show that it was once an open design question.
This note is an independent summary and interpretation of the archived exchange. Readers should consult the original messages for the participants’ complete arguments.
September 8, 2026
Anyone who spent time on personal websites in the late 1990s or early 2000s may remember rows of tiny rectangular graphics near the bottom of a page. Some promoted Netscape or Internet Explorer, some announced that a page used valid HTML, some identified software or organizations, and others simply linked to another person's website.
A particularly common size was 88 pixels wide by 31 pixels high. The 88×31 button, usually pronounced simply “88 by 31,” became one of the small visual signatures of the early personal Web.
Despite the name, these were usually not HTML <button> elements. They were generally small images, often GIFs, placed inside ordinary hyperlinks. “Button” described their appearance and their role as compact badges rather than a particular HTML control. (...). Read the full article: "The Tiny 88×31 Button Is Finding Its Way Back Onto Personal Websites".
September 2, 2026
It lets human-friendly date text carry a constrained, machine-readable counterpart. It does not convert time zones, create an add-to-calendar control, or make a page eligible for Google's event experience by itself.
A date can be perfectly clear to a person and still be awkward for software. "Next Friday," "09/10/26," and "ten past seven" all depend on language, location, context, or convention. The HTML <time> element gives authors a way to keep readable wording while adding a constrained, machine-readable value.
Use <time> when a date, time, time-zone offset, or duration in the text has a useful machine-readable equivalent. Put that value in datetime when the visible wording is not already in one of HTML's permitted formats.
The visible content is for people. The datetime attribute is for user agents, scripts, extractors, and other tools. These two layers can express the same fact in different forms:
<p>
Registration closes
<time datetime="2026-09-18T17:00:00-07:00">
September 18, 2026 at 5:00 p.m. Pacific time
</time>.
</p>
The sentence stays natural; the attribute carries a syntactically valid machine-readable date, time, and UTC offset.
The element has no special visual appearance by default. It does not produce a date picker or a countdown. Its job is semantic: the HTML Living Standard limits its value to defined forms of dates, times, offsets, and durations.
If datetime is omitted, the element's child text content supplies its datetime value. For conforming markup, that text must match one of the permitted syntaxes, and the <time> element must not have element descendants:
<time>2026-09-18</time><!-- valid date value --><time>September 18, 2026</time><!-- not a valid datetime value -->
For ordinary prose, an explicit datetime attribute is usually clearer. It allows the visible text to follow the reader's language and style while the underlying value follows HTML's syntax.
The HTML Standard accepts more than full timestamps. A <time> value can be a valid month, date, yearless date, time, local date and time, time-zone offset, global date and time, week, year, or fixed-length duration string.
Visible text: September 18, 2026
Datetime value: 2026-09-18
Visible text: September 18, 2026 at 9 a.m. at the venue
Datetime value: 2026-09-18T09:00
Visible text: September 18, 2026 at 5 p.m. Pacific time
Datetime value: 2026-09-18T17:00:00-07:00
Visible text: 90 minutes
Datetime value: PT1H30M
Visible text: Week 38 of 2026
Datetime value: 2026-W38
In HTML's terminology, "local date and time" means the value contains no time-zone offset; it does not make the browser interpret the value in the reader's time zone. HTML durations represent fixed numbers of seconds. Months and years are not valid duration components because their lengths vary.
Values such as September 18, 09/18/26, 5pm PDT, or next Friday do not match any permitted datetime syntax merely because they are placed in the attribute. The syntax is data, not a second prose field.
A numeric offset and a geographic time zone are not the same thing. In the example, -07:00 records the applicable offset from UTC; it does not preserve the IANA zone America/Los_Angeles or that zone's rules. A regional zone can use different offsets across daylight-saving transitions, and governments can change its rules.
For a one-time online meeting that occurs at the same instant worldwide, a global date and time with Z or a numeric offset is useful:
<time datetime="2026-11-05T17:00:00Z">
November 5, 2026 at 5:00 p.m. UTC
</time>
For an event tied to a venue's local clock, keep the venue and regional time zone in the surrounding content and in the system that manages the event. For a future venue event, derive any displayed offset from the regional zone and retain that zone in the event system; rules can change. Do not invent midnight when only the date is known.
It does not automatically translate the visible date, adjust it for the reader's location, add the event to a calendar, or preserve a geographic time-zone identifier. Those behaviors require separate application logic, data, or controls.
The semantic value is useful, but it should not become a hiding place for facts people need. If the year, time zone, or duration changes a user's decision, include it in the visible wording. The current W3C HTML Accessibility API Mappings Working Draft maps <time> to the ARIA time role. That describes browser exposure, not a guaranteed spoken presentation in every screen reader, so keep the page understandable from its visible wording alone.
The datetime value must represent the element's visible contents. This example is nonconforming because the dates disagree:
<!-- Nonconforming: both dates are valid strings, but they disagree -->
<time datetime="2026-09-19">September 18, 2026</time>
Readable date wording also needs context. A global audience is better served by "September 18, 2026" than an ambiguous numeric form such as "09/10/26." The machine value cannot repair confusing visible copy.
The <time> element can be combined with a structured-data vocabulary, but the element alone does not declare that a page describes an event and does not make the page eligible for Google's event experience.
Google's event documentation describes a separate Event structured-data object with required information such as a name, start date, and qualifying location details. Its date values use ISO 8601. Eligibility still does not guarantee that a rich result will appear.
That distinction matters: use <time> when visible text denotes one of HTML's permitted dates, times, offsets, or durations. Add accurate event structured data only when the page and event meet the applicable requirements. One layer does not replace the other.
Putting prose in datetime. Values such as "tomorrow evening" are readable, but do not match a permitted datetime syntax.
Leaving out the offset for a single global instant. A local date-time without an offset does not identify one precise moment worldwide.
Treating an offset as a regional time-zone rule. Store the relevant geographic zone separately when future conversion or recurrence depends on it.
Promising a search feature. The <time> element alone neither makes a page eligible for Google's event experience nor guarantees that any search feature will appear.
Is the visible date unambiguous to the intended audience?
Does datetime use one of the HTML Standard's permitted syntaxes?
Does the datetime value represent the element's visible contents?
Is Z or a numeric time-zone offset included when the value must identify one global instant?
Is the geographic time zone stored elsewhere when regional rules matter?
Are unknown times left unknown instead of being filled with a false midnight?
Has the finished markup been checked with an HTML validator?
Small semantic elements rarely transform a page on their own. Their value is quieter: they let human language and software-readable data coexist without forcing either one to impersonate the other. For dates, times, and durations, that is exactly the work <time> is designed to do.
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 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