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 updated by Ardan Michael Blum who runs a Palo Alto SEO agency since 2016.
October 22, 2026
Imagine a visitor completing a registration form. She enters her name, including its apostrophe, and selects Continue. A message appears: “Enter a valid name.” She reads what she has written and tries again. The same message returns. Eventually she removes the apostrophe, and the form lets her through. The registration has succeeded, although the answer is now less accurate than it was before.
The difficulty in this imagined encounter lies in the word “valid.” To the visitor, a valid answer is her name, correctly written. To the software, validity means satisfying the rules someone has assigned to the field. Those meanings can diverge. A form can enforce its rules perfectly while failing to collect the information it asked for.
W3C’s guidance on personal names describes assumptions that cause this trouble. People may have one name, several family names, or a family name preceding their given name. A single letter may be a complete name rather than an initial. These examples do not establish national templates for everyone. The guidance acknowledges that its introductory account simplifies a more complicated reality.1
Translating the labels will not resolve a structural mismatch. If every version of a form requires the same components, someone whose name lacks one of them still faces the same obstacle.
Spelling brings further decisions. The U.S. Web Design System recommends supporting accents, apostrophes, spaces, and variations in capitalization. It advises against automatically changing the case of a name. The distinction between McNamara and Mcnamara, or between van der Waals and Van Der Waals, illustrates why an apparently tidy formatting rule can alter what the visitor supplied.2
HTML gives a developer a way to collect this text without prescribing a universal structure for names. An input with type='text' provides a field for a single line of text. The author can add constraints. For an ordinary editable text field, required checks whether the value is empty. The pattern attribute checks a nonempty value against a rule supplied by the author, while maxlength sets an input length limit. None of these mechanisms establishes that the text is someone’s authentic name.3
This helps locate the responsibility for the opening example. A rule accepting only the letters A through Z would reject an apostrophe because its author excluded that character. The browser would be applying the restriction it received. Changing browsers would not address the underlying design decision if the service enforced the same rule elsewhere.
HTML can also describe what kind of information a field expects. The attribute autocomplete='name' identifies a field for a full name. Other values, including given-name and family-name, identify particular components for autofill. These descriptions help a browser offer relevant information; they do not certify that the answer is true. The HTML Standard itself encourages broader fields where appropriate, explaining that narrower ones can embody Western assumptions about how names are arranged.4
The practical starting point is the purpose of the request. GOV.UK’s design guidance says to collect a name only when the service needs it. It also asks designers to distinguish the name a person ordinarily uses from the version recorded on an official document. That distinction belongs in the question presented to the visitor. Someone should be able to understand which answer is needed before discovering that one version has been rejected.5
Consider two hypothetical services. A reading group wants to know what to put on a participant’s name badge. A service matching an application to an existing official record needs the name associated with that record. A field copied from the second service into the first might collect unnecessary detail. A field copied in the other direction might omit information the matching process requires. Their questions should reflect what happens to the answer after it is submitted.
A single field can often accommodate more ways of writing a name. GOV.UK recommends choosing between single and multiple fields according to the users’ needs, while warning that a complete name cannot reliably be divided into its components afterward. If a service asks for a full name, its later steps should not depend on reliably separating that answer into given and family names.5
Separate fields can still serve a purpose. The U.S. Web Design System discusses them in a context that often includes identity checks, while also advising designers to consider one field when separate components are unnecessary. It recommends clear instructions and an explanation of what to do when a name does not fit. Neither arrangement removes the need to understand the people who will use it.2
A badly chosen requirement can also undermine the quality of the resulting records. W3C describes people without a family name entering filler text to escape a compulsory family-name field. The form has obtained a nonempty answer, but the answer exists because the form demanded it. A rule intended to prevent missing information has helped manufacture inaccurate information.1
Later, a completed field may reassure someone reviewing the database. The record may conceal the fact that the visitor entered a workaround rather than the requested information.
The visible field is only part of the system that needs attention. W3C’s guidance considers the space available for names in storage and in later display, as well as during entry.1 A useful review would follow a submitted name through the service: does it survive being saved, reloaded, placed in a confirmation message, and opened by a staff member? If the apostrophe disappears after submission, a more permissive input field has repaired only the first step.
An inherited database or a connection to another organization may constrain what a team can change immediately. That is a reason to investigate the restriction and provide a workable route for the affected person. It also makes the wording of the form more consequential. The service should explain a limitation in terms of the task it needs to perform, without presenting that limitation as a defect in the person’s name.
Error messages deserve particular care. WCAG 2.2 requires that, when an input error is automatically detected, the affected item be identified and the error described in text. Its explanatory guidance includes answers that fall outside the values or formats the system allows. That definition describes a mismatch with the system’s requirements; it does not establish that the person’s account of their name is mistaken.6
W3C’s forms tutorial also recommends clear feedback and instructions that help people resolve a problem.7 For a rejected name, the useful response depends on what has actually failed. A missing answer and an unsupported character call for different explanations. Where the service cannot accommodate a name, a route to assistance should be usable without first passing the very form that has blocked the visitor.
A more courteous message, however, leaves the restriction in place. If removing an unnecessary rule would let a person give an accurate answer, rewriting the warning is an incomplete repair. The question to take back to the team is why the service needs that rule, what would happen if it changed, and which parts of the system would also need attention.
Testing can make these decisions easier to see. I would include examples that challenge the assumptions of the form, such as a complete name of one character and a name containing an apostrophe. I would check what happens when an optional component is left empty, then inspect the saved result. No short collection of examples could represent every name. It could still expose a rule whose effects had gone unnoticed.
Return to the visitor at the beginning. She has managed to register, and the service now holds a version of her name without its apostrophe. Perhaps no one will notice. Perhaps she will have to correct it later. Before the team calls the form successful, it should ask why she had to make that change. The next version should let her give the answer she entered the first time.
1. W3C Internationalization: Personal names around the world.
Naming variation, required components, and implications for fields, storage, and display.
2. U.S. Web Design System: Name.
Guidance on spelling, capitalization, field arrangements, and the purpose of collecting names.
3. WHATWG HTML Living Standard: The input element.
Text input and the required, pattern, and maxlength attributes.
4. WHATWG HTML Living Standard: Autofill.
The name, given-name, and family-name tokens and guidance on broader fields.
5. GOV.UK Design System: Names.
When to request names, how to label fields, and the tradeoffs between one field and several.
6. W3C Web Accessibility Initiative: Understanding Success Criterion 3.3.1 Error Identification.
WCAG 2.2 requirements for identifying and describing automatically detected input errors.
7. W3C Web Accessibility Initiative: User Notification.
Clear feedback and instructions after form submission.
October 2, 2026
Writing in a webpage feels simple. A cursor blinks and words appear. Underneath, several systems must agree about the writer's intentions. The EditContext Working Draft published by W3C on September 10, 2026 addresses part of this coordination. It remains a work in progress on W3C's Recommendation track.
HTML already provides useful ways to enter text. An <input> can collect a name, a <textarea> can hold a message, and contenteditable can make part of a document editable. The difficulty grows when an application wants extensive control over its presentation and editing rules. The project's explainer describes the tension between using the browser's existing editing behavior and maintaining an editor's own view of the document.
Part of that difficulty concerns what counts as input. An input method editor, usually abbreviated IME, can help a writer produce characters by converting and selecting among possibilities. Text can remain provisional while the writer revises that choice.
W3C's UI Events specification describes this process as composition and distinguishes it from individual keyboard events. Text may also come from handwriting recognition or speech. A pressed key and a completed character do not necessarily correspond.
Consider an illustrative example. Someone writing Japanese in a browser begins entering a word, reviews a suggested word, changes that choice, and finally confirms the intended text. The editor must respect the difference between an unfinished composition and an accepted result. Counting keystrokes cannot establish that difference. Nor should a developer assume that a particular key always confirms the word: the UI Events discussion of IMEs explicitly recognizes variation among devices and input systems.
The problem becomes harder when the application's visual document changes during that process. The EditContext explainer records a collaboration problem in Word Online in which updating the view during composition could interrupt the writer's input, so updates were delayed. This example belongs to the proposal's development history. It illustrates why receiving text and arranging its appearance can become entangled.
EditContext is an application programming interface, or API, through which the editor can participate in this exchange. Its state includes text, selection positions, composition information, and viewport geometry. The browser connects this state with the operating system's text services and reports changes to the application. The application updates its document and displays the result. The browser does not automatically rewrite an active EditContext editor's DOM, or Document Object Model: its structure of elements and text.
That separation gives developers room to design specialized editors, including ones that draw text on a canvas, the page's programmable drawing surface. It also assigns them work that users will never see directly. Google's implementation explanation describes receiving updates, displaying text and selection, and keeping selection information synchronized. When a user moves the cursor to another word, the application must communicate the new position. Otherwise, the input system and visible editor can disagree about where the next change belongs.
Position also has a physical meaning. Consider a second illustrative case: a layout change moves the line being edited while a candidate window remains in its earlier position. Even if the suggested word is correct, the writer has to make sense of two disconnected locations.
Chrome's developer guidance explains that the application supplies bounds for the editing region, selection, and requested characters. These coordinates help the input system place its interface beside the text.
Editing extends beyond receiving characters. The separate Input Events Level 2 draft addresses users' editing intentions, including formatting and other operations expressed through different input methods. EditContext does not supply an entire word processor: its current draft leaves rich text formatting, clipboard operations, and undo for application handling. A team building a rich editor still has to decide what those actions mean in its own document model.
Accessibility requires equally deliberate work. The EditContext draft's accessibility section explains that its text buffer is not exposed to screen readers; editors need accessible DOM content and synchronized selection. A linked open issue about canvas accessibility reports a layout problem: some browsers do not calculate positions for the canvas's alternative content, although assistive technologies may need that information. W3C's ARIA authoring guidance reinforces the wider principle: assigning a role does not supply keyboard behavior. An editor's interactions and document structure must fulfill what its accessible description promises.
The publication date also needs perspective. Microsoft announced EditContext in Edge and Chrome release 121 in February 2024, well before this September's draft. Implementation and standardization have their own histories. Neither an implementation announcement nor a newer draft establishes identical behavior across browsers, operating systems, languages, and assistive technologies.
For developers, the practical lesson is to test the experience they intend to offer. A useful evaluation would include entering and revising a composition, moving the selection, changing the layout, and using the editor with relevant assistive technology. Checking that an API exists establishes much less than watching someone successfully finish the writing task for which it was introduced.
For an ordinary form or a modest editing feature, the established HTML controls remain useful choices; Google's guidance recommends considering them for simpler needs. The broader question raised by EditContext is how a browser can give applications more control while preserving their connection to the diverse ways people produce language. W3C's Web Editing Working Group studies these limits and develops the underlying interfaces. Its subject is the largely invisible cooperation that lets a writer concentrate on a sentence.
September 29, 2026
W3C is developing a new approach to how websites demonstrate accessibility and report their progress. Its Accessibility Guidelines Working Group published an updated WCAG 3 Working Draft on September 10, 2026.
In a September 25 explanation, W3C Web Accessibility Initiative Director Shawn Lawton Henry described the central change: a common set of core requirements would establish conformance, while separate reporting tiers would show work toward that threshold and achievements beyond it. The proposal aims to make the standard clearer while encouraging continued improvement. (Working Draft; W3C's September update).
WCAG 3 remains an incomplete draft. W3C expects substantial revisions and says a completed standard is still a few years away. Its name, W3C Accessibility Guidelines, reflects an intended scope extending beyond web content to web applications, related tools, publishing, and emerging web technologies. For people maintaining websites today, W3C continues to recommend meeting WCAG 2.2 success criteria. It expects WCAG 2 to remain in use for years after WCAG 3 is finalized. (WCAG 3 Introduction).
The existing WCAG 2 framework organizes accessibility around four principles: content should be perceivable, operable, understandable, and robust. Individual success criteria carry levels A, AA, or AAA. Level AA conformance includes the criteria at both A and AA. These criteria provide a shared basis for evaluation, supported by explanatory documents, implementation techniques, and testing resources. W3C is therefore working with an established system that already connects broad accessibility goals to specific checks. (WCAG 2 Overview; Understanding Conformance).
Consider an imaginary event booking page. A visitor chooses a date, enters contact details, selects a ticket, and receives confirmation. An accessibility review might discover that a visitor using a keyboard cannot choose a date, an error message is difficult to find, and the confirmation uses unclear wording. Those are different problems within one task. A useful report should help the publisher understand both what prevents a reservation and what makes the process unnecessarily difficult. This hypothetical example illustrates accessibility and usability problems; it does not determine WCAG conformance or assign the problems to the draft's proposed tags.
The proposed WCAG 3 model would require all core requirements to be satisfied throughout a defined scope, using methods supported by the relevant browsers and assistive technologies. A formal claim would also identify the accessibility support set used; the draft's default set remains undefined. The core set is intended to cover needs similar to, though not identical with, those addressed by WCAG 2.2 at Level AA. W3C's work also includes supplemental requirements, documented assertions about accessibility practices, and recommended practices. These categories would give publishers ways to describe work beyond the baseline. (Working Draft, conformance; WCAG 3 Explainer).
The draft's exploratory reporting proposal would use four tags for core requirements: physical harm, risk, barrier, and friction. This section offers guidance rather than conformance requirements. The proposed first tier covers physical harm and risk requirements. The second adds barrier requirements. The third adds friction requirements and reaches conformance because all core requirements have been met. Higher reporting tiers would add supplemental requirements and assertions, although their thresholds remain undecided. Reporting at either of the first two tiers would describe progress without establishing conformance. (Working Draft, conformance and reporting).
WCAG 2 already encourages reporting progress beyond an achieved conformance level; WCAG 3 proposes a different structure for doing so. For the hypothetical booking page, the practical attraction is a more informative account of repairs. The publisher could explain what has improved and what remains unresolved, while preserving a clear answer about whether the evaluated content meets the baseline. My reading is that this separation could make progress reports more useful, provided the eventual language keeps partial achievement from sounding like completion. (WCAG 2.2, conformance).
Assertions record attributed claims about accessibility procedures. The explainer's examples include accessibility training, usability testing, and testing with assistive technology during development and maintenance. The explainer distinguishes documenting a statement from supplying supporting records, which it would not require for conformance. Assertions would build on core requirements and could not substitute for them; whether assertions could also become required remains under discussion. Recommended practices would offer additional guidance without determining conformance. (WCAG 3 Explainer; Working Draft, assertion tags).
That distinction matters in ordinary publishing. A team may have trained its editors, yet still publish a confusing form. It may have commissioned user research, yet leave a reported problem unresolved. Describing the process is useful when readers can also understand the condition of the finished product. A claim about work performed should make it easier to examine results.
W3C is also clarifying the relationship between standards and policy. Henry's September article distinguishes conformance to a technical standard from compliance with a law or policy that uses it. W3C develops the accessibility framework; policymakers decide how to apply requirements in their own settings. The proposed tags could help policymakers choose which WCAG requirements their laws or policies adopt. (W3C's September update).
Several decisions remain open. W3C is seeking comments on the reporting tiers and on an alternative scoring proposal described in the explainer. It is also asking for research to support or challenge requirements marked as needing further evidence. These are active development questions, and public feedback can address specific difficulties with the proposals. (WCAG 3 review questions).
Website owners have useful work to do while that discussion continues. WCAG 2.2 already addresses keyboard operation, captions, text alternatives, labels, and error handling. Reviewing those features in a real booking or registration process can reveal concrete repairs to make now. A new draft should prompt attention to this work without interrupting it. (WCAG 2.2).
W3C's existing guidance also recommends involving people with disabilities throughout design and development, alongside evaluation against standards. Such participation can reveal problems that a team has misunderstood or failed to notice, while standards help cover needs beyond those represented by individual participants. For a small publisher, watching a person with a disability attempt an important task and listening carefully to the difficulties can make the next repair much clearer. One test of the proposed reporting model will be whether it helps publishers communicate those practical improvements accurately. (Involving Users in Web Projects).
September 28, 2026
Consider a small editorial decision. A writer has typed the sentence “I sent the draft to Mara” and wants one part of it to stand out. The instruction sounds simple until someone asks what, exactly, the distinction is supposed to accomplish. Is the writer correcting the identity of the sender, distinguishing a draft from a finished manuscript, or warning that Mara was the wrong recipient?
These possibilities belong to the same string of words. They depend on what came before it, what the people involved already know, and how the sentence is presented. Marking a word can guide the reading, but the mark cannot supply the entire conversation in which that reading makes sense.
HTML makes this ordinary difficulty unusually visible. It asks an author to select from a public vocabulary of elements while working with language whose implications remain open to interpretation. The question is therefore larger than whether a passage should appear in italics or boldface. It concerns what an author commits to saying about a passage when choosing its markup, and how much of that judgment another person or system can recover.
The familiar term “tag” names the written markers, such as <em> and </em>, that delimit an element in HTML source. The element is the part of the document those markers describe. The distinction matters here because a few characters of syntax establish a classification that can persist beyond a particular visual treatment. Take two versions of the sentence:
<p><em>I</em> sent the draft to Mara.</p>
<p>I sent the <em>draft</em> to Mara.</p>
The first might answer a question about who sent the document. The second might correct someone who thought the finished manuscript had been sent. These readings are plausible because the placement of stress gives the reader a clue about which part of the sentence is being reconsidered. They remain possibilities, rather than complete interpretations dictated by the markup.
The current HTML standard defines em in terms of stress emphasis. In our example, it identifies where the writer places that stress. It does not name the alternative being rejected, establish whether the speaker sounds annoyed, or explain why the distinction matters. An author can make the intended contrast explicit by writing “I sent the draft, not the finished manuscript.” That additional information comes from the words.
A translation makes the division of work more visible. Suppose the recipient is in question, with the name marked as <em>Mara</em>. A translator might choose the French construction “C’est à Mara que j’ai envoyé le brouillon,” approximately “It was to Mara that I sent the draft.” Here the sentence's construction itself brings the recipient into focus. The translator still has to decide whether additional emphasis serves the passage. Carrying emphasis into another language requires deciding what it contributes in this particular sentence.
Importance raises a different question. Suppose the writer is preparing instructions for a contributor and marks a deadline:
<p><strong>The final version is due Friday.</strong></p>
<p>The final version is due <em>Friday</em>.</p>
The first presents meeting the deadline as an obligation the contributor needs to take seriously. The second could correct an expectation that the deadline was Thursday. An important instruction can be spoken calmly; a correction about a trivial detail can receive considerable stress. The two judgments can also coincide, as when a writer places <em>Friday</em> inside an instruction marked with <strong>.
The standard assigns strong the role of strong importance, seriousness, or urgency. It distinguishes that role from the change in sentence meaning associated with stress. This is an authoring distinction, rather than a complete theory of everything people mean by “meaning.” A warning can alter a reader's sense of the situation without altering the action its words prohibit. Stress can suggest a correction while leaving the sentence's basic factual claim intact.
Choosing between these elements requires the writer to interpret the sentence before classifying it. The deadline does not arrive with its importance already measured, any more than “Friday” identifies the mistaken expectation that stress might correct. An element records a judgment in terms that another editor can recognize and question. The standard supplies the category; the passage must justify its application.
The possibility of combining elements is significant. These categories identify features that can occur together: an important instruction can contain a correction, and a represented thought can place stress on one word. An author marks a feature of the passage without exhausting what the passage is doing. There need not be one element that expresses everything relevant about it.
The relation becomes harder to describe when <i> and <b> enter the discussion. Under HTML's suggested default rendering, <i> and <em> share an italic treatment, while <b> and <strong> share a heavier font weight. A reader looking at the finished page may therefore encounter the same visual distinction where the author has made different classifications. Appearance alone does not disclose which element was used.
There is a historical reason the names can mislead. HTML 4.01 placed I and B among its font style elements, describing italic and bold presentation. It discouraged these font elements in favor of style sheets, but did not deprecate I and B. In another chapter, it described EM and STRONG as phrase elements, associating them with emphasis and stronger emphasis.
The later definitions changed the terms of the distinction. W3C's HTML5 Differences from HTML4 explicitly identifies modified meanings for b, i, and strong. The division between phrase elements and font style elements describes that earlier specification more readily than current HTML. Even the distinction between emphasis and importance has a history within HTML's vocabulary.
In current HTML, i identifies text distinguished from its surroundings by voice, mood, or another quality of the text. A represented thought makes the distinction easier to see:
<p><i>So this is the final version</i>, Mara thought.</p>
Here the prose moves into Mara's thought before returning to the narrator. The change of voice does not tell us whether she is relieved, disappointed, or incredulous. Nor does it identify a word that must carry corrective stress. The next sentence might establish any of those readings. If the writer also stresses “final,” that would add a further judgment about the thought's delivery.
The classification is broader than this particular use. The words “Mara thought” identify whose thought is represented; the element records its shift in voice within the narration. Together, prose and markup supply more information than the element's shared category could specify by itself. Marking a thought still leaves the writer to show what kind of thought it is.
The b element provides another test. It draws attention to text for a practical purpose, without adding importance or implying a different voice or mood. Imagine a review comparing two fictional notebooks:
<p>The <b>Harbor</b> notebook opens flat. The <b>Field</b>
notebook fits in a coat pocket.</p>
In this imagined review, making the names easy to locate is meant to help readers connect each observation with its subject. The review has not thereby declared the names more consequential than the observations. Their prominence serves comparison. A reader scanning for one model can use the visible names as points of orientation.
An objection immediately suggests itself: surely drawing attention to something already calls it important. In ordinary conversation, that objection is reasonable. HTML draws a more restricted distinction for authoring purposes. In this example, locating a subject and evaluating the significance of a statement are different editorial tasks, even though ordinary language might describe both as matters of emphasis or importance.
The author must decide what the attention is for. Using a product name as a convenient reference point gives one reason to choose <b>. Warning about a serious defect gives the writer a reason to mark the warning with <strong>. A choice that makes sense in one paragraph may misdescribe the same words in another.
Nor does the existence of four categories imply that every editorial distinction fits comfortably inside one of them. A project may need to distinguish a technical term from a character's thought even when both have been marked with <i>. WHATWG's HTML FAQ acknowledges the limited specificity of i and b. Additional project conventions can record a narrower purpose, but their usefulness depends on people or software knowing those conventions. A locally meaningful label does not automatically become a shared category of HTML.
Applying a classification changes the evidence available to anyone examining the document. Calling a passage important invites a different account of it from calling it a shift in voice. Markup can make an editorial decision inspectable even where the visual result gives a reader little reason to distinguish the two.
That decision is constrained by a shared vocabulary. The standard requires elements to be used for their intended semantic purposes. It even discusses documents that are syntactically correct yet nonconforming because their elements misdescribe the content. Correctly formed code and appropriate interpretation are separate responsibilities.
There is also room to dispute a priority without establishing a misuse of HTML. Consider an editor who sincerely regards every promotional sentence as strongly important. A skeptical reader may find those priorities excessive, yet disagreement alone does not prove that the element was used outside its defined purpose. The record makes the editorial judgment available for evaluation, even when the visual treatment alone would not identify it.
Presentation contributes its own evidence. If a warning is visually lost among competing decorations, an appropriate element alone does not rescue its communication. If the stressed word in our opening sentence receives no perceptible distinction, some readers may miss the intended correction. Changing font styling does not turn <i> into <em>, but it can change the clues available to the reader. Equally, two passages can look alike while performing different functions. Language, classification, and presentation work together, but they can also pull in different directions.
Accessibility makes the distinction between recording and communicating especially important. The HTML Accessibility API Mappings Working Draft maps em to the emphasis role and strong to the strong role. It assigns i and b the same generic role, so that role alone does not preserve their different authoring meanings. The draft also describes text styling exposed through some platform interfaces. These are different kinds of information about the passage; no one of them is a complete account of its use.
W3C's H49 technique explains the value of making emphasized or special text programmatically identifiable and describes possible visual and auditory treatments. Neither it nor the mapping document establishes how every browser and screen reader combination will present a marked passage. A claim about a particular spoken effect requires evidence about the implementation and its settings.
The practical consequence returns us to writing. Where a contrast is essential, an author can state it explicitly. If Friday is an absolute cutoff, the instruction could read, “Send the final version by Friday; later submissions cannot be included.” Markup can reinforce that communication, while the wording makes the consequence available without requiring a particular font or an assumed vocal effect.
An encoded distinction may have little immediate effect if the relevant reader or tool never encounters it. Preserving the classification creates an opportunity to use it; successful communication still depends on what happens in a particular encounter. The presence of markup cannot stand as proof that someone received its meaning.
Consider a later editor preparing a new edition of Mara's story. The phrase “Mara thought” already identifies the thought in the prose. If the markup survives, it also preserves the earlier choice to classify the passage using <i>. A conversion that retains only italic appearance leaves less evidence about that choice. Keeping the element makes the previous classification available for inspection, including the possibility that it needs correction.
An element can therefore travel with a text as a limited record of a classification. That classification may come from a writer, an editor, or an automated publishing rule; the source alone need not reveal which. In each case, the question remains whether it fits the passage. Repeating a decision consistently does not settle whether it was a good decision.
Return to “I sent the draft to Mara.” Marking “I” or “draft” identifies where the writer placed stress. The surrounding exchange helps a later editor understand that choice and judge whether it still serves the passage. The tag carries a particular reading forward, open to recognition and revision. It records what the writer chose to mark, while the sentence continues to ask more of its readers.
September 23, 2026
Two controls on a page can look almost identical. One takes a visitor to the festival program; the other asks the browser to print the current page. Their color and shape do not tell you which HTML element to use. The question is what happens when someone activates them.
Use a link, normally <a href="...">, when the purpose is to follow an address: another page, a file, or a place within the current page. Use a <button> when the purpose is to perform an action, such as submitting a form, opening a dialog, or revealing a control. The distinction affects more than screen-reader announcements. It also determines the keyboard and browser behavior people can expect.
<a href="/festival/program/">See the festival program</a>
<a href="#directions">Jump to directions</a>
<h2 id="directions">Directions</h2>
<a href="/files/program.pdf" download>Download the program (PDF)</a>
The first link leads to another page. The second leads to an element on this page whose id is directions. Both are navigation, even though one leaves the page and the other does not. The third identifies a file; the download attribute asks the browser to download it. The paths in these examples stand for real site addresses; replace them before using the markup.
A real link offers familiar browser options, including copying its address and opening its destination in a new tab. A visitor can normally move to it with the Tab key and follow it with Enter. A link can also be styled to look like a large ticket-purchase button. Its appearance does not change its job: if it takes the visitor to the ticket page, it remains a link.
The href matters. Under the HTML Standard's definition of <a>, an anchor without href is a placeholder, not a hyperlink. An anchor with href="#" is a link to the current document, not a general-purpose button. Neither is a good stand-in for a control meant to open a menu or perform some other action.
<button type="button" id="print-page">Print this page</button>
<script>
document.getElementById("print-page").addEventListener("click", () => {
window.print();
});
</script>
The button has no destination URL to follow. Its JavaScript listener requests the browser's print interface when the button is activated. Other buttons can submit forms, open dialogs, or control content already on the page. For a simple disclosure, <details> with <summary> may be a more specific native choice.
An enabled button can normally be reached by keyboard and activated with Enter or Space. It can also be disabled when an action is unavailable. A hyperlink has no corresponding native disabled attribute; adding aria-disabled="true" to a live link does not stop it from working. Giving an ordinary link a role="button" does not, by itself, supply the behavior of a button. If a native <button> can do the job, it is usually the simpler choice.
Write type="button" for a button that is not meant to submit a form. An untyped button associated with a form can act as a submit button, so the explicit type prevents an unrelated control from submitting the form by accident.
<form action="/events/search/" method="get">
<label for="event-query">Search events</label>
<input id="event-query" name="q">
<button type="submit">Search</button>
</form>
Submitting this form may take the visitor to a results page, provided the example search address is backed by a working endpoint. The Search control is still a button because it performs the form's submission, including sending the entered value. By comparison, <a href="/events/">Browse all events</a> simply follows an address. Whether the screen changes afterward is not, on its own, the test.
The same reasoning applies to a site that changes pages without a full reload. If a control leads to a destination with its own URL, a real link can preserve normal link behavior while the site handles the transition. The site must also make the new content understandable to keyboard and assistive-technology users. A navigation menu can use a button to open its choices and links for the destinations inside it.
<a href="#">Show filters</a> looks like a link, but it does not show filters. Following it can move the visitor toward the top of the page. Replace it with a button whose behavior actually shows the filters.
<button type="button">Read the full article</button> looks like a control, but if its only job is to go to the article's address, use <a href="/articles/full-story/">Read the full article</a>. That gives visitors ordinary link options, including copying the address or opening it separately. Do not put a button inside a link to try to obtain both sets of behavior; HTML does not permit that nesting.
For each control, ask what the visitor expects it to do. If the answer is “go to this address,” use a link with a real href. If the answer is “do this now,” use a button, give it the appropriate type, and make sure the action is actually implemented.
Then try the finished page with a keyboard. Tab through the controls, use Enter on links, and use Enter and Space on buttons. Check that names such as “See the festival program,” “Print this page,” and “Search” describe the result accurately. Good HTML begins with that ordinary expectation: the control should behave as its words and role promise.
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.
For corrections, permissions, privacy requests, or accessibility assistance, use the contact form or call +1 (650) 427-9358. For details, see Legal, Privacy and Accessibility.
Disclosure: AI tools assist with research, summaries, drafting, and editorial review. Their use varies by article and stage of the writing process. Ardan Michael Blum writes, revises, and updates the content, shapes its arguments and interpretations, and makes the final editorial decisions.