Difference between revisions of "Rationale"
(Added external link to spec)
(→b, i, em, strong, and mark: Section removed -- does not provide any rationale information)
|Line 58:||Line 58:|
=== Text-level semantics ===
=== Text-level semantics ===
=== Embedded content ===
=== Embedded content ===
Revision as of 15:11, 2 February 2013
This rationale document is supplemental to the WHATWG HTML Living Standard specification. It is a work-in-progress.
- 1 General Rationale
- 2 Specific Elements
- 2.1 DOCTYPE (Document Type Declaration)
- 2.2 Sections
- 2.3 Grouping content
- 2.4 Text-level semantics
- 2.5 Embedded content
- 2.6 Forms
- 2.7 Interactive elements
- 3 HTML parsing
- 4 Rejected proposals
- 5 Other Pages
- 6 References
One Vendor, One Veto
Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such, browser vendors already have veto power—by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.. The veto isn’t a power that we grant browsers; it’s a right that they earn on their own by virtue of having users. The minimum market share for a veto is somewhere around 1%.
Using elements where scripts "work"
It isn't just about web browsers
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.
Experimenting with features
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. 
Versioning the spec
Most authors don't care about whether or not an implementation supports an entire, full specification; they just want to know "Can I use this feature in this browser?" So saying that all major implementations support much of CSS 2 to a high degree of correctness is useless for knowing if, say, the author can use display: run-in. In other words, the feature tables are what web authors would actually use in real life.
Modifying existing semantics
Some elements have different semantics than what HTML4 users would expect. Semantic markup isn't very useful if most pages use elements in a manner that conflicts with the defined semantics. For example, if a search engine treated dd as enclosing a term being defined, for the purposes of searching for definitions (or excluding defining occurrences from results), it would not find many definitions, and it would misclassify things.
DOCTYPE (Document Type Declaration)
Since HTML has moved to an unversioned model, the
DOCTYPE does not a have version number. The inclusion of a document type declaration is necessary merely for legacy browsers that will operate in quirks mode (a non-spec compliant rendering mode) if a
DOCTYPE is absent.
hgroup and other heading elements
The point of
hgroup is to hide the subtitle from the outlining algorithm.
The primary purpose of these elements is merely to help the author write self-explanatory markup that is easy to maintain and style; they are not intended to impose specific structures on authors.
Attributions and inline citations do not belong inside the
blockquote element because the specification does not consider them to be part of the block quote proper. In other words, the
blockquote element represents only the quote itself.
On the status of
image element is treated as an alternate (but invalid) name for
img. This is because some sites (around 0.2%) make this mistake. It is already treated as an image by most major browsers.
img element and alternate (
On certain types of pages adding alternate text (with the
alt attribute) is impossible (e.g., sites where the user can upload but with no mechanism to supply a description). Because of this, the
alt attribute is optional. 
A longdesc attribute is not needed 
The text area defaults to soft wrapping of the text area. The attribute @wrap can have one of the following values: soft, hard, or off.. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. 
progress (are not the same thing)
meter is not just a special case of
meter element represents a scalar measurement within a known range, such as storage quota usage, a relative popularity rating or relevance indicator. The control allows for the indication of high and low ranges, or minimum, maximum and optimal levels.
progress element, on the other hand, represents the completion progress of a task. This could be a real time indicator for background processing task (e.g. using Web Workers or a file upload).
progress elements can also be in the indeterminate state, indicating that something is in progress, but its completion progress is unknown.
The default rendering for a
meter element could look something like the following:
Whereas, the default rendering for the
progress element could look like this:
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:
See Re: <progress> draft for details.
details element is needed to provide an accessible way of reflecting a
common application widget in HTML-based applications without requiring authors
to use extensive scripting, ARIA, and platform-specific CSS to get the same
@DEFER and @ASYNC
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously). DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).
The HTML parser has the following behavior difference in quirks mode:
- A start tag whose tag name is "table"
- If the Document is not set to quirks mode, and the stack of open elements has a p element in scope, then act as if an end tag with the tag name "p" had been seen.
ignored white space before head
White space before the
<head> tag is ignored. The main reason is that, given the markup
<!DOCTYPE html> <html> <head> <title>Sample page</title> ...,
some people expect
to return the
A dedicated element for user comments
There is no dedicated element for marking up user comments, i.e., content composed by users in response to a newspaper or magazine article, blog entry, discussion topic, status update, image, video, etc. The spec suggests using nested
Several arguments have been put forth in favor adding a
comment element to the spec . Arguments and counterarguments run as follows:
Argument: Comments are not articles according to the commonly understood (dictionary) definition of “article.” Articles are relatively “long” pieces of writing, and they are not responses to what others have written. It’s clear that comments are not articles.
Counterargument: The element name “article” isn’t intended to carry the same meaning as its corresponding dictionary entry or any colloquial understanding of the term. A composition’s length and whether or not it’s authored by a site’s owner/staff or by it’s readers is completely irrelevant.
Argument: Comments are not articles according to the specification’s definition because, in general, articles are clearly not complete, self-contained, independently distributable or reusable pieces of writing. They depend on the context of what they are responding to. For example, “LOL” or “Yeah, especially when talking about your lobbyist friends!” are, on their own, unintelligible.
Counterargument: The definition of
article does not require that a piece of writing be fully intelligible on its own. The terms “complete,” “self-contained,” and “independent” are really meant to convey the idea of separateness. Comments are separate from what they are commenting on—they are not part of the piece of writing they are referring to. Therefore they can be independently distributed or reused. An example of this is the website reddit (consider, for example, http://www.reddit.com/r/bestof/, where every post is an example of a comment that was independently syndicated). It’s largely a matter of the author’s intent as to whether or not a piece of writing is something unto itself or part of a larger whole.
Argument: Comments can appear in reference to things that are not articles, such as blog posts, forum topics, social network status updates, images, videos, links, etc., which should not have to be marked up as articles just so the comments can be marked up as nested articles.
Counterargument: All the content types mentioned above are in fact articles according to the spec’s definition.
Argument: Robots and plugins can extract comments from web pages more easily if they have their own element. Comments can then be more easily syndicated, displayed, hidden, styled, etc.
Counterargument: There’s no compelling argument that a separate element would make this meaningfully easier than than nested
Argument: Comments sometimes appear in a different region of the page than the item they are referencing, hence the markup for comments should not have to be contained within the markup of the item.
Counterargument: No evidence has been put forth to suggest that this is a significant authorship issue.
A dedicated element for advertisements
There is no dedicated advertisement element (
<advert>, or the like) because it would give users a relatively easy method of hiding or otherwise disabling ads (and therefore the element would very likely end up not being used by content authors). The
aside element is probably the closest semantic fit for advertisements.
sandbox attribute on the
Various proposals have come up with the idea of being able to determine if a certain feature is available. These fail for a variety of reasons: Part of the problem is that browser vendors will be economical with the truth. Marketing people always have an over-optimistic view of the compliance of their product, and will always give themselves the benefit of the doubt in borderline cases. Also, changing the compliance statement, to remove false claims that are exposed, is likely to a very low priority for the developers. With regard to CSS feature compliance: Remember that CSS provides hints and implementations don't have to accept those hints, and hardware may sometimes prevent their being implemented. Some other reasons can be found in the footnotes.
custom HTML elements
Custom elements make it impossible for search engines, developers, and browsers to understand the semantics of a page.
- HTML Design Principles
- Why no namespaces
- Why no script implements
- Why not reuse legend or another mini-header element.
- XHTML2 versus HTML5
- <meta http-equiv=content-language>
- earlier page started with the same purpose.
- rationale for some new HTML5 elements
- WHATWG FAQ
- http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for <video> and <audio></a>
- http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto
- Email from Ian Hickson; comment in spec source
- [whatwg] several messages about the tree construction stage of HTML parsing