WHATWG Wiki - User contributions [en]

Specs/todo

2024-01-25T13:10:31Z

Annevk: APNG is done! And ICO is not.

There are many specifications that need editors. This page lists some of the more important ones. If you want to volunteer to edit one of these specs, contact ian@hixie.ch, post on the WHATWG mailing list or say something on [[IRC]].

== Platform ==

* [https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html HTML Editing APIs]
* multipart/form-data
* SVG
* ICO (if it contains multiple images, which one is used?)
* Animated [[GIF]]s need a spec that, in particular, specifies how to handle timings (not all browsers honor all values, so we should specify what needs to be honored exactly)
* [[Wikipedia:Robots.txt|robots.txt]]
* A specification that defines how XML maps to DOM Core. (This could be in DOM Parsing and Serialization or HTML if XML does not get updated.)
* HTTP (error handling in particular, might become less of an issue if we're successful in removing it in favor of HTTPS)
** Client-side HTTP implementation requirements specification ("option 3" in http://www.w3.org/mid/20101101063413.bf1d8102.eric@bisonsystems.net)

== APIs ==

* User Interaction Events (onclick, onkeypress, etc).
** e.g. need to define somewhere that if you cancel mousedown, an element can't get focus
** setCapture / releaseCapture [http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0308.html]
** [http://krijnhoetmer.nl/irc-logs/whatwg/20121128#l-1719 selectstart] (WebKit/IE)
** https://w3c.github.io/uievents/
* Undomanager: http://rniwa.com/editing/undomanager.html and http://rniwa.com/editing/undomanager-usecases.html
* [[DOM XPath]]
* [[DOM XSLTProcessor]]

== CSS ==

There are [http://www.w3.org/Style/CSS/current-work many specifications for extending CSS] that are in need of editors. The most important ones are:
* Hit Testing (see http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html)
* Form control styling (see [https://github.com/domenic/html-as-custom-elements HTML as Custom Elements])
* Replaced Content
** http://dev.w3.org/csswg/css3-content/ (Do we still want this or is the component model sufficient?)
* an imperative model of box-tree construction

== Registries ==

Currently, the state of registries on the Web (and indeed for the Internet in general) is a disaster. At a minimum, the following registries need dramatically updating:

* MIME types
* URL schemes

It's possible that the right solution is to change approach altogether (e.g. moving more to a wiki model of registries).

See also: [[Registries]]

== Other stuff ==

http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html has a description of some sections that needed editing in 2008 and how much work they would be.

== Stuff we managed to specify eventually ==

* innerText and outerText
** http://perfectionkills.com/the-poor-misunderstood-innerText/
** https://github.com/whatwg/compat/issues/5
** https://html.spec.whatwg.org/multipage/dom.html#the-innertext-idl-attribute
* data: URLs
** https://fetch.spec.whatwg.org/#data-urls
* Table Layout
** http://dbaron.org/css/intrinsic/
** http://dev.w3.org/csswg/css3-tables-algorithms/Overview.src.htm
** https://drafts.csswg.org/css-tables-3/
* The console.* API
** https://github.com/DeveloperToolsWG/console-object
** http://www.w3.org/Bugs/Public/show_bug.cgi?id=10694
** http://www.w3.org/mid/d7be01cb7077$4dd45010$e97cf030$@gmail.com
** http://sideshowbarker.github.com/console-spec/
** https://console.spec.whatwg.org/
* APNG
** https://w3c.github.io/PNG-spec/

[[Category:Spec coordination|*]]
[[Category:Specification editing]]

User talk:EdwardOConnor

2021-04-26T14:57:58Z

Annevk: Annevk moved page User talk:EdwardOConnor to User talk:TheresaOConnor: Automatically moved page while renaming the user "EdwardOConnor" to "TheresaOConnor"

#REDIRECT [[User talk:TheresaOConnor]]

User talk:TheresaOConnor

2021-04-26T14:57:58Z

Annevk: Annevk moved page User talk:EdwardOConnor to User talk:TheresaOConnor: Automatically moved page while renaming the user "EdwardOConnor" to "TheresaOConnor"

<pre role=image aria-describedby=foo> )\._.,--....,'``. fL
/, _.. \ _\ ;`._ ,.
`._.-(,_..'--(,_..'`-.;.'</pre>
<p id=foo hidden>An ASCII art rendition of a cat in prone position.</p>

User:EdwardOConnor

2021-04-26T14:57:58Z

Annevk: Annevk moved page User:EdwardOConnor to User:TheresaOConnor: Automatically moved page while renaming the user "EdwardOConnor" to "TheresaOConnor"

#REDIRECT [[User:TheresaOConnor]]

User:TheresaOConnor

2021-04-26T14:57:58Z

Annevk: Annevk moved page User:EdwardOConnor to User:TheresaOConnor: Automatically moved page while renaming the user "EdwardOConnor" to "TheresaOConnor"

In addition to keeping an eye on wiki spam, I occasionally [[Special:Contributions/EdwardOConnor|contribute to this wiki]].

You might also be interested in [http://www.w3.org/html/wg/wiki/Special:Contributions/Eoconnor my contributions to the HTML WG wiki].

----
{{cc-public-domain-release}}

User:Annevk

2019-05-24T12:16:44Z

Annevk:

See [https://annevankesteren.nl/about About Anne van Kesteren] for some personal details as well as contact details. See below for my WHATWG activities.

== Writing ==

* DOM - https://dom.spec.whatwg.org/
* [[Encoding]] - https://encoding.spec.whatwg.org/
* [[Fetch]] (formerly CORS) - https://fetch.spec.whatwg.org/
* HTML - https://html.spec.whatwg.org/multipage/ (primarily reviews)
* Infra - https://infra.spec.whatwg.org/
* MIME Sniffing - https://mimesniff.spec.whatwg.org/ (rewrote the MIME types part thus, need better testing plan for sniffing)
* Notifications API - https://notifications.spec.whatwg.org/
* Storage - https://storage.spec.whatwg.org/
* [[URL]] - https://url.spec.whatwg.org/
* [[XMLHttpRequest]] - https://xhr.spec.whatwg.org/

Hobby:

* [[HTTP]]
* [[TLS]]
* [[Sharing]]

Passed on:

* Fullscreen API - https://fullscreen.spec.whatwg.org/ - thanks Philip!
* CSSOM - http://dev.w3.org/csswg/cssom/
* CSSOM View - http://dev.w3.org/csswg/cssom-view/
* Media Queries - http://dev.w3.org/csswg/css3-mediaqueries/ (published as REC)
* CSS Namespaces - http://dev.w3.org/csswg/css3-namespace/ (published as REC)

Abandoned:

* Differences from HTML4 - https://html-differences.whatwg.org/
* From-Origin - http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html
* HTML Design Principles - http://dev.w3.org/html5/html-design-principles/
* Offline Web Applications - http://dev.w3.org/html5/offline-webapps/
* Selectors API - http://dev.w3.org/2006/webapi/selectors-api/ (published as REC, now folded into DOM)

== W3C ==

Past: CDF, CSS, HTML, Notifications, TAG, WebApps, WebAppsSec, XML ER

== Public domain ==
{{CC0 user}}

Style

2018-05-08T09:27:27Z

Annevk: Moved to whatwg.org proper

MediaWiki:Sidebar

2018-03-28T12:23:29Z

Annevk:

IRC

2018-03-28T12:22:48Z

Annevk: Replaced content with "{{moved|[https://whatwg.org/irc WHATWG IRC].}}"

Style

2018-03-16T17:25:47Z

Annevk: /* Dictionary */

== Language ==

American English.

== Dictionary ==

* behavior
* bitrate
* built-in (though see https://github.com/heycam/webidl/issues/350)
* cancelation
* canceled
* canceling
* cipher
* colorspace
* email
* implementer
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* nonzero
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.
* A hierarchy (not an).

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Words and phrases used as words ==
* When a word or term is not used functionally but is referred to as the word or term itself, enclose it in quotation marks. (See also: [http://www.chicagomanualofstyle.org/qanda/data/faq/topics/NoneoftheAbove/faq0012.html some examples that highlight why this is necessary].)

== Tone ==

* Avoid using "simply" or suggesting that something is simple
* Don't use "white" as meaning good and "black" as meaning bad; more concretely, "safelist" and "blocklist" are established precedent

Fork tracking

2018-01-29T12:33:42Z

Annevk: Microdata is somehow maintained again...

This page exists to document the status of the outdated forks of various WHATWG specifications, and any progress toward clarifying their out-of-dateness.

== Confusion persists ==

* Fetch: https://fetch.spec.whatwg.org/
** Obsolete subsections published as http://www.w3.org/TR/cors/
** Status: still exists as an outdated specification with no warning, causing confusion.
* DOM: https://dom.spec.whatwg.org/
** Forked to http://www.w3.org/TR/dom/
** Forked to https://w3c.github.io/dom/
** Status: still exists as an outdated snapshot (and modified in undocumented ways) with no warning, causing confusion. And has a weird rename ("DOM4") too. Editors draft has renewed forking efforts with particularly bad copy-and-paste practices.
* XMLHttpRequest: https://xhr.spec.whatwg.org/
** A subset was forked to https://www.w3.org/TR/progress-events/. (ED redirects)
* Notifications: https://notifications.spec.whatwg.org/
** Forked to http://www.w3.org/TR/notifications/
** Status: still exists as an outdated snapshot with no warning, causing confusion. The spec model has diverged significantly in the meantime, and the outdated version is actively wrong, not just incomplete.
* HTML: https://html.spec.whatwg.org/multipage/
** Forked to http://www.w3.org/TR/html5/ as an outdated fork of a subset frozen in 2013.
** Forked to http://www.w3.org/TR/html51/ as an outdated fork of a subset frozen in 2015.
** Forked to https://w3c.github.io/html/ as an outdated fork of a subset frozen in early 2016 (see [https://annevankesteren.nl/2016/01/film-at-11 blog post]).
** In general all of these attempt to copy-and-paste HTML and then apply forked patches on top, but the scripts are wonky, leading to lots of errors.
** Subsets of HTML split out into other outdated forks, none with appropriate warnings:
*** http://www.w3.org/TR/webstorage/ (ED is nice at least https://w3c.github.io/webstorage/)
*** http://www.w3.org/TR/workers/
*** http://www.w3.org/TR/webmessaging/ (ED is nice at least https://w3c.github.io/webmessaging/)
*** http://www.w3.org/TR/websockets/ (ED is nice at least https://w3c.github.io/websockets/)
*** http://www.w3.org/TR/eventsource/ (ED is nice at least https://w3c.github.io/eventsource/)
*** http://www.w3.org/TR/2dcontext/
*** https://www.w3.org/TR/2dcontext2/
*** https://www.w3.org/TR/microdata/
*** https://dvcs.w3.org/hg/webperf/raw-file/default/specs/RequestAnimationFrame/Overview.html (redirects to W3C HTML fork)

== Confusion persists with some mitigation ==

* Encoding: https://encoding.spec.whatwg.org/
** Forked to http://www.w3.org/TR/encoding/
** Status: still exists as an outdated snapshot, with a floating notice that it's an outdated snapshot at the bottom, but pretending that it provides a "stable reference"

== Confusion mitigated ==

* Fullscreen: https://fullscreen.spec.whatwg.org/
** Forked to http://www.w3.org/TR/fullscreen/
** Status: discontinued as a NOTE. ED URL (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) redirects
* Streams: https://streams.spec.whatwg.org/
** Forked to http://www.w3.org/TR/streams-api/
** Status: discontinued as NOTE. ED URL is WHATWG URL, former ED URL (http://w3c.github.io/streams-api/) redirects
* XMLHttpRequest: https://xhr.spec.whatwg.org/
** Forked to http://www.w3.org/TR/XMLHttpRequest/
** Forked to http://www.w3.org/TR/XMLHttpRequest2/
** Status: both /TR/ forks discontinued as NOTEs. ED URLs are to WHATWG XHR, former ED URL https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html redirects.
* URL: https://url.spec.whatwg.org/
** Forked to http://www.w3.org/TR/url/ plus various aliases and older versions (e.g. https://www.w3.org/TR/url-1/)
** Status: discontinued as NOTE, ED URL is WHATWG URL, former ED URL http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html redirects.
** https://w3ctag.github.io/url/ has also been fully discontinued.

GitHub

2018-01-24T17:44:59Z

Annevk: Replaced content with "{{moved|[https://github.com/whatwg WHATWG on GitHub].}}"

CanvasContexts

2018-01-24T17:43:35Z

Annevk:

{{obsolete|spec=[https://html.spec.whatwg.org/multipage/canvas.html#dom-canvas-getcontext <code>getContext()</code> in the HTML Standard]}}

This page lists the defined contexts usable with the '''HTMLCanvasElement.getContext()''' API in the [http://dev.w3.org/html5/spec/the-canvas-element.html#dom-canvas-getcontext W3C HTML5 spec].

This is no longer used by the [http://www.whatwg.org/specs/web-apps/current-work/complete/the-canvas-element.html#dom-canvas-getcontext WHATWG HTML spec].

<dl>
<dt> <code>2d</code>
<dd>
<dl>
<dt>Specification: <dd> http://dev.w3.org/html5/2dcontext/ (W3C spec) <dd> http://www.whatwg.org/specs/web-apps/current-work/complete/the-canvas-element.html#canvas-context-2d (WHATWG spec)
<dt>Compatible with: <dd> none
</dl>
<dt> <code>webgl</code>
<dd>
<dl>
<dt>Specification: <dd> http://www.khronos.org/registry/webgl/specs/latest/
<dt>Compatible with: <dd> none
</dl>
</dl>

[[Category:Registries]]

MediaWiki:Sidebar

2018-01-24T17:41:36Z

Annevk:

WorkerCanvas

2018-01-24T17:37:18Z

Annevk:

{{obsolete|spec=[https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface <code>OffscreenCanvas</code> in the HTML Standard]}}

:''Provides more control over how canvases are rendered.''

== Use Case Description ==

Feedback from web application authors using canvases have shown the need for the following controls:

* (From ShaderToy, Sketchfab, Verold): need to be able to render to multiple regions on the page efficiently using a single canvas context. 3D model warehouse sites desire to show multiple live interactive models on the page, but creating multiple WebGL contexts per page is too inefficient. A single context should be able to render to multiple regions on the page.
* (From Google Maps): need to be able to render WebGL from a worker, transfer the rendered image to the main thread without making any copy of it, and composite it with other HTML on the page, guaranteeing that the updates are all seen in the same rendered frame.
* (From Mozilla and partners using Emscripten and asm.js): need to be able to render WebGL entirely asynchronously from a worker, displaying the results in a canvas owned by the main thread, without any synchronization with the main thread. In this mode, the entire application runs in the worker. The main thread only receives input events and sends them to the worker for processing.

== WebIDL ==

[Constructor(unsigned long width, unsigned long height)]
interface WorkerCanvas {
attribute unsigned long width;
attribute unsigned long height;
RenderingContext? getContext(DOMString contextId, any... arguments);
void toBlob(FileCallback? _callback, optional DOMString type, any... arguments);
ImageBitmap transferToImageBitmap();
};

WorkerCanvas implements Transferable;
ImageBitmap implements Transferable;

partial interface HTMLCanvasElement {
WorkerCanvas transferControlToWorker();
};

partial interface ImageBitmap {
void transferToImage(HTMLImageElement image);
};

== Spec changes ==

Transferring of ImageBitmaps has to be defined. It should neuter the ImageBitmap in the sending thread. Neutering sets the ImageBitmap's width and height to 0.

HTMLCanvasElement.transferControlToWorker behaves like transferControlToProxy in the current WHATWG spec. WorkerCanvas is Transferable, but transfer fails if transferred other than from the main thread to a worker. All its methods throw if not called on a worker, or if it's neutered.

ImageBitmap.transferToImage removes the image element's "src" attribute and makes the image display the contents of the ImageBitmap (until the next transferToImage to that image, or until the image's "src" attribute is set). The ImageBitmap is neutered.

[[Category:Proposals]]

OffscreenCanvas

2018-01-24T17:36:27Z

Annevk:

{{obsolete|spec=[https://html.spec.whatwg.org/multipage/canvas.html#the-offscreencanvas-interface <code>OffscreenCanvas</code> in the HTML Standard]}}

:''Provides more control over how canvases are rendered. This is a follow-on to the [[WorkerCanvas]] proposal and will be merged once agreement is reached.''

== Use Case Description ==

Feedback from web application authors using canvases have shown the need for the following controls:

* (From ShaderToy, Sketchfab, Verold): need to be able to render to multiple regions on the page efficiently using a single canvas context. 3D model warehouse sites desire to show multiple live interactive models on the page, but creating multiple WebGL contexts per page is too inefficient. A single context should be able to render to multiple regions on the page.
* (From Google Maps): need to be able to render WebGL from a worker, transfer the rendered image to the main thread without making any copy of it, and composite it with other HTML on the page, guaranteeing that the updates are all seen in the same rendered frame.
* (From Mozilla and partners using Emscripten and asm.js): need to be able to render WebGL entirely asynchronously from a worker, displaying the results in a canvas owned by the main thread, without any synchronization with the main thread. In this mode, the entire application runs in the worker. The main thread only receives input events and sends them to the worker for processing.
* (From adopters of the Push API): need to be able to dynamically create images to use as notification icons, such as compositing avatars, or adding an unread count
* (From the Google Docs team): need to be able to layout and render text from a worker using CanvasRenderingContext2D and display those results on the main thread.
* (From the Google Slides team): want to layout and render the slide thumbnails from a worker. During initial load and heavy collaboration these update frequently, and currently cause slowdowns on the main thread.

=== Current Limitations ===

* [https://html.spec.whatwg.org/multipage/scripting.html#proxying-canvases-to-workers CanvasProxy] does not provide sufficient control to allow synchronization between workers' rendering and DOM updates on the main thread. Keeping this rendering in sync is a requirement from Google's Maps team.
* [[CanvasInWorkers]] does not allow a worker to render directly into a canvas on the main thread without running code on the main thread. Allowing completely unsynchronized rendering is a requirement from Mozilla and users of Emscripten such as Epic Games and Unity, in which the desire is to execute all of the game's rendering on a worker thread.
* [[WorkerCanvas]] mostly addresses these two use cases, but some implementers objected to the mechanism for displaying the rendering results in image elements. The specific objection was that image elements already have complex internal state (for example, the management of the image's "loaded" state), and this would make it more complex. It also did not precisely address the use case of producing new frames both on the main thread and in workers.

=== Current Usage and Workarounds ===

[https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers-today-and-faster-than-expected/ WebGL in Web Workers] details some work attempted in the Emscripten toolchain to address the lack of WebGL in workers. Due to the high volume of calls and large amount of data that is transferred to the graphics card in a typical high-end WebGL application, this approach is not sustainable. It's necessary for workers to be able to call the WebGL API directly, and present those results to the screen in a manner that does not introduce any copies of the rendering results.

=== Benefits ===

Making canvas rendering contexts available to workers will increase parallelism in web applications, leading to increased performance on multi-core systems.

=== Requests for this Feature ===

See the abovementioned use cases:

* Google's Maps team
* Emscripten users such as Epic Games and Unity
* Many others

== Web IDL ==

typedef (OffscreenCanvasRenderingContext2D or
WebGLRenderingContext or
WebGL2RenderingContext) OffscreenRenderingContext;

[Constructor(unsigned long width, unsigned long height),
Exposed=(Window,Worker)]
interface OffscreenCanvas {
attribute unsigned long width;
attribute unsigned long height;
OffscreenRenderingContext? getContext(DOMString contextId, any... arguments);

// OffscreenCanvas, like HTMLCanvasElement, maintains an origin-clean flag.
// ImageBitmaps created by calling this method also have an
// origin-clean flag which is set to the value of the OffscreenCanvas's
// flag at the time of their construction. Uses of the ImageBitmap
// in other APIs, such as CanvasRenderingContext2D or
// WebGLRenderingContext, propagate this flag like other
// CanvasImageSource types do, such as HTMLImageElement.
ImageBitmap transferToImageBitmap();

// Throws a SecurityError if the OffscreenCanvas's origin-clean flag
// is set to false.
Promise<Blob> convertToBlob(optional ImageEncodeOptions options);
};

dictionary ImageEncodeOptions {
DOMString type = "image/png";
unrestricted double quality = 1.0; // Defaults to 1.0 if value is outside 0:1 range
};

OffscreenCanvas implements Transferable;

partial interface HTMLCanvasElement {
OffscreenCanvas transferControlToOffscreen();
};

typedef (HTMLOrSVGImageElement or
HTMLVideoElement or
HTMLCanvasElement or
ImageBitmap or
OffscreenCanvas) CanvasImageSource;

[Exposed=Window, Worker]
interface OffscreenCanvasRenderingContext2D {
// commit() can only be used when HTMLCanvasElement has transferred Control
// to OffscreenCanvas. Otherwise, an InvalidStateError will be thrown.
// commit() can be invoked on main thread or worker thread. When it is invoked,
// it is expected to see the image drawn to OffscreenCanvasRenderingContext2D
// be displayed in the associated HTMLCanvasElement.
void commit();
// back-reference to the canvas
readonly attribute OffscreenCanvas canvas;
};
OffscreenCanvasRenderingContext2D implements CanvasState;
OffscreenCanvasRenderingContext2D implements CanvasTransform;
OffscreenCanvasRenderingContext2D implements CanvasCompositing;
OffscreenCanvasRenderingContext2D implements CanvasImageSmoothing;
OffscreenCanvasRenderingContext2D implements CanvasFillStrokeStyles;
OffscreenCanvasRenderingContext2D implements CanvasShadowStyles;
// Reference filters (e.g. 'url()') are not expected to work in Workers
OffscreenCanvasRenderingContext2D implements CanvasFilters;
OffscreenCanvasRenderingContext2D implements CanvasRect;
OffscreenCanvasRenderingContext2D implements CanvasDrawPath;
// Text support in workers poses very difficult technical challenges.
// Open issue: should we forgo text support in OffscreenCanvas v1?
OffscreenCanvasRenderingContext2D implements CanvasText;
OffscreenCanvasRenderingContext2D implements CanvasDrawImage;
OffscreenCanvasRenderingContext2D implements CanvasImageData;
OffscreenCanvasRenderingContext2D implements CanvasPathDrawingStyles;
OffscreenCanvasRenderingContext2D implements CanvasTextDrawingStyles;
OffscreenCanvasRenderingContext2D implements CanvasPath;

[Exposed=Window, Worker]
Partial interface CanvasPattern {
}

[Exposed=Window, Worker]
partial interface CanvasGradient {
}

partial interface WebGLRenderingContextBase {
// back-reference to the canvas
readonly attribute (HTMLCanvasElement or OffscreenCanvas) canvas;

// If this context is associated with an OffscreenCanvas that was
// created by HTMLCanvasElement's transferControlToOffscreen method,
// causes this context's current rendering results to be pushed
// to that canvas element. This has the same effect as returning
// control to the main loop in a single-threaded application. Otherwise,
// an InvalidStateError will be thrown.
void commit();
};

== Proposed Solutions ==

=== This Solution ===

This proposed API can be used in several ways to satisfy the use cases described above:

* It supports zero-copy transfer of canvases' rendering results between threads, for example from a worker to the main thread. In this model, the main thread controls when to display new frames produced by the worker, so synchronization with other DOM updates is achieved.

* It supports fully asynchronous rendering by a worker into a canvas displayed on the main thread. This satisfies certain Emscripten developers' full-screen use cases.

* It supports using a single WebGLRenderingContext or Canvas2DRenderingContext to efficiently render into multiple regions on the web page.

* It introduces ImageBitmapRenderingContext, a new canvas context type whose sole purpose is to efficiently display ImageBitmaps. This supersedes the [[WorkerCanvas]] proposal's use of HTMLImageElement for this purpose.

* It supports asynchronous encoding of OffscreenCanvases' rendering results into Blobs which can be consumed by various other web platform APIs.

==== Processing Model ====

This proposal introduces two primary processing models. The first involves ''synchronous'' display of new frames produced by the OffscreenCanvas. The application generates new frames using the RenderingContext obtained from the OffscreenCanvas. When the application is finished rendering each new frame, it calls transferToImageBitmap to "tear off" the most recently rendered image from the OffscreenCanvas -- like a Post-It note. The resulting ImageBitmap can then be used in any API receiving that data type; notably, it can be displayed in a second canvas without introducing a copy. An ImageBitmapRenderingContext is obtained from the second canvas by calling <code>getContext('bitmaprenderer')</code>. Each frame is displayed in the second canvas using the <code>transferImageBitmap</code> method on this rendering context. Note that the threads producing and consuming the frames may be the same, or they may be different. Note also that a single OffscreenCanvas may transfer frames into an arbitrary number of other ImageBitmapRenderingContexts.

The second processing model involves ''asynchronous'' display of new frames produced by the OffscreenCanvas. The main thread instantiates an HTMLCanvasElement and calls <code>transferControlToOffscreeen</code>. <code>getContext</code> is used to obtain a rendering context for that OffscreenCanvas, either on the main thread, or on a worker. The application calls <code>commit</code> against that rendering context in order to push frames to the original HTMLCanvasElement. In this rendering model, it is not defined when those frames become visible in the original canvas element. However, if the following situations apply:

* It is a worker thread which is calling commit(), and
* The worker is calling commit() repeatedly against exactly one rendering context

then it is required that the user agent synchronize the calls to commit() to the vsync interval. Calls to commit() conceptually enqueue frames for display, and after an implementation-defined number of frames have been enqueued, further calls to commit() will block until earlier frames have been presented to the screen. (This requirement allows porting of applications which drive their own main loop rather than using an event-driven loop.)

==== Limitations ====

* A known good way to drive an animation loop from a worker is needed. requestAnimationFrame or a similar API needs to be defined on worker threads.
* Some parts of the CanvasRenderingContext2D interface shall not be supported due OffscreenCanvas objects having no relation to the DOM or Frame: HitRegions, scrollPathIntoView, drawFocusIfNeeded.
* Due to technical challenges, some implementors [https://bugzilla.mozilla.org/show_bug.cgi?id=801176#c29 (Google and Mozilla)] have expressed a desire to ship without initially supporting text rendering in 2D contexts. Open Issue: Should text support be formally excluded from the specification until implementors are prepared to ship it (or until a more feasible API is designed)?

==== Implementation ====

This proposal has been vetted by developers of Apple's Safari, Google's Chrome, Microsoft's Internet Explorer, and Mozilla's Firefox browsers. All vendors agreed upon the basic form of the API, so it is likely it will be implemented widely and compatibly.

==== Adoption ====

Web page authors have demanded increased parallelism support from the web platform for multiple years. If support for multithreaded rendering is added, it is likely it will be rapidly adopted.

==== Example code ====

Jeff Gilbert from Mozilla has crafted some example code utilizing this API:

* [https://github.com/jdashg/snippets/tree/master/webgl-from-worker Rendering WebGL from a worker using the commit() API]
* [https://github.com/jdashg/snippets/blob/master/webgl-one-to-many/index.html Using one WebGL context to render to many Canvas elements]

[[Category:Proposals]]

OffscreenCanvas

2018-01-24T17:35:57Z

Annevk:

{{obsolete|spec=[https://html.spec.whatwg.org/multipage/scripting.html#the-offscreencanvas-interface <code>OffscreenCanvas</code> in the HTML Standard]}}

:''Provides more control over how canvases are rendered. This is a follow-on to the [[WorkerCanvas]] proposal and will be merged once agreement is reached.''

== Use Case Description ==

Feedback from web application authors using canvases have shown the need for the following controls:

* (From ShaderToy, Sketchfab, Verold): need to be able to render to multiple regions on the page efficiently using a single canvas context. 3D model warehouse sites desire to show multiple live interactive models on the page, but creating multiple WebGL contexts per page is too inefficient. A single context should be able to render to multiple regions on the page.
* (From Google Maps): need to be able to render WebGL from a worker, transfer the rendered image to the main thread without making any copy of it, and composite it with other HTML on the page, guaranteeing that the updates are all seen in the same rendered frame.
* (From Mozilla and partners using Emscripten and asm.js): need to be able to render WebGL entirely asynchronously from a worker, displaying the results in a canvas owned by the main thread, without any synchronization with the main thread. In this mode, the entire application runs in the worker. The main thread only receives input events and sends them to the worker for processing.
* (From adopters of the Push API): need to be able to dynamically create images to use as notification icons, such as compositing avatars, or adding an unread count
* (From the Google Docs team): need to be able to layout and render text from a worker using CanvasRenderingContext2D and display those results on the main thread.
* (From the Google Slides team): want to layout and render the slide thumbnails from a worker. During initial load and heavy collaboration these update frequently, and currently cause slowdowns on the main thread.

=== Current Limitations ===

* [https://html.spec.whatwg.org/multipage/scripting.html#proxying-canvases-to-workers CanvasProxy] does not provide sufficient control to allow synchronization between workers' rendering and DOM updates on the main thread. Keeping this rendering in sync is a requirement from Google's Maps team.
* [[CanvasInWorkers]] does not allow a worker to render directly into a canvas on the main thread without running code on the main thread. Allowing completely unsynchronized rendering is a requirement from Mozilla and users of Emscripten such as Epic Games and Unity, in which the desire is to execute all of the game's rendering on a worker thread.
* [[WorkerCanvas]] mostly addresses these two use cases, but some implementers objected to the mechanism for displaying the rendering results in image elements. The specific objection was that image elements already have complex internal state (for example, the management of the image's "loaded" state), and this would make it more complex. It also did not precisely address the use case of producing new frames both on the main thread and in workers.

=== Current Usage and Workarounds ===

[https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers-today-and-faster-than-expected/ WebGL in Web Workers] details some work attempted in the Emscripten toolchain to address the lack of WebGL in workers. Due to the high volume of calls and large amount of data that is transferred to the graphics card in a typical high-end WebGL application, this approach is not sustainable. It's necessary for workers to be able to call the WebGL API directly, and present those results to the screen in a manner that does not introduce any copies of the rendering results.

=== Benefits ===

Making canvas rendering contexts available to workers will increase parallelism in web applications, leading to increased performance on multi-core systems.

=== Requests for this Feature ===

See the abovementioned use cases:

* Google's Maps team
* Emscripten users such as Epic Games and Unity
* Many others

== Web IDL ==

typedef (OffscreenCanvasRenderingContext2D or
WebGLRenderingContext or
WebGL2RenderingContext) OffscreenRenderingContext;

[Constructor(unsigned long width, unsigned long height),
Exposed=(Window,Worker)]
interface OffscreenCanvas {
attribute unsigned long width;
attribute unsigned long height;
OffscreenRenderingContext? getContext(DOMString contextId, any... arguments);

// OffscreenCanvas, like HTMLCanvasElement, maintains an origin-clean flag.
// ImageBitmaps created by calling this method also have an
// origin-clean flag which is set to the value of the OffscreenCanvas's
// flag at the time of their construction. Uses of the ImageBitmap
// in other APIs, such as CanvasRenderingContext2D or
// WebGLRenderingContext, propagate this flag like other
// CanvasImageSource types do, such as HTMLImageElement.
ImageBitmap transferToImageBitmap();

// Throws a SecurityError if the OffscreenCanvas's origin-clean flag
// is set to false.
Promise<Blob> convertToBlob(optional ImageEncodeOptions options);
};

dictionary ImageEncodeOptions {
DOMString type = "image/png";
unrestricted double quality = 1.0; // Defaults to 1.0 if value is outside 0:1 range
};

OffscreenCanvas implements Transferable;

partial interface HTMLCanvasElement {
OffscreenCanvas transferControlToOffscreen();
};

typedef (HTMLOrSVGImageElement or
HTMLVideoElement or
HTMLCanvasElement or
ImageBitmap or
OffscreenCanvas) CanvasImageSource;

[Exposed=Window, Worker]
interface OffscreenCanvasRenderingContext2D {
// commit() can only be used when HTMLCanvasElement has transferred Control
// to OffscreenCanvas. Otherwise, an InvalidStateError will be thrown.
// commit() can be invoked on main thread or worker thread. When it is invoked,
// it is expected to see the image drawn to OffscreenCanvasRenderingContext2D
// be displayed in the associated HTMLCanvasElement.
void commit();
// back-reference to the canvas
readonly attribute OffscreenCanvas canvas;
};
OffscreenCanvasRenderingContext2D implements CanvasState;
OffscreenCanvasRenderingContext2D implements CanvasTransform;
OffscreenCanvasRenderingContext2D implements CanvasCompositing;
OffscreenCanvasRenderingContext2D implements CanvasImageSmoothing;
OffscreenCanvasRenderingContext2D implements CanvasFillStrokeStyles;
OffscreenCanvasRenderingContext2D implements CanvasShadowStyles;
// Reference filters (e.g. 'url()') are not expected to work in Workers
OffscreenCanvasRenderingContext2D implements CanvasFilters;
OffscreenCanvasRenderingContext2D implements CanvasRect;
OffscreenCanvasRenderingContext2D implements CanvasDrawPath;
// Text support in workers poses very difficult technical challenges.
// Open issue: should we forgo text support in OffscreenCanvas v1?
OffscreenCanvasRenderingContext2D implements CanvasText;
OffscreenCanvasRenderingContext2D implements CanvasDrawImage;
OffscreenCanvasRenderingContext2D implements CanvasImageData;
OffscreenCanvasRenderingContext2D implements CanvasPathDrawingStyles;
OffscreenCanvasRenderingContext2D implements CanvasTextDrawingStyles;
OffscreenCanvasRenderingContext2D implements CanvasPath;

[Exposed=Window, Worker]
Partial interface CanvasPattern {
}

[Exposed=Window, Worker]
partial interface CanvasGradient {
}

partial interface WebGLRenderingContextBase {
// back-reference to the canvas
readonly attribute (HTMLCanvasElement or OffscreenCanvas) canvas;

// If this context is associated with an OffscreenCanvas that was
// created by HTMLCanvasElement's transferControlToOffscreen method,
// causes this context's current rendering results to be pushed
// to that canvas element. This has the same effect as returning
// control to the main loop in a single-threaded application. Otherwise,
// an InvalidStateError will be thrown.
void commit();
};

== Proposed Solutions ==

=== This Solution ===

This proposed API can be used in several ways to satisfy the use cases described above:

* It supports zero-copy transfer of canvases' rendering results between threads, for example from a worker to the main thread. In this model, the main thread controls when to display new frames produced by the worker, so synchronization with other DOM updates is achieved.

* It supports fully asynchronous rendering by a worker into a canvas displayed on the main thread. This satisfies certain Emscripten developers' full-screen use cases.

* It supports using a single WebGLRenderingContext or Canvas2DRenderingContext to efficiently render into multiple regions on the web page.

* It introduces ImageBitmapRenderingContext, a new canvas context type whose sole purpose is to efficiently display ImageBitmaps. This supersedes the [[WorkerCanvas]] proposal's use of HTMLImageElement for this purpose.

* It supports asynchronous encoding of OffscreenCanvases' rendering results into Blobs which can be consumed by various other web platform APIs.

==== Processing Model ====

This proposal introduces two primary processing models. The first involves ''synchronous'' display of new frames produced by the OffscreenCanvas. The application generates new frames using the RenderingContext obtained from the OffscreenCanvas. When the application is finished rendering each new frame, it calls transferToImageBitmap to "tear off" the most recently rendered image from the OffscreenCanvas -- like a Post-It note. The resulting ImageBitmap can then be used in any API receiving that data type; notably, it can be displayed in a second canvas without introducing a copy. An ImageBitmapRenderingContext is obtained from the second canvas by calling <code>getContext('bitmaprenderer')</code>. Each frame is displayed in the second canvas using the <code>transferImageBitmap</code> method on this rendering context. Note that the threads producing and consuming the frames may be the same, or they may be different. Note also that a single OffscreenCanvas may transfer frames into an arbitrary number of other ImageBitmapRenderingContexts.

The second processing model involves ''asynchronous'' display of new frames produced by the OffscreenCanvas. The main thread instantiates an HTMLCanvasElement and calls <code>transferControlToOffscreeen</code>. <code>getContext</code> is used to obtain a rendering context for that OffscreenCanvas, either on the main thread, or on a worker. The application calls <code>commit</code> against that rendering context in order to push frames to the original HTMLCanvasElement. In this rendering model, it is not defined when those frames become visible in the original canvas element. However, if the following situations apply:

* It is a worker thread which is calling commit(), and
* The worker is calling commit() repeatedly against exactly one rendering context

then it is required that the user agent synchronize the calls to commit() to the vsync interval. Calls to commit() conceptually enqueue frames for display, and after an implementation-defined number of frames have been enqueued, further calls to commit() will block until earlier frames have been presented to the screen. (This requirement allows porting of applications which drive their own main loop rather than using an event-driven loop.)

==== Limitations ====

* A known good way to drive an animation loop from a worker is needed. requestAnimationFrame or a similar API needs to be defined on worker threads.
* Some parts of the CanvasRenderingContext2D interface shall not be supported due OffscreenCanvas objects having no relation to the DOM or Frame: HitRegions, scrollPathIntoView, drawFocusIfNeeded.
* Due to technical challenges, some implementors [https://bugzilla.mozilla.org/show_bug.cgi?id=801176#c29 (Google and Mozilla)] have expressed a desire to ship without initially supporting text rendering in 2D contexts. Open Issue: Should text support be formally excluded from the specification until implementors are prepared to ship it (or until a more feasible API is designed)?

==== Implementation ====

This proposal has been vetted by developers of Apple's Safari, Google's Chrome, Microsoft's Internet Explorer, and Mozilla's Firefox browsers. All vendors agreed upon the basic form of the API, so it is likely it will be implemented widely and compatibly.

==== Adoption ====

Web page authors have demanded increased parallelism support from the web platform for multiple years. If support for multithreaded rendering is added, it is likely it will be rapidly adopted.

==== Example code ====

Jeff Gilbert from Mozilla has crafted some example code utilizing this API:

* [https://github.com/jdashg/snippets/tree/master/webgl-from-worker Rendering WebGL from a worker using the commit() API]
* [https://github.com/jdashg/snippets/blob/master/webgl-one-to-many/index.html Using one WebGL context to render to many Canvas elements]

[[Category:Proposals]]

FAQ

2018-01-24T17:34:29Z

Annevk: Replaced content with "{{moved|the [https://whatwg.org/faq WHATWG FAQ], the [https://github.com/whatwg/html/blob/master/FAQ.md HTML Standard FAQ], and the [https://whatwg.org/mailing-list WHATWG..."

{{moved|the [https://whatwg.org/faq WHATWG FAQ], the [https://github.com/whatwg/html/blob/master/FAQ.md HTML Standard FAQ], and the [https://whatwg.org/mailing-list WHATWG Mailing List] page.}}

Style

2018-01-24T09:09:34Z

Annevk: /* Dictionary */

== Language ==

American English.

== Dictionary ==

* behavior
* bitrate
* cancelation
* canceled
* canceling
* cipher
* colorspace
* email
* implementer
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* nonzero
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.
* A hierarchy (not an).

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Words and phrases used as words ==
* When a word or term is not used functionally but is referred to as the word or term itself, enclose it in quotation marks. (See also: [http://www.chicagomanualofstyle.org/qanda/data/faq/topics/NoneoftheAbove/faq0012.html some examples that highlight why this is necessary].)

== Tone ==

* Avoid using "simply" or suggesting that something is simple
* Don't use "white" as meaning good and "black" as meaning bad; more concretely, "safelist" and "blocklist" are established precedent

Style

2018-01-19T11:55:41Z

Annevk: /* Grammar */

== Language ==

American English.

== Dictionary ==

* bitrate
* cancelation
* canceled
* canceling
* cipher
* colorspace
* email
* implementer
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* nonzero
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.
* A hierarchy (not an).

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Words and phrases used as words ==
* When a word or term is not used functionally but is referred to as the word or term itself, enclose it in quotation marks. (See also: [http://www.chicagomanualofstyle.org/qanda/data/faq/topics/NoneoftheAbove/faq0012.html some examples that highlight why this is necessary].)

== Tone ==

* Avoid using "simply" or suggesting that something is simple
* Don't use "white" as meaning good and "black" as meaning bad; more concretely, "safelist" and "blocklist" are established precedent

Style

2017-12-20T10:23:58Z

Annevk: /* Dictionary */

== Language ==

American English.

== Dictionary ==

* bitrate
* cancelation
* canceled
* canceling
* cipher
* colorspace
* email
* implementer
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* nonzero
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Words and phrases used as words ==
* When a word or term is not used functionally but is referred to as the word or term itself, enclose it in quotation marks. (See also: [http://www.chicagomanualofstyle.org/qanda/data/faq/topics/NoneoftheAbove/faq0012.html some examples that highlight why this is necessary].)

== Tone ==

* Avoid using "simply" or suggesting that something is simple
* Don't use "white" as meaning good and "black" as meaning bad; more concretely, "safelist" and "blocklist" are established precedent

Style

2017-12-20T10:19:13Z

Annevk: /* Tone */

== Language ==

American English.

== Dictionary ==

* bitrate
* cancelation
* canceled
* canceling
* cipher
* colorspace
* implementer
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* nonzero
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Words and phrases used as words ==
* When a word or term is not used functionally but is referred to as the word or term itself, enclose it in quotation marks. (See also: [http://www.chicagomanualofstyle.org/qanda/data/faq/topics/NoneoftheAbove/faq0012.html some examples that highlight why this is necessary].)

== Tone ==

* Avoid using "simply" or suggesting that something is simple
* Don't use "white" as meaning good and "black" as meaning bad; more concretely, "safelist" and "blocklist" are established precedent

Style

2017-12-20T09:47:26Z

Annevk: /* Dictionary */

MediaWiki:Anonnotice

2017-12-18T09:54:42Z

Annevk:

<div id="anonNotice">
<div style="margin: 0.5em auto; border: 1px solid #333333; background-color: #EEEEEE; padding: 0.5em; font-size: larger; text-align: center;">
A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on [[IRC]] (such as one of <span class="plainlinks">[{{fullurl:Special:ListUsers|group=autoconfirmed}} these permanent autoconfirmed members]</span>).
</div>
</div>

IRC

2017-12-12T12:51:34Z

Annevk: Update log links, remove list of people as it's rather dated

Style

2017-11-17T15:57:04Z

Annevk: /* Dictionary */

== Language ==

American English.

== Dictionary ==

* bitrate
* cancelation
* canceled
* canceling
* colorspace
* implementer
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* nonzero
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Words and phrases used as words ==
* When a word or term is not used functionally but is referred to as the word or term itself, enclose it in quotation marks. (See also: [http://www.chicagomanualofstyle.org/qanda/data/faq/topics/NoneoftheAbove/faq0012.html some examples that highlight why this is necessary].)

== Tone ==

* Avoid using "simply" or suggesting that something is simple

Style

2017-09-22T11:41:34Z

Annevk: /* Dictionary */ we never settled newline / line break; we did settle nonzero

== Language ==

American English.

== Dictionary ==

* bitrate
* cancelation
* canceled
* canceling
* colorspace
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* nonzero
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Words and phrases used as words ==
* When a word or term is not used functionally but is referred to as the word or term itself, enclose it in quotation marks. (See also: [http://www.chicagomanualofstyle.org/qanda/data/faq/topics/NoneoftheAbove/faq0012.html some examples that highlight why this is necessary].)

== Tone ==

* Avoid using "simply" or suggesting that something is simple

Style

2017-04-07T12:34:08Z

Annevk: /* Dictionary */ cancel!

== Language ==

American English.

== Dictionary ==

* bitrate
* cancelation
* canceled
* canceling
* colorspace
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)
* newline (not line break)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Tone ==

* Avoid using "simply" or suggesting that something is simple

Style

2017-03-31T15:15:13Z

Annevk:

== Language ==

American English.

== Dictionary ==

* bitrate
* colorspace
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)
* newline (not line break)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.

== Casing ==

* web, unless at the start of a sentence

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Tone ==

* Avoid using "simply" or suggesting that something is simple

Style

2017-03-27T13:56:23Z

Annevk: /* Dictionary */

== Language ==

American English.

== Dictionary ==

* bitrate
* colorspace
* keepalive (though HTTP Keep-Alive [sic] header)
* metadata
* referrer (though HTTP Referer [sic] header)
* whitespace (though CSS white-space [sic] property)
* newline (not line break)

== Grammar ==

* Use 's for possesives, even when it looks unnatural.
* Use the [https://en.wikipedia.org/wiki/Serial_comma Oxford Comma].
* Avoid "one of" unless it's followed by a bulleted list. You can normally leave it out and just use "or". If you cannot leave it out, that might be a good indication you want to use a bulleted list for clarity.

== Punctuation ==

* Spaces around — (em dash)
* Lowercase after colon (''The slot attribute is used to assign a slot to an element: an element with a slot attribute is assigned to the slot created by the slot element whose name attribute's value matches that slot attribute's value'')

== Tone ==

* Avoid using "simply" or suggesting that something is simple

FAQ

2017-03-13T09:20:07Z

Annevk:

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== How do you spell and pronounce WHATWG? ===

It is spelled WHATWG, all uppercase. It has various pronunciations: what-wee-gee, what-wig, what-double-you-gee.

=== What is the WHATWG working on? ===

The WHATWG's main focus is Web standards, specifically:

* [https://html.spec.whatwg.org/multipage/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers
* [https://url.spec.whatwg.org/ URLs], including an API for URLs

...and [https://spec.whatwg.org/ a number of other specs].

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.

=== Is there a Code of Conduct? ===

Yes, see [[Code of Conduct]]. Please read it and respect it.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].

Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.

This continues, with people sending more feedback, until nobody is able to convince the relevant editor to change the spec any more (e.g., because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.

This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.

=== What happens with WHATWG mailing list/GitHub issue discussions? ===

On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).

The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of
useful progress, since that isn't input that can help the decision-making process later.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

File an issue on the [https://spec.whatwg.org/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.

'''If you want feedback to be dealt with faster than "eventually", e.g., because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.

=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:

# Forget about the particular solution you have in mind! Solution time is later!
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].

=== Should I send new proposed text when I have a suggestion? ===

Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.

=== What does "Living Standard" mean? ===

The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.

=== Does that mean the specifications can change at any time? ===

The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)

For references to stable copies of the specifications, some WHATWG specifications follows a process by which each change to the specification (embodied in a commit) triggers the publication of a frozen snapshot of the said specification.

These snapshots are published as historical references. The WHATWG intends to keep these frozen snapshots available at their published URL permanently.

=== What's the patent story for WHATWG standards? ===

The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.

=== What is the process for translating WHATWG standards? ===

Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!

In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.

Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.

Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.

== HTML ==

=== What is HTML? ===

[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before, yet are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== What is HTML5? ===

Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.

=== How do I validate my pages? ===

Use a [https://validator.whatwg.org/ validator].

=== What parts of the specification are stable? ===

The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.

(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.)

=== Will future browsers have any idea what older HTML documents mean? ===

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.

=== How are developers to determine when certain parts of their pages will become invalid? ===

It shouldn't matter if and when old pages become invalid.

Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of the specification.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec:

* The Twitter feed: [https://twitter.com/htmlstandard @htmlstandard]

* The [https://github.com/whatwg/html/commits/master GitHub commits log]

* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client’s diff tools to compare revisions and see what has been changed.

* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/

=== What are the various versions of the HTML spec? ===

The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.

The WHATWG [https://spec.whatwg.org/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.

The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.

=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===

Yes! [https://developers.whatwg.org/ developers.whatwg.org]

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:

* http://diveintohtml5.info/
* http://caniuse.com/
* http://html5doctor.com/
* https://developer.mozilla.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!

=== When will HTML5 be finished? ===

The WHATWG is now using a Living Standard development model, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

=== What's this I hear about 2022? ===

Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than the WHATWG is aiming for. We now look for two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

=== What about Microsoft and Internet Explorer? ===

Microsoft started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.

HTML is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]] or another ''mini-header'' element.

Also see ''HTML feature proposals'' below.

== HTML syntax issues ==

=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What is the DOCTYPE for modern HTML documents? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

Fundamentally, this is an XML issue, and is not specific to XHTML.

=== How are documents from HTML4 and earlier versions parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [https://validator.whatwg.org/ HTML validator] that follows the latest specification.

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.

The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].

A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does this new HTML spec legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML feature proposals ==

=== HTML should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML should support list headers! ===

You can give a header to a list using the <figure> and <figcaption> elements:

<pre>
<figure>
<figcaption>Apples</figcaption>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can use [https://html.spec.whatwg.org/multipage/scripting.html#custom-elements custom elements].
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML should group <dt>s and <dd>s together in <di>s! ===

This was thought to be a styling problem and should be fixed in CSS. There was no reason to add a grouping element to HTML, as the semantics are already unambiguous without an additional element.

In October 2016 it became clear that CSS would not fix this in the foreseeable future, HTML was changed to allow <div> as a grouping element in <dl>. See https://github.com/whatwg/html/issues/1937 and https://github.com/whatwg/html/pull/1945

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements.

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== Where's the harm in adding— ===

Every feature we add to the Web platform has a cost:

* Implementation: someone has to write code for it in each browser
* Testing: someone has to write the tests to check the features is working
* QA: someone has to regularly run the tests to make sure the feature doesn't regress
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain
* Spec writing: someone has to write the spec for the feature and ensure it's maintained
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.

On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)

=== Which group has authority in the event of a dispute? ===

The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.

=== Isn't it bad that the specs have forked? ===

Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.

The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)
* [https://html.spec.whatwg.org/multipage/introduction.html#history-2 The history section in the HTML standard itself]

== Using HTML ==

=== Do you have any hints on how to use <section> and <article> and so on? ===

Some hopefully helpful hints:

* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a <section>/<article>/<aside>/<nav>, and if it's not in the table of contents and doesn't have an <h1>, it should probably not be a <section>/<article>/<aside>/<nav>.
* You can still use <div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.
* Generally, <section>s should start with an <h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an <h1> would be inappropriate, you probably want <div> rather than <section>.
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using <article>, and each comment could be big enough that it has separate <section>s, and so on.

== Other specifications ==

=== What ever happened to...? ===

The Web Forms 2.0 specification was folded into what is now the HTML specification.

The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.

The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.

== Mailing List ==

=== +1 ===

Please note that content-free agreement (such as +1s) have no effect on
the WHATWG list and are therefore discouraged. Editors of specs discussed
in the WHATWG only consider the quality of the arguments presented, and
not the volume of agreement.

You should therefore only post to the list if you have a substantive new point
to make, for example if you have seen a flaw in an argument presented so far,
or have a new idea to contribute, or have some information that has not yet
been brought to the table.

=== Making Outlook quote email messages properly ===
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.

=== Should I top-post or reply inline? ===

'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous emails in your replies.'''

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your email makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your email backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post emails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write email.

Ian wrote:
> Is this a good way to write email?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

FAQ

2017-03-13T09:19:26Z

Annevk: /* What is the WHATWG working on? */

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== How do you spell and pronounce WHATWG? ===

It is spelled WHATWG, all uppercase. It has various pronunciations: what-wee-gee, what-wig, what-double-you-gee.

=== What is the WHATWG working on? ===

The WHATWG's main focus is Web standards, specifically:

* [https://html.spec.whatwg.org/multipage/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers
* [https://url.spec.whatwg.org/ URLs], including an API for URLs

...and [https://spec.whatwg.org/ a number of other specs].

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.

=== Is there a Code of Conduct? ===

Yes, see [[Code of Conduct]]. Please read it and respect it.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].

Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.

This continues, with people sending more feedback, until nobody is able to convince the relevant editor to change the spec any more (e.g., because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.

This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.

=== What happens with WHATWG mailing list/GitHub issue discussions? ===

On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).

The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of
useful progress, since that isn't input that can help the decision-making process later.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.

'''If you want feedback to be dealt with faster than "eventually", e.g., because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.

=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:

# Forget about the particular solution you have in mind! Solution time is later!
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].

=== Should I send new proposed text when I have a suggestion? ===

Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.

=== What does "Living Standard" mean? ===

The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.

=== Does that mean the specifications can change at any time? ===

The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)

For references to stable copies of the specifications, some WHATWG specifications follows a process by which each change to the specification (embodied in a commit) triggers the publication of a frozen snapshot of the said specification.

These snapshots are published as historical references. The WHATWG intends to keep these frozen snapshots available at their published URL permanently.

=== What's the patent story for WHATWG standards? ===

The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.

=== What is the process for translating WHATWG standards? ===

Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!

In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.

Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.

Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.

== HTML ==

=== What is HTML? ===

[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before, yet are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== What is HTML5? ===

Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.

=== How do I validate my pages? ===

Use a [https://validator.whatwg.org/ validator].

=== What parts of the specification are stable? ===

The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.

(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.)

=== Will future browsers have any idea what older HTML documents mean? ===

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.

=== How are developers to determine when certain parts of their pages will become invalid? ===

It shouldn't matter if and when old pages become invalid.

Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of the specification.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec:

* The Twitter feed: [https://twitter.com/htmlstandard @htmlstandard]

* The [https://github.com/whatwg/html/commits/master GitHub commits log]

* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client’s diff tools to compare revisions and see what has been changed.

* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/

=== What are the various versions of the HTML spec? ===

The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.

The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.

The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.

=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===

Yes! [https://developers.whatwg.org/ developers.whatwg.org]

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:

* http://diveintohtml5.info/
* http://caniuse.com/
* http://html5doctor.com/
* https://developer.mozilla.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!

=== When will HTML5 be finished? ===

The WHATWG is now using a Living Standard development model, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

=== What's this I hear about 2022? ===

Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than the WHATWG is aiming for. We now look for two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

=== What about Microsoft and Internet Explorer? ===

Microsoft started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.

HTML is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]] or another ''mini-header'' element.

Also see ''HTML feature proposals'' below.

== HTML syntax issues ==

=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What is the DOCTYPE for modern HTML documents? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

Fundamentally, this is an XML issue, and is not specific to XHTML.

=== How are documents from HTML4 and earlier versions parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [https://validator.whatwg.org/ HTML validator] that follows the latest specification.

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.

The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].

A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does this new HTML spec legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML feature proposals ==

=== HTML should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML should support list headers! ===

You can give a header to a list using the <figure> and <figcaption> elements:

<pre>
<figure>
<figcaption>Apples</figcaption>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can use [https://html.spec.whatwg.org/multipage/scripting.html#custom-elements custom elements].
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML should group <dt>s and <dd>s together in <di>s! ===

This was thought to be a styling problem and should be fixed in CSS. There was no reason to add a grouping element to HTML, as the semantics are already unambiguous without an additional element.

In October 2016 it became clear that CSS would not fix this in the foreseeable future, HTML was changed to allow <div> as a grouping element in <dl>. See https://github.com/whatwg/html/issues/1937 and https://github.com/whatwg/html/pull/1945

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements.

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== Where's the harm in adding— ===

Every feature we add to the Web platform has a cost:

* Implementation: someone has to write code for it in each browser
* Testing: someone has to write the tests to check the features is working
* QA: someone has to regularly run the tests to make sure the feature doesn't regress
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain
* Spec writing: someone has to write the spec for the feature and ensure it's maintained
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.

On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)

=== Which group has authority in the event of a dispute? ===

The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.

=== Isn't it bad that the specs have forked? ===

Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.

The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)
* [https://html.spec.whatwg.org/multipage/introduction.html#history-2 The history section in the HTML standard itself]

== Using HTML ==

=== Do you have any hints on how to use <section> and <article> and so on? ===

Some hopefully helpful hints:

* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a <section>/<article>/<aside>/<nav>, and if it's not in the table of contents and doesn't have an <h1>, it should probably not be a <section>/<article>/<aside>/<nav>.
* You can still use <div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.
* Generally, <section>s should start with an <h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an <h1> would be inappropriate, you probably want <div> rather than <section>.
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using <article>, and each comment could be big enough that it has separate <section>s, and so on.

== Other specifications ==

=== What ever happened to...? ===

The Web Forms 2.0 specification was folded into what is now the HTML specification.

The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.

The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.

== Mailing List ==

=== +1 ===

Please note that content-free agreement (such as +1s) have no effect on
the WHATWG list and are therefore discouraged. Editors of specs discussed
in the WHATWG only consider the quality of the arguments presented, and
not the volume of agreement.

You should therefore only post to the list if you have a substantive new point
to make, for example if you have seen a flaw in an argument presented so far,
or have a new idea to contribute, or have some information that has not yet
been brought to the table.

=== Making Outlook quote email messages properly ===
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.

=== Should I top-post or reply inline? ===

'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous emails in your replies.'''

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your email makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your email backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post emails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write email.

Ian wrote:
> Is this a good way to write email?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

FAQ

2017-03-13T09:18:39Z

Annevk: add spelling and pronunciation

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== How do you spell and pronounce WHATWG? ===

It is spelled WHATWG, all uppercase. It has various pronunciations: what-wee-gee, what-wig, what-double-you-gee.

=== What is the WHATWG working on? ===

The WHATWG's main focus is Web standards, specifically:

* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers
* [https://url.spec.whatwg.org/ URLs], including an API for URLs

...and [https://whatwg.org/specs a number of other specs].

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.

=== Is there a Code of Conduct? ===

Yes, see [[Code of Conduct]]. Please read it and respect it.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].

Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.

This continues, with people sending more feedback, until nobody is able to convince the relevant editor to change the spec any more (e.g., because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.

This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.

=== What happens with WHATWG mailing list/GitHub issue discussions? ===

On the WHATWG list and in WHATWG issues on GitHub, the burden is on the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).

The purpose of debate at the WHATWG therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of
useful progress, since that isn't input that can help the decision-making process later.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.

'''If you want feedback to be dealt with faster than "eventually", e.g., because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.

=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:

# Forget about the particular solution you have in mind! Solution time is later!
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see [http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html this email].
# Get more people involved. Open a new issue in [https://github.com/whatwg/html/issues whatwg/html on GitHub] that describes the use cases and their requirements. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, as a comment on the feature's issue. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).
# Ask the spec's editor to put that solution in the spec, or create a pull request on GitHub yourself. Possibly your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which can even start before implementations start being written to the spec. Cross-browser tests for HTML are maintained in [https://github.com/w3c/web-platform-tests/tree/master/html w3c/web-platform-tests/html on GitHub].

=== Should I send new proposed text when I have a suggestion? ===

Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.

=== What does "Living Standard" mean? ===

The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.

=== Does that mean the specifications can change at any time? ===

The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)

For references to stable copies of the specifications, some WHATWG specifications follows a process by which each change to the specification (embodied in a commit) triggers the publication of a frozen snapshot of the said specification.

These snapshots are published as historical references. The WHATWG intends to keep these frozen snapshots available at their published URL permanently.

=== What's the patent story for WHATWG standards? ===

The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.

=== What is the process for translating WHATWG standards? ===

Many WHATWG standards have been translated into other languages by the WHATWG community. This is great, and highly encouraged!

In general, if you translate a WHATWG Standard, please communicate with the maintainers of the standard (e.g. via a GitHub issue) letting them know about your work. In general this will lead to adding a link to your translation to the top of the original specification, to allow interested readers to view it. You can see examples of this in many WHATWG standards, e.g. https://streams.spec.whatwg.org/.

Such translations are not normative (i.e., implementations should be sure to consult the original). Due to the nature of living standards, which can change often, it's possible for translations to become out of date compared to the original standard. If the translation shows signs of no longer being maintained, or has other quality problems, community members are encouraged to provide feedback to the maintainers of the standard, so that any links to the translation can be removed in order to avoid confusing readers.

Note that WHATWG specifications are always licensed under liberal licenses that allow the creation of derivative works like translations.

== HTML ==

=== What is HTML? ===

[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before, yet are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== What is HTML5? ===

Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.

=== How do I validate my pages? ===

Use a [https://validator.whatwg.org/ validator].

=== What parts of the specification are stable? ===

The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.

(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.)

=== Will future browsers have any idea what older HTML documents mean? ===

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.

=== How are developers to determine when certain parts of their pages will become invalid? ===

It shouldn't matter if and when old pages become invalid.

Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of the specification.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec:

* The Twitter feed: [https://twitter.com/htmlstandard @htmlstandard]

* The [https://github.com/whatwg/html/commits/master GitHub commits log]

* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client’s diff tools to compare revisions and see what has been changed.

* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/

=== What are the various versions of the HTML spec? ===

The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.

The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.

The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.

=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===

Yes! [https://developers.whatwg.org/ developers.whatwg.org]

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:

* http://diveintohtml5.info/
* http://caniuse.com/
* http://html5doctor.com/
* https://developer.mozilla.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!

=== When will HTML5 be finished? ===

The WHATWG is now using a Living Standard development model, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

=== What's this I hear about 2022? ===

Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than the WHATWG is aiming for. We now look for two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

=== What about Microsoft and Internet Explorer? ===

Microsoft started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.

HTML is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]] or another ''mini-header'' element.

Also see ''HTML feature proposals'' below.

== HTML syntax issues ==

=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What is the DOCTYPE for modern HTML documents? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

Fundamentally, this is an XML issue, and is not specific to XHTML.

=== How are documents from HTML4 and earlier versions parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [https://validator.whatwg.org/ HTML validator] that follows the latest specification.

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.

The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].

A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does this new HTML spec legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML feature proposals ==

=== HTML should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML should support list headers! ===

You can give a header to a list using the <figure> and <figcaption> elements:

<pre>
<figure>
<figcaption>Apples</figcaption>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can use [https://html.spec.whatwg.org/multipage/scripting.html#custom-elements custom elements].
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML should group <dt>s and <dd>s together in <di>s! ===

This was thought to be a styling problem and should be fixed in CSS. There was no reason to add a grouping element to HTML, as the semantics are already unambiguous without an additional element.

In October 2016 it became clear that CSS would not fix this in the foreseeable future, HTML was changed to allow <div> as a grouping element in <dl>. See https://github.com/whatwg/html/issues/1937 and https://github.com/whatwg/html/pull/1945

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements.

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== Where's the harm in adding— ===

Every feature we add to the Web platform has a cost:

* Implementation: someone has to write code for it in each browser
* Testing: someone has to write the tests to check the features is working
* QA: someone has to regularly run the tests to make sure the feature doesn't regress
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain
* Spec writing: someone has to write the spec for the feature and ensure it's maintained
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.

On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)

=== Which group has authority in the event of a dispute? ===

The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.

=== Isn't it bad that the specs have forked? ===

Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.

The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [https://platform.html5.org/history/ A feature history of the modern Web Platform] (2003 onward) ([https://github.com/whatwg/platform.html5.org/blob/master/history/index.html on GitHub])
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki] (1997 to 2008)
* [https://html.spec.whatwg.org/multipage/introduction.html#history-2 The history section in the HTML standard itself]

== Using HTML ==

=== Do you have any hints on how to use <section> and <article> and so on? ===

Some hopefully helpful hints:

* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a <section>/<article>/<aside>/<nav>, and if it's not in the table of contents and doesn't have an <h1>, it should probably not be a <section>/<article>/<aside>/<nav>.
* You can still use <div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.
* Generally, <section>s should start with an <h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an <h1> would be inappropriate, you probably want <div> rather than <section>.
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using <article>, and each comment could be big enough that it has separate <section>s, and so on.

== Other specifications ==

=== What ever happened to...? ===

The Web Forms 2.0 specification was folded into what is now the HTML specification.

The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.

The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.

== Mailing List ==

=== +1 ===

Please note that content-free agreement (such as +1s) have no effect on
the WHATWG list and are therefore discouraged. Editors of specs discussed
in the WHATWG only consider the quality of the arguments presented, and
not the volume of agreement.

You should therefore only post to the list if you have a substantive new point
to make, for example if you have seen a flaw in an argument presented so far,
or have a new idea to contribute, or have some information that has not yet
been brought to the table.

=== Making Outlook quote email messages properly ===
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.

=== Should I top-post or reply inline? ===

'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous emails in your replies.'''

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your email makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your email backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post emails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write email.

Ian wrote:
> Is this a good way to write email?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

IRC

2017-02-12T15:44:37Z

Annevk:

The Freenode IRC network has a channel called [irc://irc.freenode.net/whatwg #whatwg] where some of the more active WHATWG community members hang out. Feel free to join us!

Note that if you go to IRC to ask a question, it might take a while to get a reply. It can pay off to stick around for a couple of hours or more.

If you want to run a bot, let us know. If they are useful, e.g. providing logging facilities, then they are more than welcome.

== Logs ==

Logs for the #whatwg channel can be found here:

* http://logbot.glob.com.au/?c=freenode%23whatwg&s=today
* http://krijnhoetmer.nl/irc-logs/whatwg/ (not updated for the last couple of months)

== Getting Started with IRC ==

The simplest way to get started with IRC, if you are not familiar, is by signing up for a free [https://www.irccloud.com/ IRCCloud] account. Once you've done that, you should be logged in to the Freenode server by default. All you'll have to do is join the #whatwg channel. If you tell your browser to use IRCCloud for irc:// links, then just [irc://irc.freenode.net/whatwg clicking this link] should also take you there.

== People ==

A list of regulars, sorted by nick, and their normal timezones (winter/summer).

* {{irc user|Adactio|adactio|+0000/+0100}}
* {{irc user|Annevk|annevk|.../...}}
* {{irc user|Dglazkov|dglazkov|.../...}}
* {{irc user|Domenic|Domenic|-0500/-0400}}
* {{irc user|GPHemsley|GPHemsley|-0500/-0400}}
* {{irc user|Hixie|Hixie|-0800/-0700}}
* {{irc user|EdwardOConnor|hober|-0800/-0700}}
* {{irc user|Jgraham|jgraham|.../...}}
* {{irc user|kennyluck|kennyluck|+0800/+0800}}
* {{irc user|Mathias|matjas|.../...}}
* {{irc user|Ms2ger|Ms2ger|.../...}}
* {{irc user|Mjs|othermaciej|-0800/-0700}}
* {{irc user|ShaneHudson|ShaneHudson|+0000/+0100}}
* {{irc user|Xanthir|tabatkins|-0800/-0700}}
* {{irc user|Tantek|tantek|-0800/-0700}}
* {{irc user|Yuhong|yuhong|-0800/-0700}}
* {{irc user|Wilto|Wilto|.../...}}
* {{irc user|Zcorpan|zcorpan|.../...}}

Style

2017-01-15T12:12:04Z

Annevk:

Style

2017-01-09T08:12:46Z

Annevk: /* Grammar */

Fork tracking

2016-11-30T11:52:43Z

Annevk: streams \o/

This page exists to document the status of the outdated forks of various WHATWG specifications, and any progress toward clarifying their out-of-dateness.

== Confusion Mitigated ==

* Fullscreen: https://fullscreen.spec.whatwg.org/
** Forked to http://www.w3.org/TR/fullscreen/
** Status: discontinued as a NOTE. ED URL (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) redirects
* Streams: https://streams.spec.whatwg.org/
** Forked to http://www.w3.org/TR/streams-api/
** Status: discontinued as NOTE. ED URL is WHATWG URL, former ED URL (http://w3c.github.io/streams-api/) redirects
* XMLHttpRequest: https://xhr.spec.whatwg.org/
** Forked to http://www.w3.org/TR/XMLHttpRequest/
** Forked to http://www.w3.org/TR/XMLHttpRequest2/
** Forked to https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html
** Status: both /TR/ forks discontinued as a NOTE, although XHR2 directs visitors to both XHR1 and the XHR Standard for some reason. Editor's draft redirects.

== Confusion Somewhat Mitigated ==

* URL: https://url.spec.whatwg.org/
** Forked to http://www.w3.org/TR/url/ plus various aliases and older versions (e.g. https://www.w3.org/TR/url-1/)
** Status: has a reasonable red disclaimer, but still exists.
** https://w3ctag.github.io/url/ has been fully discontinued, at least.

== Confusion Persists ==

* Fetch: https://fetch.spec.whatwg.org/
** Obsolete subsections published as http://www.w3.org/TR/cors/
** Status: still exists as an outdated specification with no warning, causing confusion.
* DOM: https://dom.spec.whatwg.org/
** Forked to http://www.w3.org/TR/dom/
** Status: still exists as an outdated snapshot (and modified in undocumented ways) with no warning, causing confusion. And has a weird rename ("DOM4") too.
* Encoding: https://encoding.spec.whatwg.org/
** Forked to http://www.w3.org/TR/encoding/
** Status: still exists as an outdated snapshot with no warning, causing confusion
* Notifications: https://notifications.spec.whatwg.org/
** Forked to http://www.w3.org/TR/notifications/
** Status: still exists as an outdated snapshot with no warning, causing confusion. The spec model has diverged significantly in the meantime, and the outdated version is actively wrong, not just incomplete.
* HTML: https://html.spec.whatwg.org/multipage/
** Forked to http://www.w3.org/TR/html5/ as an outdated fork of a subset frozen in 2013.
** Forked to http://www.w3.org/TR/html51/ as an outdated fork of a subset frozen in 2015.
** Forked to https://w3c.github.io/html/ as an outdated fork of a subset frozen in early 2016 (see [https://annevankesteren.nl/2016/01/film-at-11 blog post]).
** In general all of these attempt to copy-and-paste HTML and then apply forked patches on top, but the scripts are wonky, leading to lots of errors.
** Subsets of HTML split out into other outdated forks, none with appropriate warnings:
*** http://www.w3.org/TR/webstorage/
*** http://www.w3.org/TR/workers/
*** http://www.w3.org/TR/webmessaging/ (ED is nice at least https://w3c.github.io/webmessaging/)
*** http://www.w3.org/TR/websockets/ (ED is nice at least https://w3c.github.io/websockets/)
*** http://www.w3.org/TR/eventsource/ (ED is nice at least https://w3c.github.io/eventsource/)
*** http://www.w3.org/TR/2dcontext/
*** https://dev.w3.org/2006/canvas-api/canvas-2d-api.html
*** https://www.w3.org/TR/2dcontext2/
*** https://www.w3.org/TR/microdata/ (published as NOTE, but still contains a bunch of outdated content)

Style

2016-11-29T08:09:53Z

Annevk:

Fork tracking

2016-11-23T12:22:14Z

Annevk: /* Confusion Persists */ oops

This page exists to document the status of the outdated forks of various WHATWG specifications, and any progress toward clarifying their out-of-dateness.

== Confusion Mitigated ==

* Fullscreen: https://fullscreen.spec.whatwg.org/
** Forked to http://www.w3.org/TR/fullscreen/
** Status: discontinued as a NOTE. ED URL (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) redirects

== Confusion Somewhat Mitigated ==

* URL: https://url.spec.whatwg.org/
** Forked to http://www.w3.org/TR/url/ plus various aliases and older versions (e.g. https://www.w3.org/TR/url-1/)
** Status: has a reasonable red disclaimer, but still exists.
** https://w3ctag.github.io/url/ has been fully discontinued, at least.
* Streams: https://streams.spec.whatwg.org/
** Forked to http://www.w3.org/TR/streams-api/
** Status: mostly gutted, with a reasonable red disclaimer.
* XMLHttpRequest: https://xhr.spec.whatwg.org/
** Forked to http://www.w3.org/TR/XMLHttpRequest/
** Forked to http://www.w3.org/TR/XMLHttpRequest2/
** Forked to https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html
** Status: both /TR/ forks discontinued as a NOTE, although XHR2 directs visitors to both XHR1 and the XHR Standard for some reason. Editor's draft still exists.

== Confusion Persists ==

* Fetch: https://fetch.spec.whatwg.org/
** Obsolete subsections published as http://www.w3.org/TR/cors/
** Status: still exists as an outdated specification with no warning, causing confusion.
* DOM: https://dom.spec.whatwg.org/
** Forked to http://www.w3.org/TR/dom/
** Status: still exists as an outdated snapshot (and modified in undocumented ways) with no warning, causing confusion. And has a weird rename ("DOM4") too.
* Encoding: https://encoding.spec.whatwg.org/
** Forked to http://www.w3.org/TR/encoding/
** Status: still exists as an outdated snapshot with no warning, causing confusion
* Notifications: https://notifications.spec.whatwg.org/
** Forked to http://www.w3.org/TR/notifications/
** Status: still exists as an outdated snapshot with no warning, causing confusion. The spec model has diverged significantly in the meantime, and the outdated version is actively wrong, not just incomplete.
* HTML: https://html.spec.whatwg.org/multipage/
** Forked to http://www.w3.org/TR/html5/ as an outdated fork of a subset frozen in 2013.
** Forked to http://www.w3.org/TR/html51/ as an outdated fork of a subset frozen in 2015.
** Forked to https://w3c.github.io/html/ as an outdated fork of a subset frozen in early 2016 (see [https://annevankesteren.nl/2016/01/film-at-11 blog post]).
** In general all of these attempt to copy-and-paste HTML and then apply forked patches on top, but the scripts are wonky, leading to lots of errors.
** Subsets of HTML split out into other outdated forks, none with appropriate warnings:
*** http://www.w3.org/TR/webstorage/
*** http://www.w3.org/TR/workers/
*** http://www.w3.org/TR/webmessaging/ (ED is nice at least https://w3c.github.io/webmessaging/)
*** http://www.w3.org/TR/websockets/ (ED is nice at least https://w3c.github.io/websockets/)
*** http://www.w3.org/TR/eventsource/ (ED is nice at least https://w3c.github.io/eventsource/)
*** http://www.w3.org/TR/2dcontext/
*** https://dev.w3.org/2006/canvas-api/canvas-2d-api.html
*** https://www.w3.org/TR/2dcontext2/
*** https://www.w3.org/TR/microdata/ (published as NOTE, but still contains a bunch of outdated content)

Fork tracking

2016-11-23T12:16:31Z

Annevk: /* Confusion Persists */

This page exists to document the status of the outdated forks of various WHATWG specifications, and any progress toward clarifying their out-of-dateness.

== Confusion Mitigated ==

* Fullscreen: https://fullscreen.spec.whatwg.org/
** Forked to http://www.w3.org/TR/fullscreen/
** Status: discontinued as a NOTE. ED URL (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) redirects

== Confusion Somewhat Mitigated ==

* URL: https://url.spec.whatwg.org/
** Forked to http://www.w3.org/TR/url/ plus various aliases and older versions (e.g. https://www.w3.org/TR/url-1/)
** Status: has a reasonable red disclaimer, but still exists.
** https://w3ctag.github.io/url/ has been fully discontinued, at least.
* Streams: https://streams.spec.whatwg.org/
** Forked to http://www.w3.org/TR/streams-api/
** Status: mostly gutted, with a reasonable red disclaimer.
* XMLHttpRequest: https://xhr.spec.whatwg.org/
** Forked to http://www.w3.org/TR/XMLHttpRequest/
** Forked to http://www.w3.org/TR/XMLHttpRequest2/
** Forked to https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html
** Status: both /TR/ forks discontinued as a NOTE, although XHR2 directs visitors to both XHR1 and the XHR Standard for some reason. Editor's draft still exists.

== Confusion Persists ==

* Fetch: https://fetch.spec.whatwg.org/
** Obsolete subsections published as http://www.w3.org/TR/cors/
** Status: still exists as an outdated specification with no warning, causing confusion.
* DOM: https://dom.spec.whatwg.org/
** Forked to http://www.w3.org/TR/dom/
** Status: still exists as an outdated snapshot with no warning, causing confusion. And has a weird rename ("DOM4") too.
* Encoding: https://encoding.spec.whatwg.org/
** Forked to http://www.w3.org/TR/encoding/
** Status: still exists as an outdated snapshot with no warning, causing confusion
* Notifications: https://notifications.spec.whatwg.org/
** Forked to http://www.w3.org/TR/notifications/
** Status: still exists as an outdated snapshot (and modified in undocumented ways) with no warning, causing confusion. The spec model has diverged significantly in the meantime, and the outdated version is actively wrong, not just incomplete.
* HTML: https://html.spec.whatwg.org/multipage/
** Forked to http://www.w3.org/TR/html5/ as an outdated fork of a subset frozen in 2013.
** Forked to http://www.w3.org/TR/html51/ as an outdated fork of a subset frozen in 2015.
** Forked to https://w3c.github.io/html/ as an outdated fork of a subset frozen in early 2016 (see [https://annevankesteren.nl/2016/01/film-at-11 blog post]).
** In general all of these attempt to copy-and-paste HTML and then apply forked patches on top, but the scripts are wonky, leading to lots of errors.
** Subsets of HTML split out into other outdated forks, none with appropriate warnings:
*** http://www.w3.org/TR/webstorage/
*** http://www.w3.org/TR/workers/
*** http://www.w3.org/TR/webmessaging/ (ED is nice at least https://w3c.github.io/webmessaging/)
*** http://www.w3.org/TR/websockets/ (ED is nice at least https://w3c.github.io/websockets/)
*** http://www.w3.org/TR/eventsource/ (ED is nice at least https://w3c.github.io/eventsource/)
*** http://www.w3.org/TR/2dcontext/
*** https://dev.w3.org/2006/canvas-api/canvas-2d-api.html
*** https://www.w3.org/TR/2dcontext2/
*** https://www.w3.org/TR/microdata/ (published as NOTE, but still contains a bunch of outdated content)

Style

2016-11-07T09:17:55Z

Annevk: Created page with "== Language == American English. == Dictionary == * bitrate * colorspace * keepalive (though HTTP Keep-Alive [sic] header) * metadata * referrer (though HTTP Referer [sic]..."

Main Page

2016-11-07T09:17:50Z

Annevk: /* Spec Development */

Welcome to the WHATWG Wiki!

You can be a part of our community, making proposals for the next version of HTML. This wiki is made available for you for drafting proposals, for writing essays, for keeping track of HTML-related issues, and so forth.

Before you begin, you may wish to read our [[WHATWG Wiki:Contribution Guidelines|contribution guidelines]]. Once you are an autoconfirmed user, you may [[WHATWG Wiki:How to create a user account|create new user accounts]], by request.

==Quick Links==
* [[FAQ]]
* [[What you can do]] — '''[[Reviewing|Review our work!]]
* [[:Category:Implementations|Implementations]]
* [[Presentations]]

==Web Developers==
* [[Authoring|Using HTML in your Web site]]
* [[Presentational elements and attributes]]
* [[HTML vs. XHTML]]

==Spec Development==
* [[Best Practices for Implementors]]
* [[:Category:Spec coordination|Spec coordination]]
* [[:Category:Proposals|Proposals]]
* [[:Category:Registries|Registries]]
* [[New Features Awaiting Implementation Interest]]
* [[Testsuite]]
* [[Style]]

==WHATWG Specifications==
* [http://www.whatwg.org/specs Complete list of specifications actively developed at the WHATWG]
* [http://whatwg.org/html HTML]
* [[HTML derivatives]]
* [[HTML snapshots]]
* [[Fork tracking]]

==Communicating with the community==
The WHATWG community has several channels of communication:
* [[IRC]] and [http://www.whatwg.org/mailing-list mailing lists]
* [http://forums.whatwg.org/ Forums]
* [http://blog.whatwg.org/ The WHATWG Blog], including [http://blog.whatwg.org/category/weekly-review WHATWG Weekly]
* [http://twitter.com/WHATWG @WHATWG] on twitter

Fork tracking

2016-10-11T16:55:11Z

Annevk: /* Confusion Persists */ add more canvas documents

This page exists to document the status of the outdated forks of various WHATWG specifications, and any progress toward clarifying their out-of-dateness.

== Confusion Mitigated ==

* Fullscreen: https://fullscreen.spec.whatwg.org/
** Forked to http://www.w3.org/TR/fullscreen/
** Status: discontinued as a NOTE. ED URL (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) redirects

== Confusion Somewhat Mitigated ==

* URL: https://url.spec.whatwg.org/
** Forked to http://www.w3.org/TR/url/ plus various aliases and older versions (e.g. https://www.w3.org/TR/url-1/)
** Status: has a reasonable red disclaimer, but still exists.
** https://w3ctag.github.io/url/ has been fully discontinued, at least.
* Streams: https://streams.spec.whatwg.org/
** Forked to http://www.w3.org/TR/streams-api/
** Status: mostly gutted, with a reasonable red disclaimer.
* XMLHttpRequest: https://xhr.spec.whatwg.org/
** Forked to http://www.w3.org/TR/XMLHttpRequest/
** Forked to http://www.w3.org/TR/XMLHttpRequest2/
** Forked to https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html
** Status: both /TR/ forks discontinued as a NOTE, although XHR2 directs visitors to both XHR1 and the XHR Standard for some reason. Editor's draft still exists.

== Confusion Persists ==

* Fetch: https://fetch.spec.whatwg.org/
** Obsolete subsections published as http://www.w3.org/TR/cors/
** Status: still exists as an outdated specification with no warning, causing confusion.
* DOM: https://dom.spec.whatwg.org/
** Forked to http://www.w3.org/TR/dom/
** Status: still exists as an outdated snapshot with no warning, causing confusion. And has a weird rename ("DOM4") too.
* Encoding: https://encoding.spec.whatwg.org/
** Forked to http://www.w3.org/TR/encoding/
** Status: still exists as an outdated snapshot with no warning, causing confusion
* Notifications: https://notifications.spec.whatwg.org/
** Forked to http://www.w3.org/TR/notifications/
** Status: still exists as an outdated snapshot with no warning, causing confusion. The spec model has diverged significantly in the meantime, and the outdated version is actively wrong, not just incomplete.
* HTML: https://html.spec.whatwg.org/multipage/
** Forked to http://www.w3.org/TR/html5/ as an outdated fork of a subset frozen in 2013.
** Forked to http://www.w3.org/TR/html51/ as an outdated fork of a subset frozen in 2015.
** Forked to https://w3c.github.io/html/ as an outdated fork of a subset frozen in early 2016 (see [https://annevankesteren.nl/2016/01/film-at-11 blog post]).
** In general all of these attempt to copy-and-paste HTML and then apply forked patches on top, but the scripts are wonky, leading to lots of errors.
** Subsets of HTML split out into other outdated forks, none with appropriate warnings:
*** http://www.w3.org/TR/webstorage/
*** http://www.w3.org/TR/workers/
*** http://www.w3.org/TR/webmessaging/ (ED is nice at least https://w3c.github.io/webmessaging/)
*** http://www.w3.org/TR/websockets/ (ED is nice at least https://w3c.github.io/websockets/)
*** http://www.w3.org/TR/eventsource/ (ED is nice at least https://w3c.github.io/eventsource/)
*** http://www.w3.org/TR/2dcontext/
*** https://dev.w3.org/2006/canvas-api/canvas-2d-api.html
*** https://www.w3.org/TR/2dcontext2/
*** https://www.w3.org/TR/microdata/ (published as NOTE, but still contains a bunch of outdated content)

Fork tracking

2016-10-11T14:21:40Z

Annevk: /* Confusion Mitigated */ add a URL I found for XHR

This page exists to document the status of the outdated forks of various WHATWG specifications, and any progress toward clarifying their out-of-dateness.

== Confusion Mitigated ==

* Fullscreen: https://fullscreen.spec.whatwg.org/
** Forked to http://www.w3.org/TR/fullscreen/
** Status: discontinued as a NOTE. ED URL (http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html) redirects
* XMLHttpRequest: https://xhr.spec.whatwg.org/
** Forked to http://www.w3.org/TR/XMLHttpRequest/
** Forked to http://www.w3.org/TR/XMLHttpRequest2/
** Forked to https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html
** Status: both forks discontinued as a NOTE, although XHR2 directs visitors to both XHR1 and the XHR Standard for some reason.

== Confusion Somewhat Mitigated ==

* URL: https://url.spec.whatwg.org/
** Forked to http://www.w3.org/TR/url/ plus various aliases and older versions (e.g. https://www.w3.org/TR/url-1/)
** Status: has a reasonable red disclaimer, but still exists.
** https://w3ctag.github.io/url/ has been fully discontinued, at least.
* Streams: https://streams.spec.whatwg.org/
** Forked to http://www.w3.org/TR/streams-api/
** Status: mostly gutted, with a reasonable red disclaimer.

== Confusion Persists ==

* Fetch: https://fetch.spec.whatwg.org/
** Obsolete subsections published as http://www.w3.org/TR/cors/
** Status: still exists as an outdated specification with no warning, causing confusion.
* DOM: https://dom.spec.whatwg.org/
** Forked to http://www.w3.org/TR/dom/
** Status: still exists as an outdated snapshot with no warning, causing confusion. And has a weird rename ("DOM4") too.
* Encoding: https://encoding.spec.whatwg.org/
** Forked to http://www.w3.org/TR/encoding/
** Status: still exists as an outdated snapshot with no warning, causing confusion
* Notifications: https://notifications.spec.whatwg.org/
** Forked to http://www.w3.org/TR/notifications/
** Status: still exists as an outdated snapshot with no warning, causing confusion. The spec model has diverged significantly in the meantime, and the outdated version is actively wrong, not just incomplete.
* HTML: https://html.spec.whatwg.org/multipage/
** Forked to http://www.w3.org/TR/html5/ as an outdated fork of a subset frozen in 2013.
** Forked to http://www.w3.org/TR/html51/ as an outdated fork of a subset frozen in 2015.
** Forked to https://w3c.github.io/html/ as an outdated fork of a subset frozen in early 2016 (see [https://annevankesteren.nl/2016/01/film-at-11 blog post]).
** In general all of these attempt to copy-and-paste HTML and then apply forked patches on top, but the scripts are wonky, leading to lots of errors.
** Subsets of HTML split out into other outdated forks, none with appropriate warnings:
*** http://www.w3.org/TR/webstorage/
*** http://www.w3.org/TR/workers/
*** http://www.w3.org/TR/webmessaging/ (ED is nice at least https://w3c.github.io/webmessaging/)
*** http://www.w3.org/TR/websockets/ (ED is nice at least https://w3c.github.io/websockets/)
*** http://www.w3.org/TR/eventsource/ (ED is nice at least https://w3c.github.io/eventsource/)
*** http://www.w3.org/TR/2dcontext/
*** https://www.w3.org/TR/microdata/ (published as NOTE, but still contains a bunch of outdated content)

FAQ

2016-04-16T06:47:39Z

Annevk: /* How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? */ GitHub is a thing now

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== What is the WHATWG working on? ===

The WHATWG's main focus is Web standards, specifically:

* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers
* [https://url.spec.whatwg.org/ URLs], including an API for URLs

...and [https://whatwg.org/specs a number of other specs].

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.

=== Is there a Code of Conduct? ===

Yes, see [[Code of Conduct]]. Please read it and respect it.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].

Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.

This continues, with people sending more feedback, until nobody is able to convince the relevant editor to change the spec any more (e.g., because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.

This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.

=== What happens with WHATWG mailing list discussions? ===

On the WHATWG list, the burden is an the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).

The purpose of debate on the WHATWG list therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of
useful progress, since that isn't input that can help the decision-making process later.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

File an issue on the [https://whatwg.org/specs/ relevant standard] as indicated at the top of that standard. All feedback is supposed to be addressed in due course. You are also welcome to take a stab at addressing the problem yourself through a GitHub pull request.

'''If you want feedback to be dealt with faster than "eventually", e.g., because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.

=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:

# Forget about the particular solution you have in mind! Solution time is later!
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html
# Get more people involved. Send your use cases and their requirements to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, again to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).
# Ask the spec's editor to put that solution in the spec. Likely your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which can even start before implementations start being written to the spec. We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.

=== Should I send new proposed text when I have a suggestion? ===

Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.

=== What does "Living Standard" mean? ===

The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.

=== Does that mean the specifications can change at any time? ===

The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)

=== What's the patent story for WHATWG standards? ===

The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.

== HTML ==

=== What is HTML? ===

[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before, yet are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== What is HTML5? ===

Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.

=== How do I validate my pages? ===

Use a [https://validator.whatwg.org/ validator].

=== What parts of the specification are stable? ===

The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.

(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.)

=== Will future browsers have any idea what older HTML documents mean? ===

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.

=== How are developers to determine when certain parts of their pages will become invalid? ===

It shouldn't matter if and when old pages become invalid.

Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of the specification.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec:

* The Twitter feed: [https://twitter.com/htmlstandard @htmlstandard]

* The [https://github.com/whatwg/html/commits/master GitHub commits log]

* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client’s diff tools to compare revisions and see what has been changed.

* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/

=== What are the various versions of the HTML spec? ===

The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.

The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.

The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.

=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===

Yes! [https://developers.whatwg.org/ developers.whatwg.org]

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:

* http://diveintohtml5.info/
* http://caniuse.com/
* http://html5doctor.com/
* https://developer.mozilla.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!

=== When will HTML5 be finished? ===

The WHATWG is now using a Living Standard development model, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

=== What's this I hear about 2022? ===

Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than the WHATWG is aiming for. We now look for two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

=== What about Microsoft and Internet Explorer? ===

Microsoft started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.

HTML is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]] or another ''mini-header'' element.

Also see ''HTML feature proposals'' below.

== HTML syntax issues ==

=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What is the DOCTYPE for modern HTML documents? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

Fundamentally, this is an XML issue, and is not specific to XHTML.

=== How are documents from HTML4 and earlier versions parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [https://validator.whatwg.org/ HTML validator] that follows the latest specification.

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.

The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].

A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does this new HTML spec legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML feature proposals ==

=== HTML should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML should support list headers! ===

You can give a header to a list using the <figure> and <figcaption> elements:

<pre>
<figure>
<figcaption>Apples</figcaption>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML should group <dt>s and <dd>s together in <di>s! ===

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

There are multiple problems with adding something like <di>:

* It would require parsing changes. These are relatively expensive.
* It would have a poor backwards-compatibility story until the parsers were all updated.
* It would have a poor backwards-compatibility story with legacy code that handles <dl>s, since they're not expecting <di>s.

The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements.

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== Where's the harm in adding— ===

Every feature we add to the Web platform has a cost:

* Implementation: someone has to write code for it in each browser
* Testing: someone has to write the tests to check the features is working
* QA: someone has to regularly run the tests to make sure the feature doesn't regress
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain
* Spec writing: someone has to write the spec for the feature and ensure it's maintained
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.

On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)

=== Which group has authority in the event of a dispute? ===

The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.

=== Isn't it bad that the specs have forked? ===

Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.

The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [https://html.spec.whatwg.org/multipage/introduction.html#history0 The history section in the HTML standard itself]

== Using HTML ==

=== Do you have any hints on how to use <section> and <article> and so on? ===

Some hopefully helpful hints:

* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a <section>/<article>/<aside>/<nav>, and if it's not in the table of contents and doesn't have an <h1>, it should probably not be a <section>/<article>/<aside>/<nav>.
* You can still use <div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.
* Generally, <section>s should start with an <h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an <h1> would be inappropriate, you probably want <div> rather than <section>.
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using <article>, and each comment could be big enough that it has separate <section>s, and so on.

== Other specifications ==

=== What ever happened to...? ===

The Web Forms 2.0 specification was folded into what is now the HTML specification.

The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.

The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.

== Mailing List ==

=== +1 ===

Please note that content-free agreement (such as +1s) have no effect on
the WHATWG list and are therefore discouraged. Editors of specs discussed
in the WHATWG only consider the quality of the arguments presented, and
not the volume of agreement.

You should therefore only post to the list if you have a substantive new point
to make, for example if you have seen a flaw in an argument presented so far,
or have a new idea to contribute, or have some information that has not yet
been brought to the table.

=== Making Outlook quote email messages properly ===
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.

=== Should I top-post or reply inline? ===

'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous emails in your replies.'''

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your email makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your email backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post emails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write email.

Ian wrote:
> Is this a good way to write email?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

FAQ

2016-04-16T06:42:51Z

Annevk: /* What is the WHATWG working on? */ add Fetch

== The WHATWG ==

=== What is the WHATWG? ===

The Web Hypertext Application Technology Working Group (WHATWG) is a growing community of people interested in evolving the Web. It focuses primarily on the development of HTML and APIs needed for Web applications.

The WHATWG was founded by individuals of Apple, the Mozilla Foundation, and Opera Software in 2004, after a W3C workshop. Apple, Mozilla and Opera were becoming increasingly concerned about the W3C’s direction with XHTML, lack of interest in HTML and apparent disregard for the needs of real-world authors. So, in response, these organisations set out with a mission to address these concerns and the Web Hypertext Application Technology Working Group was born.

=== What is the WHATWG working on? ===

The WHATWG's main focus is Web standards, specifically:

* [https://html.spec.whatwg.org/ HTML], which also includes Web Workers, Web Storage, the Web Sockets API, Server-Sent Events, Microdata, and the 2D Canvas.
* [https://fetch.spec.whatwg.org/ Fetch], including the <code>fetch()</code> API
* [https://dom.spec.whatwg.org/ DOM], including DOM Events, DOM range, and mutation observers
* [https://url.spec.whatwg.org/ URLs], including an API for URLs

...and [https://whatwg.org/specs a number of other specs].

=== How can I get involved? ===

There are lots of ways you can get involved, take a look and see ''[[What you can do]]''!

[https://www.youtube.com/watch?v=hneN6aW-d9w This video from Domenic Denicola] is a good introduction to working with standards bodies.

=== Is participation free? ===

Yes, everyone can contribute. There are no memberships fees involved, it's an open process. You may easily [https://github.com/whatwg participate on GitHub] or subscribe to the [https://whatwg.org/mailing-list WHATWG mailing lists]. There are no meetings, since meetings prevent people with limited time or money from participating.

=== Is there a Code of Conduct? ===

Yes, see [[Code of Conduct]]. Please read it and respect it.

== The WHATWG Process ==

=== How does the WHATWG work? ===

People [https://github.com/whatwg collaborate on GitHub] or send email to [https://whatwg.org/mailing-list#specs the mailing list].

Each standard has one or more editors, who are responsible for dealing with feedback for that document. Those editors read all the feedback, and, taking it into account along with research, studies, and feedback from many other sources (blogs, forums, IRC, etc.) make language design decisions intended to address everyone's needs as well as possible while keeping the languages and APIs consistent.

This continues, with people sending more feedback, until nobody is able to convince the relevant editor to change the spec any more (e.g., because two people want opposite things, and the editor has considered all the information available and decided that one of the two proposals is the better one).

For new features, or significant changes to the processing models, the relevant editor will typically describe the intended changes in the relevant bug or mailing list thread to give people a chance to point out problems with it before the spec is updated. Implementors, especially, are urged to indicate on such threads whether they approve of the suggested changes or new feature, so that we can avoid the spec containing material which implementors are later found to disagree with.

This is not a consensus-based approach — there's no guarantee that everyone will be happy! There is also no voting. There is a small oversight committee (known historically as the "WHATWG members", from the name that the original [https://whatwg.org/charter charter] used, though that terminology is misleading) who have the authority to override or replace editors if they start making bad decisions, but so far that has never happened in over ten years. This committee has a private mailing list, but it receives very few messages, usually going years with no emails at all. Discussions on that list are summarized and described on the public list, to make sure everyone is kept up to date.

=== What happens with WHATWG mailing list discussions? ===

On the WHATWG list, the burden is an the spec editors to evaluate the various positions that have been put forward in a discussion, and figure out which one is strongest (or find another position that strikes a better balance between all of them).

The purpose of debate on the WHATWG list therefore isn't to convince everyone; it is to put forward the arguments that exist, so that the
relevant editor can make a well-informed decision. As a corollary: If some points are made, rebutted, and not further defended, then maybe the person making the arguments is hoping that the relevant editor will consider the rebuttals weak, or thinks that the argument they have presented is strong despite the rebuttals. If you find someone is not making good arguments, or is ignoring your arguments, your best bet is to stop responding. Repeating previously-stated arguments doesn't help, since the editors will see all the arguments when they look at the thread. Similarly, as soon as threads start being meta-threads about people's argumentation behaviour, we stop making any kind of
useful progress, since that isn't input that can help the decision-making process later.

=== How should tool developers, screen reader developers, browser vendors, search engine vendors, and other implementors interact with the WHATWG? ===

Feedback on a feature should be sent to whatwg@whatwg.org (but you have to [https://whatwg.org/mailing-list#specs join the mailing list] first), or the editor of the [https://whatwg.org/specs/ relevant spec]. All feedback is supposed to receive a reply in due course.

'''If you want feedback to be dealt with faster than "eventually", e.g., because you are about to work on that feature and need the spec to be updated to take into account all previous feedback, let the editors know''' by either emailing them, or contacting them on [[IRC]]. Requests for priority feedback handling are handled confidentially if desired so other implementers won't know that you are working on that feature.

Questions and requests for clarifications should be asked either on the mailing list or on [[IRC]], in the #whatwg channel on Freenode.

=== {{anchor|Is_there_a_process_for_removing_bad_idesa_from_the_spec.3F}}Is there a process for removing bad ideas from a specification? ===

There are several processes by which we trim weeds from the specifications.

* Occasionally, we go through every section and mark areas as being considered for removal. This happened early in 2008 with the data templates, repetition blocks, and DFN-element cross references, for example. If no feedback is received to give us strong reasons to keep such features, then they eventually are removed altogether.

* Anyone can ask for a feature to be removed; such feedback is considered like all other feedback and is based on the merits of the arguments put forward. If it's been a few years and there's no implementation, and no vendor is showing any interest in eventually implementing that section; or if it's a section that browsers previously implemented but where the momentum shows that browsers are actually removing support, then it is highly likely that the request to remove the section will be honoured. (Sometimes, a warning is first placed in the spec, as with [https://html.spec.whatwg.org/multipage/webappapis.html#dialogs-implemented-using-separate-documents showModalDialog()].)

* If browsers don't widely implement a feature, or if authors don't use a feature, or if the uses of the feature are inconsequential or fundamentally wrong or damaging, then, after due consideration, features will be removed.

Removing features is a critical part of spec development.

=== {{anchor|Is_there_a_process_for_adding_new_features_to_the_spec.3F}}Is there a process for adding new features to a specification? ===

The process is rather informal, but basically boils down to this:

# Forget about the particular solution you have in mind! Solution time is later!
# Write down a description of the underlying problem you're trying to solve. What are the use cases? A use case is an actual user wanting to do something. Then list requirements for each use case. For a good example of how to do this, see http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0835.html
# Get more people involved. Send your use cases and their requirements to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask fellow Web developers about their opinions (but remind them of step 1 above). Adjust the list of use cases and requirements as appropriate. Say which use cases are important and which are just nice to have.
# Optionally, your work is done at this point. If you have done a good job of the above steps and convinced other people that your use case is an important one to solve, they can do the remaining steps. (On the flip side, if nobody else cares about the use case, chances are solutions for it will not succeed despite being awesome.)
# Research existing solutions. Come up with new solutions. Try to keep the solutions as simple as possible, maybe only addressing the important use cases and leaving the nice to have use cases for later (when there's implementation experience). Send this list of solutions, old and new, again to [https://whatwg.org/mailing-list#specs whatwg@whatwg.org]. Ask browser vendors for feedback. Maybe some particular solutions don't fit with the browser's architecture, optimizations, etc., and just are not going to be implemented no matter how much you like them. Strike those solutions and don't grieve about the loss!
# Evaluate how well each of the remaining solutions address each use case and how well they meet the requirements. This step should show which solution is the technically best fit (might turn out to be someone else's solution).
# Ask the spec's editor to put that solution in the spec. Likely your text won't be taken verbatim but will be written in a style that is more suitable for implementors or better hooks in to the rest of the spec, etc.
# Ask browser vendors to implement the newly specified solution, even if it's just an experimental implementation. This implementation experience usually means that new problems are found with the solution that need to be addressed, or that a different solution is actually better.
# Write a test suite for the feature to see if the implementations match the spec. This usually highlights bugs in the implementations and also bugs in the spec.
# Participate in subsequent design discussions. When there are two or more mature implementations, it may be time to extend the feature to address the nice to have use cases (but this whole process should be repeated even for such extensions).

If the idea survives the above design process, the spec will be eventually updated to reflect the new design. Implementations will then be updated to reflect the new design (if they aren't, that indicates the new design is not good, and it will be reworked or removed). The spec will be updated to fix the many problems discovered by authors and implementors, over a period of several years, as more authors and implementors are exposed to the design. Eventually, a number of provably interoperable implementations are deployed. At this point development of the feature is somewhat frozen.

Writing a comprehensive test suite is also an important step, which can even start before implementations start being written to the spec. We don't yet have a good story with respect to test suites, sadly. If you want to help us out, let the mailing list know! Be aware, though, it's a lot of work.

=== Should I send new proposed text when I have a suggestion? ===

Please do not suggest new text, instead, say what is wrong with the current text. Just proposing new text makes it impossible for the editor to determine if the problem is endemic (requiring more changes than you realise), or whether what the editor thinks of as mistakes in the new proposed text are intentional or not (and should be fixed or not), or whether stylistic differences are intentional or not, etc.

=== What does "Living Standard" mean? ===

The WHATWG specifications are described as Living Standards. This means that they are standards that are continuously updated as they receive feedback, either from Web designers, browser vendors, tool vendors, or indeed any other interested party. It also means that new features get added to them over time, at a rate intended to keep the specifications a little ahead of the implementations but not so far ahead that the implementations give up.

Despite the continuous maintenance, or maybe we should say ''as part'' of the continuing maintenance, a significant effort is placed on getting the specifications and the implementations to converge — the parts of the specification that are mature and stable are not changed willy nilly. Maintenance means that the days where the specifications are brought down from the mountain and remain forever locked, even if it turns out that all the browsers do something else, or even if it turns out that the specification left some detail out and the browsers all disagree on how to implement it, are gone. Instead, we now make sure to update the specifications to be detailed enough that all the implementations (not just browsers, of course) can do the same thing. Instead of ignoring what the browsers do, we fix the spec to match what the browsers do. Instead of leaving the specification ambiguous, we fix the the specification to define how things work.

=== Does that mean the specifications can change at any time? ===

The specifications do not change arbitrarily: we are extremely careful! As parts of a specification mature, and implementations ship, the spec cannot be changed in backwards-incompatible ways (because the implementors would never agree to break compatibility unless for security reasons). The specifications are never complete, since the Web is continuously evolving. The last time HTML was described as "complete" was after HTML4, when development stopped for several years, leading to stagnation. (If the Web is replaced by something better and dies, the HTML spec will die with it.)

=== What's the patent story for WHATWG standards? ===

The WHATWG operates as a W3C Community Group and thus uses the W3C Community Group patent policies.
So far we have published one FSA with [http://www.w3.org/community/whatwg/spec/82/commitments patent commitments] from Google, Mozilla, and others covering the URL standard.
[https://blog.whatwg.org/make-patent-commitments You can make patent commitments too!]
Some of our specifications have also been forked and republished by the W3C with patent commitments from certain companies.

== HTML ==

=== What is HTML? ===

[https://html.spec.whatwg.org/multipage/ HTML] is one of the standards being worked on by the WHATWG community. It is a new version of HTML4, XHTML1, and DOM Level 2 HTML addressing many of the issues of those specifications while at the same time enhancing (X)HTML to more adequately address Web applications. Besides defining a markup language that can be written in both HTML and XML (XHTML) it also defines many APIs that form the basis of the Web architecture. Some of these APIs were known as "DOM Level 0" and were never documented before, yet are extremely important for browser vendors to support existing Web content and for authors to be able to build Web applications.

=== What is HTML5? ===

Going forward, the WHATWG is just working on "HTML", without worrying about version numbers. When people talk about HTML5 in the context of the WHATWG, they usually mean just "the latest work on HTML", not necessarily a specific version. For more details, see the section called [https://html.spec.whatwg.org/multipage/introduction.html#is-this-html5? "Is this HTML5?"] in the specification.

=== How do I validate my pages? ===

Use a [https://validator.whatwg.org/ validator].

=== What parts of the specification are stable? ===

The whole specification is more or less stable except where there are big messages pointing out some unresolved issue. (These are pretty rare.) There are some parts of the spec that describe new technology that has not yet been implemented, but at this point these additions are only added after the design itself is pretty stable.

(In practice, implementations all follow the latest specification drafts anyway, not so-called "finished" snapshots. The problem with following a snapshot is that you end up following something that is ''known to be wrong''. That's obviously not the way to get interoperability! This has in fact been a real problem at the W3C, where mistakes are found and fixed in the editors' drafts of specifications, but implementors who aren't fully engaged in the process go and implement obsolete snapshots instead, including those bugs, without realising the problems, and resulting in differences between the browsers.)

=== Will future browsers have any idea what older HTML documents mean? ===

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles ''all previous versions of HTML'', as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.

=== How are developers to determine when certain parts of their pages will become invalid? ===

It shouldn't matter if and when old pages become invalid.

Validity (more often referred to as document conformance in the WHATWG) is a quality assurance tool to help authors avoid mistakes. We don't make things non-conforming (invalid) for the sake of it, we use conformance as a guide for developers to help them avoid bad practices or mistakes (like typos). So there's not really any need to worry about whether old pages are conforming or not, it's only helpful when you're writing a new page, and it's always most helpful to have the latest advice. It wouldn't be useful to check for compliance against last week's rules, for instance. After all, we fixed mistakes in those rules this week! For more details, see [https://html.spec.whatwg.org/multipage/introduction.html#conformance-requirements-for-authors part of the introduction] of the specification.

=== How can I keep track of changes to the spec? ===

There are a number of ways to track changes to the spec:

* The Twitter feed: [https://twitter.com/htmlstandard @htmlstandard]

* The [https://github.com/whatwg/html/commits/master GitHub commits log]

* The specification is available in the [https://github.com/whatwg/html/ Git repository]. You may use any Git client to check out the latest version and use your client’s diff tools to compare revisions and see what has been changed.

* At a broader level, Anne and Simon once wrote a document that gave a high-level overview of changes to HTML over the last decade or so: https://html-differences.whatwg.org/

=== What are the various versions of the HTML spec? ===

The HTML Standard is available in two forms: [https://html.spec.whatwg.org/ single-page] (''very large'') and '''[https://html.spec.whatwg.org/multipage/ multi-page]'''.

The WHATWG [https://whatwg.org/specs/ also works on other standards], such as the DOM, URL, and XMLHttpRequest standards.

The W3C publishes some forked versions of these specifications. We have requested that they stop publishing these but they have refused. They copy most of our fixes into their forks, but their forks are usually weeks to months behind. They also make intentional changes, and sometimes even unintentional changes, to their versions. We highly recommend not paying any attention to the W3C forks of WHATWG standards.

=== Are there versions of the HTML specification aimed specifically at authors/implementors? ===

Yes! [https://developers.whatwg.org/ developers.whatwg.org]

=== When will we be able to start using these new features? ===

You can use some of them now. Others might take a few more years to get widely implemented. Here are some sites to help you work out what you can use:

* http://diveintohtml5.info/
* http://caniuse.com/
* http://html5doctor.com/
* https://developer.mozilla.org/

If you know of any more (or if you have some yourself) then add them to the list! If there are some on the list that aren't very useful compared to the rest, then remove them!

=== When will HTML5 be finished? ===

The WHATWG is now using a Living Standard development model, so this question is no longer really pertinent. See above, under "[[FAQ#What_is_HTML.3F|What is HTML5?]]". The real question is, when can you use new features? For an answer to 'that' question, see "[[FAQ#When_will_we_be_able_to_start_using_these_new_features.3F|When will we be able to start using these new features?]]".

=== What's this I hear about 2022? ===

Before the WHATWG transitioned to an unversioned model for HTML, when we were still working on HTML5 and still thought in terms of snapshot drafts reaching milestones as a whole rather than on a per-section basis, the editor estimated that we'd reach Last Call in October 2009, Candidate Recommendation in the year 2012, and Recommendation in the year 2022 or later. This would be approximately 18-20 years of development, since beginning in mid-2004, which is on par with the amount of work that other specs of similar size and similar maturity receive to get to the same level of quality. For instance, it's in line with the timeline of CSS2/2.1. Compared to HTML4's timetable it may seem long, but consider: work on HTML4 started in the mid 90s, and HTML4 ''still'', more than ten years later, hadn't reached the level that we want to reach with HTML now. There was no real test suite, there are many parts of the HTML4 spec that are lacking real implementations, there are big parts of HTML4 that aren't interoperable, and the HTML4 spec has hundreds if not thousands of known errors that haven't been fixed. When HTML4 came out, REC meant something much less exciting than the WHATWG is aiming for. We now look for two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long.

Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

=== What about Microsoft and Internet Explorer? ===

Microsoft started implementing new parts of the contemporary HTML standard in IE8 and has been adding more to IE since.

HTML is being developed with compatibility with existing browsers in mind, though (including IE). Support for many features can be simulated using JavaScript.

=== Is design rationale documented? ===

Sort of. Often the documentation can be found in the mailing list or IRC channel archives. Sometimes an issue was raised formally, and resolution is recorded in the issue tracker. Sometimes, there is an explanation in the specification, but doing that everywhere would make the specification huge.

For a few cases that someone did take the time document, the information can be found at the following locations:

* [[Rationale]] — a page that documents some reasons behind decisions in the spec, originally written and maintained by Variable. If anyone wants to help him out, try to grab someone on [[IRC]] (e.g. Hixie), we're always looking for more contributors and this is a good place to start.
* [[Why no namespaces]]
* [[Why no script implements]]
* [[Why not reuse legend]] or another ''mini-header'' element.

Also see ''HTML feature proposals'' below.

== HTML syntax issues ==

=== Will HTML finally put an end to the XHTML as <code>text/html</code> debate? ===

Yes. Unlike HTML4 and XHTML1, the choice of HTML or XHTML is solely dependent upon the choice of the media type, rather than the DOCTYPE. See [[HTML vs. XHTML]]''

=== What is the DOCTYPE for modern HTML documents? ===

In HTML:

<code><!DOCTYPE html></code>

In XHTML: no DOCTYPE is required and its use is generally unnecessary. However, you may use one if you want (see the following question). Note that the above is well-formed XML and so it may also appear in XHTML documents.

For compatibility with legacy producers designed for outputting HTML, but which are unable to easily output the above DOCTYPE, this alternative legacy-compat version may be used instead.

<code><!DOCTYPE html SYSTEM "about:legacy-compat"></code>

Note that this is '''not''' intended for dealing with any compatibility issues with legacy browsers. It is meant for legacy authoring tools only.

Excluding the string <code>"about:legacy-compat"</code>, the DOCTYPE is case insensitive in HTML. In XHTML, it is case sensitive and must be either of the two variants given above. For this reason, the DOCTYPEs given above are recommended to be used over other case variants, such as <code><!DOCTYPE HTML></code> or <code><!doctype html></code>.

These alternatives were chosen because they meet the following criteria:

* They trigger standards mode in all current and all relevant legacy browsers.
* They are well-formed in XML and can appear in XHTML documents.
* It is possible to output at least one of the alternatives, if not both, with extant markup generators.
* They intentionally contain no language version identifier so the DOCTYPE will remain usable for all future revisions of HTML.
* The first is short and memorable to encourage its use.
* The legacy-compat DOCTYPE is intentionally unattractive and self descriptive of purpose to discourage unnecessary use.

=== Under what conditions should a DOCTYPE be used in XHTML? ===

Generally, the use of a DOCTYPE in XHTML is unnecessary. However, there are cases where inclusion of a DOCTYPE is a reasonable thing to do:

# The document is intended to be a polyglot document that may be served as both HTML or XHTML.
# You wish to declare entity references for use within the document. Note that most browsers only read the internal subset and do not retrieve external entities. (This is not compatible with HTML, and thus not suitable for polyglot documents.)
# You wish to use a custom DTD for DTD-based validation. But take note of [http://about.validator.nu/#faq what's wrong with DTDs].

Fundamentally, this is an XML issue, and is not specific to XHTML.

=== How are documents from HTML4 and earlier versions parsed? ===

All documents with a text/html media type (that is, including those without or with an HTML 2.0, HTML 3.2, HTML4, or XHTML1 DOCTYPE) will be parsed using the same parser algorithm as defined by the HTML spec. This matches what Web browsers have done for HTML documents so far and keeps code complexity down. That in turn is good for security, maintainability, and in general keeping the amount of bugs down. The HTML syntax as now defined therefore does not require a new parser and documents with an HTML4 DOCTYPE for example will be parsed as described by the new HTML specification.

Validators are allowed to have different code paths for previous levels of HTML.

=== If there is no DTD, how can I validate my page? ===

With an [https://validator.whatwg.org/ HTML validator] that follows the latest specification.

=== What is an HTML Serialization? ===

The HTML serialization refers to the syntax of an HTML document defined in the HTML specification. The syntax is inspired by the SGML syntax from earlier versions of HTML, bits of XML (e.g. allowing a trailing slash on void elements, xmlns attributes), and reality of deployed content on the Web.

Any document whose MIME type is determined to be <code>text/html</code> is considered to be an HTML serialization and must be parsed using an HTML parser.

=== What is an XML (or XHTML) Serialization? ===

The XML Serialization refers to the syntax defined by XML 1.0 and Namespaces in XML 1.0. A resource that has an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>, is an XML document and if it uses elements in the HTML namespace, it contains XHTML. If the root element is “html” in the HTML namespace, the document is referred to as an XHTML document.

=== What MIME type does HTML use? ===

The HTML serialization ''must'' be served using the <code>text/html</code> MIME type.

The XHTML serialization ''must'' be served using an XML MIME type, such as <code>application/xhtml+xml</code> or <code>application/xml</code>. Unlike the situation as of XHTML1, the HTML specification says that XHTML must no longer be served as <code>text/html</code>.

Using the incorrect MIME type (<code>text/html</code>) for XHTML will cause the document to be parsed according to parsing requirements for HTML. In other words, it will be treated as tag soup. Ensuring the use of an XML MIME type is the only way to ensure that browsers handle the document as XML.

=== Should I close empty elements with <code>/></code> or <code>></code>? ===

Void elements in HTML (e.g. the <code>br</code>, <code>img</code> and <code>input</code> elements) do not require a trailing slash. e.g. Instead of writing <code><br /></code>, you only need to write <code><br></code>. This is the same as in HTML4. However, due to the widespread attempts to use XHTML1, there are a significant number of pages using the trailing slash. Because of this, the trailing slash syntax has been permitted on void elements in HTML in order to ease migration from XHTML1 back to HTML.

The new HTML specification also introduces the ability to embed MathML elements. On elements inside a <code>math</code> element the trailing slash works just like it does in XML. I.e. it closes the element. This is only inside that context however, it does not work for normal HTML elements.

=== If I’m careful with the syntax I use in my HTML document, can I process it with an XML parser? ===

Yes. Find guidance in [[HTML_vs._XHTML#Differences_Between_HTML_and_XHTML|HTML vs. XHTML]] and [http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html Polyglot Markup: HTML-Compatible XHTML Documents].

A word of warning though. You have to be '''really''' careful for this to work, and it's almost certainly not worth it. You'd be better off just using an HTML-to-XML parser. That way you can just use HTML normally while still using XML pipeline tools.

=== What is the namespace declaration? ===

In XHTML, you are required to specify the [http://www.w3schools.com/xml/xml_namespaces.asp namespace.]

<html xmlns="http://www.w3.org/1999/xhtml">

In HTML, the <code>xmlns</code> attribute is currently allowed on any HTML element, but only if it has the value “<code>http://www.w3.org/1999/xhtml</code>“. It doesn’t do anything at all, it is merely allowed to ease migration from XHTML1. It is not actually a namespace declaration in HTML, because HTML doesn’t yet support namespaces. See the question [[FAQ#Will_there_be_support_for_namespaces_in_HTML.3F|will there be support for namespaces in HTML]].

=== Will there be support for namespaces in HTML? ===

HTML is being defined in terms of the DOM and during parsing of a text/html all HTML elements will be automatically put in the HTML namespace, <code>http://www.w3.org/1999/xhtml</code>. However, unlike the XHTML serialization, there is no real namespace syntax available in the HTML serialization (see previous question). In other words, you do not need to declare the namespace in your HTML markup, as you do in XHTML. However, you are permitted to put an <code>xmlns</code> attribute on each HTML element as long as the namespace is <code>http://www.w3.org/1999/xhtml</code>.

In addition, the HTML syntax provides for a way to embed elements from MathML and SVG. Elements placed inside the container element <code>math</code> or <code>svg</code> will automatically be put in the MathML namespace or the SVG namespace, respectively, by the parser. Namespace syntax is not required, but again an <code>xmlns</code> attribute is allowed if its value is the right namespace.

In conclusion, while HTML does not allow the XML namespace syntax, there is a way to embed MathML and SVG and the xmlns attribute can be used on any element under the given constraints, in a way that is reasonably compatible on the DOM level.

=== How do I specify the character encoding? ===

For HTML, it is strongly recommended that you specify the encoding using the HTTP <code>Content-Type</code> header. If you are unable to [http://www.w3.org/International/O-HTTP-charset configure your server] to send the correct headers, then you may use the <code>meta</code> element:

<meta charset="UTF-8">

The following restrictions apply to character encoding declarations:

* The character encoding name given must be the name of the character encoding used to serialize the file.
* The value must be a [http://www.iana.org/assignments/character-sets valid character encoding name], and must be the preferred name for that encoding.
* The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
* The <code>meta</code> element used for this purpose must occur within the first 512 bytes of the file. It is considered good practice for this to be the first child of the <code>head</code> element so that it is as close to the beginning of the file as possible.

Note that this <code>meta</code> element is different from HTML 4, though it is compatible with many browsers because of the way encoding detection has been implemented.

For polyglot documents, which may be served as either HTML or XHTML, you may also include that in XHTML documents, but only if the encoding is "UTF-8".

To ease transition from HTML4 to the latest HTML specification, although the former is the recommended syntax, you may also use the following. (This does not apply to XHTML or polyglot documents)

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

In XHTML, XML rules for determining the character encoding apply. The meta element is never used for determining the encoding of an XHTML document (although it may appear in UTF-8 encoded XHTML documents). You should use either the HTTP <code>Content-Type</code> header or the XML declaration to specify the encoding.

<?xml version="1.0" encoding="UTF-8"?>

Otherwise, you must use the default of <code>UTF-8</code> or <code>UTF-16</code>. It is recommended that you use <code>UTF-8</code>.

=== What are the differences between HTML and XHTML? ===

See the list of [[HTML vs. XHTML#Differences_Between_HTML_and_XHTML|differences between HTML and XHTML]] in the wiki.

=== What are best practices to be compatible with HTML DOM and XHTML DOM? ===

Though the intent is that HTML and XHTML can both produce identical DOMs, there still are some differences between working with an HTML DOM and an XHTML one.

Case sensitivity :
* Whenever possible, avoid testing Element.tagName and Node.nodeName (or do toLowerCase() before testing).
Namespaces:
* Use the namespace-aware version for creating elements: Document.createElementNS(ns, elementName)

=== Why does this new HTML spec legitimise tag soup? ===

Actually it doesn’t. This is a misconception that comes from the confusion between conformance requirements for documents, and the requirements for user agents.

Due to the fundamental design principle of supporting existing content, the spec must define how to handle all HTML, regardless of whether documents are conforming or not. Therefore, the spec defines (or will define) precisely how to handle and recover from erroneous markup, much of which would be considered tag soup.

For example, the spec defines algorithms for dealing with syntax errors such as incorrectly nested tags, which will ensure that a well structured DOM tree can be produced.

Defining that is essential for one day achieving interoperability between browsers and reducing the dependence upon reverse engineering each other.

However, the conformance requirements for authors are defined separately from the processing requirements. Just because browsers are required to handle erroneous content, it does not make such markup conforming.

For example, user agents will be required to support the marquee element, but authors must not use the marquee element in conforming documents.

It is important to make the distinction between the rules that apply to user agents and the rules that apply to authors for producing conforming documents. They are completely orthogonal.

== HTML feature proposals ==

=== HTML should support <code>href</code> on any element! ===

The spec allows <a> to contain blocks. It doesn't support putting href="" on any element, though.

Supporting <code>href</code> on any element has several problems associated with it that make it difficult to support in HTML. The main reason this isn't in HTML is that browser vendors have reported that implementing it would be extremely complex. Browser vendors get to decide what they implement, and there's no point to us telling them to do something they aren't going to do. In addition:

* It isn’t backwards compatible with existing browsers.
* It adds no new functionality that can’t already be achieved using the <code>a</code> element and a little script.
* It doesn’t make sense for all elements, such as interactive elements like <code>input</code> and <code>button</code>, where the use of href would interfere with their normal function.

The only advantage it seems to add is that it reduces typing for authors in some cases, but that is not a strong enough reason to support it in light of the other reasons.

Wrapping <a> elements around blocks solves most use cases. It doesn't handle making rows in tables into links, though; for those just do something like this instead:
<pre>
<tr onclick="location = this.getElementsByTagName('a')[0]"> ... </tr>
</pre>

=== HTML should support list headers! ===

You can give a header to a list using the <figure> and <figcaption> elements:

<pre>
<figure>
<figcaption>Apples</figcaption>
<ul>
<li>Granny Smith</li>
<li>Evil Apple of Knowledge</li>
<li>Apple, Inc</li>
</ul>
</figure>
</pre>

You can also label a group of lists using a definition list:

<pre>
<dl>
<dt>Dry:</dt>
<dd>
<ul>
<li>1c flour</li>
<li>1/4c sugar</li>
<li>1tsp baking soda</li>
</ul>
</dd>
<dt>Wet:</dt>
<dd>
<ul>
<li>1 egg </li>
<li>1/2c milk</li>
<li>1tsp vanilla extract</li>
</ul>
</dd>
</dl>
</pre>

These techniques are preferred over adding an <lh> element as proposed in the old HTML3 draft, mostly because of thorny issues with parsing near <li> elements.

=== HTML should support a way for anyone to invent new elements! ===

There are actually quite a number of ways for people to invent their own extensions to HTML:

* Authors can use the ''class'' attribute to extend elements, effectively creating their own elements, while using the most applicable existing "real" HTML element, so that browsers and other tools that don't know of the extension can still support it somewhat well. This is the tack used by Microformats, for example.
* Authors can include data for scripts to process using the ''data-*=""'' attributes. These are guaranteed to never be touched by browsers, and allow scripts to include data on HTML elements that scripts can then look for and process.
* Authors can use the ''<meta name="" content="">'' mechanism to include page-wide metadata. Names should be registered on the wiki's [[MetaExtensions]] page.
* Authors can use the ''rel=""'' mechanism to annotate links with specific meanings. This is also used by Microformats. Names should be registered on the wiki's [[RelExtensions]] page.
* Authors can embed raw data using the ''<script type="">'' mechanism with a custom type, for further handling by a script.
* Authors can create plugins and invoke them using the ''<embed>'' element. This is how Flash works.
* Authors can extend APIs using the JS prototyping mechanism. This is widely used by script libraries, for instance.
* Authors can use the microdata feature (the item="" and itemprop="" attributes) to embed nested name-value pairs of data to be shared with other applications and sites.
* Authors can propose new elements and attributes to the working group and, if the wider community agrees that they are worth the effort, they are added to the language. (If an addition is urgent, please let us know when proposing it, and we will try to address it quickly.)

There is currently no mechanism for introducing new proprietary features in HTML documents (i.e. for introducing new elements and attributes) without discussing the extension with user agent vendors and the wider Web community. This is intentional; we don't want user agents inventing their own proprietary elements and attributes like in the "bad old days" without working with interested parties to make sure their feature is well designed.

We request that people not invent new elements and attributes to add to HTML without first contacting the working group and getting a proposal discussed with interested parties.

=== HTML should group <dt>s and <dd>s together in <di>s! ===

This is a styling problem and should be fixed in CSS. There's no reason to add a grouping element to HTML, as the semantics are already unambiguous.

There are multiple problems with adding something like <di>:

* It would require parsing changes. These are relatively expensive.
* It would have a poor backwards-compatibility story until the parsers were all updated.
* It would have a poor backwards-compatibility story with legacy code that handles <dl>s, since they're not expecting <di>s.

The cost just doesn't seem worth it, given that a CSS solution would also solve a bunch of other problems (like styling implied sections).

=== Why are some presentational elements like <b>, <i> and <small> still included? ===

The inclusion of these elements is a largely pragmatic decision based upon their widespread usage, and their usefulness for use cases which are not covered by more specific elements.

While there are a number of common use cases for italics which are covered by more specific elements, such as emphasis (em), citations (cite), definitions (dfn) and variables (var), there are many other use cases which are not covered well by these elements. For example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Similarly, although a number of common use cases for bold text are also covered by more specific elements such as strong emphasis (strong), headings (h1-h6) or table headers (th); there are others which are not, such as key words in a document abstract or product names in a review.

Some people argue that in such cases, the span element should be used with an appropriate class name and associated stylesheet. However, the b and i elements provide for a reasonable fallback styling in environments that don't support stylesheets or which do not render visually, such as screen readers, and they also provide some indication that the text is somehow distinct from its surrounding content.

In essence, they convey distinct, though non-specific, semantics, which are to be determined by the reader in the context of their use. In other words, although they don’t convey specific semantics by themselves, they indicate that that the content is somehow distinct from its surroundings and leaves the interpretation of the semantics up to the reader.

This is further explained in the article <cite>[http://lachy.id.au/log/2007/05/b-and-i The <b> and <i> Elements]</cite>

Similarly, the small element is defined for content that is commonly typographically rendered in small print, and which often referred to as fine print. This could include copyright statements, disclaimers and other legal text commonly found at the end of a document.

==== But they are PRESENTATIONAL! ====

The problem with elements like <font> isn't that they are ''presentational'' per se, it's that they are media-dependent (they apply to visual browsers but not to speech browsers). While <b>, <i> and <small> historically have been presentational, they are defined in a media-independent manner in HTML5. For example, <small> corresponds to the really quickly spoken part at the end of radio advertisements.

=== The <cite> element should allow names of people to be marked up ===

From what some have seen, <cite> is almost always used to mean "italics". More careful authors have used the element to mark up names and titles, and some people have gone out of their way to only mark up citations.

So, we can't really decide what the element should be based on past practice, like we usually do.

This leaves the question of what is the most useful use we can put the element to, if we keep it. The conclusion so far has been that the most useful use for <cite> is as an element to allow typographic control over titles, since those are often made italics, and that semantic is roughly close to what it meant in previous versions, and happens to match at least one of the common uses for the element. Generally, however, names and titles aren't typeset the same way, so making the element apply to both would lead to confusing typography.

There are already many ways of marking up names already (e.g. the [http://microformats.org/wiki/hcard hCard microformat], the microdata vCard vocabulary, <span> and class names, etc), if you really need it.

=== Where's the harm in adding— ===

Every feature we add to the Web platform has a cost:

* Implementation: someone has to write code for it in each browser
* Testing: someone has to write the tests to check the features is working
* QA: someone has to regularly run the tests to make sure the feature doesn't regress
* Code maintenance: when browser vendors refactor code, they have to refactor more code if there's more features
* Tutorials: people who write tutorials have to include the feature, or handle feedback asking for them to do so
* Cognitive load: authors learning the platform have more documentation to wade through even if they don't care about the feature
* [http://www.nngroup.com/articles/stagnating-expertise/ Extra features discourage exploration]: Having more features means less overall feature usage.
* Page maintenance: authors have to know how to maintain the feature if other people have used it in pages they now maintain
* Spec writing: someone has to write the spec for the feature and ensure it's maintained
* Bug fixing: when bugs are found in the spec or implementations, someone has to figure out a fix, implement it, test it, ship it, tests have to be fixed, documentation has to be updated, etc
* Code size: each feature increases the size of browsers (both on-disk binaries and in-memory resident size)

== WHATWG and the W3C HTML WG ==

=== Are there plans to merge the groups? ===

No. The two groups have different goals. The WHATWG spec is intended to describe what browsers should aim for, introducing new features and describing reality in as much, and as accurate, detail as possible. The W3C spec is intended to follow the W3C process to REC.

On the WHATWG side, the editors read the feedback sent to both groups and take all input into account — and indeed there are far more places where input on HTML is sent than just these two mailing lists (e.g. blogs, www-html@w3.org, forums, direct mail, meetings, etc). (In particular, the editors do not look at the source of technical arguments when attempting to determine what path to take on an issue or other.)

=== Which group has authority in the event of a dispute? ===

The two groups have different specs, so each has authority over its spec. The specs can and have diverged on some topics; unfortunately, these differences are not documented anywhere.

=== Isn't it bad that the specs have forked? ===

Yes. The WHATWG originally committed to remaining consistent with the W3C spec unless the W3C working group showed a lapse in judgement. When that (in Hixie's opinion) occurred, there was little choice left but to let the specs diverge.

The plan to get the specs to converge again, such as it is, is to just do a better job with the WHATWG spec, such that it becomes the logical and obvious choice for anyone wanting to figure out which spec they should use.

=== What is the history of HTML? ===

Here are some documents that detail the history of HTML:
* [http://esw.w3.org/topic/HTML/history HTML's timeline on the ESW wiki]
* [https://html.spec.whatwg.org/multipage/introduction.html#history0 The history section in the HTML standard itself]

== Using HTML ==

=== Do you have any hints on how to use <section> and <article> and so on? ===

Some hopefully helpful hints:

* One way to look at it is how would you draw the page outline/table-of-contents? Each entry in the table of contents should be a <section>/<article>/<aside>/<nav>, and if it's not in the table of contents and doesn't have an <h1>, it should probably not be a <section>/<article>/<aside>/<nav>.
* You can still use <div>. It's the right element if you need a styling hook because CSS can't give you enough to do what you want.
* Generally, <section>s should start with an <h1> and the section title. It's not a hard-and-fast rule, but if you find yourself in a situation where an <h1> would be inappropriate, you probably want <div> rather than <section>.
* Sections can contain Articles, and vice versa. e.g. you can have a section that is news, a section that is editorials, a section that is sports, each with many articles, and each of those can have subsections, and each section can have comments, which are marked up using <article>, and each comment could be big enough that it has separate <section>s, and so on.

== Other specifications ==

=== What ever happened to...? ===

The Web Forms 2.0 specification was folded into what is now the HTML specification.

The Web Controls 1.0 specification was overtaken by events and has been abandoned. Its problem space is mostly handled by ARIA and Web Components now.

The DOM Parsing specification was abandoned by the WHATWG because the W3C was doing a better job of maintaining that specification. We do not want to cause confusion in the market place, so when another organisation writes a specification that covers the same technology as one of ours, we only continue to publish it if our version is technically superior.

== Mailing List ==

=== +1 ===

Please note that content-free agreement (such as +1s) have no effect on
the WHATWG list and are therefore discouraged. Editors of specs discussed
in the WHATWG only consider the quality of the arguments presented, and
not the volume of agreement.

You should therefore only post to the list if you have a substantive new point
to make, for example if you have seen a flaw in an argument presented so far,
or have a new idea to contribute, or have some information that has not yet
been brought to the table.

=== Making Outlook quote email messages properly ===
If you use Outlook or Outlook Express, you can use either [http://home.in.tum.de/~jain/software/outlook-quotefix/ Outlook-QuoteFix] or [http://home.in.tum.de/~jain/software/oe-quotefix/ OE-QuoteFix]. These plugins fix several of Outlook's problems with sending properly formatted emails.

=== Should I top-post or reply inline? ===

'''Please reply inline or make the reply self-contained, and trim extraneous quotes from previous emails in your replies.'''

Basically, please remove anything after the last line you have written, so that people don't have to scroll down to find out what else you wrote, and make sure that your email makes sense on its own, as it will probably be read out of context years later.

That is, you should reply like this:

<pre>
Ian wrote:
> What do you want?

I want cats!

> When do you want it?

Now!
</pre>

You should definitely not reply like this (because this requires people to read your email backwards):

<pre class="error" >
No

Ian wrote:
> Is this a good example of how to post emails?
</pre>

You should also not reply like this (because this leaves people to wonder if there is any text lower down that you have written):

<pre class="error" >
This is a bad way to write email.

Ian wrote:
> Is this a good way to write email?
> Lorem ipsum foo bar baz.
> Unrelated other bits that aren't replied to.
> Yet more text
</pre>

You should also not reply like this (with no context at all), because the reader will not know what you are referring to:

<pre class="error" >
No, I think that's a bad idea. It wouldn't be good for the readers, for instance.
</pre>

Quote enough original text or provide an introduction yourself.

IRC

2016-04-12T07:09:07Z

Annevk:

The Freenode IRC network has a channel called [irc://irc.freenode.net/whatwg #whatwg] where some of the more active WHATWG community members hang out. Feel free to join us!

If you want to run a bot, let us know. If they are useful, e.g. providing logging facilities, then they are more than welcome.

== Logs ==

Logs for the #whatwg channel can be found here:

* http://logbot.glob.com.au/?c=freenode%23whatwg&s=today
* http://krijnhoetmer.nl/irc-logs/whatwg/ (not updated for the last couple of months)

== People ==

A list of regulars, sorted by nick, and their normal timezones (winter/summer).

* {{irc user|Adactio|adactio|+0000/+0100}}
* {{irc user|Annevk|annevk|.../...}}
* {{irc user|Dglazkov|dglazkov|.../...}}
* {{irc user|Domenic|Domenic|-0500/-0400}}
* {{irc user|GPHemsley|GPHemsley|-0500/-0400}}
* {{irc user|Hixie|Hixie|-0800/-0700}}
* {{irc user|EdwardOConnor|hober|-0800/-0700}}
* {{irc user|Jgraham|jgraham|.../...}}
* {{irc user|kennyluck|kennyluck|+0800/+0800}}
* {{irc user|Mathias|matjas|.../...}}
* {{irc user|Ms2ger|Ms2ger|.../...}}
* {{irc user|Mjs|othermaciej|-0800/-0700}}
* {{irc user|ShaneHudson|ShaneHudson|+0000/+0100}}
* {{irc user|Xanthir|tabatkins|-0800/-0700}}
* {{irc user|Tantek|tantek|-0800/-0700}}
* {{irc user|Yuhong|yuhong|-0800/-0700}}
* {{irc user|Wilto|Wilto|.../...}}
* {{irc user|Zcorpan|zcorpan|.../...}}

DOM XSLTProcessor

2016-02-29T08:27:33Z

Annevk: /* Issue for standardization */

== Issue for standardization ==

https://github.com/whatwg/dom/issues/181

== IDL ==

<pre>
Constructor]
interface XSLTProcessor {
void importStylesheet(Node style);
DocumentFragment transformToFragment(Node source, Document output);
Document transformToDocument(Node source);
void setParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName, any value);
any getParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName);
void removeParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName);
void clearParameters();
void reset();
};
</pre>

== MDN ==

https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor

DOM XSLTProcessor

2016-02-29T08:24:35Z

Annevk: /* IDL */

== Issue for standardization ==

...

== IDL ==

<pre>
Constructor]
interface XSLTProcessor {
void importStylesheet(Node style);
DocumentFragment transformToFragment(Node source, Document output);
Document transformToDocument(Node source);
void setParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName, any value);
any getParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName);
void removeParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName);
void clearParameters();
void reset();
};
</pre>

== MDN ==

https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor

DOM XSLTProcessor

2016-02-29T08:24:21Z

Annevk: Created page with "== Issue for standardization == ... == IDL == <pre> Constructor] interface XSLTProcessor { void importStylesheet(Node style); DocumentFragment transformToFragment(Node..."

== Issue for standardization ==

...

== IDL ==

<pre>
Constructor]
interface XSLTProcessor {
void importStylesheet(Node style);
DocumentFragment transformToFragment(Node source, Document output);
Document transformToDocument(Node source);
void setParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName, any value);
any getParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName);
void removeParameter([TreatNullAs=EmptyString] DOMString namespaceURI, DOMString localName);
void clearParameters();
void reset();
};
<pre>

== MDN ==

https://developer.mozilla.org/en-US/docs/Web/API/XSLTProcessor