is tolerated but has no effect: the parser ignores it, so the element is still treated as closed by the parsing rules and not by the slash. This is one of the points where HTML's syntax departs from XML's, which requires void elements to be self-closed.\n\nA minimal valid document shows the main parts:\n\n\n\n \n \n
Hello, world.
\n![\"Site](\"logo.png\")
\n \n\n\nThe first line is the DOCTYPE, a required preamble that tells browsers the document is HTML. In current HTML it is written simply as , and the keyword is matched without regard to case. The document element is an html element, which holds a head for metadata such as the title, character encoding and linked resources, and a body for the displayed content. The specification also allows an optional byte order mark and any number of comments and whitespace characters before, between and after these parts. Some start and end tags, including those of head and body, can be omitted in defined circumstances, but authors are generally advised to write them out.\n\nEach element has a content model that specifies what it may contain, and the parser uses these rules to decide how to handle misplaced markup. For example, a p element accepts only phrasing content, so placing a div inside it is not allowed. When a parser meets such a div, it closes the paragraph first. List items belong inside ul, ol or menu, and table parts must follow a fixed nesting order. The script and style elements are raw text elements: their contents are not parsed as markup, and the text must not contain a closing tag matching their own name. The title and textarea elements are RCDATA elements, which means they can contain character references but not other tags. The detailed content rules form a separate topic, but the general principle is that the specification, not the browser, decides what a valid document may contain.\n\nComments are written as . Browsers do not display them, and they are ignored when the DOM is built. Special characters are written with character references. Named references such as &, <, > and " are common, and numeric references such as < or < can express any Unicode code point. A literal < in text is safe only where it does not begin a tag, and a literal & should be escaped when it could be read as the start of a reference. Inside attribute values, a double-quoted value must escape its own double quote as ". Unquoted attribute values are permitted only when they contain no spaces, quotation marks, equals signs, angle brackets or backticks. Boolean attributes such as disabled or required may be written without any value.\n\nTaken together, these rules give HTML a syntax that is compact for authors but precise enough for the parser to rebuild the same tree from any conforming source. The rules are summarized in the standard, which is maintained as the syntax of a markup language rather than a programming language. The resulting tree is exposed to scripts as the Document Object Model, and the same plain-text source can be read by any browser that follows the standard."
},
{
"heading": "Semantics and the content model",
"text": "Semantic versus presentational markup\n\nMany HTML elements carry a meaning that browsers, search engines and assistive software can read, not just a default look. The HTML Standard requires authors to use each element only for its intended semantic purpose, because software otherwise cannot process the page correctly. The specification forbids repurposing elements, attributes or attribute values for other ends, since that prevents software from processing the page as intended.\n\nOlder terms such as \"block-level\" and \"inline\" describe how elements are displayed, not what they mean. Those ideas came from earlier specifications and CSS defaults, and they describe presentation of elements but not their meaning. HTML 4.01 drew that block/inline line, and HTML5 replaced it with a set of more complex set of content categories.\n\nThe sectioning elements (article, aside, nav and section) define the scope of the header and footer elements that belong to them, and they build the document outline. The section element is not a generic container; when an element is needed only for styling or scripting convenience, the div element is the recommended choice. The article element suits material that could stand alone, such as a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment. The nav element marks a section of a page that links to other pages or to parts within the page. The main element identifies the primary content, and a page should normally contain only one, with content unique to that page.\n\nHeadings run from h1 to h6, and user agents can use heading information to construct a table of contents for a document automatically. Authors should not choose headings for their size: headings should not be used to resize text, and the CSS font-size property should be used instead. Levels should also not be skipped.\n\nText-level, grouping and list elements\n\nText-level (phrasing) elements mark up meaning within a sentence. em signals stress emphasis that can change a sentence's meaning, while strong signals importance. cite, abbr, code, time and mark give further information about titles, abbreviations, machine-readable dates and highlighted text. The older presentational elements b and i survive with narrower meanings, for conventional typography without added importance or for text in an alternative voice.\n\nGrouping elements, such as p, div, blockquote and pre, organise content without adding much meaning of their own. List elements are more informative: ul and ol mark unordered and ordered lists, li marks each item, and dl pairs terms with descriptions. Assistive software announces lists and their item counts, and an ordered list tells the user that sequence matters. Because of this, choosing the right list or paragraph element affects navigation for screen-reader users as well as visual layout.\n\nTables and the layout misuse\n\nTables are meant for tabular data, meaning information whose rows and columns express relationships. Their history is different. Tables were added by Mosaic (later Netscape) after the 1993 HTML recommendation, and even HTML 2.0, which was completed in November of 1995, did not include most advanced browser features, including tables. Tables have existed as part of web standards since the HTML 3.2 standard (January 1997).\n\nDesigners quickly used tables to control layout. Perhaps the most popular of these techniques was the use of HTML tables to create multi-dimensional, nested grids. Spacer images and nested cells made such pages hard to maintain. The standard later turned against the practice: warnings appeared in HTML 4 in 1998 and 4.01 in 1999, and CSS1 was added to the standard in 1998 to provide layout flexibility without having to resort to tables. The current specification states that tables must not be used as layout aids. The accessibility cost was real: while the use of table markup was transparent to visual readers, it forced AT users into table reading mode.\n\nCorrect data tables use header cells, captions and scope attributes to state which headers apply to which cells, so that the relationships are available to assistive software.\n\nThe content model categories\n\nEvery element belongs to one or more content categories, and these categories define the content model: what each element can take as descendants. For example, the paragraph element can only contain phrasing content, while the div element can contain flow content.\n\nThe main categories are metadata, flow, sectioning, heading, phrasing, embedded and interactive content. These categories are not hierarchical. They do not stack or inherit from one another. Flow content is the broad class used in the body, and sectioning content, heading content, phrasing content, embedded content, and interactive content are all types of flow content. Phrasing content is the text and the markup inside it, and sequences of phrasing content make up paragraphs. Heading content defines the title of a section.\n\nBecause one element can fall into several categories, placement rules are specific. The a element, for instance, is flow and phrasing content in general, and it becomes interactive content when it has an href attribute. A flow-only element such as a div placed inside a phrasing element like span is non-conforming, even if browsers still render it. Authors therefore check not only that a tag is spelled correctly, but that each parent accepts that child."
},
{
"heading": "Hyperlinks, media and embedded content",
"text": "Anchors, URLs and fragment identifiers\n\nThe a element creates a hyperlink. Its href attribute holds a URL, which may be absolute (a complete address with a scheme and host) or relative, in which case the browser resolves it against the address of the current document or against a base element if one is present. A link can also point to a position inside a document. The part after a \"#\" is a fragment identifier, and the browser looks for the element whose id attribute matches it. Any element with an id can serve as a target, so authors rarely need the older name attribute on a, which HTML5 has dropped in favour of id. Graphical browsers scroll so that the target sits at the top of the viewport, which makes fragments the usual mechanism for tables of contents and \"skip to content\" links. The :target pseudo-class in CSS can style the element that a fragment currently points to. A fragment can also be appended to the address of another page, so a link can open a specific section of a different document.\n\nImages, responsive sources and the picture element\n\nThe img element requires an src attribute and an alt attribute. The alt text stands in for the image when it cannot be displayed and is read aloud by screen readers; a decorative image is given an empty alt value so that assistive software skips it. To serve different files for different screens, img accepts a srcset attribute that lists candidate files either by intrinsic width (with the w descriptor) or by pixel density (with the x descriptor). The sizes attribute tells the browser how wide the image will be laid out at various viewport widths, so that it can choose and start downloading the right file before stylesheets have been processed. Without sizes, a browser may assume the image fills the whole viewport and pick a larger file than necessary.\n\nWhen a change of crop or file format is needed rather than a change of resolution, the picture element is used. It contains one or more source elements, each with its own srcset and optional media or type attributes, and the browser uses the first source that matches. A plain img inside the picture element remains necessary as the fallback. Authors are advised to include width and height so that the page layout does not shift when the image arrives, and to avoid lazy loading for the main image above the fold.\n\nAudio, video and text tracks\n\nThe audio and video elements embed time-based media without a plug-in. A source can be given directly with src, or several source children can offer the same media in different formats, with the browser choosing the first format it can play. Any content placed between the opening and closing tags is ignored by modern browsers and shown only by agents that do not understand the element, so it serves as a fallback message or a download link. Captions and other timed text are attached with track elements. The kind attribute specifies whether a track holds subtitles, captions, descriptions, chapter titles or metadata, while srclang and label identify its language and the name shown in the player menu, and default selects the track to display initially. The track files are normally written in WebVTT. Because browsers restrict autoplay, pages that want media to start on their own often mute it.\n\nEmbedded content: iframe, object and embed\n\nThe iframe element loads another HTML document into a rectangular region of the page, creating a separate browsing context. Its sandbox attribute applies a set of restrictions to the framed document, such as disabling scripts, form submission and popups, and treating the content as a unique origin. Specific capabilities can be re-enabled with tokens, but combining allow-scripts with allow-same-origin for same-origin content effectively removes the protection, because the embedded page can then strip the sandbox attribute itself. The allow attribute controls access to features such as camera, fullscreen or autoplay through Permissions Policy, and the loading attribute with the value lazy defers fetching frames that are off screen, which reduces bandwidth and speeds up initial loading, although each frame still adds a further document, scripts and third-party requests.\n\nThe object element is a general container for external resources such as images, nested documents or plug-ins, and it can carry fallback content inside its tags. The embed element is a void element that simply points to an external resource. Both were once used for browser plug-ins such as Java applets and Flash, which have largely disappeared from the web, so their use is now mostly limited to PDFs and other documents. Their security and performance profiles depend on what they load, and they offer fewer sandboxing controls than iframe. Embedding third-party content of any kind raises concerns about privacy and tracking, and it is discussed further in the section on security and privacy."
},
{
"heading": "Forms and user input",
"text": "HTML forms are the standard way a web page collects information from a person and sends it onward. A form is a container element that groups controls such as text fields, check boxes, radio buttons, menus and buttons, and its action and method attributes tell the browser where to send the data and how. The method attribute accepts two values. With the default GET method, the browser appends the name–value pairs to the action URL after a ?, which makes the result bookmarkable and cacheable but places the data in the address bar and history. With POST, the same data travels in the body of the HTTP request, so it stays out of the URL and is not constrained by URL length. Developers therefore use GET for harmless lookups such as search queries and POST for anything that changes server state, such as creating an account or placing an order. Because GET data is visible and easy to alter, it should never carry passwords or other sensitive values. The request format itself is defined by the HTTP protocol, and the server-side handling of submitted data is covered in web application architecture rather than in HTML itself.\n\nInput controls and labels\n\nMost form fields are created with the input element, and its type attribute decides what kind of control appears. If no type is given, the field defaults to plain text. Besides text and password fields, HTML defines types for email addresses, telephone numbers, URLs, numbers, range sliders, search boxes, and date, time and month values. Browsers render several of these as native controls. A date type opens a calendar or numeric pickers, a color type opens a color chooser, and a file type shows a file-selection dialog. The accept and multiple attributes restrict or expand what a file upload may contain. Each control should be tied to a label element, either by wrapping it or by matching the label's for attribute to the control's id. This association gives the field a name for assistive software and lets users click the label to focus the field. The select element provides a drop-down list of option elements, and textarea provides a multi-line text box. Each control's submitted value is identified by its name attribute; controls without a name are not sent.\n\nSome types also normalize their values. A date field, for example, always submits a fixed format regardless of how the browser displays it to the user, and a color field submits a six-digit hexadecimal string. Developers who rely on these types must therefore expect a standard format on the server, not the display format the user saw.\n\nBuilt-in validation and its limits\n\nHTML provides constraint validation, which lets the browser check input before submission without custom scripts. The required attribute makes a field mandatory; on a check box it means the box must be ticked, and on a group of radio buttons sharing a name it means one option must be selected. minlength and maxlength limit the number of characters in text-like fields. min, max and step constrain numbers and date-like values, with step restricting values to a set of intervals. The pattern attribute takes a regular expression that the value must match, and it applies to text, search, URL, telephone, email and password fields but not to number fields. When a value fails a constraint, the browser normally blocks submission and displays a message, and the title attribute can supply a custom hint for pattern failures.\n\nThese mechanisms have clear limits. Browsers differ in the wording and appearance of their messages, and some constraints behave differently across engines or are only partly supported in older browsers. Validation runs only in the client, so it can be bypassed by anyone who sends a request directly, which means servers must repeat all checks before trusting the data. Built-in checks also cannot verify that an email address exists, that a password is strong, or that a value is consistent with other records. Accessibility depends on how error messages are announced, which is a separate concern discussed under security and accessibility practices.\n\nDatalist, textarea and other native controls\n\nThe datalist element supplies a set of predefined options that an input can offer as suggestions. The input is linked to the list through its list attribute, which must match the list's id. The user can still type any value, so a datalist differs from a select menu, which restricts the choice to listed options. Datalists work with text, number, date and range inputs, and with color inputs they offer a palette of swatches. Older or unsupported browsers may ignore the suggestions, so the field should still work without them. The textarea element handles long free-form text, and its size and wrapping can be set by attributes or styles.\n\nBecause native controls are rendered by each browser or operating system, their appearance and behavior vary, which affects consistency across platforms. Developers who need a uniform design often replace them with scripted widgets, but that approach adds code and can reduce accessibility if not built carefully. Native controls remain the most reliable baseline because they work without scripting and carry built-in keyboard and assistive-technology support.\n\nForms as the channel for user input\n\nForms remain the principal mechanism through which people give information to websites. Login pages, search boxes, checkout flows, surveys, content editors and administrative consoles all depend on them, and many web applications are essentially collections of forms backed by databases. Since so much data passes through this channel, the quality of form markup affects usability, data quality and security. Well-labeled, correctly typed fields reduce errors and help browsers offer autofill, while poorly designed forms cause abandoned transactions and invalid records. Because form data is untrusted, the data must be validated and handled safely on the server, and the protection of submitted personal information connects this topic to data privacy concerns."
},
{
"heading": "Origins at CERN (1989–1991)",
"text": "The origins of HTML lie in Tim Berners-Lee's work at CERN, the European particle physics laboratory in Geneva. In 1980, while working there as a contractor, he wrote ENQUIRE, a notebook program that let him link arbitrary nodes of information. Each node had a title, a type and a list of typed, bidirectional links. ENQUIRE was never published, but it served as the conceptual basis for the Web. The problem it addressed was a practical one: physicists arriving at CERN from many countries used incompatible computers and presentation software, and their information sat in separate, self-contained databases that could not be connected.\n\nIn March 1989 Berners-Lee circulated a paper titled Information Management: A Proposal, which argued for an internet-based hypertext system. Its reception was lukewarm; the proposal generated little interest from management. It was recirculated in May 1990, and in October it was reformulated with encouragement from divisional management, with Robert Cailliau as co-author. In November 1990 the two submitted a formal management proposal, WorldWideWeb: Proposal for a HyperText Project, which requested a small team for six months. Management supported the project only at a lower level, but Berners-Lee's superior, Mike Sendall, encouraged him to build a pilot implementation on a newly acquired NeXT workstation. The proposal divided the envisioned system into a browser and a server that communicate through a standardized protocol, and it explicitly treated copyright enforcement and data security as outside its scope, because CERN's culture rested on free exchange of information.\n\nBy the end of 1990 the core pieces existed on the NeXT machine: a markup format (HTML), the URL scheme, an early version of HTTP, the first browser and the first server, which ran at the address info.cern.ch. The browser, called WorldWideWeb, was also an editor. It was a \"what you see is what you get\" program that allowed links to be created inline, and it reflected Berners-Lee's original goal that the Web should support authoring and personal organization, not only reading. The earliest known HTML document is dated 3 December 1990. Cailliau contributed to the project's organization and promotion, and the first web page described the project itself, which made the early Web largely self-documenting.\n\nThe first public description of the language was a document titled \"HTML Tags\", placed on CERN's server in late 1991; the Web Design Museum dates it to 29 October 1991. It described the first eighteen tags, among them title, a (anchor), p, h1 to h6, address, the list elements ul, li, dl, dt and dd, and menu and dir. Except for the hyperlink tag, these elements were strongly influenced by SGMLguid, an in-house documentation format at CERN based on SGML. Eleven of the original elements still existed in HTML 4.\n\nThe early design favored simplicity and the sharing of scientific documents over visual layout. Its goal was a universal format that any computer could display, with the browser deciding how each element looked. Headings, paragraphs, lists and links described what a piece of text was, not how it should appear. This choice, which fit the needs of physicists exchanging reports and data, later became the basis of the separation between structure and presentation that the standard pursued. The minimal vocabulary also made the language easy to learn and implement, which helped the Web grow quickly once Berners-Lee and Cailliau made the software publicly available."
},
{
"heading": "Early standards and the browser era (1993–1997)",
"text": "Formal standardization of HTML moved out of CERN and into the Internet standards process. Between 1993 and 1995, documents were distributed publicly by IETF, first in June 1993 as an Internet Draft. In 1994, the Internet Engineering Task Force formed an HTML working group, which published several Internet Drafts of a specification for HTML. The result was RFC 1866, a product of the HTML Working Group of the IETF, edited by Dan Connolly, which was published in November 1995 as \"HTML 2.0.\"\n\nRFC 1866 described HTML as a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics, so the language was defined in terms of SGML rather than as a standalone grammar. Its stated scope was broad, covering hypertext news, mail, documentation, and hypermedia; menus of options; database query results. The specification roughly corresponds to the capabilities of HTML in common use prior to June 1994, so it codified existing practice rather than inventing a new design. Its support for presentation was minimal: it allowed an external style sheet to be associated with a document through a LINK element, but did not define styling itself.\n\nResponsibility for the language then shifted. The IETF HTML Working group disbanded in December 1995 and the W3C became the home for HTML standardization. The W3C had been founded in October 1994 with Berners-Lee as Director. Its first HTML specification, HTML 3.2, was issued as a W3C Recommendation, in January 1997. It was developed with industry participants, and the W3C later noted that HTML 3.2 was developed together with vendors including IBM, Microsoft, Netscape Communications Corporation, Novell, SoftQuad, Spyglass, and Sun Microsystems. The working group's aim was to codify common practice in 1996, meaning that features already used by browsers were written down. HTML 3.2 added tables, applets, text flow around images, superscripts and subscripts. An earlier, far more ambitious HTML 3.0 draft had circulated in 1995 but did not become the basis of a standard.\n\nCompetition between browser vendors, particularly Netscape and Microsoft, pushed the language in several directions at once. Each vendor introduced nonstandard elements and attributes, such as Netscape's blink and font-related markup and Microsoft's marquee, to answer customer demands before standards caught up. Pages that depended on these features worked only in one browser, and the gap between vendor practice and the published specifications produced compatibility problems that persisted for years. Much of the later effort to define HTML's parsing and error handling can be read as a response to this period.\n\nHTML 4.0 became a W3C Recommendation on 18 December, 1997. It extends HTML with mechanisms for style sheets, scripting, frames, embedding objects, improved support for right to left and mixed direction text, richer tables, and enhancements to forms, offering improved accessibility for people with disabilities.\n\nThe separation of presentation from structure became an explicit goal in this period. Style sheets had been proposed earlier: a proposal for a syntax for cascading style sheets to permit the separation of styling instructions for HTML content from its semantic structure was proposed in October 1994 by Håkon Lie. Before style sheets were widely available, HTML 3.2 carried a number of attributes and elements offering control over alignment, font size, and text color. Authors also exploited tables and images as a means for laying out pages. HTML 4.0 treated this as a problem: its developers stated that better distinction between document structure and presentation was a priority, encouraging authors to use style sheets rather than presentation elements. The specification explained that style sheets simplify HTML markup and largely relieve HTML of the responsibilities of presentation. Accordingly, the W3C said it will eventually phase out many of HTML's presentation elements and attributes, and marked such features as deprecated, a policy that shaped the design of later versions."
},
{
"heading": "XHTML and the XML turn (1998–2009)",
"text": "Reformulating HTML as XML\n\nIn 1998 the W3C's HTML working group began rebuilding HTML on top of XML 1.0, a language the W3C had published as a Recommendation in February 1998. The first result, XHTML 1.0, became a W3C Recommendation on 26 January 2000. It was defined as a reformulation of HTML 4 as an XML application, and it provided three document types matching the Strict, Transitional and Frameset variants of HTML 4. The aim was to keep existing pages working in browsers while making documents usable by XML tools, such as XSLT transformations and CSS styling, and by programs that process documents as a DOM tree. The specification included compatibility guidelines explaining how to write XHTML that current browsers would still display.\n\nThe motivations were partly technical. Browsers had long tolerated markup errors, and the extra code needed to recover from them caused performance problems, particularly on small devices. HTML 4 was nominally an application of SGML, but SGML was complicated, and neither browsers nor the HTML 4 specification fully conformed to it. XML offered a simpler underlying syntax that servers could generate and transform more easily for mobile phones and other devices. XHTML was therefore a bet that a strictly defined syntax would make the Web more predictable.\n\nModularization and XHTML Basic\n\nAlongside the core language, the working group developed modularization. XHTML Basic, a W3C Recommendation of December 2000, selected a minimal set of modules for devices such as phones, pagers and televisions. The Modularization of XHTML, published as a Recommendation on 10 April 2001, split XHTML 1.0 into abstract modules that could be combined, subsetted or extended. XHTML 1.1, built from these modules, followed on 31 May 2001. The intention was that an industry, such as mobile telephony, could define its own XHTML variant by dropping features such as tables or frames and adding vocabularies from other XML namespaces.\n\nIn practice the mechanism was demanding. Extending the modules through DTDs required considerable parameter-entity work, so the modules were later re-expressed in XML Schema, and a RelaxNG version followed in 2010. The attempt to make the language extensible in this way foreshadowed the much larger ambitions of XHTML 2.0.\n\nStrict parsing and the adoption problem\n\nXML requires that every element be closed, that attributes be quoted, and that documents be well formed. A conforming XML processor is expected to stop at the first well-formedness error rather than guess what the author meant. Browsers did the opposite, accepting the loose \"tag soup\" that authors had been writing for years. This left authors with an awkward choice. If XHTML was served with the text/html type, browsers handled it as HTML and the strictness was lost. If it was served as application/xhtml+xml, which RFC 3236 registered as a media type, any error could make the page fail to display, and some widely used browsers, including older versions of Internet Explorer, did not support that type at all.\n\nMany authors, content management systems and tool vendors found the discipline costly, and the expected migration from HTML to XHTML did not happen on the scale the W3C had hoped. The result was that most pages stayed in HTML syntax even when they claimed to be XHTML.\n\nXHTML 2.0 and the return to HTML\n\nXHTML 2.0 was meant to be the more ambitious successor. The first W3C draft appeared in 2002 and was last updated in 2006, and the XHTML2 Working Group was chartered in March 2007. The design broke compatibility with XHTML 1.0, which the W3C later identified as the main reason the project was abandoned. On 2 July 2009 the W3C announced that the group's charter would expire at the end of 2009 without renewal, and that resources would move to the HTML Working Group to accelerate HTML5 and clarify the future of HTML. The XHTML2 group was formally closed on 17 December 2010, and a draft of XHTML 2.0 was published only as a Working Group Note. XHTML survived as a serialization: the HTML5 specification contains an XHTML syntax section, and the W3C's XHTML 1.0 second edition was marked retired in 2018."
},
{
"heading": "WHATWG, HTML5 and the Living Standard (2004–present)",
"text": "Origins of the WHATWG (2004)\n\nIn the early 2000s the Web standards body was moving toward XHTML, an XML-based successor to HTML. At a W3C workshop in June 2004, Opera and Mozilla presented a position paper proposing extensions to HTML that would remain compatible with existing browsers. The workshop concluded with a vote—8 for, 14 against—for continuing work on HTML. The WHATWG mailing list was announced on 4 June 2004, two days after the initiatives of a joint Opera–Mozilla position paper had been voted down by the W3C members at the W3C Workshop on Web Applications and Compound Documents. Apple, Mozilla and Opera then continued the effort as the Web Hypertext Application Technology Working Group. The new group was intended to produce a better HTML specification that could support the new breed of web applications, without — crucially — breaking backwards compatibility.\n\nIts specification goals were concrete. A key objective for the WHATWG was backwards compatibility to ensure good rendering of existing websites. Another objective was that the specification be detailed enough that implementers such as browser developers can achieve complete interoperability without reverse-engineering.\n\nFrom HTML5 to HTML (2007–2014)\n\nThe W3C's HTML working group later adopted the WHATWG work as its starting point. On 9 May 2007, the new HTML working group of the W3C resolved to do that. The WHATWG published its first public draft on 22 January 2008, and HTML5 was first released in a public-facing form on 22 January 2008. In January 2011 the WHATWG renamed its specification from HTML5 to the HTML Living Standard. The W3C nevertheless continued its project to release HTML5. The W3C advanced HTML5 to \"Last Call\" in May 2011, and on 28 October 2014, HTML5 was released as a W3C Recommendation. Later snapshots followed: 5.0 (2014); 5.1 (2016); 5.2 (2017).\n\nThe 2012 split\n\nThe two bodies formally separated their work in 2012. The WHATWG editor, Ian Hickson, explained that the W3C had split its HTML5 material into subspecifications, while the WHATWG had tried to match that structure. The result was an increasing confusion of versions of the spec, so we eventually went back to just having a single spec on the WHATWG side, which became the HTML Living Standard. Hickson described the two efforts as having different aims: the WHATWG would focus on developing the canonical description of HTML and related technologies, while the W3C would produce a snapshot developed according to the venerable W3C process. In practice the disagreement was partly over terminology. In 2012, the two groups announced that the WHATWG would maintain a living standard, while the W3C would continue with versions.\n\nThe result was divergence. While the W3C standard was identical to the WHATWG, in 2007, the standards have since progressively diverged due to different design decisions. Browser vendors generally treated the WHATWG text as the reference. A Mozilla engineer described this in 2014: \"When the W3C's and WHATWG's HTML specifications differ, we tend to follow the WHATWG one.\"\n\nThe living standard model\n\nA living standard has no version numbers and is revised continuously. The concept of a living standard is that it is never complete and is always being updated and improved. New features can be added but functionality will not be removed. This model also changed how features reached the web. Browsers started implementing new elements and API's as experimental features, before they were fully defined in an official specification. Real-world implementation experience then fed back into the text.\n\nReconvergence\n\nThe split was eventually reversed in practice. Under a memorandum of understanding signed in May 2019, WHATWG will maintain the HTML and DOM Living Standards, while W3C will facilitate community work directly in the WHATWG repositories. W3C is ending its publishing of its designated list of specifications and will work to take WHATWG Review Drafts to W3C Recommendations. Under this arrangement the WHATWG text is the main source for HTML, while W3C continues to endorse snapshots of it."
},
{
"heading": "Parsing and error handling",
"text": "Turning a served document into a DOM tree happens in two stages. The input is a stream of code points, which is passed through a tokenization stage followed by a tree construction stage. The tokenizer reads characters and groups them into tokens, and the tree builder consumes those tokens to produce a Document object. The tokenizer is driven by a state machine; one account puts the number of states at 80. The tokens fall into a small set of kinds: doctype, start and end tags, comments, runs of characters, and end of file.\n\nThe two stages are tightly coupled. When a token is emitted, it must immediately be handled by the tree construction stage. The tree builder applies the rules tied to the current insertion mode, so the same token can be handled differently depending on where the parser is in the document. The builder also keeps a stack of open elements to automatically correct errors, which lets it close elements the author left open and insert elements the author implied. It can also change how the tokenizer reads input. When the tree builder sees certain start tag tokens, it will switch state of the tokenizer to a text-like mode. Examples include title, textarea (RCDATA) and style, xmp, iframe, noembed, noframes, noscript (if scripting is enabled) (RAWTEXT).\n\nScripts add a further dependency. A script can call document.write during parsing, inserting markup that the tokenizer must read next, so the specification tracks a script nesting level and a parser pause flag. The tree construction stage is reentrant, meaning that while the tree construction stage is handling one token, the tokenizer might be resumed. Parsing does not freeze the tree afterward either: after parsing completes, scripts can still modify the tree in real time, which is the path through which the Document Object Model is later changed by JavaScript.\n\nThe specification treats parse errors as a normal part of parsing rather than a reason to stop. It defines the parsing rules for HTML documents, whether they are syntactically correct or not. A user agent may either apply the defined recovery behavior or abort processing at the first error that they encounter for which it does not wish to apply the rules. Conformance checkers have a different duty: they must report at least one parse error condition to the user if one or more parse error conditions exist in the document, but are not required to recover from parse errors. The aim of the recovery rules is consistency. Because the rules are fixed, HTML parsers are more complete and deterministic than SGML or XML parsers. Byte-level problems follow the same pattern: bytes or sequences of bytes that could not be converted to Unicode code points must be converted to U+FFFD REPLACEMENT CHARACTERs.\n\nThis consistency was a response to history. SGML also did not specify any error handling behavior. Meanwhile web content was poorly formed, and browsers developed their own recovery habits. The result, often called tag soup, meant that each browser was correcting all these errors in a different way.\n\nThe contrast with XML explains why HTML kept a forgiving syntax. XML, published in 1997, mandated that all programs that consumed XML must treat so-called \"well-formedness\" errors as fatal. An XML processor is required to report such errors and to cease normal processing. XHTML brought this model to the web, and browsers serving XHTML as XML had to follow it. The cost was that while the browsers agreed to enforce the draconian error handling, this led to the proliferation of blank error pages. A single unescaped ampersand in a link's href could be enough to stop a page from rendering. HTML therefore retained its tolerant parsing model and is treated as a separate language with its own parsing rules rather than as an XML dialect.\n\nFor authors, the practical consequence is that browser recovery often hides mistakes instead of reporting them. Validation and linting are the tools for finding malformed markup before it reaches a browser. The parsing algorithm defines what a browser shows when markup is broken, and that definition is why the same broken page tends to look the same across engines."
},
{
"heading": "Integration with CSS, JavaScript and the DOM",
"text": "The Document Object Model\n\nWhen a browser receives an HTML file, it converts the byte stream into an in-memory tree of objects, the Document Object Model (DOM). Each element, attribute and text run becomes a node. Scripts do not read the source markup after the page loads; they query and change this tree, for example by looking up an element by its ID, changing its text, or inserting new nodes. The rendering engine then turns the tree, together with the styles computed from CSS rules, into the visible page. Because the DOM is the live state of the document, a change made by a script is reflected on screen without reloading the file, although the original HTML source remains unchanged. The standard that defines HTML also defines how the DOM is structured, so the markup, the tree and the scripting interface are three views of one document.\n\nScript and style elements, and loading order\n\nThe JavaScript script element is the main way HTML hands control to code, and its loading behaviour is one of the most consequential details of page performance. By default, a classic script halts the HTML parser: the browser downloads an external file if needed, runs it, and only then resumes building the tree. The reason is that a script may write to the document, so the parser cannot safely work ahead. Browsers have since added speculative parsing, which scans ahead for resources to fetch, but inline scripts still stop the main parse.\n\nThe async and defer attributes relax this constraint in different ways. An async script is downloaded in parallel and runs as soon as it arrives, which may happen before parsing ends and out of document order; it is suited to independent scripts such as analytics. A defer script is downloaded in parallel but runs only after parsing is complete, and deferred scripts run in the order they appear. Module scripts defer by default. Neither attribute works on inline scripts without a src.\n\nStylesheets interact with this sequence. A link to a stylesheet does not stop the parser from building the DOM, but it does block rendering, and a script that follows a stylesheet must wait until that stylesheet is available, because the script might read computed styles. For this reason, placing a plain script in the head of a page can delay the first visible paint.\n\nWeb APIs exposed through HTML\n\nMany capabilities that users associate with web applications are reached through HTML elements or through interfaces attached to the document and window. The canvas element provides a drawing surface; a script obtains a 2D rendering context and issues drawing commands to it, and the same surface can be exported as image data. The Web Storage API adds two key-value stores: localStorage, which is partitioned by origin and survives closing the browser, and sessionStorage, which is scoped to a single tab and page session. The History API lets a script change the URL and navigation state of a single-page application without a full reload. These APIs are defined in separate specifications but are part of the same web platform, and they are controlled by the same origin and permission rules that govern the rest of the document.\n\nCustom elements, shadow DOM and templates\n\nHTML's component model rests on three standards. The template element holds markup that the parser stores but does not render or run; a script can clone its contents when needed. Custom elements allow authors to define new element types as JavaScript classes that extend HTMLElement, registered with customElements.define; by convention, the name must contain a hyphen, which distinguishes it from built-in elements. Shadow DOM attaches an encapsulated subtree to an element, so that the component's internal structure and CSS do not leak into or get affected by the surrounding page, while slot elements control where light-DOM children are placed inside that subtree. The combination provides self-contained, reusable components that behave much like built-in elements. Recent browsers also support declarative shadow DOM, in which a template element with a shadowrootmode attribute lets the HTML parser create the shadow root without script, which helps with server-rendered components. Encapsulation has limits, notably for sharing global stylesheets with the shadow tree, and it has to be balanced against accessibility, since content hidden inside shadow roots can complicate focus and labelling."
},
{
"heading": "Character encoding, language and metadata",
"text": "Character encoding\n\nA browser must know how to turn the bytes of an HTML file into characters before it can display them. Authors usually state this in a meta element with a charset attribute, as in a charset attribute that sets the character encoding for the page, and the declaration belongs early in the head so the parser sees it before any non-ASCII text. A mismatch between the declared and actual encoding produces garbled text. The classic example is a UTF-8 page whose German place name may display incorrectly because the software guessed a different encoding before testing for UTF-8.\n\nUTF-8 has become the near-universal choice. In September 2026, W3Techs measured UTF-8 on 99.1% of all the websites whose character encoding we know, and the next encoding, ISO-8859-1, accounted for only 0.8%. UTF-8 is the encoding form of Unicode that matters most for the web. It supports all valid Unicode code points using a variable-width encoding of one to four bytes, which allows a single HTML document to mix Latin, Arabic, Chinese, Devanagari and emoji without switching encodings. Because it preserves ASCII for the basic Latin range, older ASCII-only content also remains valid.\n\nLanguage and direction\n\nThe lang attribute can be placed on any element to declare the natural language of its content. Browsers use this information for font selection, hyphenation and spell-checking, and assistive technologies use it to choose the correct speech synthesis voice. Language and direction are separate properties. As one guide notes, language declarations do not imply directionality or vice versa, so the two must be set separately.\n\nThe dir attribute controls base text direction and takes the values ltr, rtl or auto. Authors normally set a dir attribute on the html tag to set the default base direction of the page if it is right-to-left, and apply the attribute to individual blocks where a different direction is needed. The auto value suits content whose direction is unknown in advance, such as data coming from user input or external sources. Direction is inherited from the parent element, and if no ancestor sets a direction, the default is left-to-right. The W3C's internationalization guidance recommends that markup rather than CSS control directionality in HTML, since the expected behavior of the dir attribute is clearly defined in the HTML specification.\n\nMetadata\n\nMetadata elements carry information that is not displayed on the page. The meta element contains information used by browsers and search engines rather than directly visible on the page. A named meta element pairs a name with a content value; the most common names include description, theme-color and viewport. The description is used by search engines such as Google to adjust how a page appears in search results. The theme-color value suggests a color that browsers can use to customize the page or the surrounding interface.\n\nThe viewport meta element governs layout on mobile devices. The widely used form width=device-width, initial-scale=1.0 gives the browser instructions on how to control the page's dimensions and scaling. The width value makes the layout follow the device's screen width, and the initial scale sets the zoom level on first load. Developers should avoid restricting user zoom without strong reason, because allowing user scaling supports accessibility unless specific restrictions are required.\n\nThe link element, which is separate from meta, identifies resources related to the document, such as stylesheets, icons, alternate-language versions and canonical URLs. Its rel and hreflang attributes describe how each resource relates to the page.\n\nInternationalization challenges\n\nMixed-script text is the most structurally demanding case. When a document contains right-to-left characters, the user agent must apply the bidirectional algorithm to decide the visual order of runs of text. The result can be correct only when the markup is correct: a Hebrew sentence containing English words displays those words in their proper order only if the bidi algorithm handles them properly, and inline phrases that run against the base direction should be wrapped in elements that set their own direction. The bidirectional text rules are therefore a common source of errors in multilingual pages.\n\nDates, times and numbers pose a related problem. HTML provides the time element with a machine-readable datetime attribute, so that a page can carry an unambiguous value such as an ISO 8601 date while the browser or script formats it for the reader's locale. Date order, calendar systems, digit shapes and decimal separators differ across cultures, and JavaScript APIs such as Intl are commonly used to apply locale conventions rather than hard-coding a single format."
},
{
"heading": "Accessibility",
"text": "Accessibility matters to HTML because most assistive technologies cannot read the visual rendering of a page. Screen readers, braille displays, switch devices and voice-control software work from the accessibility tree that the browser derives from the web document. The elements an author chooses largely determine that tree. A native button arrives with a role, a name, a state and keyboard behaviour. A div with a click handler arrives with none of these, so semantic markup is the most economical form of accessibility.\n\nSemantic markup and text alternatives\n\nReal headings (h1 to h6), landmark elements such as header, nav, main and footer, and proper lists let a screen reader user jump between regions, skip repeated navigation and hear how many items a list contains. Non-text content needs a text equivalent. The alt attribute on img supplies one, and an empty alt value marks a decorative image so that assistive software skips it. Tables need header cells that are associated with their data cells, and multimedia needs captions and transcripts. Authors who rely on visual cues alone, such as colour or position, exclude users who cannot perceive them.\n\nARIA and the first rule\n\nWAI-ARIA is a W3C specification from the Web Accessibility Initiative. It defines roles, states and properties that describe dynamic or custom interface components, such as tabs, tree views and live status messages, which native HTML does not express. ARIA changes only how assistive technology perceives an element. It adds no keyboard handling, focus behaviour or styling. The specification's first rule is to use a native element or attribute that already has the required semantics and behaviour, instead of repurposing an element and adding a role. The second rule is not to change native semantics unless necessary, so a heading should not be turned into a tab. The contrast is clear in practice. Making a div act as a button requires role=\"button\", a tabindex, and scripts for the Enter and Space keys, all written by the developer. The native button provides these by default. A 2026 WebAIM Million report, as summarised by one industry guide, found that pages using ARIA averaged more detectable errors than pages without it, which suggests that ARIA is often applied incorrectly. The figure is correlational and does not prove causation.\n\nKeyboard access, focus and form labels\n\nNative interactive elements are reachable by keyboard and expose focus indicators without extra work. Custom widgets must implement arrow-key navigation, focus movement and visible focus rings themselves. A dialog, for example, should receive focus when it opens and return it to the triggering control when it closes. Every form control needs an accessible name. The usual method is a label element associated with the control through for and id, or wrapping it directly. Where a visible label cannot be used, aria-label or aria-labelledby supply the name. Placeholder text and icons alone do not provide a reliable name. Controls must also be operable without a mouse, and this applies equally to form-related scripted components.\n\nStandards and legal reasons for compliance\n\nThe Web Content Accessibility Guidelines (WCAG) are the principal technical reference. Legal requirements in several jurisdictions refer to them. US federal agencies and organisations receiving federal funds fall under Section 508 of the Rehabilitation Act, which, after its 2017 refresh, references WCAG 2.0 Level A and AA. In the European Union, the European Accessibility Act, which applies to many digital products and services and has been enforced since June 2025, relies on EN 301 549, which incorporates WCAG 2.1 AA. Private-sector websites in the United States are assessed under the Americans with Disabilities Act, and US courts commonly use WCAG Level AA as a benchmark. Compliance is therefore partly a legal obligation and partly a procurement condition. Automated checkers detect only some problems, and human testing with assistive technologies remains necessary. The social reasons are equally direct. Accessible design allows people with disabilities to take part in education, employment and public services, and it narrows the gap described under the digital divide."
},
{
"heading": "Security and privacy",
"text": "Injection and cross-site scripting\n\nMost HTML security problems start when a page places untrusted text into markup without encoding it. If a site echoes a search term or a comment straight into the document, an attacker can supply a fragment containing a script tag or an event-handler attribute, and the browser will run it with the page's privileges. This is cross-site scripting (XSS), which security researchers have treated as one of the most persistent threats on the web for more than a decade. Reflected, stored and DOM-based variants differ in where the payload comes from and where it is written into the page, but all of them depend on the same mistake: data is interpreted as markup. The usual defence is context-aware output encoding, so that characters such as angle brackets and quotation marks are escaped differently in element text, attribute values and script blocks. Developers also avoid assigning untrusted strings to properties that parse HTML, and prefer APIs that insert text as text.\n\nSanitizing user-supplied HTML\n\nSome applications, such as comment systems, wikis and rich-text editors, must accept formatting from users. In these cases the input is parsed and passed through a sanitizer, which keeps an allowlist of safe elements and attributes and strips everything else, including script elements, event-handler attributes and dangerous URL schemes in links. Sanitization is error-prone because the parser's behaviour on malformed input is complex, so a sanitizer should be built on the browser's own parsing rules rather than on regular expressions, and it should be updated when new attributes or features appear. Server-side filtering alone is fragile for the same reason, which is why it is usually combined with the policy mechanisms described below.\n\nContent Security Policy\n\nContent Security Policy (CSP) is a browser mechanism, defined by the W3C, that limits which resources a page may load and run. It is delivered as an HTTP response header, and a policy consists of directives separated by semicolons. The most important directive is script-src, which governs external scripts, inline script blocks, inline event-handler attributes, javascript: URLs and dynamic evaluation. A policy such as a script source limited to the page's own origin, combined with object-src set to none and base-uri set to none, blocks many injection routes even when the page's own escaping has failed. Allowlists of hosts are less robust, since a whitelisted domain that hosts user content or a permissive JSONP endpoint can be abused. Stricter designs instead rely on a per-response nonce or on hashes of approved scripts, so that only scripts the server marked as its own may execute. Inline scripts and styles written without such marking are then blocked, which forces developers to refactor older code. CSP also has a meta-element form, but that form cannot express every directive, so the header is preferred for security-critical settings.\n\nSandboxing frames and controlling cross-origin data\n\nThe sandbox attribute on an iframe places the embedded document under restrictions. An empty value applies all of them, including a unique opaque origin, the blocking of scripts, form submission and popups, while space-separated tokens such as allow-scripts or allow-same-origin lift specific limits. Combining allow-scripts and allow-same-origin for content served from the same origin as the parent is effectively no sandbox at all, because the embedded script can remove the attribute itself, and the W3C has warned that such combinations need careful reasoning. Sandboxing also fails if the same untrusted document is opened directly in a new tab, so hostile user uploads should be served from a separate origin. The Referrer-Policy header and the referrerpolicy attribute control how much of the originating URL is sent to other sites; modern browsers default to a strict-origin-when-cross-origin policy. The rel=\"noreferrer\" keyword removes the Referer header for a link and also implies noopener, while target=\"_blank\" links now get an implicit noopener in current browsers, which closes the older reverse-tabnabbing risk. The Cross-Origin-Opener-Policy header offers a document-wide way to separate browsing context groups.\n\nPrivacy considerations\n\nSecurity and privacy overlap but are not the same. Form autofill is convenient, yet the autocomplete attribute decides which fields browsers may fill and which should be left alone, and fields for sensitive data such as one-time codes or passwords are often better marked explicitly. Third-party content, including advertising scripts, analytics snippets and embedded widgets, can read the page context and set or read storage, and every image or stylesheet fetched from a third-party server reveals the visitor's address and, through the Referer header, possibly the full URL being viewed. Developers reduce this exposure by limiting referrer data, restricting which third-party origins are allowed through CSP, lazy-loading embeds only when users request them, and avoiding unnecessary cross-site requests. Because tracking can be carried out through ordinary page resources, these choices intersect with wider data protection obligations."
},
{
"heading": "Conformance, testing and interoperability",
"text": "Conformance to HTML is checked in two ways: by tools that test individual documents, and by shared test suites that test browser engines. The best-known document tool is the W3C Markup Validation Service. In November 2008, the W3C released the validator.nu HTML5 engine and the ability to check documents for conformance to HTML5. The modern checker is an open-source HTML validator that checks documents against the living HTML standard maintained by WHATWG. It goes beyond syntax: it also flags incorrect nesting, deprecated element usage, and accessibility-related HTML errors. A validator can show that a page follows the grammar, but it cannot predict how every engine will render that page.\n\nThe second approach is the web-platform-tests (WPT) project, which was founded in 2010 to test browser conformance to web standards. Its tests are written so that they can be run in all browsers, which gives browser projects confidence that they are shipping software compatible with other implementations. The suite is large and continuously exercised: its over 56,552 tests (with 1.8 million subtests) were reported at the time of the source, and its infrastructure runs tests across the latest versions of all major browser engines on a daily basis. For the HTML standard specifically, the W3C noted that the HTML5 Recommendation's comprehensive test suite is maintained and kept up to date as part of the Web Platform Tests project.\n\nEach W3C HTML release has also been accompanied by an implementation report. The HTML 5.2 report, for instance, outlines known implementations for the features added between HTML 5.1 and HTML 5.2, with a per-feature table of support across Blink, Gecko, Edge, Internet Explorer and WebKit. Its stated purpose was to demonstrate sufficient interoperability to justify moving HTML 5.2 from Candidate Recommendation, and it was not expected to be updated after October 2017. These tables also reveal the gap between ideal and actual behaviour. In the HTML 5.1 report, for example, support for appeared in Chrome and Yandex and in Edge, but was marked absent for Firefox and Safari. Many cells were also left as unknown, so the tables measure what has been tested rather than what the standard requires.\n\nTest suites can also be misread. In 2010, the W3C's internal HTML5 test results were copied to a public web site and were taken by the press as proof that one vendor led on HTML5 compliance. An Opera engineer responded that \"This test suite is vastly incomplete.\" The episode showed that a suite's scores reflect its coverage, not complete compliance. Browsers also differ when they handle invalid markup, because when browsers encounter invalid HTML, they apply error recovery algorithms that may interpret your markup differently across engines.\n\nCoordination among vendors happens through several channels. WPT builds consensus between browser engineering teams on changes to the test suite and governance model through a Request for Comment (RFC) process, and disagreements that cannot be solved through this process are escalated to the Core Team. The Interop Project defines a metric based on a set of web technologies and uses automated tests to score how much progress each participating browser has made reaching the shared goals. The W3C's Browser Testing and Tools Working Group adopts a parallel rule: all changes made to specifications in Candidate Recommendation or to features that have deployed implementations will have tests. Together, these mechanisms are how the standard's ideal behaviour is gradually turned into interoperable browser behaviour."
},
{
"heading": "Related formats, ecosystem and practical uses",
"text": "HTML sits in a family of markup languages, and its syntax has changed as its relatives have. HTML descends from SGML, the document standard that the earliest versions followed. The HTML5 standard no longer counts as an SGML application and defines its own syntax. HTML5 can be written in two serializations: an HTML form served as text/html, and an XML form served as application/xhtml+xml. The XML form is what is usually called XHTML5. Both serializations can represent the same document in most cases, but each has limits. The HTML form cannot nest some structured inline elements inside certain parents, and the XML form cannot represent every tree that HTML's error recovery can produce. Browsers choose the parsing mode from the MIME type, not from the DOCTYPE, so an XHTML 1.0 DOCTYPE alone does not make a document XHTML.\n\nPublishing is one of the largest practical users of HTML's vocabulary. EPUB 3, the widely used e-book format, is based on HTML5, CSS and JavaScript, and its content documents may use HTML5 elements. The EPUB 3 specification, however, accepts only the XML serialization, so e-book content is XHTML in practice. This shows how the choice between HTML and XHTML affects real tools and readers.\n\nMost HTML on the web is not written by hand. Templating systems insert data into HTML skeletons, and web frameworks and content management systems produce pages on the server or in the browser. Markdown and similar lightweight languages let authors write text with simple punctuation, which a converter then turns into HTML. Static site generators apply this process to whole sites in advance, so the server delivers finished files. HTML also appears in email, where mail clients support only a subset of the language, and in document generation pipelines that produce reports or invoices from HTML templates.\n\nHTML has also moved onto desktop and mobile devices. Electron is a framework for building desktop applications with JavaScript, HTML and CSS. It embeds the Chromium rendering engine and the Node.js runtime, so one codebase can target Windows, macOS and Linux. Several widely used desktop programs, such as Visual Studio Code and Slack, are built this way. Electron applications split work between a main process, which runs JavaScript with access to system resources, and renderer processes, which display HTML pages. Mobile apps use a similar approach through embedded web views, which render HTML inside a native app shell on smartphones. Such apps can share most of their interface code with websites, though the native shell still determines how the app installs, updates and accesses device features.\n\nThese uses show that HTML is no longer confined to web pages. Its document model, its styling through CSS and its scripting through JavaScript now form a general-purpose base for software that reaches users through browsers, readers, mail clients and desktop windows."
},
{
"heading": "Debates and open questions",
"text": "The most persistent debate concerns the living-standard model itself. Since 2011 the WHATWG has maintained HTML without version numbers, adding features continuously, while the W3C has published versioned snapshots. Defenders argue that this matches how browsers actually ship features and avoids the long gaps that produced HTML5 as a finished target. Critics argue that a moving text makes it hard for schools, testing bodies, procurement officers and tool vendors to name the version of the language a document is meant to follow. The division also reflects a disagreement about purpose. The two organizations once worked from a single source document, but the W3C wanted a \"finished\" HTML5, while the WHATWG prioritized ongoing fixes and features. The W3C now publishes recommendations drawn from the WHATWG text on a roughly yearly schedule, which reconciles the two models only partly: a conformance claim still has to specify which snapshot and which date it refers to.\n\nGovernance is a second area of dispute. The WHATWG's Steering Group is made up of Apple, Google, Microsoft and Mozilla, the organizations behind the dominant browser engines, and the editors of each specification decide what enters the text, with disputes going to that group. Critics see a structural concentration: the companies that implement HTML also control its evolution, which can favor features that are cheap for large engine teams and slow the adoption of proposals from outside. Supporters respond that the process is public, runs largely on GitHub and gained a formal intellectual-property policy in 2017 precisely so that more organizations, including Microsoft, could contribute on equal terms. Whether that openness is sufficient for independent researchers, accessibility advocates and small projects remains contested, and the question is harder to answer because most of the participants are employed by the vendors themselves.\n\nThe third debate concerns scope: should HTML remain a document language or keep absorbing application-level behavior? Over the past decade the specification has taken on features that were once the province of scripts or plugins, including canvas, media playback, drag and drop, storage, custom elements, the popover mechanism and declarative shadow roots. Advocates see this as the logical outcome of the browser being the application platform, and they point out that a declarative, standardized core can reduce dependence on heavy JavaScript frameworks and improve performance and accessibility. Critics fear that the language is becoming a large runtime with overlapping mechanisms, that its original role in describing documents is being diluted, and that every addition enlarges the surface that implementers and authors must master. The tension is visible in practice: a declarative feature can remove a script-driven widget, but only if browsers agree on its details.\n\nFinally, the complexity of the standard creates its own problems. The specification covers parsing, the DOM, rendering hooks, security policy, accessibility semantics and many APIs, and its size makes accurate implementation costly. This raises the barrier to building a new independent browser engine, so that a small number of engine families effectively define how the standard behaves. Interoperability efforts show both the value and the limits of coordination. In the Interop project, the overall pass rate on the selected web-platform tests rose from about 29% at the start of 2025 to 97% by year's end, yet organizers have also noted that a good test score can coexist with behavior that differs across browsers. Accessibility gaps persist alongside this progress, since many interactive components built by authors are still inaccessible even though native elements provide most of the needed behavior. How to weigh stability against continuous change, openness against the influence of engine vendors, and breadth against simplicity is therefore unresolved, and the answers will shape how the web develops."
}
],
"links": [
"world-wide-web",
"programming-language",
"javascript",
"cern",
"internet",
"computer-science",
"syntax",
"semantics",
"hypertext-transfer-protocol",
"cybersecurity",
"data-privacy",
"mobile-phone",
"unicode",
"digital-divide",
"microsoft-windows",
"linux",
"smartphone"
],
"sources": [
{
"title": "HTML Standard",
"url": "https://html.spec.whatwg.org/"
},
{
"title": "HTML",
"url": "https://en.wikipedia.org/wiki/HTML"
},
{
"title": "Hypertext Markup Language - 2.0",
"url": "https://www.w3.org/MarkUp/html-spec/html-spec.html"
},
{
"title": "MIME TEXT/HTML",
"url": "https://www.mimes.info/text/html/"
},
{
"title": "What is the MIME Type?",
"url": "https://reqbin.com/req/fvhorfob/mime-type-example"
},
{
"title": "MIME Types - HTML5: Up and Running [Book]",
"url": "https://www.oreilly.com/library/view/html5-up-and/9781449392154/ch01s02.html"
},
{
"title": "13 The HTML syntax",
"url": "https://html.spec.whatwg.org/multipage/syntax.html"
},
{
"title": "Void element - Glossary - MDN Web Docs - Mozilla",
"url": "https://developer.mozilla.org/en-US/docs/Glossary/Void_element"
},
{
"title": "Void element",
"url": "https://developer.mozilla.org/docs/Glossary/Empty_element"
},
{
"title": "HTML Standard",
"url": "https://html.spec.whatwg.org/multipage/dom.html"
},
{
"title": "HTML content categories - Max Design",
"url": "https://www.maxdesign.com.au/articles/html-content-categories.html"
},
{
"title": "HTML Content Model Categories - Max Design",
"url": "https://russmaxdesign.github.io/html5-content-types/"
},
{
"title": "HTML Standard",
"url": "https://html.spec.whatwg.org/multipage/sections.html"
},
{
"title": "3-8: Introducing HTML5 footer, header, nav, article, section and aside elements",
"url": "http://www.cellbiol.com/bioinformatics_web_development/chapter-3-your-first-web-page-learning-html-and-css/introducing-html5-footer-header-nav-article-section-and-aside-elements/"
},
{
"title": "