WHATWG Wiki - User contributions [en]

User:Michel Fortin

2015-02-08T18:57:19Z

Michel Fortin:

[https://michelf.ca/ I'm here.]

HTML vs. XHTML

2007-03-07T17:18:40Z

Michel Fortin: Undo revision 2127 by Special:Contributions/Ahneu (User talk:Ahneu)

== Differences Between HTML and XHTML ==

'''Please note that the information in here is based upon the current spec for (X)HTML5. Some of the issues technically do not apply to previous versions of HTML.'''

Although HTML and XHTML appear to have similarities in their syntax, they are significantly different in many ways.

'''Note''': As the current WHATWG document is a draft, this section will need to track to a moving target.
Differences marked @@@ are differences that could theoretically be changed without affecting
backwards compatibility.

=== MIME Types ===

* XHTML must be served with an XML MIME type, such as <code>application/xml</code> or <code>application/xhtml+xml</code>.
* HTML must be served as <code>text/html</code>.

It is the MIME type that determines what type of document you are using. If you use attempt to send XHTML as <code>text/html</code>, you are actually just using HTML, possibly with syntax errors.

Technically, according to the spec, XHTML 1.0 is allowed to be served as <code>text/html</code>. But, due to the above reason, such a document is considered to be an HTML document, not an XHTML document.

=== Parsing ===

XHTML uses XML parsing requirements. HTML uses its own which are defined much more closely to the way browsers actually handle HTML today.

* In XHTML, well-formedness errors are fatal. In HTML, error handling rules are much more graceful. Well-formedness errors, which are also syntax errors in HTML, include the following:
** Unencoded ampersands (<code>&</code> instead of <code>&amp;</code>), and less than signs (<code><</code> instead of <code>&lt;</code>) (This does not apply to <code>CDATA</code>).
** Comments containing extra pairs of hyphens or ending with a hyphen. e.g.
*** <code></code> or
*** <code></code>.
** Mismatched end tags (does not apply to elements with optional tags)
** Unclosed tags.
** Unexpected characters occuring in or before attribute names.
** Unexpected occurrence of EOF.
** Unexpected characters before the DOCTYPE name.
** Missing DOCTYPE name.
** A <code>PUBLIC</code> identifer in a <code>DOCTYPE</code> without a <code>SYSTEM</code> identifier (Note: including either of these is a syntax error in HTML5; but, in XML only the <code>SYSTEM</code> identifier is allowed to occur on its own).
** End tags with attributes.
** Unexpected end tags (in HTML, an unexpected <code></br></code> or <code></p></code> can cause the start tag to be implied before it).
* The internal subset is permitted in XML, but meaningless (and forbidden) in HTML.
** In some cases, an internal subset in HTML would end up being partly rendered inline.
* The sequence of characters "<code>]]></code>" when it does not mark the end of a <code>CDATA</code> section is a well-formedness error in XHTML, but valid in HTML.
* In XHTML: <code><![CDATA[...]]></code> is a <code>CDATA</code> section. In HTML, it's a bogus comment.
* In XHTML, <code><?foo ...?></code> is a processing instruction. In HTML, it's a bogus comment.
* In HTML, the trailing slash used for the empty element syntax is a parse error for non-void elements (see below), but is ignored in all cases.
* In HTML, the <code>script</code> and <code>style</code> elements are parsed as <code>CDATA</code>. (Note: the definition of <code>CDATA</code> differs from that in XML). In XML, they're parsed as normal elements (which means that comments are treated as <em>real</em> comments, and things that look like start tags actually are start tags).
* In HTML, the <code>title</code> and <code>textarea</code> elements are parsed as <code>RCDATA</code>. (Note: The definition of <code>RCDATA</code> differs from that in SGML and there is no <code>RCDATA</code> in XML).
* In HTML, if scripting is enabled, the <code>noscript</code> element is parsed as <code>CDATA</code>. If scripting is disabled, it's parsed as <code>PCDATA</code>. In XHTML, the element has no effect, and can't really be used to stop content from being present when script is disabled.
* In HTML, the <code>iframe</code>, <code>noembed</code> and <code>noframes</code> elements are parsed as <code>CDATA</code>. In XHTML, they are parsed as normal elements, and therefore do not stop content from being used.
* White space characters in attribute values are [http://www.w3.org/TR/REC-xml/#AVNormalize normalized] to spaces in XHTML.
* Elements with optional tags are implied in certain conditions.
* In HTML, <code>base</code>, <code>link</code>, <code>meta</code>, <code>style</code> and <code>title</code> elements with tags occurring in the body are moved inserted into the head. In XHTML, they stay where they were specified.
* In HTML, tags for certain elements, which appear out of context, are ignored. This includes <code>caption</code>, <code>col</code>, <code>colgroup</code>, <code>frame</code>, <code>frameset</code>, <code>head</code>, <code>option</code>, <code>optgroup</code>, <code>tbody</code>, <code>td</code>, <code>tfoot</code>, <code>th</code>, <code>thead</code>, <code>tr</code>.
* The <code>plaintext</code> element has a special parsing requirement in HTML. (it is, however, forbidden).
* <em>Many other special handling of edge cases and error conditions, not all of which are listed here, occur in HTML.</em>

=== Syntax ===

* In HTML, [http://blog.whatwg.org/faq/#doctype the <code>doctype</code> is required]. In XHTML, it is optional.
* In XHTML, tag names and attribute names are case sensitive. In HTML, they are case insensitive.
* In XHTML, non-empty elements require both a start and an end tag. In HTML, certain elements allow the omission of either or both:
** <code>html</code> (both)
** <code>head</code> (both)
** <code>body</code> (both)
** <code>li</code> (end tag)
** <code>dt</code> (end tag)
** <code>dd</code> (end tag)
** <code>p</code> (end tag)
** <code>colgroup</code> (both)
** <code>thead</code> (end tag)
** <code>tbody</code> (both)
** <code>tfoot</code> (end tag)
** <code>tr</code> (end tag)
** <code>td</code> (end tag)
** <code>th</code> (end tag)
* In XHTML, empty elements may use either the empty element syntax (<code><br/></code>) or have an end tag immediately follow the start tag (<code><br></br></code>). In HTML, the empty element syntax (trailing slash) is allowed on void elements, but forbidden on other elements. However, it serves no purpose whatsoever and can be omitted. End tags for void elements are forbidden.
** <code>base</code>,<code> link</code>, <code>meta</code>, <code>hr</code>, <code>br</code>, <code>img</code>, <code>embed</code>, <code>param</code>, <code>area</code>, <code>col</code> and <code>input</code>
** Note: the following are treated as void elements for the purpose in the parsing requirements, but, as they are obsolete and non-standard, the trailing slash is not permitted: <code>basefont</code>, <code>b</code><code>gsound</code>, <code>spacer</code>, <code>wbr</code>. (although, since these elements are not permitted anyway, it doesn't make much difference).
* HTML allows attribute minimisation (i.e. omitting the value), XHTML does not.
* HTML allows the use of unquoted attribute values, XHTML does not.
* XHTML allows the use of <code>CDATA</code> sections, HTML does not.
* XHTML allows the use of processing instructions, HTML does not.
* In HTML, all entity references are predefined and do not require a DTD. But because there is no DTD for XHTML5, entity references cannot be used in XHTML. (excluding the 5 predefined entities: <code>&amp;</code>, <code>&lt;</code>, <code>&gt;</code>, <code>&quot;</code> and <code>&apos;)</code>
** You may provide your own DTD for use with your own validating parser, but be aware that browsers do not use validating parsers and will not read the DTD.
* The valid set of unicode characters in XML 1.0 is limited beyond that in HTML.
* Namespace prefixes are permitted in XHTML. They are forbidden in HTML.

=== Markup ===

* The [http://blog.whatwg.org/faq/#namespace-decl namespace declaration] (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on the <code>html</code> element in HTML on the condition that is has the value <code><nowiki>"http://www.w3.org/1999/xhtml"</nowiki></code>.
** <code><nowiki><html xmlns="http://www.w3.org/1999/xhtml"></nowiki></code>
** In HTML, the xmlns attribute has absolutely no effect. It is basically a talisman. It is allowed merely to make migration to and from XHTML mildly easier. When parsed by an HTML parser, the attribute ends up in the null namespace
** In XML (with an [http://www.w3.org/TR/xml-names/ XML Namespaces]-aware parser), an xmlns attribute is part of the namespace declaration mechanism, and an element cannot actually have an xmlns attribute in the null namespace. In DOM implementations, the attribute ends up in the "<code><nowiki>http://www.w3.org/2000/xmlns/</nowiki></code>" namespace.
* XHTML allows non XHTML elements and attributes (in different namespaces) to be used, HTML does not.
* XHTML uses the <code>xml:lang</code> attribute, HTML uses <code>lang</code> instead,
* XML ID introduces <code>xml:id</code>, which could be used in XHTML. In HTML it has no effect.
* In HTML, the <code>noscript</code> element may be used. In XHTML, it is forbidden.
* HTML uses the <code>base</code> element, XHTML uses <code>xml:base</code> instead.
* In XHTML, <code>p</code> elements may contain structured inline level elements including <code>blockquote</code>, <code>dl</code>, <code>menu</code>, <code>ol</code>, <code>ul</code>, <code>pre</code> and <code>table</code>. In the HTML serialisation, due to backwards compatibility constraints, this is not possible (though it may be done through DOM manipulation).
* In XHTML, <code>table</code> elements may contain child <code>tr</code> elements. In the HTML serialisation, due to backwards compatibility constraints, this is not possible (though it may be done through DOM manipulation).

=== Character Encoding ===

* In XHTML, the XML declaration may be used to [http://blog.whatwg.org/faq/#charset specify the character encoding]. In HTML, the xml declaration is forbidden
* In HTML, the <code>meta</code> element may be used insted. The <code>http-equiv</code> attribute on the <code>meta</code> element is forbidden in XHTML and is ignored if included.
* The default character encoding for XHTML is, according to XML rules, <code>UTF-8</code> or <code>UTF-16</code>. If the encoding is unspecified in HTML, it should be determined through implementation specific heuristics or fallback to a default value (Note: this section of the spec is not yet finished).

=== Scripts ===

* <code>document.write()</code> and <code>document.writeln()</code> cannot be used in XHTML, they can in HTML.
* In XHTML, the use of the <code>innerHTML</code> property requires that the string be a well-formed fragment of XML.
* DOM APIs are case sensitive in XHTML and some are case insensitive in HTML. (This does not apply to elements which are not in the HTML namespace)
** Element.tagName, Node.nodeName, and Node.localName return the value in uppercase.
** Document.createElement() is case insensitive (the canonical form is lowercase).
** Element.setAttributeNode() will change the attribute name to lowercase.
** Element.setAttribute() is case insensitive (the canonical form is lowercase).
** Document.getElementsByTagName() and Element.getElementsByTagName() are case insensitive.
** Document.renameNode(). If the new namespace is the HTML namespace, then the new qualified name must be lowercased before the rename takes place.
* In HTML, Document.createElement() will create an element in the HTML namespace. In XML (including XHTML), the namespace is defined by both DOM2 and DOM3 to be null.
** In XHTML, browsers lack interoperability in this area. In Firefox, the namespace is dependent upon the MIME type. In Opera, it's dependent upon the root element and in Safari, it's always null.

=== Stylesheets ===

* Selectors, as used in CSS, match case sensitively in XHTML, but case insensitively in HTML.
* CSS requires special handling of the body element in HTML for painting backgrounds on the canvas, which do not apply to XHTML.

== Differences Between HTML 4.01 and HTML 5 ==

=== MIME Type ===

Both HTML 4.01 and HTML 5 use <code>text/html</code>.

<code>Content-Type: text/html; charset=UTF-8</code>

=== Parsing HTML ===

* HTML 2.0 to HTML 4.01 were formally based on SGML, but browsers did not implement SGML parsers. [http://www.w3.org/TR/html4/conform.html#h-4.2 4.2 SGML] and [http://www.w3.org/TR/html4/appendix/notes.html#h-B.3 B.3 SGML implementation notes], HTML 4.01. This is a non-normative section of HTML 4.01 specification. And it already makes the difference between HTML user agents and SGML user agents.
* HTML 5 is defines its own parsing requirements based on the way browsers actually handle HTML.

=== Syntax ===

* TODO

=== Markup ===

* [http://www.w3.org/TR/html4/index/elements.html List of HTML 4.01 elements]
* [http://www.w3.org/TR/html4/index/attributes.html List of HTML 4.01 attributes]
* [http://simon.html5.org/html5-elements HTML5 Elements and Attributes]

==== Obsolete Attributes ====

Some attributes that were defined in HTML4 are not included in HTML5. Here's a current list (subject to change, see the spec):

* html@version
* head@profile
* a@rev, link@rev
* a@target, area@target, base@target, form@target (is mentioned in WF2...), link@target
* a@charset, link@charset, script@charset
* table@summary
* td@headers, th@headers
* td@axis, th@axis
* param@valuetype
* object@standby
* meta@scheme
* object@archive

In addition, HTML5 has none of the presentational attributes that were in HTML4 (including those on <table>). Any attributes defined on ''elements'' that are not in HTML5 are (obviously) also not in HTML5.

==== Obsolete Elements ====

The following elements were present in HTML4 but are not defined in HTML5:

* acronym (use <abbr> instead)
* applet (use <object> instead)
* basefont
* big
* center
* dir
* font
* frame
* frameset
* isindex
* noframes
* noscript (only in XHTML)
* s
* strike
* tt
* u

=== Character Encoding ===

The character encoding can be declared using the meta element, but the syntax of the meta element has changed. In HTML 4.01 and earlier, the meta element was:

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

In HTML5, the syntax was simplified to remove the unnecessary markup, yet still remain compatible with the encoding detection implemented in most existing browsers.

<meta charset="UTF-8">

==== HTML 4 Algorithm ====

Source [http://www.w3.org/TR/html4/charset.html#h-5.2.2 5.2.2 Specifying the character encoding], HTML 4.01 Specification.

# An HTTP "charset" parameter in a "Content-Type" field.
# A META declaration with "http-equiv" set to "Content-Type" and a value set for "charset".
# The charset attribute set on an element that designates an external resource.

==== HTML 5 Algorithm ====

The exact algorithm that browsers must follow in order to [http://www.whatwg.org/specs/web-apps/current-work/#the-input0 determine the character encoding] is specified in HTML 5. The basic algorithm works as follows:

# If the transport layer specifies an encoding, use that, and abort these steps. (e.g. The HTTP Content-Type header).
# Read the first 512 bytes of the file, or at least as much as possible if less than that.
# If the file starts with a UTF-8, UTF-16 or UTF-32 BOM, then use that and abort these steps.
# Otherwise use the special algorithm to search the first 512 bytes for a meta element that declares the encoding. The algorithm is relatively lenient in what it will detect, though since it doesn't use the normal parsing algorithm, there are some restrictions.

== Differences Between DOM Level 2.0, 3.0 and the HTML 5 DOM APIs ==

'''This section might belong on a separate page.'''

* TODO (need to talk about the changes to the DOM API that HTML5 is making, compared with DOM2 and DOM3)

== Translations ==

* [http://meiert.com/de/publications/translations/whatwg.org/html-vs-xhtml/ German translation: "HTML 5 und XHTML 5 im Vergleich (WHATWG)"]

Talk:Feature Proposals

2007-01-04T22:44:13Z

Michel Fortin: /* Corner Element */

== Guidelines ==

Lachlan, I think these feature proposal guidelines are cluttering this page unnecessarily. It would be better to put them elsewhere and just create a link to the guidelines. Elsewhere could be on the Contribution Guidelines page, were you've put them initially, because feature proposals <em>are</em> contributions. --[[User:Michel Fortin|Michel Fortin]] 08:15, 16 November 2006 (PST)

: Replying to myself (again), maybe the guidelines are not needed anymore. If someone creates a proposal from the template and fills all the sections he can, others can complete the proposal if they think its valuable and are knowledgeable enough. That's why we have a wiki in the first place, isn't it? -[[User:Michel Fortin|Michel Fortin]] 08:21, 16 November 2006 (PST)

== Corner Element ==

Do we really need a <corner> element mentioned in the page? This is clearly presentational and already addressed by CSS. Same goes for <blink>. --[[User:Matthew Raymond|Matthew Raymond]] 14:46, 4 January 2007 (UTC)

: It's a bad proposal, but it's still a proposal. Maybe it should be classed in a list of rejected proposals with a short explaination of why it is rejected (mostly what you've just said above). The idea is that if someone want to propose it again by adding it on the wiki he'll see it's already there and know against what he has to argue if he wishes to pursue. --[[User:Michel Fortin|Michel Fortin]] 22:44, 4 January 2007 (UTC)

Common Subset

2006-12-09T13:43:02Z

Michel Fortin: Some corrections.

The common subset intersecting HTML5 and XHTML5 is a subset of both syntaxes meant to create . The common subset is only implicitly defined by the HTML and XHTML specification because they have many syntax elements in common. A document is said to use the common subset when it can parse correctly with both the XML parser and the HTML parser.

A document using the '''conforming''' common subset is conforming with the specification whether it is interpreted as HTML or XHTML. The conforming common subset rejects any element with are not conforming in either of the two DOM variants.

A document using the common subset can be served as HTML (text/html media type) or XHTML (with an XML media type). The media type is what the browser use to decide if it'll be parsed as HTML or XHTML and which varient of the DOM is used.

== Common Syntax ==

[TBD]

== Limitations from HTML ==

* The [http://blog.whatwg.org/faq/#doctype doctype is required] to be <code><!DOCTYPE html></code>
* Tag and attribute names must be lowercase.
* XMLish end tag tailing slash must not be used with non-void elements; they'll be ignored by the HTML parser and are invalid in HTML.
* XMLish CDATA blocks will not work.
* HTML does not allow mixing with other XML dialects.
* HTML does not support <code>p</code> elements may contain structured inline level elements including <code>blockquote</code>, <code>dl</code>, <code>menu</code>, <code>ol</code>, <code>ul</code>, <code>pre</code> and <code>table</code>.
* <code>script</code> elements cannot contain <code></</code>.

== Limitations from XML and XHTML ==

* The doctype, optional in XHTML but mandatory in HTML, must match case-sensitivly this <code><!DOCTYPE html></code> to be well-formed and valid in XHTML.
* Well-formness contrains, not respecting these will generate fatal errors in XHTML.
** Comments cannot contain double-hyphens (<code>--</code>).
** Start tags and end tags must be balenced correctly, unless they're void element.
** Void tags must always be closed by a tailing slash (<code>/></code>).
** All attributes values must be quoted. Attributes without value are disallowed.
** All <code><</code> and <code>&</code> in the text must be escaped, so is <code>></code> inside attribute values or anywhere in the text when preceded by <code>]]</code> (where it would be CDATA section end marker).
** Some characters are illegal in XML (U+0009, U+000A, U+000D, U+0020-U+D7FF, U+E000-U+FFFD, U+10000-U+10FFFF) [http://www.w3.org/TR/REC-xml/#charsets XML charsets]
** Others constrains defined in the [http://www.w3.org/TR/REC-xml/ XML specification].
* <code>script</code> and <code>style</code> elements may not contain <code><</code> or <code>&</code> in their unescaped form. External scripts and stylesheets are unaffected.
** There is a trick to allow <code><</code> and <code>&</code> which involves using CDATA blocks and inside JavaScript comments. See the workarounds section.
* <code>noscript</code> has no effect in XHTML.
* <code>document.write()</code> does not work in XHTML.
* Entity references cannot be used in XHTML (excluding the 5 predefined entities: <code>&amp;</code>, <code>&lt;</code>, <code>&gt;</code>, <code>&quot;</code> and <code>&apos;</code>).
* The namespace declaration (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on the html element in HTML on the condition that is has the value "http://www.w3.org/1999/xhtml". <html xmlns="http://www.w3.org/1999/xhtml">
* DOM apis are case-sensitive in XHTML, scripts should always use lowercase to be compatible.
* Style rules are matching case sensitivly in XHTML, stylesheets should always use lowercase tag, attribute and class names to be compatible.

== Markup Issues and Workarounds ==

=== Base URI ===

HTML:

<base src="uri">

XML / XHTML:

<html xml:base="uri">

Workaround: HTTP Content-Location header:

Content-Location: uri

[http://www.w3.org/TR/html4/struct/links.html#h-12.4.1 HTML 4 Spec]

=== Character Set ===

HTML

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

XHTML / XML

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

Workaround: HTTP Content-Type header with encoding specified:

Content-Type: text/html;charset=utf-8
Content-Type: application/xhtml+xml;charset=utf-8

=== Language ===

HTML

<html lang="en">

XML / XHTML

<html xml:lang="en">

Workaround: HTTP Content-Language header:

Content-Language: en

[http://www.whatwg.org/specs/web-apps/current-work/#lang HTML 5 Spec]
[http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2 HTML 4 Spec]

Note that there is no conforming workaround to switch language for different parts of a document. There is a method which will work however: if you use HTML's lang attribute, instead of the conformant xml:lang, browser will correctly deduce the language of the element. But this will make the document non-conforming when served with an XML media type and interpreted as XHTML.

=== Scripts & Style ===

HTML

<script type="text/javascript">
if (a < 0 && a > 10) alert("A not in range (0 < a < 10).")
</script>

XML / XHTML

<script type="text/javascript">
if (a &lt; 0 &amp;&amp; a > 10) alert("A not in range (0 &lt; a &lt; 10).")
</script>

or

<script type="text/javascript">
<![CDATA[
if (a < 0 && a > 10) alert("A not in range (0 < a < 10).")
]]>
</script>

Workaround: Commented CDATA block around the problemantic part of the script, or the whole script:

<script type="text/javascript">
/* <![CDATA[ */
if (a < 0 && a > 10) alert("A not in range (0 < a < 10).")
/* ]]> */
</script>

This works because HTML puts the CDATA block markers textually inside the script, but as they're then inside comments it has no effect, and the CDATA block allows the XML parser to work with unescaped character data. The same trick can be applied to the <code>style</code> element when it contains <code><</code> or <code>&</code>.

Note that the element must not contain the string <code>]]></code>, or the XML wouldn't be well-formed, and it may not contain <code></</code>, or it would be non-conformant HTML. In all cases, this is only needed where <code>script</code> or <code>style</code> contains <code>&</code> or <code><</code>.

Common Subset

2006-12-09T13:08:44Z

Michel Fortin:

The common subset intersecting HTML5 and XHTML5 is a subset of both syntaxes meant to create . The common subset is only implicitly defined by the HTML and XHTML specification because they have many syntax elements in common. A document is said to use the common subset when it can parse correctly with both the XML parser and the HTML parser.

A document using the '''conforming''' common subset is conforming with the specification whether it is interpreted as HTML or XHTML. The conforming common subset rejects any element with are not conforming in either of the two DOM variants.

A document using the common subset can be served as HTML (text/html media type) or XHTML (with an XML media type). The media type is what the browser use to decide if it'll be parsed as HTML or XHTML and which varient of the DOM is used.

== Common Syntax ==

[TBD]

== Limitations from HTML ==

* The [http://blog.whatwg.org/faq/#doctype doctype is required] to be <code><!DOCTYPE html></code>
* Tag and attribute names must be lowercase.
* XMLish end tag tailing slash must not be used with non-void elements; they'll be ignored by the HTML parser and are invalid in HTML.
* XMLish CDATA blocks will not work.
* HTML does not allow mixing with other XML dialects.
* HTML does not support <code>p</code> elements may contain structured inline level elements including <code>blockquote</code>, <code>dl</code>, <code>menu</code>, <code>ol</code>, <code>ul</code>, <code>pre</code> and <code>table</code>.
* <code>script</code> elements cannot contain <code></</code>.

== Limitations from XML and XHTML ==

* The doctype, optional in XHTML but mandatory in HTML, must match case-sensitivly this <code><!DOCTYPE html></code> to be well-formed and valid in XHTML.
* Well-formness contrains, not respecting these will generate fatal errors in XHTML.
** Comments cannot contain double-hyphens (<code>--</code>).
** Start tags and end tags must be balenced correctly, unless they're void element.
** Void tags must always be closed by a tailing slash (<code>/></code>).
** All attributes values must be quoted. Attributes without value are disallowed.
** All <code><</code> and <code>&</code> in the text must be escaped, so is <code>></code> inside comments or anywhere in the text when preceded by <code>]]</code> (where it would be CDATA section end marker).
** Some characters are illegal in XML (U+0009, U+000A, U+000D, U+0020-U+D7FF, U+E000-U+FFFD, U+10000-U+10FFFF) [http://www.w3.org/TR/REC-xml/#charsets XML charsets]
** Others constrains defined in the [http://www.w3.org/TR/REC-xml/ XML specification].
* <code>script</code> and <code>style</code> elements may not contain <code><</code> or <code>&</code> in their unescaped form. External scripts and stylesheets are unaffected.
** There is a tricky way to make that work which involves using CDATA blocks and inside JavaScript comments.
* <code>noscript</code> has no effect in XHTML.
* <code>document.write()</code> does not work in XHTML.
* Entity references cannot be used in XHTML (excluding the 5 predefined entities: <code>&amp;</code>, <code>&lt;</code>, <code>&gt;</code>, <code>&quot;</code> and <code>&apos;</code>).
* The namespace declaration (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on the html element in HTML on the condition that is has the value "http://www.w3.org/1999/xhtml". <html xmlns="http://www.w3.org/1999/xhtml">
* DOM apis are case-sensitive in XHTML, scripts should always use lowercase to be compatible.
* Style rules are matching case sensitivly in XHTML, stylesheets should always use lowercase tag, attribute and class names to be compatible.

== Markup Issues and Workarounds ==

=== Base URI ===

HTML:

<base src="uri">

XML / XHTML:

<html xml:base="uri">

Workaround: HTTP Content-Location header:

Content-Location: uri

[http://www.w3.org/TR/html4/struct/links.html#h-12.4.1 HTML 4 Spec]

=== Character Set ===

HTML

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

XHTML / XML

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

Workaround: HTTP Content-Type header with encoding specified:

Content-Type: text/html;charset=utf-8
Content-Type: application/xhtml+xml;charset=utf-8

=== Language ===

HTML

<html lang="en">

XML / XHTML

<html xml:lang="en">

Workaround: HTTP Content-Language header:

Content-Language: en

[http://www.whatwg.org/specs/web-apps/current-work/#lang HTML 5 Spec]
[http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2 HTML 4 Spec]

Note that there is no conforming workaround to switch language for different parts of a document. There is a method which will work however: if you use HTML's lang attribute, instead of the conformant xml:lang, browser will correctly deduce the language of the element. But this will make the document non-conforming when served with an XML media type and interpreted as XHTML.

=== Scripts & Style ===

HTML

<script type="text/javascript">
if (a < 0 && a > 10) alert("A not in range (0 < a < 10).")
</script>

XML / XHTML

<script type="text/javascript">
if (a &lt; 0 &amp;&amp; a > 10) alert("A not in range (0 &lt; a &lt; 10).")
</script>

Workaround: Commented CDATA block around the problemantic part of the script, or the whole script:

<script type="text/javascript">
/* <![CDATA[ */
if (a < 0 && a > 10) alert("A not in range (0 < a < 10).")
/* ]]> */
</script>

This works because HTML puts the CDATA block markers textually inside the script, but as they're then inside comments it has no effect, and the CDATA block allows the XML parser to work with unescaped character data. The same trick can be applied to the <code>style</code> element when it contains <code><</code> or <code>&</code>.

Note that the element must not contain the string <code>]]></code>, or the XML wouldn't be well-formed, and it may not contain <code></</code>, or it would be non-conformant HTML. In all cases, this is only needed where <code>script</code> or <code>style</code> contains <code>&</code> or <code><</code>.

Common Subset

2006-12-08T20:44:53Z

Michel Fortin: /* Limitations from XML and XHTML */ Added reference to XML character spec and fixed some entities.

The common subset intersecting HTML5 and XHTML5 is a subset of both syntaxes meant to create . The common subset is only implicitly defined by the HTML and XHTML specification because they have many syntax elements in common. A document is said to use the common subset when it can parse correctly with both the XML parser and the HTML parser.

A document using the '''conforming''' common subset is conforming with the specification whether it is interpreted as HTML or XHTML. The conforming common subset rejects any element with are not conforming in either of the two DOM variants.

A document using the common subset can be served as HTML (text/html media type) or XHTML (with an XML media type). The media type is what the browser use to decide if it'll be parsed as HTML or XHTML and which varient of the DOM is used.

== Common Syntax ==

[TBD]

== Limitations from HTML ==

* The [http://blog.whatwg.org/faq/#doctype doctype is required] to be <code><!DOCTYPE html></code>
* Tag and attribute names must be lowercase.
* XMLish end tag tailing slash must not be used with non-void elements; they'll be ignored by the HTML parser and are invalid in HTML.
* XMLish CDATA blocks will not work.
* HTML does not allow mixing with other XML dialects.
* HTML does not support <code>p</code> elements may contain structured inline level elements including <code>blockquote</code>, <code>dl</code>, <code>menu</code>, <code>ol</code>, <code>ul</code>, <code>pre</code> and <code>table</code>.

== Limitations from XML and XHTML ==

* The doctype, optional in XHTML but mandatory in HTML, must match case-sensitivly this <code><!DOCTYPE html></code> to be well-formed and valid in XHTML.
* Well-formness contrains, not respecting these will generate fatal errors in XHTML.
** Comments cannot contain double-hyphens (<code>--</code>).
** Start tags and end tags must be balenced correctly, unless they're void element.
** Void tags must always be closed by a tailing slash (<code>/></code>).
** All attributes values must be quoted. Attributes without value are disallowed.
** All <code><</code> and <code>&</code> in the text must be escaped, so is <code>></code> inside comments or anywhere in the text when preceded by <code>]]</code> (where it would be CDATA section end marker).
** Some characters are illegal in XML (U+0009, U+000A, U+000D, U+0020-U+D7FF, U+E000-U+FFFD, U+10000-U+10FFFF) [http://www.w3.org/TR/REC-xml/#charsets XML charsets]
** Others constrains defined in the [http://www.w3.org/TR/REC-xml/ XML specification].
* <code>script</code> and <code>style</code> elements may not contain <code><</code> or <code>&</code> in their unescaped form, unless they're in a CDATA block which would make the document non-conforming on the HTML side (althoug it should still be possible to make it work). External scripts and stylesheets are unaffected.
* <code>noscript</code> has no effect in XHTML.
* <code>document.write()</code> does not work in XHTML.
* Entity references cannot be used in XHTML (excluding the 5 predefined entities: <code>&amp;</code>, <code>&lt;</code>, <code>&gt;</code>, <code>&quot;</code> and <code>&apos;</code>).
* The namespace declaration (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on the html element in HTML on the condition that is has the value "http://www.w3.org/1999/xhtml". <html xmlns="http://www.w3.org/1999/xhtml">
* DOM apis are case-sensitive in XHTML, scripts should always use lowercase to be compatible.
* Style rules are matching case sensitivly in XHTML, stylesheets should always use lowercase tag, attribute and class names to be compatible.

== Markup Issues and Workarounds ==

=== Base URI ===

HTML:

<base src="uri">

XML / XHTML:

<html xml:base="uri">

Workaround: HTTP Content-Location header:

Content-Location: uri

[http://www.w3.org/TR/html4/struct/links.html#h-12.4.1 HTML 4 Spec]

=== Character Set ===

HTML

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

XHTML / XML

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

Workaround: HTTP Content-Type header with encoding specified:

Content-Type: text/html;charset=utf-8
Content-Type: application/xhtml+xml;charset=utf-8

=== Language ===

HTML

<html lang="en">

XML / XHTML

<html xml:lang="en">

Workaround: HTTP Content-Language header:

Content-Language: en

[http://www.whatwg.org/specs/web-apps/current-work/#lang HTML 5 Spec]
[http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2 HTML 4 Spec]

Note that there is no conforming workaround to switch language for different parts of a document. There is a method which will work however: if you use HTML's lang attribute, instead of the conformant xml:lang, browser will correctly deduce the language of the element. But this will make the document non-conforming when served with an XML media type and interpreted as XHTML.

Common Subset

2006-12-08T20:38:36Z

Michel Fortin: /* Limitations from HTML */

The common subset intersecting HTML5 and XHTML5 is a subset of both syntaxes meant to create . The common subset is only implicitly defined by the HTML and XHTML specification because they have many syntax elements in common. A document is said to use the common subset when it can parse correctly with both the XML parser and the HTML parser.

A document using the '''conforming''' common subset is conforming with the specification whether it is interpreted as HTML or XHTML. The conforming common subset rejects any element with are not conforming in either of the two DOM variants.

A document using the common subset can be served as HTML (text/html media type) or XHTML (with an XML media type). The media type is what the browser use to decide if it'll be parsed as HTML or XHTML and which varient of the DOM is used.

== Common Syntax ==

[TBD]

== Limitations from HTML ==

* The [http://blog.whatwg.org/faq/#doctype doctype is required] to be <code><!DOCTYPE html></code>
* Tag and attribute names must be lowercase.
* XMLish end tag tailing slash must not be used with non-void elements; they'll be ignored by the HTML parser and are invalid in HTML.
* XMLish CDATA blocks will not work.
* HTML does not allow mixing with other XML dialects.
* HTML does not support <code>p</code> elements may contain structured inline level elements including <code>blockquote</code>, <code>dl</code>, <code>menu</code>, <code>ol</code>, <code>ul</code>, <code>pre</code> and <code>table</code>.

== Limitations from XML and XHTML ==

* The doctype, optional in XHTML but mandatory in HTML, must match case-sensitivly this <code><!DOCTYPE html></code> to be well-formed and valid in XHTML.
* Well-formness contrains, not respecting these will generate fatal errors in XHTML.
** Comments cannot contain double-hyphens (--).
** Start tags and end tags must be balenced correctly, unless they're void element.
** Void tags must always be closed by a tailing slash ("/>").
** All attributes values must be quoted. Attributes without value are disallowed.
** All < and & in the text must be escaped, so is > inside comments or anywhere in the text when preceded by ]] (where it would be CData section end marker).
** Some characters are illegal in XML (U+0009, U+000A, U+000D, U+0020-U+D7FF, U+E000-U+FFFD, U+10000-U+10FFFF)
** Others constrains defined in the [http://www.w3.org/TR/REC-xml/ XML specification].
* <code>script</code> and <code>style</code> elements may not contain < or & in their unescaped form, unless they're in a CDATA block which would make the document non-conforming on the HTML side (althoug it should still be possible to make it work). External scripts and stylesheets are unaffected.
* <code>noscript</code> has no effect in XHTML.
* <code>document.write()</code> does not work in XHTML.
* Entity references cannot be used in XHTML (excluding the 5 predefined entities: &, <, >, " and ').
* The namespace declaration (<code>xmlns</code> attribute) is required in XHTML. The xmlns attribute is also allowed to appear on the html element in HTML on the condition that is has the value "http://www.w3.org/1999/xhtml". <html xmlns="http://www.w3.org/1999/xhtml">
* DOM apis are case-sensitive in XHTML, scripts should always use lowercase to be compatible.
* Style rules are matching case sensitivly in XHTML, stylesheets should always use lowercase tag, attribute and class names to be compatible.

== Markup Issues and Workarounds ==

=== Base URI ===

HTML:

<base src="uri">

XML / XHTML:

<html xml:base="uri">

Workaround: HTTP Content-Location header:

Content-Location: uri

[http://www.w3.org/TR/html4/struct/links.html#h-12.4.1 HTML 4 Spec]

=== Character Set ===

HTML

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

XHTML / XML

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

Workaround: HTTP Content-Type header with encoding specified:

Content-Type: text/html;charset=utf-8
Content-Type: application/xhtml+xml;charset=utf-8

=== Language ===

HTML

<html lang="en">

XML / XHTML

<html xml:lang="en">

Workaround: HTTP Content-Language header:

Content-Language: en

[http://www.whatwg.org/specs/web-apps/current-work/#lang HTML 5 Spec]
[http://www.w3.org/TR/html4/struct/dirlang.html#h-8.1.2 HTML 4 Spec]

Note that there is no conforming workaround to switch language for different parts of a document. There is a method which will work however: if you use HTML's lang attribute, instead of the conformant xml:lang, browser will correctly deduce the language of the element. But this will make the document non-conforming when served with an XML media type and interpreted as XHTML.

Common Subset

2006-12-08T20:38:23Z

Michel Fortin: /* Limitations from XHTML */

Common Subset

2006-12-08T13:42:21Z

Michel Fortin:

Common Subset

2006-12-08T13:27:00Z

Michel Fortin:

User:Matthew Raymond/altinput element

2006-11-29T14:31:51Z

Michel Fortin: Reverted edits by Apeloverage (Talk); changed back to last version by Matthew Raymond

The <altinput> element is intended to be a possible alternative to my earlier [[User:Matthew_Raymond:dataentry_element|<dataentry>]] element.

The <altinput> element is a way of accomplishing the same goals as <dataentry> while ensuring that the size of a form's elements collection and the position of controls within it doesn't change between legacy and WF2 browsers. Rather than the element itself being a form control, <altinput> instead performs the following:

* If it has a control with an |id| attribute equal to its |for| attribute, then it attempts to assign its own |type| attribute value to the |type| of the specified control.
* If the |type| is not supported, then the <altinput> acts as nothing more than a <span>.
* However, if the |type| is supported, the control has its |type| changed and the entire contents of the <altinput> element, with the exception of specified control, are not be rendered.

The result is that, in most cases, <altinput> acts almost exactly like <dataentry>.

==Examples==

Here's a simple example for the three <select> scenario:

<altinput for="d1" type="date" value="2005-02-09">
<input type="hidden" id="d1" name="d1" />
<select name="d1_day"></select> /
<select name="d1_month"></select> /
<select name="d1_year"></select>
</altinput>

Here's an example for users of jscalendar:

<altinput for="sel1" type="date">
<input type="text" id="sel1" name="date1" size="30" />
<input type="reset" value=" ... " onclick="return showCalendar('sel1', '%Y-%m-%d');">
YYYY-MM-DD
</altinput>

==Pros==

# The size of a form's elements collection in Javascript never changes.
# The <altinput> element can allow for a far greater range of legacy fallback than <input> alone.
# Because the |type| is defined in an attribute, <altinput> can be used for input types in later specifications, or for vendor-specific input types.
# Because the elemnt requires a child form control, it encourages the use of <input> alone in simple cases where legacy fallback needs are minimal.
# The element is designed only to prevent the presentation of its child elements. It does not require user agents to delete contents from the DOM or suppress Javascript execution.

==Cons==

# It's slightly more complicated to use than <dataentry>.
# In some situations, you must use a hidden <input> control as the target of the <altinput> element's |for| attribute.
# It may still inherit some minor issues from <dataentry>.

Link Hashes

2006-11-18T13:56:10Z

Michel Fortin: Added to the Feature Request category.

Many download sites, especially for software download, give hashes or digests for the file they distribute so that users can check the validity of the files once they've downloaded it. The process for verifying the hash however isn't straightforward.

== Problem Description ==
A lot of software download pages already give you MD5 or SHA-1 digests values to check the validity of the downloaded file. Checking the file ensure that the downloaded file is same as the author of the page wanted to give you. Corrupted or tampered files can be detected that way.

The problem is that there is no way to automate that verification process. To automate this process, a browser would need to extract the hash associated with the link on the original page.

=== Current Usage ===
Some links to software download pages featuring hashes:
* Apple: [http://www.apple.com/support/downloads/securityupdate20060061039client.html Security Update 2006-006]
* [http://www.php.net/downloads.php PHP Downloads]
* Apache: [http://httpd.apache.org/download.cgi HTTP Server]

Other examples can be found on the [http://microformats.org/wiki/hash-examples#Who_offers_MD5.2FSHA-1_checksums_with_software hash examples] page on the Microformat wiki.

=== Benefits ===
Easier discoverability of tampered files which could come from a mirror server being hacked.

== Proposed Solutions ==

=== hash attribute ===
A hash attribute could contain a md5 checksum of the target file. If the hash of the downloaded file does not match the one from the link, the file is deleted or quarantined and the user is alerted of a potential security risk.

<pre>
<a href="..." hash="b3187253c1667fac7d20bb762ad53967">
</pre>

==== Processing Model ====
When the link is clicked, the browser keeps the hash in memory to compare it with the it hashes from the downloaded file. Once the file is downloaded, the the computed hash is compared against the expected hash.

:"To be completed: what to do about non-download links, like links to other pages, when they have a hash?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Hash Microformat ===
The hash microformat provides a way to associate hash values with links:

<pre>
<span class="download">
<a rel="bookmark" href="...">Download OpenOffice.org
<span class="checksum md5">e0d123e5f316bef78bfdf5a008837577</span>
</a>
</span>
</pre>

The microformat is better described on the [http://microformats.org/wiki/hash-examples hash-examples] page.

==== Processing Model ====
When a link is clicked, the browser check if it corresponds to the microformat (''details to be added''). If it is the hash value is extracted and, once the file is downloaded, the computed hash for the file is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

The microformat markup is heavier that it needs to be. It also force page authors to put the hash visible inside the link, or to apply specific stylesheets to hide it on visual browsers.

=== Link Fingerprint ===
Append a digest for the file in the fragment identifier of the URL. The browser can then check the validity of the file when it downloads it.

<pre>
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967
</pre>

The [http://www.gerv.net/security/link-fingerprints/ Link Fingerprints article] by Gervase Markham gives more details.

==== Processing Model ====
When the link is clicked, the browser check if the URL contains a hash. If the URL contains a hash, once the file is downloaded the computed hash is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
Work only for downloaded files; fragment identifiers are used in other ways for regular pages and PDF files opened in the browser with a plugin.

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Content-MD5 HTTP Header ===
It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.

== Mailing List References ==
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007833.html Re: hash attribute] -- Tom Pike, Wed Nov 8 05:21:22 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Ian Hickson, Wed Nov 8 08:28:19 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007857.html Re: hash attribute] -- Gervase Markham, Thu Nov 9 09:23:32 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006

[[Category:Feature Request]]

WHATWG Wiki talk:About

2006-11-18T13:52:00Z

Michel Fortin:

== Copyright ==

* I did put a public domain copyright notice here, but was told the wiki was initially under the GFDL before the reinstall, so I've had to change it back. Although GFDL is at least acceptable, personally, I don't believe in sticking copyright notices on such things and would like everything here to just go in the Public Domain (cause, seriously, who really cares what someone wants to use it for?), but it would require all existing contributors to agree. So, which licence do you think we should use? --[[User:Lachlan Hunt|Lachlan Hunt]] 09:22, 18 November 2006 (UTC)
** I have no problem with that; feel free to use anything I've written on the wiki as public domain. --[[User:Michel Fortin|Michel Fortin]] 13:52, 18 November 2006 (UTC)
** Any chance we could reuse freely what was written to the mailing list? I've reused some parts of my own emails in creating the [[Image Caption]] and [[Link Hashes]] pages; since I own the copyright on these emails there's no problem. But should we ask for permission before using other's people emails, even if the content is publicly available in the mailing list archive? Probably. And it seems the server is located in the US, so I guess it's the US fair use clauses that should apply when gathering examples or some other content from other sources, but that's just a guess. --[[User:Michel Fortin|Michel Fortin]] 13:52, 18 November 2006 (UTC)

Link Hashes

2006-11-17T18:44:44Z

Michel Fortin: /* Link Fingerprint */

Link Hashes

2006-11-17T18:43:11Z

Michel Fortin: /* Link Fingerprint */

Many download sites, especially for software download, give hashes or digests for the file they distribute so that users can check the validity of the files once they've downloaded it. The process for verifying the hash however isn't straightforward.

== Problem Description ==
A lot of software download pages already give you MD5 or SHA-1 digests values to check the validity of the downloaded file. Checking the file ensure that the downloaded file is same as the author of the page wanted to give you. Corrupted or tampered files can be detected that way.

The problem is that there is no way to automate that verification process. To automate this process, a browser would need to extract the hash associated with the link on the original page.

=== Current Usage ===
Some links to software download pages featuring hashes:
* Apple: [http://www.apple.com/support/downloads/securityupdate20060061039client.html Security Update 2006-006]
* [http://www.php.net/downloads.php PHP Downloads]
* Apache: [http://httpd.apache.org/download.cgi HTTP Server]

Other examples can be found on the [http://microformats.org/wiki/hash-examples#Who_offers_MD5.2FSHA-1_checksums_with_software hash examples] page on the Microformat wiki.

=== Benefits ===
Easier discoverability of tampered files which could come from a mirror server being hacked.

== Proposed Solutions ==

=== hash attribute ===
A hash attribute could contain a md5 checksum of the target file. If the hash of the downloaded file does not match the one from the link, the file is deleted or quarantined and the user is alerted of a potential security risk.

<pre>
<a href="..." hash="b3187253c1667fac7d20bb762ad53967">
</pre>

==== Processing Model ====
When the link is clicked, the browser keeps the hash in memory to compare it with the it hashes from the downloaded file. Once the file is downloaded, the the computed hash is compared against the expected hash.

:"To be completed: what to do about non-download links, like links to other pages, when they have a hash?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Hash Microformat ===
The hash microformat provides a way to associate hash values with links:

<pre>
<span class="download">
<a rel="bookmark" href="...">Download OpenOffice.org
<span class="checksum md5">e0d123e5f316bef78bfdf5a008837577</span>
</a>
</span>
</pre>

The microformat is better described on the [http://microformats.org/wiki/hash-examples hash-examples] page.

==== Processing Model ====
When a link is clicked, the browser check if it corresponds to the microformat (''details to be added''). If it is the hash value is extracted and, once the file is downloaded, the computed hash for the file is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

The microformat markup is heavier that it needs to be. It also force page authors to put the hash visible inside the link, or to apply specific stylesheets to hide it on visual browsers.

=== Link Fingerprint ===
Append a digest to the file in the fragment identifier of the URL. The browser can then check the validity of the file when it downloads it.

<pre>
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967
</pre>

The [http://www.gerv.net/security/link-fingerprints/ Link Fingerprints article] by Gervase Markham gives more details.

==== Processing Model ====
When the link is clicked, the browser check if the URL contains a hash. If the URL contains a hash, once the file is downloaded the computed hash is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
Work only for downloaded files; fragment identifiers are used in other ways for regular pages and PDF files opened in the browser with a plugin.

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Content-MD5 HTTP Header ===
It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.

== Mailing List References ==
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007833.html Re: hash attribute] -- Tom Pike, Wed Nov 8 05:21:22 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Ian Hickson, Wed Nov 8 08:28:19 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007857.html Re: hash attribute] -- Gervase Markham, Thu Nov 9 09:23:32 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006

Link Hashes

2006-11-17T18:42:33Z

Michel Fortin: Added a link to Gervase Markham's article on Link Fingerprints.

User:Michel Fortin

2006-11-17T18:29:50Z

Michel Fortin:

[http://www.michelf.com/ I'm here.]

Talk:Problem Solving

2006-11-17T17:58:28Z

Michel Fortin: Typo Fix

* I just added a new page based on this template -- [[Link Hashes]] -- and I begin to wonder if the template should not be a lot more flexible regarding how the information is organised. There is just too much repetition of the same thing between different solutions, but if you compare to another problem -- like [[Image Caption]] -- repetitions are not on the same items. Maybe we should try to better organise these two problem pages and then update the template with what we've determined to be a good and flexible enough organisation. --[[User:Michel Fortin|Michel Fortin]] 09:52, 17 November 2006 (PST)

== Problem Description ==

=== Current Limitations ===

* I think "Current Limitations" and "Problem Description" will generally be the same thing. Almost always, the problem <em>is</em> a current limitation. Sure we could formulate problems in more general term, like "Problem: need to markup a dialogue; Limitation: no semantic markup for that", but in fact, marking up the dialog isn't really a problem (it's easy to markup a dialog with <dl>), the limitation is. --[[User:Michel Fortin|Michel Fortin]] 07:17, 17 November 2006 (PST)
** I changed Problem Description to Use Case Description to clarify why I think they're different. The use case is about describing what kind of information you are trying to mark up. The current limitations is for explaining why existing markup is not appropriate. --[[User:Lachlan Hunt|Lachlan Hunt]] 09:37, 17 November 2006 (PST)

Talk:Link Hashes

2006-11-17T17:56:56Z

Michel Fortin: /* Link Fingerprint */

==== Link Fingerprint ====

Just a note to say that while this is certainly out of scope for HTML, it's nonetheless a good solution, and mentioning it there, with enough details, can serve of a justification to not include other proposed solutions in the spec. --[[User:Michel Fortin|Michel Fortin]] 09:56, 17 November 2006 (PST)

Talk:Link Hashes

2006-11-17T17:56:32Z

Michel Fortin: Link Fingerprint Note

==== Link Fingerprint ====

Just a note to say that while this should probably out of scope for HTML, it's nonetheless a good solution, and mentioning it there, with enough details, can serve of a justification to not include other proposed solutions in the spec. --[[User:Michel Fortin|Michel Fortin]] 09:56, 17 November 2006 (PST)

Talk:Problem Solving

2006-11-17T17:52:49Z

Michel Fortin:

* I just added a new page based on this template -- [[Link Hashes]] -- and I begin to wonder if the template should not be a lot more flexible regarding how the information is organised. There is just too much repetition of the same thing between different solutions, but if you compare to another problem -- like [[Image Captions]] -- repetitions are not on the same items. Maybe we should try to better organise these two problem pages and then update the template with what we've determined to be a good and flexible enough organisation. --[[User:Michel Fortin|Michel Fortin]] 09:52, 17 November 2006 (PST)

== Problem Description ==

=== Current Limitations ===

* I think "Current Limitations" and "Problem Description" will generally be the same thing. Almost always, the problem <em>is</em> a current limitation. Sure we could formulate problems in more general term, like "Problem: need to markup a dialogue; Limitation: no semantic markup for that", but in fact, marking up the dialog isn't really a problem (it's easy to markup a dialog with <dl>), the limitation is. --[[User:Michel Fortin|Michel Fortin]] 07:17, 17 November 2006 (PST)
** I changed Problem Description to Use Case Description to clarify why I think they're different. The use case is about describing what kind of information you are trying to mark up. The current limitations is for explaining why existing markup is not appropriate. --[[User:Lachlan Hunt|Lachlan Hunt]] 09:37, 17 November 2006 (PST)

Link Hashes

2006-11-17T17:40:35Z

Michel Fortin:

Many download sites, especially for software download, give hashes or digests for the file they distribute so that users can check the validity of the files once they've downloaded it. The process for verifying the hash however isn't straightforward.

== Problem Description ==
A lot of software download pages already give you MD5 or SHA-1 digests values to check the validity of the downloaded file. Checking the file ensure that the downloaded file is same as the author of the page wanted to give you. Corrupted or tampered files can be detected that way.

The problem is that there is no way to automate that verification process. To automate this process, a browser would need to extract the hash associated with the link on the original page.

=== Current Usage ===
Some links to software download pages featuring hashes:
* Apple: [http://www.apple.com/support/downloads/securityupdate20060061039client.html Security Update 2006-006]
* [http://www.php.net/downloads.php PHP Downloads]
* Apache: [http://httpd.apache.org/download.cgi HTTP Server]

Other examples can be found on the [http://microformats.org/wiki/hash-examples#Who_offers_MD5.2FSHA-1_checksums_with_software hash examples] page on the Microformat wiki.

=== Benefits ===
Easier discoverability of tampered files which could come from a mirror server being hacked.

== Proposed Solutions ==

=== hash attribute ===
A hash attribute could contain a md5 checksum of the target file. If the hash of the downloaded file does not match the one from the link, the file is deleted or quarantined and the user is alerted of a potential security risk.

<pre>
<a href="..." hash="b3187253c1667fac7d20bb762ad53967">
</pre>

==== Processing Model ====
When the link is clicked, the browser keeps the hash in memory to compare it with the it hashes from the downloaded file. Once the file is downloaded, the the computed hash is compared against the expected hash.

:"To be completed: what to do about non-download links, like links to other pages, when they have a hash?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Hash Microformat ===
The hash microformat provides a way to associate hash values with links:

<pre>
<span class="download">
<a rel="bookmark" href="...">Download OpenOffice.org
<span class="checksum md5">e0d123e5f316bef78bfdf5a008837577</span>
</a>
</span>
</pre>

The microformat is better described on the [http://microformats.org/wiki/hash-examples hash-examples] page.

==== Processing Model ====
When a link is clicked, the browser check if it corresponds to the microformat (''details to be added''). If it is the hash value is extracted and, once the file is downloaded, the computed hash for the file is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

The microformat markup is heavier that it needs to be. It also force page authors to put the hash visible inside the link, or to apply specific stylesheets to hide it on visual browsers.

=== Link Fingerprint ===
Append a digest for the file in the fragment identifier of the URL. The browser can then check the validity of the file when it downloads it.

<pre>
http://example.com/file#!md5!b3187253c1667fac7d20bb762ad53967
</pre>

==== Processing Model ====
When the link is clicked, the browser check if the URL contains a hash. If the URL contains a hash, once the file is downloaded the computed hash is compared against the expected hash. Browsers should keep the initial hash value across redirections, if any. This only applies to files downloaded to the disk.

:"Could the syntax be extended so that fragment identifiers could cohabit with fingerprints?"

==== Limitations ====
Work only for downloaded files; fragment identifiers are used in other ways for regular pages and PDF files opened in the browser with a plugin.

==== Implementation ====
The software industry as a whole is more and more concerned about security implications of the Internet. Security has become another feature of the browser. Something that increase security with minor impact to the user experience will probably be welcome.

A browser could display the following message when in case of hash mismatch:

:''File "image.iso" is different from the file linked on page "My Software CD Images". It is possible that this file has been tampered with and it'd be advisable to not open it. Do you wish to delete the file?''<br>[Delete File] [Keep in Quarantine]

==== Adoption ====
Distributors that already give hashes for their users to verify the files are very likely to add this extra attribute if it simplifies the security checks for their users. The fact that the digests are already available on these pages means that the author of the page is already concerned about security of the transfered file.

=== Content-MD5 HTTP Header ===
It has been suggested to use the [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 Content-MD5] HTTP header. A tampered file on a hacked server is very likely to get its digest updated accordingly however.

== Mailing List References ==
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007833.html Re: hash attribute] -- Tom Pike, Wed Nov 8 05:21:22 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Ian Hickson, Wed Nov 8 08:28:19 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007857.html Re: hash attribute] -- Gervase Markham, Thu Nov 9 09:23:32 PST 2006
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-November/007903.html Re: hash attribute] -- Michel Fortin, Tue Nov 14 08:53:43 PST 2006

Talk:Problem Solving

2006-11-17T15:17:59Z

Michel Fortin: /* Current Limitations */

== Problem Description ==

=== Current Limitations ===

I think "Current Limitations" and "Problem Description" will generally be the same thing. Almost always, the problem <em>is</em> a current limitation. Sure we could formulate problems in more general term, like "Problem: need to markup a dialogue; Limitation: no semantic markup for that", but in fact, marking up the dialog isn't really a problem (it's easy to markup a dialog with <dl>), the limitation is. --[[User:Michel Fortin|Michel Fortin]] 07:17, 17 November 2006 (PST)

Talk:Problem Solving

2006-11-17T15:17:30Z

Michel Fortin:

Image Caption Examples

2006-11-17T14:51:13Z

Michel Fortin: Adding a reference to the mailing list archive

This page is a collection of sample usage for images with captions from around the web. Markup samples provided here have been reformatted and often simplified by removing presentational elements to better illustrate what "defines" the figure in them.

These real-world examples provides support for the [[Image Caption]] proposal.

----

Some images in the CSS 2.1 specification ([http://www.w3.org/TR/CSS21/colors.html#img-bg-repeat example 1], [http://www.w3.org/TR/CSS21/tables.html#img-cell-align example 2]) use class names to add captions to figures. Reduced to a simpler form, the markup looks like this:

<pre>
<div class="figure">
<p><img src="..." alt="[caption text]">
<p class="caption">[Caption Text]
</div>
</pre>

(Note: Removed form this simplified markup is the [D] link to a long description that was put beside the image.)

----

Articles form the Salon.com magazine ([http://www.salon.com/opinion/blumenthal/2006/11/16/baker_rescue/index_np.html example]) use this markup for accompaniment photographs:

<pre>
<div class='article_photo_right'>
<img src='...'><br />
<p class='article_photo_credit'>Photo: [Photograph's Name]</p>
<p class='article_photo_caption'>[Caption Text]</p>
</div>
</pre>

----

MacWorld magazine website uses two-row tables to add a caption to screenshots in [http://www.macworld.com/2006/06/firstlooks/flciviv/index.php this article]. Interestingly, they're not using the <caption> element with is meant to be used inside <table>. By using it, they could have saved themselves the trouble of specifying a width for each of their screenshots without having the image description extending the table. Here is a simplified version of the markup used on this page:

<pre>
<table width="310" align="right">
<tr><td>
<img src="...">
</td></tr>
<tr><td>
<p>[Caption Text or Image Description]</p>
</td></tr>
</table>
</pre>

----

Wikipedia thumbnail image with caption can be reduced to this once the links are removed:

<pre>
<div class="thumb tright">
<img src="..." alt="[Caption Text]" longdesc="..." />
<div class="thumbcaption">
[Caption Text]
</div>
</div>
</pre>

----

Some documents ([http://www.stanford.edu/group/hopes/basics/basichd/a2.html example]) simply put the caption text inside the image.

== Other Examples ==

http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_paths/chapter_4_section_2.html

<pre>
<div>
<a name="..." title="[Caption Text]"></a>
<p>[Caption Text]</p>
<img src="..." alt="[Caption Text]">
</div>
</pre>

----

http://medicine.plosjournals.org/perlserv?request=get-document&doi=10.1371/journal.pmed.0020228

<pre>
<div class="figureFM">
<a name="..." id="..."></a>
<img src="..."/>
<h5>[Caption Text]</h5>
</div>
</pre>

----

http://www.darsie.net/string/

<pre>
<table WIDTH="346">
<tr><td>
<img align=top src="..." ALT="Photo of Position 1">
</td></tr>
<tr><td>
Position 1
</td></tr>
</table>
</pre>

== Mailing List References ==
* [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-June/006828.html Rep: image captions], 27 June 2006 -- Michel Fortin

Image Caption

2006-11-17T14:17:42Z

Michel Fortin: /* <label> defining attributes with nested markup */

Image caption are often found on the web, but there is no standard markup for this.

== Problem Description ==
Currently, most people use either a table, custom class names, or simply put the image inside a paragraph, each option either conveying a wrong meaning or being ambiguous with the rest of the content.

An interesting analysis has been done on the subject by Dan Cederholm in one of his SimpleQuiz. [http://www.simplebits.com/notebook/2004/01/20/sqxi_conclusion.html His conclusion]:

<blockquote>So in this case, I might choose option A -- because visually it shows the relationship between the items better than the others. But I suppose this is bad semantics. Or maybe just another case where we don't have the 'perfect' set of defined elements for this (very) specific job.</blockquote>

And his option A was:
<pre>
<p><img scr="..."><br />
Caption Text</p>
</pre>

In other word, he could not figure out anything good using current elements available in HTML, and, as most people do, had to create his own solution.

Setting a standard for such things -- an explicit association between the caption and the illustration -- would help image search engines, it could enable the automatic creation of a figure index for a page. The fact that image captions should be treated differently to body text (they are not in the main flow of the document) suggests this element could be important for figure handling by assistive tools allowing e.g. aural browsers to skip captions except on explicit user request.

=== Current Methods and Workarounds ===
See [[Image Caption Examples]] for a couple of sample cases.

== Proposed Solutions ==

=== <figure> with <caption> ===
A <figure> element contains illustrative content for the current section. It can contain a <caption> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</pre>

==== Processing Model ====
The processing model for HTML files must be changed so that the <caption> is no longer ignored when outside the context of a table. It could also be a good idea to add a new figure insertion mode that would prevent figure captions from being moved to the enclosing table when inside a table cell, otherwise <figure> will break in table-based layouts.

<pre>
<table>
<tr><td>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</td></tr>
</table>
</pre>

==== Limitations ====
<caption> being ignored by current browsers when outside a table makes it impossible to style, and it'll also be terribly broken with table layouts when figure captions end up at the top (or the bottom) of the enclosing layout table.

==== Implementation ====
Parsing changes in this solution could be hard to implement given <caption> element's legacy within <table>.

Putting aside the parsing problem, there's not much else to implement for visual browsers. A good display model that could be used to display figures is already available in CSS 2.1:

<pre>
figure { display: table; }
caption { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the caption either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the caption's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
The syntax is pretty straightforward to use. "figure" and "caption" are commonly used terms to designate exactly this feature in the print world. It should be a natural choice to authors that wonder how to markup their images.

This markup won't work however if an author wants the caption to be elsewhere in the document. (In this proposal, <caption> is pinned to the figure's content.) It does not seem a common use case however.

=== <figure> with <legend> ===
A <figure> element contains illustrative content for the current section. It can contain a <legend> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<legend>Caption Text</legend>
<img src="...">
</figure>
</pre>

==== Processing Model ====
:''To be completed''

==== Limitations ====
:''To be completed''

==== Implementation ====
A good display model that could be used to display figures is already available in CSS 2.1, the table model. A default stylesheet could look like this:

<pre>
figure { display: table; }
figure legend { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the figure legend either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the legend's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
"figure" and "legend" are commonly used terms in the print world, so their use could prove natural to authors. It is most likely that authors that need a markup for their figure will chose this one if it is sanctioned in a standard.

This markup won't work if an author wants the caption to be elsewhere in the document. (In this proposal, <legend> is pinned to the figure's content.) It does not seem a common use case however.

=== Adjacent <caption> or <legend> ===
<caption> or <legend> elements directly following a <img> element give the caption text for that image.

<pre>
<img src="...">
<caption>Caption Text</caption>
</pre>

<pre>
<img src="...">
<legend>Caption Text</legend>
</pre>

==== Processing Model ====
The processing model for HTML files must be changed so that the <caption> is no longer ignored when outside the context of a table. It could also be a good idea to add a new figure insertion mode that would prevent figure captions from being moved to the enclosing table when inside a table cell, otherwise <figure> will break in table-based layouts.

:''Are the elements in this construct inline or block-level content? Currently <img> is inline.''

If any other element, or non-whitespace text nodes are found between <img> and its corresponding caption element, elements are considered to not be adjacent, the semantic link is broken and it generates a parse error.

==== Limitations ====
<caption> being ignored by current browsers when outside a table makes it impossible to style, and it'll also be terribly broken with table layouts when captions end up at the top (or the bottom) of the enclosing layout table.

:''To be completed: <legend> parsing''

==== Implementation ====
Parsing changes in this solution could be hard to implement given <caption> element's legacy within <table>.

:''To be completed: <legend> parsing implementation''

Giving a distinctive visual style to figure captions may prove difficult with this design. If a browser wants to treat figures in a distinctive manner, it'll have treat them as a special case; the adjacent element selector in CSS can't distinguish between adjacent elements which are separated by text and those that are not.

==== Adoption ====
:''To be completed''

"legend" and "caption" are commonly used terms in the print world, so their use could prove natural to authors. Difficulties in styling are likely however to cause authors to always warp figures in a <div> element as most already do anyway (see [[Image Caption Examples]]).

This markup won't work if an author wants the caption to be elsewhere in the document. It does not seem a common use case however.

=== <label> defining attributes with nested markup ===
A <label> element holds a value which should be treated the same way like the title attribute on <img>, except that it can contain nested markup. The for attribute of the label contains the id of the target element. A new type attribute on the label indicates which attribute the label intend to replace on the target.

<pre>
<img id="img1" src="...">
<label for="img1" type="title">...</label>
</pre>

==== Processing Model ====
:''To be completed: Attribute override, progressive rendering, etc.''

==== Limitations ====
:''To be completed''

==== Implementation ====
:''To be completed''

==== Adoption ====
This markup has the benefit that it'll work if an author wants the caption to be elsewhere in the document.

:''To be completed''

[[Category:Feature Request]]

Image Caption

2006-11-17T14:14:07Z

Michel Fortin: Added two proposed solutions; updated links to Image Caption Examples page.

Image caption are often found on the web, but there is no standard markup for this.

== Problem Description ==
Currently, most people use either a table, custom class names, or simply put the image inside a paragraph, each option either conveying a wrong meaning or being ambiguous with the rest of the content.

An interesting analysis has been done on the subject by Dan Cederholm in one of his SimpleQuiz. [http://www.simplebits.com/notebook/2004/01/20/sqxi_conclusion.html His conclusion]:

<blockquote>So in this case, I might choose option A -- because visually it shows the relationship between the items better than the others. But I suppose this is bad semantics. Or maybe just another case where we don't have the 'perfect' set of defined elements for this (very) specific job.</blockquote>

And his option A was:
<pre>
<p><img scr="..."><br />
Caption Text</p>
</pre>

In other word, he could not figure out anything good using current elements available in HTML, and, as most people do, had to create his own solution.

Setting a standard for such things -- an explicit association between the caption and the illustration -- would help image search engines, it could enable the automatic creation of a figure index for a page. The fact that image captions should be treated differently to body text (they are not in the main flow of the document) suggests this element could be important for figure handling by assistive tools allowing e.g. aural browsers to skip captions except on explicit user request.

=== Current Methods and Workarounds ===
See [[Image Caption Examples]] for a couple of sample cases.

== Proposed Solutions ==

=== <figure> with <caption> ===
A <figure> element contains illustrative content for the current section. It can contain a <caption> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</pre>

==== Processing Model ====
The processing model for HTML files must be changed so that the <caption> is no longer ignored when outside the context of a table. It could also be a good idea to add a new figure insertion mode that would prevent figure captions from being moved to the enclosing table when inside a table cell, otherwise <figure> will break in table-based layouts.

<pre>
<table>
<tr><td>
<figure>
<caption>Caption Text</caption>
<img src="...">
</figure>
</td></tr>
</table>
</pre>

==== Limitations ====
<caption> being ignored by current browsers when outside a table makes it impossible to style, and it'll also be terribly broken with table layouts when figure captions end up at the top (or the bottom) of the enclosing layout table.

==== Implementation ====
Parsing changes in this solution could be hard to implement given <caption> element's legacy within <table>.

Putting aside the parsing problem, there's not much else to implement for visual browsers. A good display model that could be used to display figures is already available in CSS 2.1:

<pre>
figure { display: table; }
caption { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the caption either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the caption's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
The syntax is pretty straightforward to use. "figure" and "caption" are commonly used terms to designate exactly this feature in the print world. It should be a natural choice to authors that wonder how to markup their images.

This markup won't work however if an author wants the caption to be elsewhere in the document. (In this proposal, <caption> is pinned to the figure's content.) It does not seem a common use case however.

=== <figure> with <legend> ===
A <figure> element contains illustrative content for the current section. It can contain a <legend> element, either as the first or the last child, that will be used to describe or give a caption to the content of the figure.

<pre>
<figure>
<legend>Caption Text</legend>
<img src="...">
</figure>
</pre>

==== Processing Model ====
:''To be completed''

==== Limitations ====
:''To be completed''

==== Implementation ====
A good display model that could be used to display figures is already available in CSS 2.1, the table model. A default stylesheet could look like this:

<pre>
figure { display: table; }
figure legend { display: table-caption; }
</pre>

This would display the figure as a one-cell table, and the figure legend either at the top or at the bottom (depending on the [http://www.w3.org/TR/CSS21/tables.html#propdef-caption-side caption-side] property). The interesting part of this model is that the legend's width is constrained by the width of the figure, making it the ideal choice for floated figures.

==== Adoption ====
"figure" and "legend" are commonly used terms in the print world, so their use could prove natural to authors. It is most likely that authors that need a markup for their figure will chose this one if it is sanctioned in a standard.

This markup won't work if an author wants the caption to be elsewhere in the document. (In this proposal, <legend> is pinned to the figure's content.) It does not seem a common use case however.

=== Adjacent <caption> or <legend> ===
<caption> or <legend> elements directly following a <img> element give the caption text for that image.

<pre>
<img src="...">
<caption>Caption Text</caption>
</pre>

<pre>
<img src="...">
<legend>Caption Text</legend>
</pre>

==== Processing Model ====
The processing model for HTML files must be changed so that the <caption> is no longer ignored when outside the context of a table. It could also be a good idea to add a new figure insertion mode that would prevent figure captions from being moved to the enclosing table when inside a table cell, otherwise <figure> will break in table-based layouts.

:''Are the elements in this construct inline or block-level content? Currently <img> is inline.''

If any other element, or non-whitespace text nodes are found between <img> and its corresponding caption element, elements are considered to not be adjacent, the semantic link is broken and it generates a parse error.

==== Limitations ====
<caption> being ignored by current browsers when outside a table makes it impossible to style, and it'll also be terribly broken with table layouts when captions end up at the top (or the bottom) of the enclosing layout table.

:''To be completed: <legend> parsing''

==== Implementation ====
Parsing changes in this solution could be hard to implement given <caption> element's legacy within <table>.

:''To be completed: <legend> parsing implementation''

Giving a distinctive visual style to figure captions may prove difficult with this design. If a browser wants to treat figures in a distinctive manner, it'll have treat them as a special case; the adjacent element selector in CSS can't distinguish between adjacent elements which are separated by text and those that are not.

==== Adoption ====
:''To be completed''

"legend" and "caption" are commonly used terms in the print world, so their use could prove natural to authors. Difficulties in styling are likely however to cause authors to always warp figures in a <div> element as most already do anyway (see [[Image Caption Examples]]).

This markup won't work if an author wants the caption to be elsewhere in the document. It does not seem a common use case however.

=== <label> defining attributes with nested markup ===
A <label> element holds a value which should be treated the same way like the title attribute on <img>, except that it can contain nested markup. The for attribute of the label contains the id of the target element. A new type attribute on the label indicates which attribute the label intend to replace on the target.

<pre>
<img id="img1" src="...">
<label for="img1" type="title">...</label>
</pre>

==== Processing Model ====
:''To be completed''

==== Limitations ====
:''To be completed''

==== Implementation ====
:''To be completed''

==== Adoption ====
:''To be completed''

This markup has the benefit that it'll work if an author wants the caption to be elsewhere in the document.

[[Category:Feature Request]]

Talk:Image Caption Usage

2006-11-17T14:08:50Z

Michel Fortin: Talk:Image Caption Usage moved to Talk:Image Caption Examples

#REDIRECT [[Talk:Image Caption Examples]]

Talk:Image Caption Examples

2006-11-17T14:08:50Z

Michel Fortin: Talk:Image Caption Usage moved to Talk:Image Caption Examples

* If we're going to list examples, wouldn't it be better that we followed the microformats method by using an "Examples" suffix. Generally, microformats uses spec-examples as the URL, but somehow their page titles differ slightly from the URI. We can just use something like "<var>Format Name</var> Examples". e.g. "Image Caption Examples". Should we rename and redirect this page? --[[User:Lachlan Hunt|Lachlan Hunt]] 22:03, 16 November 2006 (PST)
** Agreed. --[[User:Michel Fortin|Michel Fortin]] 06:07, 17 November 2006 (PST)

Image Caption Usage

2006-11-17T14:08:49Z

Michel Fortin: Image Caption Usage moved to Image Caption Examples

#REDIRECT [[Image Caption Examples]]

Image Caption Examples

2006-11-17T14:08:49Z

Michel Fortin: Image Caption Usage moved to Image Caption Examples

Talk:Image Caption Examples

2006-11-17T14:07:50Z

Michel Fortin:

Problem Solving

2006-11-16T17:04:57Z

Michel Fortin: /* Details */

This is an empty page that describes what should be documented about a problem and the different solutions proposed to address it. Feel free to copy this template to when creating a new page.

:''Brief description of the problem to solve.''

== Problem Description ==
:''Complete description of the problem, explanation of why the current markup is insufficient, etc.''

== Proposed Solutions ==

=== My Solution ===
:''Brief description of the solution and of how it address the problem at hand.''

==== Processing Model ====
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
:''Description of how and why browser vendors would take advantage of this feature.''

==== Adoption ====
:''Reasons why page authors would use this solution.''

== Usage ==
:''Some evidence is there that this feature is desparately needed on the web.''

Talk:Feature Proposals

2006-11-16T16:21:07Z

Michel Fortin: /* Guidelines */

Talk:Feature Proposals

2006-11-16T16:15:56Z

Michel Fortin:

Talk:Image Caption

2006-11-16T16:04:09Z

Michel Fortin:

==== <figure> with <legend> ====

I'm not sure if this shouldn't be grouped with the other "figure with caption" solution. They're pretty similar in concept, but they have different implications. --[[User:Michel Fortin|Michel Fortin]] 08:04, 16 November 2006 (PST)

Image Caption

2006-11-16T16:01:37Z

Michel Fortin: Added <figure> with <legend>

Image Caption

2006-11-16T15:36:50Z

Michel Fortin: Completed <figure> with <caption>

Image Caption

2006-11-16T14:47:08Z

Michel Fortin: Begun explaining the problematic, this isn't very complement at the moment.

Talk:Main Page

2006-11-16T11:40:46Z

Michel Fortin: Forgot to login before previous editing; adding my name where it belongs.

== WHATWG Specifications ==

* I think this whole section should go. Problems should be categorised by what they apply to, not classified by which specification should solve them. The solution, not the problem, is bound to a particular specification. --[[User:Michel Fortin|Michel Fortin]]
** I agree that problems shouldn't be categorised by the specification, but I don't agree this section should go. I think it's ok to provide some documentation about the actual specifications, including the actual features included within. It should be used to provide summaries and examples of actual features. Only when a proposal has been accepted and included in the spec, should it be included in this section. --[[User:Lachlan Hunt|Lachlan Hunt]] 22:03, 15 Nov 2006 (PST)
*** That's fine with me. --[[User:Michel Fortin|Michel Fortin]]

== Terms, Acronyms and Abbreviations ==

* I think this section too should go too. --[[User:Michel Fortin|Michel Fortin]]
** I agree. If needed, we could create a glossary, but I don't think abbreviations and other terms should be on separate pages. --[[User:Lachlan Hunt|Lachlan Hunt]] 22:05, 15 Nov 2006 (PST)

Talk:Main Page

2006-11-16T05:49:36Z

Michel Fortin: Sections that should go...

== WHATWG Specifications ==

I think this whole section should go. Problems should be categorised by what they apply to, not classified by which specification should solve them. The solution, not the problem, is bound to a particular specification. --[[User:Michel Fortin|Michel Fortin]]

== Terms, Acronyms and Abbreviations ==

I think this section too should go too. --[[User:Michel Fortin|Michel Fortin]]

WHATWG Wiki talk:Contribution Guidelines

2006-11-16T05:14:16Z

Michel Fortin: /* Site Specific Policies */

==Site Specific Policies==

I think it's a bad idea for feature requests to include proposed element names in the page title. There's always significant discussion about appropriate element names for features, so the proposal should focus on the problem to be solved, rather than the specific solution. e.g. instead of proposing a <footnote> element, propose a way to mark up footnotes. [[User:Lachlan Hunt|Lachlan Hunt]] 20:58, 15 Nov 2006 (PST)

:It seems that while you were writing this, in that spirit I created the [[Feature Proposals]] page some minutes ago. --[[User:Michel Fortin|Michel Fortin]] 21:05, 15 Nov 2006 (PST)

I also don't think feature requests should have to go into the User: or Group Proposal: space. I think all feature requests, regardless of who proposes it, should go under a common name like Feature:. e.g. Feature:Footnotes [[User:Lachlan Hunt|Lachlan Hunt]] 20:58, 15 Nov 2006 (PST)

:I completely agree, that's exactly what I've made with the [[Feature Proposals]] page. --[[User:Michel Fortin|Michel Fortin]] 21:05, 15 Nov 2006 (PST)

::Replying to myself, I don't think there would be any problem removing that as Matthew Raymond seems to have abandoned the wiki as it was in April 2005. It seems it was just an idea that was never really used, until now. (There was no other [[Special:Listusers|registered user]] than Matthew before I register a few hours ago.) --[[User:Michel Fortin|Michel Fortin]] 21:14, 15 Nov 2006 (PST)

Main Page

2006-11-16T05:07:56Z

Michel Fortin:

Welcome to the WHATWG Wiki. Before you begin, please read the [[WHATWG Wiki:Contribution Guidelines|Contribution Guidelines]].

==Purpose==
The purpose of the WHATWG Wiki is to create a place for WHATWG contributors to post and compile their own proposals and ideas regarding WHATWG specifications. The specifications themselves will not be available for editing via this wiki. However, ideas you post here may find their way into current and future WHATWG specifications.

== Feature Proposals ==

See [[Feature Proposals]].

==WHATWG Specifications==
* [[Web Forms 2.0]]
* [[Web Applications 1.0]]
* [[Web Controls 1.0]]

==Terms, Acronyms and Abbreviations==
* [[Common Abbreviations and Acronyms]]
* [[Common Terms]]

WHATWG Wiki talk:Contribution Guidelines

2006-11-16T05:05:02Z

Michel Fortin:

Problem Solving

2006-11-16T04:51:15Z

Michel Fortin:

This is an empty page that describes what should be documented about a problem and the different solutions proposed to address it. Feel free to copy this template to when creating a new page.

:''Brief description of the problem to solve.''

== Problem Description ==
:''Complete description of the problem, explanation of why the current markup is insufficient, etc.''

== Proposed Solutions ==

=== My Solution ===
:''Brief description of the solution and of how it address the problem at hand.''

==== Details ====
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
:''Description of how and why browser vendors would take advantage of this feature.''

==== Adoption ====
:''Reasons why page authors would use this solution.''

== Usage ==
:''Some evidence is there that this feature is desparately needed on the web.''

Feature Proposals

2006-11-16T04:32:00Z

Michel Fortin:

This document contains a list of the problems for which feature requests have been made. Linked problem pages contain the document of the problem and their relevant solutions. Obviously, we want to keep HTML as simple as possible. That means not everyone will get what they want. Having good documentation for the problems at hand will help all of us work out what is most important.

If you want to add a feature request, you should probably start by coping the [[Problem Solving]] template page on a new page and fill as much information as you can.

== Document Markup ==
* [[Dialogue]]
* [[Annotation]]
* [[Footnotes]]
* [[Sidenotes]]
* [[Image Caption]]
* [[Inline Math]]

== DOM Scripting ==
* [[Text in Canvas]]

== Security ==
* [[Link Hashes]]
* [[Digital Signatures]]

Feature Proposals

2006-11-16T04:31:47Z

Michel Fortin:

Feature Proposals

2006-11-16T04:19:47Z

Michel Fortin:

Problem Solving

2006-11-16T03:19:39Z

Michel Fortin:

This is an empty page that describes what should be documented about a problem and the different solutions proposed to address it. Feel free to copy this template to when creating a new page.

:''Brief description of the problem to solve.''

== Problem Description ==
:''Complete description of the problem, explanation of why the current markup is insufficient, etc.''

== Possible Solutions ==

=== My Solution ===
:''Brief description of the solution and of how it address the problem at hand.''

==== Details ====
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''

==== Limitations ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
:''Description of how and why browser vendors would take advantage of this feature.''

==== Adoption ====
:''Reasons why page authors would use this solution.''

== Usage ==
:''Some evidence is there that this feature is desparately needed on the web.''

Problem Solving

2006-11-16T03:19:03Z

Michel Fortin:

This is an empty page that describes what should be documented about a problem and the different solutions proposed to address it. Feel free to copy this template to when creating a new page.

:''Brief description of the problem to solve.''

== Problem Description ==
:''Complete description of the problem, explanation of why the current markup is insufficient, etc.''

== Possible Solutions ==

=== My Solution ===
:''Brief description of the solution and of how it address the problem at hand.''

==== Details ====
:''Explanation of the changes introduced by this solution. It explains how the document is processed, and how errors are handled. This should be very clear, including things such as event timing if the solution involves events, how to create graphs representing the data in the case of semantic proposals, etc.''

==== Limitations and Other Problems ====
:''Cases not covered by this solution in relation to the problem description; other problems with this solution, if any.''

==== Implementation ====
:''Description of how and why browser vendors would take advantage of this feature.''

==== Adoption ====
:''Reasons why page authors would use this solution.''

== Usage ==
:''Some evidence is there that this feature is desparately needed on the web.''