https://wiki.whatwg.org/api.php?action=feedcontributions&user=Ocolon&feedformat=atomWHATWG Wiki - User contributions [en]2024-03-28T09:32:11ZUser contributionsMediaWiki 1.39.3https://wiki.whatwg.org/index.php?title=Rationale&diff=5448Rationale2010-08-27T10:22:02Z<p>Ocolon: /* B, I, EM, STRONG, and MARK */ corrected typo</p>
<hr />
<div><!--<br />
notes of things to add<br />
1. explanation of <device> <br />
2. Why the WHATWG version is unversioned and called HTML5...<br />
3. explain difference between W3C and WHATWG version?<br />
4. Explain all the different uses of the header, hgroup, .... elements<br />
6. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025920.html - add this somewhere.<br />
7. add header/h1 and such explanation<br />
8. Better explain Defer/async<br />
9. skip links??<br />
10. http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23220.html<br />
--><br />
This document serves a rationale document for various parts of the HTML5 specification. Over time this page will be a complete rationale document.<br />
<br />
== General Rationale ==<br />
<br />
=== One Vendor, One Veto === <br />
<br />
Part of the the goal of the WHATWG is to document how web browsers actually handle HTML. As such browser vendors already have veto power - by not following the standard. The W3C and WHATWG do not have any enforcement power and can only write what browsers are willing to implement. Not removing features from the HTML standard that at least one browser vendor has stated they are unwilling to implement causes the HTML spec to not accurately document reality.<ref>http://lists.w3.org/Archives/Public/public-html/2009Jul/0257.html -- Re: Codecs for &lt;video&gt; and &lt;audio&gt;</a></ref><ref>http://lists.w3.org/Archives/Public/www-archive/2009Jul/0075.html --Formal Objection to One vendor, One Veto</ref>. The veto isn't a<br />
power that we grant browsers, it's a right that they earn on their own by virtue of having users. The minimum market share for a veto is somewhere around 1%.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-June/026897.html</ref><br />
<br />
=== Using elements where scripts "work" ===<br />
In addition, arguments were made that JavaScript-based implementations of details suffer from problems and limitations. Scripting behavior may be inconsistent across browsers, or even unavailable in some contexts. Accessibility is "bolted on", allowing more opportunity for author error, even when using libraries. The data model is not exposed in a consistent way in the markup. And matching native appearance and behavior across a range of platforms may be impractical.<ref>http://lists.w3.org/Archives/Public/public-html/2010Jun/att-0659/issue-93-decision.html</ref><br />
<br />
=== It isn't just about web browsers ===<br />
Web browsers are not the only programs that use HTML. Sometimes elements and features are needed even when browsers won't use them in any meaningful way. Document authoring tools, validators, search engines, screen readers, outliners, researchers, etc. all need and can use more information than a browser can. Furthermore if you provide more information than is currently used by browsers it opens up room for innovation.<br />
<br />
=== experimenting with features ===<br />
New unknown and untested features are unlikely to get accepted into the WHATWG spec. Browsers and browser extensions (like Google Gears) are expected to first establish use cases and implementation possibilities before the spec is changed. <ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22577.html</ref><br />
<br />
== Specific Elements ==<br />
<br />
=== Plaintext ===<br />
the &lt;plaintext&gt; element is a obsolete precursor to the &lt;pre&gt; element. <ref>http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt</ref> It is is now in the HTML5 spec as a method of stopping all further html token parsing. It lacks an end tag and just emits the rest of the page as plain text. It throws a parse error upon reaching the end of the document as it is not considered a valid element (and it is missing an end-tag).<br />
<br />
=== Image ===<br />
<br />
&lt;image&gt; element is treated as an alternate (but invalid) name for &lt;img&gt;. This is because some sites (around 0.2%<ref>Email from Ian Hickson; comment in spec source</ref>) make this mistake. It is already treated as an image by most major browsers.<br />
<br />
=== Meter and Progress (are not the same thing) ===<br />
<br />
&lt;meter&gt; is not just a special case of &lt;progress&gt;. The meter element represents a scalar measurement within a known range, such as storage quota usage, a relative popularity rating or relevance indicator. The control allows for the indication of high and low ranges, or minimum, maximum and optimal levels.<br />
<br />
The progress element, on the other hand, represents the completion progress of a task. This could be a real time indicator for background processing task (e.g. using Web Workers or a file upload). Progress elmements can also be in the indeterminate state, indicating that something is in progress, but it's completion progress is unknown.<ref>http://html5doctor.com/your-questions-answered-11/</ref><br />
<br />
The default rendering for a meter element could look something like the following:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_leveldiscrete.gif" alt="example of proper rendering for the meter element"><br />
<br />
Whereas, the default rendering for the progress element could look like this:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_determprogsizes.jpg"><br />
<br />
Alternatively, an indeterminate progress bar could also be styled as a throbber, which indicates progress without any indication of the remaining progress:<br />
<br />
<img src="http://developer.apple.com/mac/library/documentation/userexperience/conceptual/applehiguidelines/art/ct_asynchprogindsizes.jpg" alt="picture of the default apple throbber"><br />
<br />
See [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg01308.html Re: &lt;progress&gt; draft] for details.<br />
<br />
=== B, I, EM, STRONG, and MARK ===<br />
&lt;em&gt; is meant to indicate that some text is emphasized. &lt;strong&gt; is meant to confer importance upon text. &lt;b&gt; is meant for text that is stylistically offset from the rest of the text. Finally &lt;i&gt; is used to indicate that some text is meant to be read in an alternate mood.<br />
<br />
<!-- should I use a different sentence for each element or the same one? --><br />
For example <br />
Cats are &lt;em&gt;cute&lt;/em&gt; animals.<br />
could mean that cats are specifically cute.<br />
Cats are &lt;strong&gt;cute&lt;/strong&gt; animals.<br />
could mean that the word cute is in some way important<br />
Cats are &lt;b&gt;cute&lt;/b&gt; animals.<br />
could mean that the word cute is a new word (perhaps in a language lesson) but is not important<br />
Cats are &lt;i&gt;cute&lt;/i&gt; animals.<br />
could mean that the word cute is meant to be read in a different tone (sarcastically for example)<br />
Cats are &lt;mark&gt;cute&lt;/mark&gt; animals.<br />
means that the sentence is to be read normally but the word "cute" should be highlighted or marked in some way. This could be used for search terms on the page or alterations to an original text.<br />
<br />
=== IMG tag & alt text ===<br />
On certain types of pages adding alt text is impossible (like sites that the user could upload images but does not supply a description). Because of this the alt attribute is optional <ref>http://www.paciellogroup.com/resources/articles/altinhtml5.html</ref><ref>http://juicystudio.com/article/requiring-alt-attribute-html5.php</ref><ref>http://lists.w3.org/Archives/Public/public-html/2007Jun/0393.html</ref><br />
A longdesc attribute is not needed <ref>http://juicystudio.com/article/html5-image-element-no-alt.php</ref><br />
<br />
=== textarea ===<br />
<br />
The text area defaults to soft wrapping of the text area. The attribute @wrap can have one of the following values: soft, hard, or off.<ref>http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element-0</ref>. "off" is considered a non-conforming value because it appears to have no purpose other than a visual presentational effect. <ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022022.html</ref><ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22660.html</ref><br />
<br />
=== hgroup and other heading elements ===<br />
The point of &lt;hgroup&gt; is to hide the subtitle from the outlining algorithm.<br />
<br />
<!--<br />
=== br and linebreaks ===<br />
--><br />
=== details element === <br />
The <details> element is needed to provide an accessible way of reflecting a<br />
common application widget in HTML-based applications without requiring authors<br />
to use extensive scripting, ARIA, and platform-specific CSS to get the same<br />
effect.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13</ref><ref>http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails</ref><br />
<br />
== HTML parsing ==<br />
<br />
=== script element ===<br />
<br />
Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#restrictions-for-contents-of-script-elements restrictions for contents of script elements]? Why the [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#script-data-double-escaped-dash-dash-state complicated parsing rules for script elements]?<br />
<br />
See http://lists.w3.org/Archives/Public/public-html-comments/2010Mar/0017.html<br />
<br />
==== @DEFER and @ASYNC ====<br />
ASYNC tells the browsers to run the script with its following content at the SAME time(namely, asynchronously).<br />
DEFER tells the browsers to run the script LATER, and to run the following content first(the browsers will run the script until the page is ready).<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg22436.html</ref><br />
<br />
=== quirks mode ===<br />
<br />
The HTML parser has [http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody the following] behavior difference in quirks mode:<br />
<br />
<blockquote><dl><dt>A start tag whose tag name is "table"<br />
<dd>If the Document is not set to quirks mode, and the stack of open elements has a p element in scope, then act as if an end tag with the tag name "p" had been seen.</dl></blockquote><br />
<br />
Why? See http://hsivonen.iki.fi/last-html-quirk/<br />
<br />
=== ignored white space before head ===<br />
<br />
White space before the <code>&lt;head></code> tag is ignored. The main reason is that, given the markup<br />
<br />
<pre><br />
<!DOCTYPE html><br />
<html><br />
<head><br />
<title>Sample page</title><br />
...,<br />
</pre><br />
<br />
some people expect<br />
<br />
<pre><br />
document.documentElement.firstChild<br />
</pre><br />
<br />
to return the <code>head</code> element.<ref><cite>[http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-March/014148.html &#91;whatwg&#93; several messages about the tree construction stage of HTML parsing]</cite></ref><br />
<br />
<!-- needs to be confirmed --><br />
<!--<br />
=== Why all input elements are candidates for Constraint validation ===<br />
Some elements have the API but are barred because it makes it <br />
easier to loop through form.elements and do the validation stuff without <br />
checking if the validation stuff is available on the element. (Same reason <br />
<textarea> has .type.)<br />
<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027195.html</ref><br />
--><br />
<br />
== Failed proposals ==<br />
=== An "advert" tag for advertisements ===<br />
There is no advert tag because if users had an easy method of plainly disabling all ads from downloading or appearing content authors would cease to use the tag.<ref>http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013939.html</ref><br />
<br />
=== sandbox attribute on the html element ===<br />
HTML is the wrong level for disabling scripts or other features. This is the kind of thing we should do at the HTTP layer.<ref>http://www.w3.org/Bugs/Public/show_bug.cgi?id=8849</ref><ref>https://wiki.mozilla.org/Security/CSP</ref><br />
<br />
=== feature queries ===<br />
Various proposals have come up with the idea of being able to determine of a certain feature is available.<ref>http://lists.w3.org/Archives/Public/www-style/2009Dec/0130.html</ref> These fail for a variety of reasons:<br />
Part of the problem is that browser vendors will be economical with the truth. Marketing people always have an over-optimistic view of the compliance of their product, and will always give themselves the benefit of the doubt in borderline cases. Also, changing the compliance statement, to remove false claims that are exposed, is likely to a very low priority for the developers.<ref>http://lists.w3.org/Archives/Public/www-style/2010Jul/0097.html</ref><br />
With regard to CSS feature compliance: Remember that CSS<br />
provides hints and implementations don't have to accept those hints, and<br />
hardware may sometimes prevent their being implemented.<ref>http://lists.w3.org/Archives/Public/www-style/2003Nov/0000.html</ref> <br />
Some other reasons can be found in the footnotes.<ref>http://lists.w3.org/Archives/Public/www-style/2003Oct/0074.html</ref><ref>http://lists.w3.org/Archives/Public/www-style/2004Mar/0282.html</ref><br />
<br />
<!--<br />
=== secure key-value data stores ===<br />
[http://www.nczonline.net/blog/securestore-proposal/ A proposal for secure key-value stores for localstorage]<ref>http://www.mail-archive.com/whatwg@lists.whatwg.org/msg20754.html</ref><br />
--><br />
== Other Pages ==<br />
<br />
* [[Why no namespaces]]<br />
* [[Why no script implements]]<br />
* [[Why not reuse legend|Why not reuse legend or another ''mini-header'' element.]]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements Rationale for a variety of elements]<br />
* [[XHTML2 versus HTML5]]<br />
* [http://lists.w3.org/Archives/Public/public-html/2008Aug/0300.html &lt;meta http-equiv=content-language> ]<br />
* [http://www.w3.org/html/wg/wiki/RationalesGathering earlier page started with the same purpose.]<br />
* [http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements rationale for some new HTML5 elements]<br />
* [http://wiki.whatwg.org/wiki/FAQ WHATWG FAQ]<br />
<br />
== References ==<br />
<references/></div>Ocolonhttps://wiki.whatwg.org/index.php?title=Talk:RelExtensions&diff=5422Talk:RelExtensions2010-08-23T02:08:00Z<p>Ocolon: /* canonical-wwwnone */ added a question on handling different values in different files under one domain</p>
<hr />
<div>== Memorandum of understanding ==<br />
<br />
* http://wiki.whatwg.org/wiki/RelExtensions<br />
<br />
This Web page and associated Web services, if any, are provided with the understanding that providing them is cheap and relatively reliable, and that the URIs for these resources will not change after HTML5's completion, unless circumstances outside of the administrator's control force such a change.<br />
<br />
Organisations that believe these pages to be of vital importance are encouraged to put aside funds for the defence of this page should the need arise.<br />
<br />
--[[User:Hixie|Hixie]] 23:40, 10 December 2007 (UTC)<br />
<br />
== XFN noise ==<br />
<br />
Could XFN relations be separated? I'm under impression that they inflate the list.<br />
:I think that they should be removed, or moved to a microformat list where they would be named eg <code>xfn.friend</code>. I also want to emphasize that I dislike XFN as it implies to complex relation, that can be hard to resolve. For example "the maintaner of that document had that relation to the maintaner of the referenced document when the document was last edited/created" is not a good example of a relation. If we assume one knows the maintainer of the current document, how is one to know who the maintainer of the referenced document is? Someone could also be confused by the name of the relation and think that the current resource if a friend of the author…<br />
<br />
== Re: shortlink ==<br />
<br />
shortlink has also been proposed (on the blagosphere) as shorter and shorturl<br />
<br />
== On canonical-domain, canonical-wwwnone, and canonical-first ==<br />
<br />
Responding to your summary on the last reversion:<br />
<br />
Two were analogous services, as noted, not the exact services. The concepts were discussed by Google and were justified there.<br />
<br />
For canonical-wwwnone, for the concept underlying it, Google says this at the linked page under "Set your preferred domain":<br />
"Setting your preferred domain tells Google which version of your site's URL (http://www.example.com or http://example.com) you prefer.<br />
"If you set your preferred domain as http://example.com, we'll treat links to http://www.example.com exactly the same as links to your preferred domain."<br />
<br />
Since Google supports this by requiring the site owner to tell Google through a tool apparently not on the website owner's site, I proposed a method apropos to all search engines that wish to implement it.<br />
<br />
For canonical-domain, while the same Google page supports only intradomain canonicalization, it does support that (see under "Specify the canonical link for each version of the page"). I extended their concept to interdomain canonicalization, because many institutions have multiple domains for identical content or the same website. An owner of one website with multiple domains who wants to do well in search engine results would likely prefer that all external inbound links point to one domain but can't ask everyone else to edit their links without risking links being deleted and a lowering in search results, and just asking everyone is a bunch of work. My proposal reduces the workload and eliminates that risk while raising site credibility that helps with positioning in search engine results.<br />
<br />
Examples of domains that probably share sites (although I didn't drill down to check beyond the home pages and didn't have the plugin to view the home page/s on the first pair): <http://esbnyc.com/> and <http://empirestatebuilding.com/>, which might redirect, and <http://www.networksolutions.com/> and <netsol.com>, as I typed it, which redirects.<br />
<br />
While redirection is an easy solution, the site owner might prefer to display a message to users of one domain and not the other as part of educating the general public about the preferred domain (as used to be the case at yaho.com (one "o")). In that case, canonical-domain would inform search engines who wish to implement it while allowing the site owner to educate the part of the public that types the wrong name. For example, in New York City the agency that intervenes for abused children is still widely known by initials that have been abolished for 40 years (I heard it in conversation on the 15th of this month).<br />
<br />
However, I do see one defect with my proposal. Where a rel link works, a rev link can usually be expected to work, and rev for canonical-domain could be used to steal traffic from a competitor or other site. So I will add that rev must be meaningless.<br />
<br />
I will do the same for canonical-wwwnone, since I understand that it's possible, albeit unusual, to have separate websites for www and bare forms of the same domain, depending on the host's architecture, which means it's possible, albeit very unlikely, that the two websites could be under separate managers, and perhaps separate owners, who bitterly compete. So I will add that rev must be meaningless for that keyword, too.<br />
<br />
For canonical-first, I did not cite Google. Because it is possible to have a canonical set of pages and one noncanonical page in situations where the keywords alternate and print wouldn't be technically adequate or semantically apt, and the canonical set of pages might not fully occupy a directory, it might be more convenient to have canonical-first as shorthand. That's easier because only one page needs coding rather than two or more. Because it is shorthand, however, it is more dispensable, if people would like to reject it. I'm putting it back for the time being, i.e., for decision, since it seems to have been removed on the basis of the Google position, but I hadn't asserted that Google supported it. I will also add that rev must be meaningless for this keyword, too.<br />
<br />
Thank you.<br />
[[User:Nick|Nick]] 20:10, 20 September 2009 (UTC)<br />
<br />
== On footnote, note, and jump ==<br />
<br />
The footnote and jump both seem useful if a browser opens an additional window so that the main text or prejump text, respectively, remains visible, especially useful for endnotes after long texts. This is analogous to the behavior for sidebar [http://www.w3.org/TR/html5/history.html#link-type-sidebar (HTML5, working draft of 8-25-09, section 6.12.3.16)]. To that end, I'm renaming this proposed keyword ''note'', as a more generic name, and adding ''footnote'' and ''endnote'' to the description. I don't know what a sidenote is and, while I can guess, I don't recall it being used or mentioned in literature, a local central public librarian doesn't remember ever seeing one, my OOo 3.0.0 spellchecker rejects it, and a callout isn't a sidenote, although I suppose this link pointing to a callout would be okay. While I'm taking ''sidenote'' out of the synonymy, which is only for legacy support (I gather it wasn't a past rel keyword), I'm still adding it to the description, in case, to preserve the original proposer's intent.<br />
<br />
Thanks. [[User:Nick|Nick]] 00:33, 8 October 2009 (UTC)<br />
<br />
== canonical-wwwnone ==<br />
<br />
=== Error in the description ===<br />
<br />
Currently it says:<br />
<br />
<pre>The rel value is the form preferred for indexing, e.g., rel="http://example.net".</pre><br />
<br />
I am pretty sure this should be:<br />
<br />
<pre>The href value is the form preferred for indexing, e.g., href="http://example.net".</pre> [[User:Ocolon|Ocolon]] 09:40, 21 August 2010 (UTC)<br />
<br />
=== Redundancy ===<br />
<br />
[[User:Nick|Nick]], my impression is that your proposal <code>canonical-domain</code> already covers everything your proposal <code>canonical-wwwnone</code> achieves. Wouldn't it be better to concentrate on the more powerful <code>canonical-domain</code> and drop <code>canonical-wwwnone</code>? [[User:Ocolon|Ocolon]] 09:40, 21 August 2010 (UTC)<br />
<br />
=== Responses ===<br />
<br />
==== Error ====<br />
<br />
You're right about href; that's my stupid error. I corrected it.<br />
<br />
==== Usage conflict ====<br />
<br />
Since canonical-domain is for the case where someone owns widgetstore.example and bigfabulouswidgetstore.example and would rather everyone find the latter in search engine results, folding canonical-wwwnone into canonical-domain raises a question: Could there be a case (often enough) in which the site owner would '''not''' want a preference between the www and bare forms of bigfabulouswidgetstore.example? I understand that there are unusual but real cases in which an owner has separate sites for www and no-www.<br />
<br />
I assume there is a realistic although small frequency, so I'd leave the range of rel values in their hands, plus keep the clarity for page authors of there being separate rel values for somewhat different purposes. But if the case is too obscure and too rare, maybe it should be folded in. In that case, the multi-domain-name site owner will either not pick canonicality at all (unlikely except for amateurs) or will have to choose either bare or www when doing so.<br />
<br />
One possible use case would be measuring marketing success by comparing sales by what people typed, thus what advertising they saw. Getting people to say what ad they saw so often fails that companies use many department numbers, 800 phone numbers, domain names, and so on. Bare-or-www in a log might serve that same purpose.<br />
<br />
(I'm using the .example TLD per RFC 2606, akin to example.net, in case subdomains of the latter are considered a special case.)<br />
<br />
Thanks. [[User:Nick|Nick]] 17:42, 22 August 2010 (UTC)<br />
<br />
: Thank you for your examples – I see that cases like the ones you describe can occur. However, bigfabulouswidgetstore.example and www.bigfabulouswidgetstore.example are de facto two different domains, because technically "www" is a subdomain like "wiki" or any other prefix would be. Therefore <code>canonical-wwwnone</code> is already covered by <code>canonical-domain</code> (it doesn't have to be explicitly folded into it anymore), unless it is explicitly defined as not being implied. I don't think such a definition would be justified by the given example.<br />
<br />
: Let's have a closer look at two cases that are similar to the scenario you described:<br />
<br />
:* Case 1: A website owner wants to name bigfabulouswidgetstore.example without www as <code>canonical-domain</code> for widgetstore.example. He also wants to name www.bigfabulouswidgetstore.example with www as <code>canonical-domain</code> for appstore.example. And he doesn't want to define a general preference for bigfabulouswidgetstore.example or www.bigfabulouswidgetstore.example.<br />
:** Does this work when <code>canonical-domain</code> includes the power of <code>canonical-wwwnone</code> as well ("www-sensitive")? Yes. That's because a general preference for using bigfabulouswidgetstore.example with or without www, meaning one is the canonical domain of the other, would only be defined if <code>canonical-domain</code> was set with one of these values at (www.)bigfabulouswidgetstore.example. Setting different values at appstore.example and widgetstore.example is perfectly possible and only affects appstore.example and widgetstore.example, not (www.)bigfabulouswidgetstore.example.<br />
:** Does this work if <code>canonical-domain</code> does not differentiate between a domain with or without www ("www-neutral")? No. The websites appstore.example and widgetstore.example can only define an unspecific (www.)bigfabulouswidgetstore.example as canonical domain name for both or with the add of <code>canonical-wwwnone</code> at (www.)bigfabulouswidgetstore.example a general preference.<br />
<br />
: It turns out that the "www-sensitive" <code>canonical-domain</code> allone offers more possibilities in this case than <code>canonical-wwwnone</code> and/or a "www-neutral" <code>canonical-domain</code>.<br />
<br />
:* Case 2: A website owner wants to specify a <code>canonical-domain</code> at widgetstore.example, namely (www.)bigfabulouswidgetstore.example, without specifying whether bigfabulouswidgetstore.example or www.bigfabulouswidgetstore.example should be the canonical domain for widgetstore.example. I'm not sure which benefit could arise from this but let's consider it anyway:<br />
:** This is clearly not possible with a single "www-sensitive" <code>canonical-domain</code>. It would be possible to use two different "www-sensitive" <code>canonical-domain</code>s though. This would look weird and I wouldn't recommend to allow this, but finally that's what the domain owner wants in this scenario: Two canonical domains, with and without www.<br />
:** Does this make more sense with a "www-neutral" <code>canonical-domain</code>? I don't think it does: While it doesn't look as weird it does the same, it assigns two domains, with and without www. However, there's a side effect here: greatfruitstore.example and www.greatfruitstore.example become impossible <code>canonical-domain</code> values if these sites don't share the same content (or else "half of the canonical domain" would be defunct or misleading).<br />
<br />
: It seems that for the advantage of making a rare case more elegantly possible "www-neutral" <code>canonical-domain</code>s could only be used when the www- and non-www version of the href-attribute both exist and share the same content.<br />
<br />
: So, although you are right that a "www-sensitive" <code>canonical-domain</code> doesn't satisfy all possible scenarios, I believe it works in more scenarios than a "www-neutral" <code>canonical-domain</code> would.<br />
<br />
: From keeping <code>canonical-domain</code> "www-sensitive" follows that <code>canonical-wwwnone</code> doesn't provide extra functionality and could be dropped (it could still be supported as a special case of <code>canonical-domain</code> for historical reasons if used somewhere but shouldn't be used in new webpages).<br />
<br />
I'm sorry these case explanations became so long. Might look complicated. Actually your proposal <code>canonical-domain</code> is simple yet powerful. Google webmaster tools show there's a need for this. I like this one very much. [[User:Ocolon|Ocolon]] 00:48, 23 August 2010 (UTC)<br />
<br />
=== Handling different values in different files under one domain ===<br />
<br />
Another thought on <code>canonical-domain</code>/<code>canonical-wwwnone</code>: Is this to be handled individually for each file or domain-wide? If this should be interpreted domain-wide, how should conflicting values in different files be handled?<br />
<br />
Example:<br />
* <nowiki>http://foo.example/001.html</nowiki> contains <code><nowiki><meta name="canonical-domain" href="http://one.example/"></nowiki></code><br />
* <nowiki>http://foo.example/002.html</nowiki> contains <code><nowiki><meta name="canonical-domain" href="http://two.example/"></nowiki></code><br />
<br />
On the one hand it seems to be more appropriate to have this applied for each file individually (a link-tag in a file usually adds meta information just to this file, that's why it's in this file's head). On the other hand applying this to one file only would "degrade" <code>canonical-domain</code>/<code>canonical-wwwnone</code> to something very similar to <code>canonical</code> which works also on a file basis.<br />
<br />
Considering this, it might even be cleverer to do this with [http://en.wikipedia.org/wiki/Robots.txt robots.txt]? [[User:Ocolon|Ocolon]] 02:08, 23 August 2010 (UTC)</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Time_element&diff=5421Time element2010-08-23T01:17:39Z<p>Ocolon: /* Fuzzy dates */ ask whether the introduction should be edited to better reflect what is proposed</p>
<hr />
<div>Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].<br />
<br />
<br />
HTML5's new &lt;time&gt; element presents a huge opportunity to improve the publishing of datetime information on the web, the biggest opportunity since the introduction of hCalendar and other time-based microformats.<br />
<br />
However, the &lt;time&gt; element currently has several shortcomings that both prevent it from being used in numerous use-cases, and are suboptimal for authoring and data longevity.<br />
<br />
Please read the following proposals for improving the &lt;time&gt; element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.<br />
<br />
<br />
Thanks for your consideration,<br />
<br />
[[User:Tantek|Tantek]] (and other proposal authors).<br />
<br />
<br />
Please add new proposals to the end of the most relevantly related section, or if you're not sure where (or if there is no related section), at the end of the [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.<br />
<br />
=Date granularity=<br />
== year only ==<br />
The time element should accept just a year.<br />
;ISO8601 syntax<br />
:YYYY<br />
=== year only use cases ===<br />
use case research:<br />
* http://microformats.org/wiki/birthday-examples#year_only<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]<br />
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)<br />
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]<br />
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:<br />
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]<br />
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]<br />
*Citations from a bibliography which list two or more works by the same author disambiguate them by year<br />
*Commerce<br />
** "a piece of jewellery hallmarked 1933"<br />
** "a 1973 Chevy"<br />
*Sport<br />
**2008 Olympics<br />
**1966 World Cup<br />
*Awards<br />
**"1973 Oscar for best film"<br />
**"1988 Nobel Peace Prize"<br />
*Restyling dates for localisation and to follow user conventions<br />
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)<br />
* Relative dates in texts: news websites and blogs often use phrases such as<br />
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],<br />
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]<br />
<br />
=== year only discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.<br />
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year only related posts ===<br />
Related posts (listed with quotes directly related to year only) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote><br />
<br />
== year month only ==<br />
The time element should accept just a year and a month.<br />
;ISO8601 syntax<br />
:YYYY-MM<br />
<br />
=== year month use cases ===<br />
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)<br />
** http://www.flickr.com/photos/tantek/archives/<br />
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)<br />
* output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]<br />
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)<br />
* Restyling dates for localisation and to follow user conventions<br />
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)<br />
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:<br />
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]<br />
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]<br />
<br />
=== year month discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[User:Tantek|Tantek]] I think the blog archives use case (where blogs often link to their archives by a specific month and year) is sufficient to justify adding this capability to the time element. Content hosting sites like Flickr also list archives by specific year/month, e.g. see http://www.flickr.com/photos/tantek/archives/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.<br />
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year month related posts ===<br />
Related posts (listed with quotes directly related to year-month) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote><br />
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote><br />
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote><br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the <nowiki>[sic]</nowiki> it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.</blockquote><br />
<br />
== year week only ==<br />
The time element should accept just a year and a week number.<br />
;ISO8601 syntax<br />
:YYYY-WNN<br />
;use case research<br />
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.<br />
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
;reasoning<br />
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code><br />
<br />
See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] per good design of impedance matching date time inputs.<br />
* ...<br />
</div><br />
<br />
== month day only ==<br />
The time element should accept just a month and a day.<br />
;ISO8601 syntax<br />
:--MM-DD<br />
;use case research<br />
:http://microformats.org/wiki/birthday-examples#month_and_day_only<br />
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF - see external links<br />
:Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 "radiz" implied support for --MM-DD with the use case question: "How to use &lt;time&gt; with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per [http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF, e.g. birthdays, wedding anniversaries - see external links)<br />
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.<br />
* ...<br />
</div><br />
<br />
= HTML5 internal consistency =<br />
== impedance match new date time inputs ==<br />
The time element should be able to represent every granularity of times and dates that the new date time <code>&lt;input&gt;</code> elements allow. Here is a list of all the date time <code>&lt;input&gt;</code> elements along with the corresponding <code>&lt;time&gt;</code> element usage (if applicable)<br />
<br />
<pre><nowiki><br />
<input type="date"> - <time>YYYY-MM-DD</time><br />
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time><br />
<input type="month"> - not supported in current time element<br />
<input type="week"> - not supported in current time element<br />
<input type="time"> - <time>HH:MM:SS</time><br />
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time><br />
New proposed input elements:<br />
<input type="year"> - not supported in current time element<br />
<input type="month-day"> - not supported in current time element<br />
</nowiki></pre><br />
<br />
In particular the <code>&lt;time&gt;</code> element is missing support for the following date inputs:<br />
<br />
* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].<br />
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].<br />
<br />
In addition, if the new proposed [[input]] elements are accepted, the respective time element support should be added as well:<br />
<br />
* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].<br />
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]]<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]]<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]]<br />
* ...<br />
</div><br />
<br />
= Proposals extending scope =<br />
<br />
== Fuzzy dates ==<br />
The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and eras ("Edwardian", "bronze age", "Jurassic")".<br />
<br />
;Use cases:<br />
:1. "... an application that might input Wikipedia data and output an annotated visual timeline. For movements or trends rather than events, it would need to output rough dates and date ranges like 2001-2003, rather than exact dates."[http://www.zeldman.com/superfriends/guide/#time] <br />
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.<br />
:2. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]<br />
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion<br />
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]<br />
:4 ...<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)<br />
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.<br />
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)<br />
* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:<br />
** certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)<br />
** certainty attribute takes an ISO8601 duration.<br />
** alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful)<br />
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre><br />
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 Bruce Darcus says]: "[While] I definitely think the use case is important...<br />
**"...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] I like the concept, but the syntax should be less verbose and more precise.<br />
** "Circa" can be indicated with a tilde prefix "~"<br />
** Ranges can use [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).<br />
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.<br />
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)<br />
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)<br />
**It is not proposed to define terms like "bronze age" here; but to cater for a) any definitions emerging from the EDTF efforts and/or b) a publisher using their own definition, such as, say <code><time datetime="[3300-1200 BC]">Bronze age</time></code>. It's not that "this isn't well thought through" so much as "this is brought here for the community to think through". [[User:Pigsonthewing|Pigsonthewing]] 22:34, 22 August 2010 (UTC)<br />
*** I wrote "this doesn't seem to be well thought through '''yet'''", of course implying this can change. Thanks for the details on the "bronze age" example. Should the introduction sentence to the [http://wiki.whatwg.org/index.php?title=Time_element&oldid=5419#Fuzzy_dates fuzzy date section] be edited to reflect this? Currently it does propose "bronze age" etc. as examples for future time values. [[User:Ocolon|Ocolon]] 01:17, 23 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== Calendar scale ==<br />
The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 emergent vCard 4 specification], to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using one of a set of pre-defined CALSCALE types.<br />
<br />
=== Calendar scale example ===<br />
Example:<br />
<br />
<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre><br />
<br />
=== Calendar scale processing ===<br />
User agents could be instructed to ignore any unrecognised CALSCALE value, treating the contents of the element as plain text for data-processing (but not styling) purposes. This would prevent, for example the processing of the above example by an agent written to deal only with Gregorian dates. (At some point, CSS should recognise CALSCALE, allowing authors to, say, style all Julian dates differently to Gregorian dates.)<br />
<br />
=== Calendar scale use cases ===<br />
Use case research:<br />
* The Wikipedia timeline example in [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element] proposes to map a timeline of dates from Wikipedia (e.g. 2001-2003 Gregorian). However, Wikipedia includes several thousand articles about or referring to <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - target site currently broken, but worked previously; a fix is promised shortly) can only map Wikipedia's Gregorian dates, because there is currently no way to mark up Julian dates in a machine-readable format. The use of CALSCALE as suggested would allow this implementation and others to map all of these dates. (Note that the implementation works with any site, not just Wikipedia, parsing hCalendar microformats.)<br />
* Julian dates in [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]: <br />
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.<br />
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar<br />
<br />
=== Calendar scale discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)<br />
* 0 [[User:Tantek|Tantek]] - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.<br />
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.<br />
**Dates from 2000+ years ago in non-European calendars such as those you mention can be converted to Julian calendar dates (but not Gregorian dates), just as modern dates in those calendars can be converted to the Gregorian calendar. The use of Julian extends the range of dates which can be expressed. [[User:Pigsonthewing|Pigsonthewing]] 22:40, 22 August 2010 (UTC)<br />
* …<br />
</div><br />
<br />
=== Calendar scale related posts ===<br />
Related posts (listed with quotes directly related to Calendar scale) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like [(refers to prototype CALSCALE)] where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale<br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.<br />
<br />
= Syntax improvements for reducing DRY violations =<br />
<br />
We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).<br />
<br />
This experience yielded the microformats adoption of the DRY principle - '''D'''on't '''R'''epeat '''Y'''ourself - in application to (meta)dataformat designs and techniques.<br />
<br />
<br />
The &lt;time&gt; element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).<br />
<br />
This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the &lt;abbr&gt; element.<br />
<br />
Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related &lt;abbr&gt; problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).<br />
<br />
http://microformats.org/wiki/value-class-pattern#Date_and_time_values<br />
<br />
We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 &lt;time&gt; element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).<br />
<br />
Accordingly, please consider the following &lt;time&gt; syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.<br />
<br />
<br />
== composite nested time elements ==<br />
A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.<br />
<br />
This is intended as a cleaner way to provide functionality equivalent to the microformats [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])<br />
<br />
<pre><nowiki><br />
<time class="published" datetime="2009-12-13T17:43:29"><br />
Sunday, December 13th, 2009<br />
5:43pm<br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
and have the parent &lt;time&gt; element composite a complete datetime from the child &lt;time&gt; elements with separate date and time.<br />
<br />
The <em>separate</em> date and time <code>datetime</code> attribute values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the "same" value as the in-content text, thus resulting in incrementally more accurate data over time.<br />
<br />
This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== background ===<br />
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"<br />
datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).<br />
<br />
=== microformats value class pattern DRY advantage ===<br />
With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<span class="dtstart"><br />
<span class="value">18:00</span> on <br />
<span class="value">2010-08-05</span><br />
</span>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.<br />
<br />
Disadvantage: the loss of the HTML5 time semantic and related processing.<br />
<br />
=== simple nested time example improvement ===<br />
We'd like to have our <code>&lt;time&gt;</code> and date time separation as well, so this should work:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
=== summary of updated datetime algorithm ===<br />
In short: the algorithm for determining the "datetime" of a time element should:<br />
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)<br />
# check for nested &lt;time&gt; elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)<br />
# use the complete contents of the &lt;time&gt; element as its datetime value.<br />
<br />
Essentially, step 2 is added to enable composing nested child time elements.<br />
<br />
=== applicability to microdata ===<br />
All of the aforementioned advantages for microformats apply to microdata use of the &lt;time&gt; element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).<br />
<br />
=== nested time example with datetime attribute ===<br />
If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> information), thus reducing the risk of data divergence due to duplication.<br />
<br />
=== nested time example with two datetimes ===<br />
If the publisher prefers to publish a "localized" form of times, they can do that as well:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time datetime="18:00:00">6pm</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.<br />
<br />
The AM/PM proposal below further helps improve this example.<br />
<br />
=== nested time discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.<br />
* -1 [[User:Pigsonthewing|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time datetime="2005-10-05/2005-10-07"><br />
<time class="dtstart">October 5</time>-<br />
<time class="dtend">7</time><br />
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div></nowiki></pre><br />
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== am pm and coarser time parsing ==<br />
Right now time values inside a &lt;time&gt; element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)<br />
<br />
<pre><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time>5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.<br />
<br />
This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== am pm syntax summary ===<br />
<br />
In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).<br />
<br />
In short, the current &lt;time&gt; element only allows for the following time syntax:<br />
<br />
* HH:MM:SS - where HH is in 24 hour time.<br />
<br />
This proposal expands the allowed time syntax to:<br />
<br />
* HH:MM:SSam<br />
* HH:MM:SSpm<br />
* HH:MMam<br />
* HH:MMpm<br />
* HHam<br />
* HHpm<br />
<br />
=== am pm syntax details ===<br />
* '''periods, white-space, case-insensitivity.''' "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").<br />
* '''implied 00 minutes and seconds.''' When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;<br />
* '''handling of 12am and 12pm.''' "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).<br />
<br />
=== simple am pm example ===<br />
A simple example:<br />
<br />
<pre><nowiki><br />
I went to the cafe at <time>6pm</time>.<br />
</nowiki></pre><br />
<br />
Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.<br />
<br />
=== am pm example with nested time elements ===<br />
Example (uses aforementioned composite nested time element proposal as well)<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>6pm</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: again, this reduces DRY violations, in this case further improving upon the composite nested time elements case.<br />
<br />
=== am pm discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - in practice we in the microformats community have found that enabling users to markup am/pm times leads to many more cases where we can avoid violating DRY and thus encourage greater accuracy over time for such content. I think the HTML5 &lt;time&gt; element presents us with the opportunity to more cleanly markup times (than what we've been able to do with the aforementioned microformats value-class-pattern), and thus we should do so.<br />
* 0(query) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.<br />
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
=== am pm FAQ ===<br />
==== noon and midnight ====<br />
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?<br />
<br />
'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.<br />
<br />
==== am pm i18n ====<br />
'''Question:''' How does this internationalise "am" and "pm", for languages which do not use them? <br />
<br />
'''Answer:''' For languages that do not use "am" or "pm", the am pm proposal does not confer any additional advantage.<br />
<br />
= Minor editorial fixes =<br />
<br />
== Update hCalendar example ==<br />
<br />
Summary: please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.<br />
<br />
=== Current example ===<br />
<br />
The HTML5 spec currently has this hCalendar example:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>:<br />
<time class="dtstart" datetime="2007-10-05">October 5</time> -<br />
<time class="dtend" datetime="2007-10-20">19</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
<br />
(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)<br />
</nowiki></pre><br />
<br />
This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.<br />
<br />
=== Updated example ===<br />
<br />
Here is a suggested update:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time class="dtstart" datetime="2005-10-05">October 5</time>-<br />
<time class="dtend" datetime="2005-10-07">7</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
</nowiki></pre><br />
<br />
The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue dtend issue] for details).<br />
<br />
= Miscellaneous proposals =<br />
<br />
==Choose different default date==<br />
The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.<br />
<br />
A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* 0 (comment) [[User:Pigsonthewing|Andy Mabbett]] - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?<br />
* -1 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.<br />
* ...<br />
</div><br />
<br />
= Issues without specific proposals =<br />
==Specification ambiguities==<br />
The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.<br />
<br />
Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.<br />
<br />
<br />
= See Also =<br />
* [[input]] - the input element, related proposals expanding upon the new datetime inputs.<br />
<br />
= External links =<br />
<br />
== Tag ==<br />
Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time <!-- links to follow --><br />
<br />
== Prior discussion ==<br />
<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]<br />
* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith<br />
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]<br />
<br />
== Resources ==<br />
<br />
* [http://www.loc.gov/standards/datetime/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)<br />
** [http://www.loc.gov/standards/datetime/proposals.html EDTF proposals] (use-cases)<br />
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]<br />
** mailing list was datetime-comments@w3.org. - anyone have archives URL?<br />
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)<br />
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]<br />
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates<br />
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]<br />
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]<br />
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]<br />
* Dublin Core terms, e.g. <br />
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal<br />
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]<br />
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created<br />
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]<br />
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Talk:RelExtensions&diff=5420Talk:RelExtensions2010-08-23T00:48:01Z<p>Ocolon: /* Usage conflict */ further notes on why canonical-domain covers canonical-wwwnone already</p>
<hr />
<div>== Memorandum of understanding ==<br />
<br />
* http://wiki.whatwg.org/wiki/RelExtensions<br />
<br />
This Web page and associated Web services, if any, are provided with the understanding that providing them is cheap and relatively reliable, and that the URIs for these resources will not change after HTML5's completion, unless circumstances outside of the administrator's control force such a change.<br />
<br />
Organisations that believe these pages to be of vital importance are encouraged to put aside funds for the defence of this page should the need arise.<br />
<br />
--[[User:Hixie|Hixie]] 23:40, 10 December 2007 (UTC)<br />
<br />
== XFN noise ==<br />
<br />
Could XFN relations be separated? I'm under impression that they inflate the list.<br />
:I think that they should be removed, or moved to a microformat list where they would be named eg <code>xfn.friend</code>. I also want to emphasize that I dislike XFN as it implies to complex relation, that can be hard to resolve. For example "the maintaner of that document had that relation to the maintaner of the referenced document when the document was last edited/created" is not a good example of a relation. If we assume one knows the maintainer of the current document, how is one to know who the maintainer of the referenced document is? Someone could also be confused by the name of the relation and think that the current resource if a friend of the author…<br />
<br />
== Re: shortlink ==<br />
<br />
shortlink has also been proposed (on the blagosphere) as shorter and shorturl<br />
<br />
== On canonical-domain, canonical-wwwnone, and canonical-first ==<br />
<br />
Responding to your summary on the last reversion:<br />
<br />
Two were analogous services, as noted, not the exact services. The concepts were discussed by Google and were justified there.<br />
<br />
For canonical-wwwnone, for the concept underlying it, Google says this at the linked page under "Set your preferred domain":<br />
"Setting your preferred domain tells Google which version of your site's URL (http://www.example.com or http://example.com) you prefer.<br />
"If you set your preferred domain as http://example.com, we'll treat links to http://www.example.com exactly the same as links to your preferred domain."<br />
<br />
Since Google supports this by requiring the site owner to tell Google through a tool apparently not on the website owner's site, I proposed a method apropos to all search engines that wish to implement it.<br />
<br />
For canonical-domain, while the same Google page supports only intradomain canonicalization, it does support that (see under "Specify the canonical link for each version of the page"). I extended their concept to interdomain canonicalization, because many institutions have multiple domains for identical content or the same website. An owner of one website with multiple domains who wants to do well in search engine results would likely prefer that all external inbound links point to one domain but can't ask everyone else to edit their links without risking links being deleted and a lowering in search results, and just asking everyone is a bunch of work. My proposal reduces the workload and eliminates that risk while raising site credibility that helps with positioning in search engine results.<br />
<br />
Examples of domains that probably share sites (although I didn't drill down to check beyond the home pages and didn't have the plugin to view the home page/s on the first pair): <http://esbnyc.com/> and <http://empirestatebuilding.com/>, which might redirect, and <http://www.networksolutions.com/> and <netsol.com>, as I typed it, which redirects.<br />
<br />
While redirection is an easy solution, the site owner might prefer to display a message to users of one domain and not the other as part of educating the general public about the preferred domain (as used to be the case at yaho.com (one "o")). In that case, canonical-domain would inform search engines who wish to implement it while allowing the site owner to educate the part of the public that types the wrong name. For example, in New York City the agency that intervenes for abused children is still widely known by initials that have been abolished for 40 years (I heard it in conversation on the 15th of this month).<br />
<br />
However, I do see one defect with my proposal. Where a rel link works, a rev link can usually be expected to work, and rev for canonical-domain could be used to steal traffic from a competitor or other site. So I will add that rev must be meaningless.<br />
<br />
I will do the same for canonical-wwwnone, since I understand that it's possible, albeit unusual, to have separate websites for www and bare forms of the same domain, depending on the host's architecture, which means it's possible, albeit very unlikely, that the two websites could be under separate managers, and perhaps separate owners, who bitterly compete. So I will add that rev must be meaningless for that keyword, too.<br />
<br />
For canonical-first, I did not cite Google. Because it is possible to have a canonical set of pages and one noncanonical page in situations where the keywords alternate and print wouldn't be technically adequate or semantically apt, and the canonical set of pages might not fully occupy a directory, it might be more convenient to have canonical-first as shorthand. That's easier because only one page needs coding rather than two or more. Because it is shorthand, however, it is more dispensable, if people would like to reject it. I'm putting it back for the time being, i.e., for decision, since it seems to have been removed on the basis of the Google position, but I hadn't asserted that Google supported it. I will also add that rev must be meaningless for this keyword, too.<br />
<br />
Thank you.<br />
[[User:Nick|Nick]] 20:10, 20 September 2009 (UTC)<br />
<br />
== On footnote, note, and jump ==<br />
<br />
The footnote and jump both seem useful if a browser opens an additional window so that the main text or prejump text, respectively, remains visible, especially useful for endnotes after long texts. This is analogous to the behavior for sidebar [http://www.w3.org/TR/html5/history.html#link-type-sidebar (HTML5, working draft of 8-25-09, section 6.12.3.16)]. To that end, I'm renaming this proposed keyword ''note'', as a more generic name, and adding ''footnote'' and ''endnote'' to the description. I don't know what a sidenote is and, while I can guess, I don't recall it being used or mentioned in literature, a local central public librarian doesn't remember ever seeing one, my OOo 3.0.0 spellchecker rejects it, and a callout isn't a sidenote, although I suppose this link pointing to a callout would be okay. While I'm taking ''sidenote'' out of the synonymy, which is only for legacy support (I gather it wasn't a past rel keyword), I'm still adding it to the description, in case, to preserve the original proposer's intent.<br />
<br />
Thanks. [[User:Nick|Nick]] 00:33, 8 October 2009 (UTC)<br />
<br />
== canonical-wwwnone ==<br />
<br />
=== Error in the description ===<br />
<br />
Currently it says:<br />
<br />
<pre>The rel value is the form preferred for indexing, e.g., rel="http://example.net".</pre><br />
<br />
I am pretty sure this should be:<br />
<br />
<pre>The href value is the form preferred for indexing, e.g., href="http://example.net".</pre> [[User:Ocolon|Ocolon]] 09:40, 21 August 2010 (UTC)<br />
<br />
=== Redundancy ===<br />
<br />
[[User:Nick|Nick]], my impression is that your proposal <code>canonical-domain</code> already covers everything your proposal <code>canonical-wwwnone</code> achieves. Wouldn't it be better to concentrate on the more powerful <code>canonical-domain</code> and drop <code>canonical-wwwnone</code>? [[User:Ocolon|Ocolon]] 09:40, 21 August 2010 (UTC)<br />
<br />
=== Responses ===<br />
<br />
==== Error ====<br />
<br />
You're right about href; that's my stupid error. I corrected it.<br />
<br />
==== Usage conflict ====<br />
<br />
Since canonical-domain is for the case where someone owns widgetstore.example and bigfabulouswidgetstore.example and would rather everyone find the latter in search engine results, folding canonical-wwwnone into canonical-domain raises a question: Could there be a case (often enough) in which the site owner would '''not''' want a preference between the www and bare forms of bigfabulouswidgetstore.example? I understand that there are unusual but real cases in which an owner has separate sites for www and no-www.<br />
<br />
I assume there is a realistic although small frequency, so I'd leave the range of rel values in their hands, plus keep the clarity for page authors of there being separate rel values for somewhat different purposes. But if the case is too obscure and too rare, maybe it should be folded in. In that case, the multi-domain-name site owner will either not pick canonicality at all (unlikely except for amateurs) or will have to choose either bare or www when doing so.<br />
<br />
One possible use case would be measuring marketing success by comparing sales by what people typed, thus what advertising they saw. Getting people to say what ad they saw so often fails that companies use many department numbers, 800 phone numbers, domain names, and so on. Bare-or-www in a log might serve that same purpose.<br />
<br />
(I'm using the .example TLD per RFC 2606, akin to example.net, in case subdomains of the latter are considered a special case.)<br />
<br />
Thanks. [[User:Nick|Nick]] 17:42, 22 August 2010 (UTC)<br />
<br />
: Thank you for your examples – I see that cases like the ones you describe can occur. However, bigfabulouswidgetstore.example and www.bigfabulouswidgetstore.example are de facto two different domains, because technically "www" is a subdomain like "wiki" or any other prefix would be. Therefore <code>canonical-wwwnone</code> is already covered by <code>canonical-domain</code> (it doesn't have to be explicitly folded into it anymore), unless it is explicitly defined as not being implied. I don't think such a definition would be justified by the given example.<br />
<br />
: Let's have a closer look at two cases that are similar to the scenario you described:<br />
<br />
:* Case 1: A website owner wants to name bigfabulouswidgetstore.example without www as <code>canonical-domain</code> for widgetstore.example. He also wants to name www.bigfabulouswidgetstore.example with www as <code>canonical-domain</code> for appstore.example. And he doesn't want to define a general preference for bigfabulouswidgetstore.example or www.bigfabulouswidgetstore.example.<br />
:** Does this work when <code>canonical-domain</code> includes the power of <code>canonical-wwwnone</code> as well ("www-sensitive")? Yes. That's because a general preference for using bigfabulouswidgetstore.example with or without www, meaning one is the canonical domain of the other, would only be defined if <code>canonical-domain</code> was set with one of these values at (www.)bigfabulouswidgetstore.example. Setting different values at appstore.example and widgetstore.example is perfectly possible and only affects appstore.example and widgetstore.example, not (www.)bigfabulouswidgetstore.example.<br />
:** Does this work if <code>canonical-domain</code> does not differentiate between a domain with or without www ("www-neutral")? No. The websites appstore.example and widgetstore.example can only define an unspecific (www.)bigfabulouswidgetstore.example as canonical domain name for both or with the add of <code>canonical-wwwnone</code> at (www.)bigfabulouswidgetstore.example a general preference.<br />
<br />
: It turns out that the "www-sensitive" <code>canonical-domain</code> allone offers more possibilities in this case than <code>canonical-wwwnone</code> and/or a "www-neutral" <code>canonical-domain</code>.<br />
<br />
:* Case 2: A website owner wants to specify a <code>canonical-domain</code> at widgetstore.example, namely (www.)bigfabulouswidgetstore.example, without specifying whether bigfabulouswidgetstore.example or www.bigfabulouswidgetstore.example should be the canonical domain for widgetstore.example. I'm not sure which benefit could arise from this but let's consider it anyway:<br />
:** This is clearly not possible with a single "www-sensitive" <code>canonical-domain</code>. It would be possible to use two different "www-sensitive" <code>canonical-domain</code>s though. This would look weird and I wouldn't recommend to allow this, but finally that's what the domain owner wants in this scenario: Two canonical domains, with and without www.<br />
:** Does this make more sense with a "www-neutral" <code>canonical-domain</code>? I don't think it does: While it doesn't look as weird it does the same, it assigns two domains, with and without www. However, there's a side effect here: greatfruitstore.example and www.greatfruitstore.example become impossible <code>canonical-domain</code> values if these sites don't share the same content (or else "half of the canonical domain" would be defunct or misleading).<br />
<br />
: It seems that for the advantage of making a rare case more elegantly possible "www-neutral" <code>canonical-domain</code>s could only be used when the www- and non-www version of the href-attribute both exist and share the same content.<br />
<br />
: So, although you are right that a "www-sensitive" <code>canonical-domain</code> doesn't satisfy all possible scenarios, I believe it works in more scenarios than a "www-neutral" <code>canonical-domain</code> would.<br />
<br />
: From keeping <code>canonical-domain</code> "www-sensitive" follows that <code>canonical-wwwnone</code> doesn't provide extra functionality and could be dropped (it could still be supported as a special case of <code>canonical-domain</code> for historical reasons if used somewhere but shouldn't be used in new webpages).<br />
<br />
I'm sorry these case explanations became so long. Might look complicated. Actually your proposal <code>canonical-domain</code> is simple yet powerful. Google webmaster tools show there's a need for this. I like this one very much. [[User:Ocolon|Ocolon]] 00:48, 23 August 2010 (UTC)</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Sanitization_rules&diff=5414Sanitization rules2010-08-22T17:31:29Z<p>Ocolon: Undo revision 5398 by Demver5 (talk)</p>
<hr />
<div>This page was initially seeded with the sanitization lists and rules implemented by the [http://code.google.com/p/html5lib/ html5lib] sanitizer, which in turn was based on [http://golem.ph.utexas.edu/instiki/show/HomePage Jacques Distler's branch of Instiki], which in turn was based on the sanitization logic in the [http://www.feedparser.org/ Universal Feed Parser].<br />
<br />
It is hoped that others will add, update, and extend this list based on their experiences in their own products, and furthermore that some will update their products based on these lists. One such product is [http://htmlpurifier.org/ HTMLPurifier] ([http://intertwingly.net/stories/2007/08/11/diffs diffs]). Another product is [http://www.bloglines.com/help/css-support bloglines].<br />
<br />
As a suggestion but not as a requirement: people who do update their products to reflect information from this list are encouraged to add a link to this page as a comment in the hopes that it will encourage subsequent maintainers to keep this page up to date.<br />
<br />
As a convenience, [http://intertwingly.net/stories/2007/08/13/sanitize_lists.cgi this script] ([http://intertwingly.net/stories/2007/08/13/sanitize_lists.rb source]) converts these lists into a syntax shared by a number of common programming languages.<br />
<br />
=== Acceptable Elements ===<br />
<br />
* a<br />
* abbr<br />
* acronym<br />
* address<br />
* area<br />
* b<br />
* bdo<br />
* big<br />
* blockquote<br />
* br<br />
* button<br />
* caption<br />
* center<br />
* cite<br />
* code<br />
* col<br />
* colgroup<br />
* dd<br />
* del<br />
* dfn<br />
* dir<br />
* div<br />
* dl<br />
* dt<br />
* em<br />
* fieldset<br />
* font<br />
* form<br />
* h1<br />
* h2<br />
* h3<br />
* h4<br />
* h5<br />
* h6<br />
* hr<br />
* i<br />
* img<br />
* input<br />
* ins<br />
* kbd<br />
* label<br />
* legend<br />
* li<br />
* map<br />
* menu<br />
* ol<br />
* optgroup<br />
* option<br />
* p<br />
* pre<br />
* q<br />
* s<br />
* samp<br />
* select<br />
* small<br />
* span<br />
* strike<br />
* strong<br />
* sub<br />
* sup<br />
* table<br />
* tbody<br />
* td<br />
* textarea<br />
* tfoot<br />
* th<br />
* thead<br />
* tr<br />
* tt<br />
* u<br />
* ul<br />
* var<br />
* wbr<br />
<br />
==== mathml Elements ====<br />
<br />
* maction<br />
* math<br />
* merror<br />
* mfrac<br />
* mi<br />
* mmultiscripts<br />
* mn<br />
* mo<br />
* mover<br />
* mpadded<br />
* mphantom<br />
* mprescripts<br />
* mroot<br />
* mrow<br />
* mspace<br />
* msqrt<br />
* mstyle<br />
* msub<br />
* msubsup<br />
* msup<br />
* mtable<br />
* mtd<br />
* mtext<br />
* mtr<br />
* munder<br />
* munderover<br />
* none<br />
<br />
==== svg Elements ====<br />
<br />
* a<br />
* animate<br />
* animateColor<br />
* animateMotion<br />
* animateTransform<br />
* circle<br />
* defs<br />
* desc<br />
* ellipse<br />
* font-face<br />
* font-face-name<br />
* font-face-src<br />
* g<br />
* glyph<br />
* hkern<br />
* image<br />
* linearGradient<br />
* line<br />
* marker<br />
* metadata<br />
* missing-glyph<br />
* mpath<br />
* path<br />
* polygon<br />
* polyline<br />
* radialGradient<br />
* rect<br />
* set<br />
* stop<br />
* svg<br />
* switch<br />
* text<br />
* title<br />
* tspan<br />
* use<br />
<br />
=== Acceptable Attributes ===<br />
<br />
* abbr<br />
* accept<br />
* accept-charset<br />
* accesskey<br />
* action<br />
* align<br />
* alt<br />
* axis<br />
* border<br />
* cellpadding<br />
* cellspacing<br />
* char<br />
* charoff<br />
* charset<br />
* checked<br />
* cite<br />
* class<br />
* clear<br />
* cols<br />
* colspan<br />
* color<br />
* compact<br />
* coords<br />
* datetime<br />
* dir<br />
* disabled<br />
* enctype<br />
* for<br />
* frame<br />
* headers<br />
* height<br />
* href<br />
* hreflang<br />
* hspace<br />
* id<br />
* ismap<br />
* label<br />
* lang<br />
* longdesc<br />
* maxlength<br />
* media<br />
* method<br />
* multiple<br />
* name<br />
* nohref<br />
* noshade<br />
* nowrap<br />
* prompt<br />
* readonly<br />
* rel<br />
* rev<br />
* rows<br />
* rowspan<br />
* rules<br />
* scope<br />
* selected<br />
* shape<br />
* size<br />
* span<br />
* src<br />
* start<br />
* style<br />
* summary<br />
* tabindex<br />
* target<br />
* title<br />
* type<br />
* usemap<br />
* valign<br />
* value<br />
* vspace<br />
* width<br />
* xml:lang<br />
<br />
==== mathml Attributes ====<br />
<br />
* actiontype<br />
* align<br />
* columnalign<br />
* columnalign<br />
* columnalign<br />
* columnlines<br />
* columnspacing<br />
* columnspan<br />
* depth<br />
* display<br />
* displaystyle<br />
* equalcolumns<br />
* equalrows<br />
* fence<br />
* fontstyle<br />
* fontweight<br />
* frame<br />
* height<br />
* linethickness<br />
* lspace<br />
* mathbackground<br />
* mathcolor<br />
* mathvariant<br />
* mathvariant<br />
* maxsize<br />
* minsize<br />
* other<br />
* rowalign<br />
* rowalign<br />
* rowalign<br />
* rowlines<br />
* rowspacing<br />
* rowspan<br />
* rspace<br />
* scriptlevel<br />
* selection<br />
* separator<br />
* stretchy<br />
* width<br />
* width<br />
* xlink:href<br />
* xlink:show<br />
* xlink:type<br />
* xmlns<br />
* xmlns:xlink<br />
<br />
==== svg Attributes ====<br />
<br />
* accent-height<br />
* accumulate<br />
* additive<br />
* alphabetic<br />
* arabic-form<br />
* ascent<br />
* attributeName<br />
* attributeType<br />
* baseProfile<br />
* bbox<br />
* begin<br />
* by<br />
* calcMode<br />
* cap-height<br />
* class<br />
* color<br />
* color-rendering<br />
* content<br />
* cx<br />
* cy<br />
* d<br />
* dx<br />
* dy<br />
* descent<br />
* display<br />
* dur<br />
* end<br />
* fill<br />
* fill-rule<br />
* font-family<br />
* font-size<br />
* font-stretch<br />
* font-style<br />
* font-variant<br />
* font-weight<br />
* from<br />
* fx<br />
* fy<br />
* g1<br />
* g2<br />
* glyph-name<br />
* gradientUnits<br />
* hanging<br />
* height<br />
* horiz-adv-x<br />
* horiz-origin-x<br />
* id<br />
* ideographic<br />
* k<br />
* keyPoints<br />
* keySplines<br />
* keyTimes<br />
* lang<br />
* marker-end<br />
* marker-mid<br />
* marker-start<br />
* markerHeight<br />
* markerUnits<br />
* markerWidth<br />
* mathematical<br />
* max<br />
* min<br />
* name<br />
* offset<br />
* opacity<br />
* orient<br />
* origin<br />
* overline-position<br />
* overline-thickness<br />
* panose-1<br />
* path<br />
* pathLength<br />
* points<br />
* preserveAspectRatio<br />
* r<br />
* refX<br />
* refY<br />
* repeatCount<br />
* repeatDur<br />
* requiredExtensions<br />
* requiredFeatures<br />
* restart<br />
* rotate<br />
* rx<br />
* ry<br />
* slope<br />
* stemh<br />
* stemv<br />
* stop-color<br />
* stop-opacity<br />
* strikethrough-position<br />
* strikethrough-thickness<br />
* stroke<br />
* stroke-dasharray<br />
* stroke-dashoffset<br />
* stroke-linecap<br />
* stroke-linejoin<br />
* stroke-miterlimit<br />
* stroke-opacity<br />
* stroke-width<br />
* systemLanguage<br />
* target<br />
* text-anchor<br />
* to<br />
* transform<br />
* type<br />
* u1<br />
* u2<br />
* underline-position<br />
* underline-thickness<br />
* unicode<br />
* unicode-range<br />
* units-per-em<br />
* values<br />
* version<br />
* viewBox<br />
* visibility<br />
* width<br />
* widths<br />
* x<br />
* x-height<br />
* x1<br />
* x2<br />
* xlink:actuate<br />
* xlink:arcrole<br />
* xlink:href<br />
* xlink:role<br />
* xlink:show<br />
* xlink:title<br />
* xlink:type<br />
* xml:base<br />
* xml:lang<br />
* xml:space<br />
* xmlns<br />
* xmlns:xlink<br />
* y<br />
* y1<br />
* y2<br />
* zoomAndPan<br />
<br />
=== CSS Rules ===<br />
<br />
First <code>urls</code> matching the following regular expression are removed:<br />
<pre>url\s*\(\s*[^\s)]+?\s*\)\s*</pre><br />
<br />
The style strings that don't match the following are deemed obfuscated, and ignored entirely:<br />
<pre>^([:,;#%.\sa-zA-Z0-9!]|\w-\w|'[\s\w]+'|"[\s\w]+"|\([\d,\s]+\))*$</pre><br />
<pre>^(\s*[-\w]+\s*:\s*[^:;]*(;|$))*$</pre><br />
<br />
==== style Properties ====<br />
<br />
* azimuth<br />
* background, background-*<br />
* border, border-*<br />
* clear<br />
* color<br />
* cursor<br />
* direction<br />
* display<br />
* elevation<br />
* float<br />
* font<br />
* font-family<br />
* font-size<br />
* font-style<br />
* font-variant<br />
* font-weight<br />
* height<br />
* letter-spacing<br />
* line-height<br />
* margin, margin-*<br />
* overflow<br />
* padding, padding-*<br />
* pause<br />
* pause-after<br />
* pause-before<br />
* pitch<br />
* pitch-range<br />
* richness<br />
* speak<br />
* speak-header<br />
* speak-numeral<br />
* speak-punctuation<br />
* speech-rate<br />
* stress<br />
* text-align<br />
* text-decoration<br />
* text-indent<br />
* unicode-bidi<br />
* vertical-align<br />
* voice-family<br />
* volume<br />
* white-space<br />
* width<br />
<br />
==== style Property Values ====<br />
<br />
* auto<br />
* aqua<br />
* black<br />
* block<br />
* blue<br />
* bold<br />
* both<br />
* bottom<br />
* brown<br />
* center<br />
* collapse<br />
* dashed<br />
* dotted<br />
* fuchsia<br />
* gray<br />
* green<br />
* !important<br />
* italic<br />
* left<br />
* lime<br />
* maroon<br />
* medium<br />
* none<br />
* navy<br />
* normal<br />
* nowrap<br />
* olive<br />
* pointer<br />
* purple<br />
* red<br />
* right<br />
* solid<br />
* silver<br />
* teal<br />
* top<br />
* transparent<br />
* underline<br />
* white<br />
* yellow<br />
<br />
In addition, values that match the following regular expression are valid:<br />
<br />
<code>^(#[0-9a-f]+|rgb\(\d+%?,\d*%?,?\d*%?\)?|\d{0,2}\.?\d{0,2}(cm|em|ex|in|mm|pc|pt|px|%|,|\))?)$</code><br />
<br />
==== svg style Properties ====<br />
<br />
* fill<br />
* fill-opacity<br />
* fill-rule<br />
* stroke<br />
* stroke-width<br />
* stroke-linecap<br />
* stroke-linejoin<br />
* stroke-opacity<br />
<br />
=== URIs ===<br />
==== Attributes whose value is a URI ====<br />
<br />
* href<br />
* src<br />
* cite<br />
* action<br />
* longdesc<br />
* xlink:href<br />
* xml:base<br />
<br />
==== URI schemes ====<br />
<br />
* afs<br />
* aim<br />
* callto<br />
* data (see [[#Safe data URL content types]])<br />
* ed2k<br />
* feed<br />
* ftp<br />
* gopher<br />
* http<br />
* https<br />
* irc<br />
* mailto<br />
* news<br />
* nntp<br />
* rsync<br />
* rtsp<br />
* sftp<br />
* ssh<br />
* tag<br />
* tel<br />
* telnet<br />
* urn<br />
* webcal<br />
* wtai<br />
* xmpp<br />
<br />
==== Safe data URL content types ====<br />
Note: This section is being [http://wiki.whatwg.org/wiki/Talk:Sanitization_rules discussed].<br />
* text/plain<br />
* image/gif<br />
* image/jpeg<br />
* image/png</div>Ocolonhttps://wiki.whatwg.org/index.php?title=SRT_research&diff=5411SRT research2010-08-22T13:41:15Z<p>Ocolon: Undo revision 5405 by Rebeca123rebec (talk)</p>
<hr />
<div>= Implementations =<br />
<br />
== Authoring tools ==<br />
* [http://zuggy.wz.cz/dvd.php SubRip] (Windows only)<br />
* [http://home.gna.org/subtitleeditor/ Subtitle Editor] (For UNIX/GTK+2/GStreamer)<br />
*: Does not appear to support writing any styling tags or other than the basic times+text.<br />
<br />
=== Test cases ===<br />
*...<br />
<br />
== Interpreters ==<br />
For each interpreter, please link to a page with videos showing how the test files are rendered, or describe the results.<br />
<br />
=== [http://www.videolan.org/vlc/ VLC] ===<br />
* 1-001 - PASS (basic one-cue)<br />
* 1-002 - PASS (basic one-cie two-line)<br />
* 1-003 - PASS (basic two-cue)<br />
* 1-004 - no X1: support apparent; positioning information ignored<br />
* 1-005 - PASS non-numeric IDs supported<br />
* 1-006 - PASS IDs optional<br />
* 1-007 - PASS (control)<br />
* 1-008 - PASS out-of-order IDs ignored<br />
* 1-009 - FAIL non-chronological titles strangely skipped<br />
* 1-010 - FAIL non-chronological titles strangely skipped<br />
* 1-011 - PASS simultaneous titles supported<br />
* 1-012 - &lt;i>, &lt;b>, &lt;u> supported; &lt;font> parsed but ignored with no effect<br />
* 1-013 - inline formatting supported in a somewhat buggy fashion; end tags implied; unknown tags ignored if matched only; known tags auto-close<br />
* 1-014 - PASS decimal separator supported<br />
* 1-015 - PASS unknown settings ignored<br />
* 1-016 - Leading WEBSRT header ignored<br />
<br />
=== Totem Movie Player ===<br />
<br />
Totem is the media player Ubuntu ships by default. It is based on GStreamer, so other software using GStreamer should have similar results.<br />
<br />
Totem does not seem to support SRT files with less than 3 cues and sometimes asks if you want to install the application/x-subrip plugin which it cannot find.<br />
<br />
* 1-004 - no support for X1.<br />
* 1-005 - no support for non-numeric IDs<br />
* 1-006 - no support for missing IDs<br />
* 1-007 - PASS<br />
* 1-008 - PASS - out of order IDs ignored<br />
* 1-009 - FAIL - everything but ---- and ---4 is not shown<br />
* 1-010 - FAIL - everything but ---- and ---4 is not shown<br />
* 1-011 - FAIL - only the "P" is displayed<br />
* 1-012 - only italics and underline work (with non-default font settings bold also works)<br />
* 1-013 - end tags implied at end of cue; numbers following &lt; causes &lt; to be emitted, &lt;b &lt;i&gt; gives &lt;b followed by text in italics; unknown tags ignored<br />
* 1-014 - PASS - afaict<br />
* 1-015 - PASS<br />
* 1-016 - not recognized as SRT<br />
<br />
=== [http://www.mplayerhq.hu/ MPlayer] ===<br />
* 1-001 - PASS<br />
* 1-002 - PASS<br />
* 1-003 - PASS<br />
* 1-004 - FAIL: X/Y is ignored<br />
* 1-005 - PASS<br />
* 1-006 - PASS<br />
* 1-007 - PASS<br />
* 1-008 - PASS<br />
* 1-009 - PASS<br />
* 1-010 - PASS<br />
* 1-011 - FAIL: only "P" appears<br />
* 1-012 - FAIL: all text is unstyled. displayed text, in order, is: "Formatting test", "italics", "bold", "underline", "font", "font size=3", "font color=#00FF00", 'font color="#00FF00"', "font color=green", 'font color="green"'<br />
* 1-013 - FAIL: all text is unstyled, all tags are stripped. needs more analysis?<br />
* 1-014 - PASS: probably, exact timing only verified "by eye"<br />
* 1-015 - PASS: Line 1..5 appears with no garbage and timing seems correct<br />
* 1-016 - PASS: leading WEBSRT is ignored<br />
<br />
=== Test cases ===<br />
# http://www.hixie.ch/tests/adhoc/srt/<br />
<br />
= Existing content =<br />
To avoid sample biases, where possible, this should be based on automated searches.<br />
<br />
== OpenSubtitles ==<br />
http://blog.foolip.org/2010/08/20/srt-research/<br />
<br />
Analysis of 10000 files provided by OpenSubtitles. Notable results:<br />
* Only 6.66% were valid UTF-8<br />
* 17.07% had overlapping cues<br />
* Only 0.38% had something other than whitespace trailing the timings<br />
* 55.25% used some kind of markup, the most common being &lt;i>, &lt;b>, &lt;font ...> and &lt;u><br />
<br />
== Random notes in #whatwg ==<br />
http://krijnhoetmer.nl/irc-logs/whatwg/20100630#l-104<br />
<br />
# [01:18] &lt;zcorpan_> Hixie: the first random srt i download has &lt;i> wrapping multiple lines <br />
# [01:18] &lt;zcorpan_> (well, the second random. the first didn't have any markup) <br />
# [01:19] &lt;zcorpan_> http://www.opensubtitles.org/en/download/sub/3695049 <br />
# [01:19] &lt;zcorpan_> i have no idea which encoding that one is using <br />
# [01:21] &lt;Hixie> zcorpan_: ah, excellent, good to know, thanks <br />
# [01:26] &lt;zcorpan_> it seems existing srts use different legacy encodings and don't declare it :( <br />
<br />
# [01:43] * zcorpan_ finds an srt with Traducerea ∫i adaptarea: &lt;font color=#ff99cc>Kprice&lt;/font> <br />
# [01:43] * zcorpan_ &lt;font color=#ffffff>Subtitr„ri-Noi Team&lt;/font> <br />
<br />
# [19:27] * zcorpan_ finds an srt with &lt;b>&lt;font color="#00afad">Join us on Facebook ! <br />
# [19:27] * zcorpan_ Squadra Dell'Ombra&lt;/font>&lt;/b> <br />
# [19:27] &lt;zcorpan_> Hixie: ^ <br />
# [19:33] &lt;zcorpan_> Hixie: http://www.tvsubtitles.net/subtitle-132566.html has &lt;i>Et maintenant "Les transcroyables <br />
# [19:33] &lt;zcorpan_> exploits de Zapp Brannigan" <br />
# [19:33] &lt;zcorpan_> (i.e. unclosed &lt;i> <br />
# [19:33] &lt;zcorpan_> ) <br />
# [19:34] &lt;Hixie> zcorpan_: i'm intentionally not going to be supporting attributes at this point <br />
# [19:34] &lt;Hixie> zcorpan_: and will support unclosed &lt;i>s <br />
# [19:36] &lt;zcorpan_> Hixie: it was just the first srt i found with &lt;b> <br />
# [19:36] &lt;Hixie> ah <br />
# [19:36] &lt;zcorpan_> {\pos(192,240)}On a des photos. <br />
# [19:36] &lt;zcorpan_> http://www.tvsubtitles.net/subtitle-132551.html <br />
# [19:37] &lt;zcorpan_> &lt;i>{\a6}TY, <br />
# [19:37] &lt;zcorpan_> L'ASSISTANT DU CORONER&lt;/i> <br />
# [19:39] &lt;Hixie> wow, i wonder what UA supports that <br />
# [19:46] &lt;zcorpan_> VLC doesn't support it <br />
<br />
# [20:00] &lt;zcorpan_> MPlayer seems to support {\pos(192,240)} <br />
# [20:01] &lt;zcorpan_> and ignores {\a6}, or replaces it with a space or something <br />
# [20:10] &lt;zcorpan_> Hixie: all subtitles from tvsubtitles.net seem to have 9999 <br />
# [20:10] &lt;zcorpan_> 00:00:0,500 --> 00:00:2,00 <br />
# [20:10] &lt;zcorpan_> &lt;font color="#ffff00" size=14>www.tvsubtitles.net&lt;/font> <br />
# [20:10] &lt;zcorpan_> at the *end* of the file <br />
# [20:16] &lt;Hixie> yeah, i think the parser will likely support out-of-order cues <br />
# [20:17] &lt;Hixie> (in fact it already does) <br />
# [20:18] &lt;Hixie> it doesn't support times with only one digit for the seconds or two digits for the thousandths, though <br />
# [20:18] &lt;Hixie> do UAs support that? <br />
# [20:18] &lt;Hixie> it's trivial for me to add support if necessary <br />
# [20:20] &lt;zcorpan_> VLC supports single-digit seconds <br />
# [20:21] &lt;zcorpan_> MPlayer too <br />
# [20:25] &lt;zcorpan_> heh, vlc interprets 00:00:00,5000 as if it were 00:00:05,000 <br />
# [20:29] &lt;zcorpan_> mplayer also interprets 00:00:00,5000 as if it were 00:00:05,000 <br />
# [20:33] &lt;zcorpan_> ok vlc interprets 00:00:01,99 as 00:00:01,099 <br />
# [20:36] &lt;zcorpan_> vlc seems to just overlap without changing position</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Time_element&diff=5410Time element2010-08-22T13:32:06Z<p>Ocolon: /* Calendar scale discussion */ added thoughts: we should either stick to one calendar scale or be prepared to have to incorporate all calendar scales and live with the consequences</p>
<hr />
<div>Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].<br />
<br />
<br />
HTML5's new &lt;time&gt; element presents a huge opportunity to improve the publishing of datetime information on the web, the biggest opportunity since the introduction of hCalendar and other time-based microformats.<br />
<br />
However, the &lt;time&gt; element currently has several shortcomings that both prevent it from being used in numerous use-cases, and are suboptimal for authoring and data longevity.<br />
<br />
Please read the following proposals for improving the &lt;time&gt; element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.<br />
<br />
<br />
Thanks for your consideration,<br />
<br />
[[User:Tantek|Tantek]] (and other proposal authors).<br />
<br />
<br />
Please add new proposals to the end of the most relevantly related section, or if you're not sure where (or if there is no related section), at the end of the [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.<br />
<br />
=Date granularity=<br />
== year only ==<br />
The time element should accept just a year.<br />
;ISO8601 syntax<br />
:YYYY<br />
=== year only use cases ===<br />
use case research:<br />
* http://microformats.org/wiki/birthday-examples#year_only<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]<br />
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)<br />
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]<br />
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:<br />
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]<br />
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]<br />
*Citations from a bibliography which list two or more works by the same author disambiguate them by year<br />
*Commerce<br />
** "a piece of jewellery hallmarked 1933"<br />
** "a 1973 Chevy"<br />
*Sport<br />
**2008 Olympics<br />
**1966 World Cup<br />
*Awards<br />
**"1973 Oscar for best film"<br />
**"1988 Nobel Peace Prize"<br />
*Restyling dates for localisation and to follow user conventions<br />
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)<br />
* Relative dates in texts: news websites and blogs often use phrases such as<br />
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],<br />
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]<br />
<br />
=== year only discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.<br />
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year only related posts ===<br />
Related posts (listed with quotes directly related to year only) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote><br />
<br />
== year month only ==<br />
The time element should accept just a year and a month.<br />
;ISO8601 syntax<br />
:YYYY-MM<br />
<br />
=== year month use cases ===<br />
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)<br />
** http://www.flickr.com/photos/tantek/archives/<br />
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)<br />
* output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]<br />
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)<br />
* Restyling dates for localisation and to follow user conventions<br />
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)<br />
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:<br />
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]<br />
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]<br />
<br />
=== year month discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[User:Tantek|Tantek]] I think the blog archives use case (where blogs often link to their archives by a specific month and year) is sufficient to justify adding this capability to the time element. Content hosting sites like Flickr also list archives by specific year/month, e.g. see http://www.flickr.com/photos/tantek/archives/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.<br />
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year month related posts ===<br />
Related posts (listed with quotes directly related to year-month) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote><br />
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote><br />
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote><br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the <nowiki>[sic]</nowiki> it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.</blockquote><br />
<br />
== year week only ==<br />
The time element should accept just a year and a week number.<br />
;ISO8601 syntax<br />
:YYYY-WNN<br />
;use case research<br />
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.<br />
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
;reasoning<br />
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code><br />
<br />
See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] per good design of impedance matching date time inputs.<br />
* ...<br />
</div><br />
<br />
== month day only ==<br />
The time element should accept just a month and a day.<br />
;ISO8601 syntax<br />
:--MM-DD<br />
;use case research<br />
:http://microformats.org/wiki/birthday-examples#month_and_day_only<br />
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF - see external links<br />
:Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 "radiz" implied support for --MM-DD with the use case question: "How to use &lt;time&gt; with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per [http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF, e.g. birthdays, wedding anniversaries - see external links)<br />
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.<br />
* ...<br />
</div><br />
<br />
= HTML5 internal consistency =<br />
== impedance match new date time inputs ==<br />
The time element should be able to represent every granularity of times and dates that the new date time <code>&lt;input&gt;</code> elements allow. Here is a list of all the date time <code>&lt;input&gt;</code> elements along with the corresponding <code>&lt;time&gt;</code> element usage (if applicable)<br />
<br />
<pre><nowiki><br />
<input type="date"> - <time>YYYY-MM-DD</time><br />
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time><br />
<input type="month"> - not supported in current time element<br />
<input type="week"> - not supported in current time element<br />
<input type="time"> - <time>HH:MM:SS</time><br />
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time><br />
New proposed input elements:<br />
<input type="year"> - not supported in current time element<br />
<input type="month-day"> - not supported in current time element<br />
</nowiki></pre><br />
<br />
In particular the <code>&lt;time&gt;</code> element is missing support for the following date inputs:<br />
<br />
* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].<br />
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].<br />
<br />
In addition, if the new proposed [[input]] elements are accepted, the respective time element support should be added as well:<br />
<br />
* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].<br />
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]]<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]]<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]]<br />
* ...<br />
</div><br />
<br />
= Proposals extending scope =<br />
<br />
== Fuzzy dates ==<br />
The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and eras ("Edwardian", "bronze age", "Jurassic")".<br />
<br />
;Use cases:<br />
:1. "... an application that might input Wikipedia data and output an annotated visual timeline. For movements or trends rather than events, it would need to output rough dates and date ranges like 2001-2003, rather than exact dates."[http://www.zeldman.com/superfriends/guide/#time] <br />
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.<br />
:2. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]<br />
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion<br />
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]<br />
:4 ...<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)<br />
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.<br />
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)<br />
* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:<br />
** certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)<br />
** certainty attribute takes an ISO8601 duration.<br />
** alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful)<br />
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre><br />
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 Bruce Darcus says]: "[While] I definitely think the use case is important...<br />
**"...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] I like the concept, but the syntax should be less verbose and more precise.<br />
** "Circa" can be indicated with a tilde prefix "~"<br />
** Ranges can use [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).<br />
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.<br />
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)<br />
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== Calendar scale ==<br />
The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 emergent vCard 4 specification], to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using one of a set of pre-defined CALSCALE types.<br />
<br />
=== Calendar scale example ===<br />
Example:<br />
<br />
<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre><br />
<br />
=== Calendar scale processing ===<br />
User agents could be instructed to ignore any unrecognised CALSCALE value, treating the contents of the element as plain text for data-processing (but not styling) purposes. This would prevent, for example the processing of the above example by an agent written to deal only with Gregorian dates. (At some point, CSS should recognise CALSCALE, allowing authors to, say, style all Julian dates differently to Gregorian dates.)<br />
<br />
=== Calendar scale use cases ===<br />
Use case research:<br />
* The Wikipedia timeline example in [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element] proposes to map a timeline of dates from Wikipedia (e.g. 2001-2003 Gregorian). However, Wikipedia includes several thousand articles about or referring to <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - target site currently broken, but worked previously; a fix is promised shortly) can only map Wikipedia's Gregorian dates, because there is currently no way to mark up Julian dates in a machine-readable format. The use of CALSCALE as suggested would allow this implementation and others to map all of these dates. (Note that the implementation works with any site, not just Wikipedia, parsing hCalendar microformats.)<br />
* Julian dates in [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]: <br />
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.<br />
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar<br />
<br />
=== Calendar scale discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)<br />
* 0 [[User:Tantek|Tantek]] - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.<br />
* 0 [[User:Ocolon|Martin Janecke]] - I'm afraid the current proposal is too "Western World" centered. If you plan to allow Julian and Gregorian dates – what about the Islamic, Chinese, Hebrew, …, Mesopotamian and Mayan calenders? I don't mean to say we mustn't incorporate other calender scales – but if we do, we'll probably have to implement all of them, making things easier in some and much more complicated in many aspects. This could result in many parsers not being able to understand many of the dates, making the time element less useful. I'd rather use just one scale as it is in the spec right now. The Gregorian calender is an international standard, so it should be fine. But I don't know if it is right to expect others to use "my" calendar (which the Gregorian calender is), hence the neutral vote.<br />
* …<br />
</div><br />
<br />
=== Calendar scale related posts ===<br />
Related posts (listed with quotes directly related to Calendar scale) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like [(refers to prototype CALSCALE)] where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale<br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.<br />
<br />
= Syntax improvements for reducing DRY violations =<br />
<br />
We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).<br />
<br />
This experience yielded the microformats adoption of the DRY principle - '''D'''on't '''R'''epeat '''Y'''ourself - in application to (meta)dataformat designs and techniques.<br />
<br />
<br />
The &lt;time&gt; element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).<br />
<br />
This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the &lt;abbr&gt; element.<br />
<br />
Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related &lt;abbr&gt; problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).<br />
<br />
http://microformats.org/wiki/value-class-pattern#Date_and_time_values<br />
<br />
We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 &lt;time&gt; element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).<br />
<br />
Accordingly, please consider the following &lt;time&gt; syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.<br />
<br />
<br />
== composite nested time elements ==<br />
A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.<br />
<br />
This is intended as a cleaner way to provide functionality equivalent to the microformats [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])<br />
<br />
<pre><nowiki><br />
<time class="published" datetime="2009-12-13T17:43:29"><br />
Sunday, December 13th, 2009<br />
5:43pm<br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
and have the parent &lt;time&gt; element composite a complete datetime from the child &lt;time&gt; elements with separate date and time.<br />
<br />
The <em>separate</em> date and time <code>datetime</code> attribute values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the "same" value as the in-content text, thus resulting in incrementally more accurate data over time.<br />
<br />
This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== background ===<br />
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"<br />
datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).<br />
<br />
=== microformats value class pattern DRY advantage ===<br />
With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<span class="dtstart"><br />
<span class="value">18:00</span> on <br />
<span class="value">2010-08-05</span><br />
</span>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.<br />
<br />
Disadvantage: the loss of the HTML5 time semantic and related processing.<br />
<br />
=== simple nested time example improvement ===<br />
We'd like to have our <code>&lt;time&gt;</code> and date time separation as well, so this should work:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
=== summary of updated datetime algorithm ===<br />
In short: the algorithm for determining the "datetime" of a time element should:<br />
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)<br />
# check for nested &lt;time&gt; elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)<br />
# use the complete contents of the &lt;time&gt; element as its datetime value.<br />
<br />
Essentially, step 2 is added to enable composing nested child time elements.<br />
<br />
=== applicability to microdata ===<br />
All of the aforementioned advantages for microformats apply to microdata use of the &lt;time&gt; element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).<br />
<br />
=== nested time example with datetime attribute ===<br />
If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> information), thus reducing the risk of data divergence due to duplication.<br />
<br />
=== nested time example with two datetimes ===<br />
If the publisher prefers to publish a "localized" form of times, they can do that as well:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time datetime="18:00:00">6pm</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.<br />
<br />
The AM/PM proposal below further helps improve this example.<br />
<br />
=== nested time discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.<br />
* -1 [[User:Pigsonthewing|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time datetime="2005-10-05/2005-10-07"><br />
<time class="dtstart">October 5</time>-<br />
<time class="dtend">7</time><br />
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div></nowiki></pre><br />
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== am pm and coarser time parsing ==<br />
Right now time values inside a &lt;time&gt; element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)<br />
<br />
<pre><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time>5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.<br />
<br />
This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== am pm syntax summary ===<br />
<br />
In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).<br />
<br />
In short, the current &lt;time&gt; element only allows for the following time syntax:<br />
<br />
* HH:MM:SS - where HH is in 24 hour time.<br />
<br />
This proposal expands the allowed time syntax to:<br />
<br />
* HH:MM:SSam<br />
* HH:MM:SSpm<br />
* HH:MMam<br />
* HH:MMpm<br />
* HHam<br />
* HHpm<br />
<br />
=== am pm syntax details ===<br />
* '''periods, white-space, case-insensitivity.''' "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").<br />
* '''implied 00 minutes and seconds.''' When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;<br />
* '''handling of 12am and 12pm.''' "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).<br />
<br />
=== simple am pm example ===<br />
A simple example:<br />
<br />
<pre><nowiki><br />
I went to the cafe at <time>6pm</time>.<br />
</nowiki></pre><br />
<br />
Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.<br />
<br />
=== am pm example with nested time elements ===<br />
Example (uses aforementioned composite nested time element proposal as well)<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>6pm</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: again, this reduces DRY violations, in this case further improving upon the composite nested time elements case.<br />
<br />
=== am pm discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - in practice we in the microformats community have found that enabling users to markup am/pm times leads to many more cases where we can avoid violating DRY and thus encourage greater accuracy over time for such content. I think the HTML5 &lt;time&gt; element presents us with the opportunity to more cleanly markup times (than what we've been able to do with the aforementioned microformats value-class-pattern), and thus we should do so.<br />
* 0(query) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.<br />
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
=== am pm FAQ ===<br />
==== noon and midnight ====<br />
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?<br />
<br />
'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.<br />
<br />
==== am pm i18n ====<br />
'''Question:''' How does this internationalise "am" and "pm", for languages which do not use them? <br />
<br />
'''Answer:''' For languages that do not use "am" or "pm", the am pm proposal does not confer any additional advantage.<br />
<br />
= Minor editorial fixes =<br />
<br />
== Update hCalendar example ==<br />
<br />
Summary: please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.<br />
<br />
=== Current example ===<br />
<br />
The HTML5 spec currently has this hCalendar example:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>:<br />
<time class="dtstart" datetime="2007-10-05">October 5</time> -<br />
<time class="dtend" datetime="2007-10-20">19</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
<br />
(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)<br />
</nowiki></pre><br />
<br />
This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.<br />
<br />
=== Updated example ===<br />
<br />
Here is a suggested update:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time class="dtstart" datetime="2005-10-05">October 5</time>-<br />
<time class="dtend" datetime="2005-10-07">7</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
</nowiki></pre><br />
<br />
The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue dtend issue] for details).<br />
<br />
= Miscellaneous proposals =<br />
<br />
==Choose different default date==<br />
The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.<br />
<br />
A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* 0 (comment) [[User:Pigsonthewing|Andy Mabbett]] - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?<br />
* -1 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.<br />
* ...<br />
</div><br />
<br />
= Issues without specific proposals =<br />
==Specification ambiguities==<br />
The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.<br />
<br />
Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.<br />
<br />
<br />
= See Also =<br />
* [[input]] - the input element, related proposals expanding upon the new datetime inputs.<br />
<br />
= External links =<br />
<br />
== Tag ==<br />
Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time <!-- links to follow --><br />
<br />
== Prior discussion ==<br />
<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]<br />
* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith<br />
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]<br />
<br />
== Resources ==<br />
<br />
* [http://www.loc.gov/standards/datetime/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)<br />
** [http://www.loc.gov/standards/datetime/proposals.html EDTF proposals] (use-cases)<br />
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]<br />
** mailing list was datetime-comments@w3.org. - anyone have archives URL?<br />
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)<br />
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]<br />
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates<br />
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]<br />
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]<br />
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]<br />
* Dublin Core terms, e.g. <br />
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal<br />
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]<br />
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created<br />
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]<br />
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Time_element&diff=5409Time element2010-08-22T12:54:38Z<p>Ocolon: /* Fuzzy dates */ added sceptic remarks about the current fuzzy date concept</p>
<hr />
<div>Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].<br />
<br />
<br />
HTML5's new &lt;time&gt; element presents a huge opportunity to improve the publishing of datetime information on the web, the biggest opportunity since the introduction of hCalendar and other time-based microformats.<br />
<br />
However, the &lt;time&gt; element currently has several shortcomings that both prevent it from being used in numerous use-cases, and are suboptimal for authoring and data longevity.<br />
<br />
Please read the following proposals for improving the &lt;time&gt; element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.<br />
<br />
<br />
Thanks for your consideration,<br />
<br />
[[User:Tantek|Tantek]] (and other proposal authors).<br />
<br />
<br />
Please add new proposals to the end of the most relevantly related section, or if you're not sure where (or if there is no related section), at the end of the [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.<br />
<br />
=Date granularity=<br />
== year only ==<br />
The time element should accept just a year.<br />
;ISO8601 syntax<br />
:YYYY<br />
=== year only use cases ===<br />
use case research:<br />
* http://microformats.org/wiki/birthday-examples#year_only<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]<br />
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)<br />
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]<br />
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:<br />
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]<br />
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]<br />
*Citations from a bibliography which list two or more works by the same author disambiguate them by year<br />
*Commerce<br />
** "a piece of jewellery hallmarked 1933"<br />
** "a 1973 Chevy"<br />
*Sport<br />
**2008 Olympics<br />
**1966 World Cup<br />
*Awards<br />
**"1973 Oscar for best film"<br />
**"1988 Nobel Peace Prize"<br />
*Restyling dates for localisation and to follow user conventions<br />
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)<br />
* Relative dates in texts: news websites and blogs often use phrases such as<br />
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],<br />
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]<br />
<br />
=== year only discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.<br />
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year only related posts ===<br />
Related posts (listed with quotes directly related to year only) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote><br />
<br />
== year month only ==<br />
The time element should accept just a year and a month.<br />
;ISO8601 syntax<br />
:YYYY-MM<br />
<br />
=== year month use cases ===<br />
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)<br />
** http://www.flickr.com/photos/tantek/archives/<br />
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)<br />
* output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]<br />
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)<br />
* Restyling dates for localisation and to follow user conventions<br />
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)<br />
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:<br />
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]<br />
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]<br />
<br />
=== year month discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[User:Tantek|Tantek]] I think the blog archives use case (where blogs often link to their archives by a specific month and year) is sufficient to justify adding this capability to the time element. Content hosting sites like Flickr also list archives by specific year/month, e.g. see http://www.flickr.com/photos/tantek/archives/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.<br />
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year month related posts ===<br />
Related posts (listed with quotes directly related to year-month) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote><br />
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote><br />
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote><br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the <nowiki>[sic]</nowiki> it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.</blockquote><br />
<br />
== year week only ==<br />
The time element should accept just a year and a week number.<br />
;ISO8601 syntax<br />
:YYYY-WNN<br />
;use case research<br />
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.<br />
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
;reasoning<br />
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code><br />
<br />
See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] per good design of impedance matching date time inputs.<br />
* ...<br />
</div><br />
<br />
== month day only ==<br />
The time element should accept just a month and a day.<br />
;ISO8601 syntax<br />
:--MM-DD<br />
;use case research<br />
:http://microformats.org/wiki/birthday-examples#month_and_day_only<br />
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF - see external links<br />
:Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 "radiz" implied support for --MM-DD with the use case question: "How to use &lt;time&gt; with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per [http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF, e.g. birthdays, wedding anniversaries - see external links)<br />
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.<br />
* ...<br />
</div><br />
<br />
= HTML5 internal consistency =<br />
== impedance match new date time inputs ==<br />
The time element should be able to represent every granularity of times and dates that the new date time <code>&lt;input&gt;</code> elements allow. Here is a list of all the date time <code>&lt;input&gt;</code> elements along with the corresponding <code>&lt;time&gt;</code> element usage (if applicable)<br />
<br />
<pre><nowiki><br />
<input type="date"> - <time>YYYY-MM-DD</time><br />
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time><br />
<input type="month"> - not supported in current time element<br />
<input type="week"> - not supported in current time element<br />
<input type="time"> - <time>HH:MM:SS</time><br />
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time><br />
New proposed input elements:<br />
<input type="year"> - not supported in current time element<br />
<input type="month-day"> - not supported in current time element<br />
</nowiki></pre><br />
<br />
In particular the <code>&lt;time&gt;</code> element is missing support for the following date inputs:<br />
<br />
* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].<br />
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].<br />
<br />
In addition, if the new proposed [[input]] elements are accepted, the respective time element support should be added as well:<br />
<br />
* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].<br />
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]]<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]]<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]]<br />
* ...<br />
</div><br />
<br />
= Proposals extending scope =<br />
<br />
== Fuzzy dates ==<br />
The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and eras ("Edwardian", "bronze age", "Jurassic")".<br />
<br />
;Use cases:<br />
:1. "... an application that might input Wikipedia data and output an annotated visual timeline. For movements or trends rather than events, it would need to output rough dates and date ranges like 2001-2003, rather than exact dates."[http://www.zeldman.com/superfriends/guide/#time] <br />
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.<br />
:2. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]<br />
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion<br />
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]<br />
:4 ...<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)<br />
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.<br />
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)<br />
* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:<br />
** certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)<br />
** certainty attribute takes an ISO8601 duration.<br />
** alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful)<br />
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre><br />
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 Bruce Darcus says]: "[While] I definitely think the use case is important...<br />
**"...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] I like the concept, but the syntax should be less verbose and more precise.<br />
** "Circa" can be indicated with a tilde prefix "~"<br />
** Ranges can use [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).<br />
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.<br />
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)<br />
* -1 [[User:Ocolon|Martin Janecke]] - I don't object to the idea of fuzzy dates in general (a well defined certainty attribute sounds interesting) but this doesn't seem to be well thought through yet. E.g. "bronze age" rather defines a stage of development of a culture than a time, just as "adolescence" does for a human. The time element could be suitable for adding markup to the term "bronze age" in a text talking about a specific culture. But you would really add markup to the term, not use this term as time markup, exactly because "bronze age" does not tell a time. Please don't make the time element too unspecific as I am afraid this would reduce its usability rather than adding to it. [[User:Ocolon|Ocolon]] 12:54, 22 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== Calendar scale ==<br />
The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 emergent vCard 4 specification], to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using one of a set of pre-defined CALSCALE types.<br />
<br />
=== Calendar scale example ===<br />
Example:<br />
<br />
<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre><br />
<br />
=== Calendar scale processing ===<br />
User agents could be instructed to ignore any unrecognised CALSCALE value, treating the contents of the element as plain text for data-processing (but not styling) purposes. This would prevent, for example the processing of the above example by an agent written to deal only with Gregorian dates. (At some point, CSS should recognise CALSCALE, allowing authors to, say, style all Julian dates differently to Gregorian dates.)<br />
<br />
=== Calendar scale use cases ===<br />
Use case research:<br />
* The Wikipedia timeline example in [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element] proposes to map a timeline of dates from Wikipedia (e.g. 2001-2003 Gregorian). However, Wikipedia includes several thousand articles about or referring to <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - target site currently broken, but worked previously; a fix is promised shortly) can only map Wikipedia's Gregorian dates, because there is currently no way to mark up Julian dates in a machine-readable format. The use of CALSCALE as suggested would allow this implementation and others to map all of these dates. (Note that the implementation works with any site, not just Wikipedia, parsing hCalendar microformats.)<br />
* Julian dates in [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]: <br />
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.<br />
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar<br />
<br />
=== Calendar scale discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)<br />
* 0 [[User:Tantek|Tantek]] - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.<br />
* …<br />
</div><br />
<br />
=== Calendar scale related posts ===<br />
Related posts (listed with quotes directly related to Calendar scale) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like [(refers to prototype CALSCALE)] where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale<br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.<br />
<br />
= Syntax improvements for reducing DRY violations =<br />
<br />
We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).<br />
<br />
This experience yielded the microformats adoption of the DRY principle - '''D'''on't '''R'''epeat '''Y'''ourself - in application to (meta)dataformat designs and techniques.<br />
<br />
<br />
The &lt;time&gt; element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).<br />
<br />
This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the &lt;abbr&gt; element.<br />
<br />
Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related &lt;abbr&gt; problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).<br />
<br />
http://microformats.org/wiki/value-class-pattern#Date_and_time_values<br />
<br />
We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 &lt;time&gt; element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).<br />
<br />
Accordingly, please consider the following &lt;time&gt; syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.<br />
<br />
<br />
== composite nested time elements ==<br />
A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.<br />
<br />
This is intended as a cleaner way to provide functionality equivalent to the microformats [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])<br />
<br />
<pre><nowiki><br />
<time class="published" datetime="2009-12-13T17:43:29"><br />
Sunday, December 13th, 2009<br />
5:43pm<br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
and have the parent &lt;time&gt; element composite a complete datetime from the child &lt;time&gt; elements with separate date and time.<br />
<br />
The <em>separate</em> date and time <code>datetime</code> attribute values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the "same" value as the in-content text, thus resulting in incrementally more accurate data over time.<br />
<br />
This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== background ===<br />
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"<br />
datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).<br />
<br />
=== microformats value class pattern DRY advantage ===<br />
With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<span class="dtstart"><br />
<span class="value">18:00</span> on <br />
<span class="value">2010-08-05</span><br />
</span>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.<br />
<br />
Disadvantage: the loss of the HTML5 time semantic and related processing.<br />
<br />
=== simple nested time example improvement ===<br />
We'd like to have our <code>&lt;time&gt;</code> and date time separation as well, so this should work:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
=== summary of updated datetime algorithm ===<br />
In short: the algorithm for determining the "datetime" of a time element should:<br />
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)<br />
# check for nested &lt;time&gt; elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)<br />
# use the complete contents of the &lt;time&gt; element as its datetime value.<br />
<br />
Essentially, step 2 is added to enable composing nested child time elements.<br />
<br />
=== applicability to microdata ===<br />
All of the aforementioned advantages for microformats apply to microdata use of the &lt;time&gt; element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).<br />
<br />
=== nested time example with datetime attribute ===<br />
If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> information), thus reducing the risk of data divergence due to duplication.<br />
<br />
=== nested time example with two datetimes ===<br />
If the publisher prefers to publish a "localized" form of times, they can do that as well:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time datetime="18:00:00">6pm</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.<br />
<br />
The AM/PM proposal below further helps improve this example.<br />
<br />
=== nested time discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.<br />
* -1 [[User:Pigsonthewing|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time datetime="2005-10-05/2005-10-07"><br />
<time class="dtstart">October 5</time>-<br />
<time class="dtend">7</time><br />
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div></nowiki></pre><br />
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== am pm and coarser time parsing ==<br />
Right now time values inside a &lt;time&gt; element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)<br />
<br />
<pre><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time>5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.<br />
<br />
This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== am pm syntax summary ===<br />
<br />
In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).<br />
<br />
In short, the current &lt;time&gt; element only allows for the following time syntax:<br />
<br />
* HH:MM:SS - where HH is in 24 hour time.<br />
<br />
This proposal expands the allowed time syntax to:<br />
<br />
* HH:MM:SSam<br />
* HH:MM:SSpm<br />
* HH:MMam<br />
* HH:MMpm<br />
* HHam<br />
* HHpm<br />
<br />
=== am pm syntax details ===<br />
* '''periods, white-space, case-insensitivity.''' "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").<br />
* '''implied 00 minutes and seconds.''' When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;<br />
* '''handling of 12am and 12pm.''' "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).<br />
<br />
=== simple am pm example ===<br />
A simple example:<br />
<br />
<pre><nowiki><br />
I went to the cafe at <time>6pm</time>.<br />
</nowiki></pre><br />
<br />
Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.<br />
<br />
=== am pm example with nested time elements ===<br />
Example (uses aforementioned composite nested time element proposal as well)<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>6pm</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: again, this reduces DRY violations, in this case further improving upon the composite nested time elements case.<br />
<br />
=== am pm discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - in practice we in the microformats community have found that enabling users to markup am/pm times leads to many more cases where we can avoid violating DRY and thus encourage greater accuracy over time for such content. I think the HTML5 &lt;time&gt; element presents us with the opportunity to more cleanly markup times (than what we've been able to do with the aforementioned microformats value-class-pattern), and thus we should do so.<br />
* 0(query) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.<br />
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
=== am pm FAQ ===<br />
==== noon and midnight ====<br />
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?<br />
<br />
'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.<br />
<br />
==== am pm i18n ====<br />
'''Question:''' How does this internationalise "am" and "pm", for languages which do not use them? <br />
<br />
'''Answer:''' For languages that do not use "am" or "pm", the am pm proposal does not confer any additional advantage.<br />
<br />
= Minor editorial fixes =<br />
<br />
== Update hCalendar example ==<br />
<br />
Summary: please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.<br />
<br />
=== Current example ===<br />
<br />
The HTML5 spec currently has this hCalendar example:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>:<br />
<time class="dtstart" datetime="2007-10-05">October 5</time> -<br />
<time class="dtend" datetime="2007-10-20">19</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
<br />
(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)<br />
</nowiki></pre><br />
<br />
This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.<br />
<br />
=== Updated example ===<br />
<br />
Here is a suggested update:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time class="dtstart" datetime="2005-10-05">October 5</time>-<br />
<time class="dtend" datetime="2005-10-07">7</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
</nowiki></pre><br />
<br />
The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue dtend issue] for details).<br />
<br />
= Miscellaneous proposals =<br />
<br />
==Choose different default date==<br />
The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.<br />
<br />
A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* 0 (comment) [[User:Pigsonthewing|Andy Mabbett]] - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?<br />
* -1 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.<br />
* ...<br />
</div><br />
<br />
= Issues without specific proposals =<br />
==Specification ambiguities==<br />
The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.<br />
<br />
Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.<br />
<br />
<br />
= See Also =<br />
* [[input]] - the input element, related proposals expanding upon the new datetime inputs.<br />
<br />
= External links =<br />
<br />
== Tag ==<br />
Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time <!-- links to follow --><br />
<br />
== Prior discussion ==<br />
<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]<br />
* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith<br />
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]<br />
<br />
== Resources ==<br />
<br />
* [http://www.loc.gov/standards/datetime/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)<br />
** [http://www.loc.gov/standards/datetime/proposals.html EDTF proposals] (use-cases)<br />
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]<br />
** mailing list was datetime-comments@w3.org. - anyone have archives URL?<br />
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)<br />
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]<br />
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates<br />
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]<br />
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]<br />
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]<br />
* Dublin Core terms, e.g. <br />
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal<br />
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]<br />
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created<br />
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]<br />
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Time_element&diff=5408Time element2010-08-22T12:24:41Z<p>Ocolon: supported the proposals for YYYY only and YYYY-MM only dates</p>
<hr />
<div>Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].<br />
<br />
<br />
HTML5's new &lt;time&gt; element presents a huge opportunity to improve the publishing of datetime information on the web, the biggest opportunity since the introduction of hCalendar and other time-based microformats.<br />
<br />
However, the &lt;time&gt; element currently has several shortcomings that both prevent it from being used in numerous use-cases, and are suboptimal for authoring and data longevity.<br />
<br />
Please read the following proposals for improving the &lt;time&gt; element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.<br />
<br />
<br />
Thanks for your consideration,<br />
<br />
[[User:Tantek|Tantek]] (and other proposal authors).<br />
<br />
<br />
Please add new proposals to the end of the most relevantly related section, or if you're not sure where (or if there is no related section), at the end of the [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.<br />
<br />
=Date granularity=<br />
== year only ==<br />
The time element should accept just a year.<br />
;ISO8601 syntax<br />
:YYYY<br />
=== year only use cases ===<br />
use case research:<br />
* http://microformats.org/wiki/birthday-examples#year_only<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]<br />
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)<br />
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]<br />
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:<br />
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]<br />
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]<br />
*Citations from a bibliography which list two or more works by the same author disambiguate them by year<br />
*Commerce<br />
** "a piece of jewellery hallmarked 1933"<br />
** "a 1973 Chevy"<br />
*Sport<br />
**2008 Olympics<br />
**1966 World Cup<br />
*Awards<br />
**"1973 Oscar for best film"<br />
**"1988 Nobel Peace Prize"<br />
*Restyling dates for localisation and to follow user conventions<br />
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)<br />
* Relative dates in texts: news websites and blogs often use phrases such as<br />
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],<br />
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]<br />
<br />
=== year only discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.<br />
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next year I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year only related posts ===<br />
Related posts (listed with quotes directly related to year only) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote><br />
<br />
== year month only ==<br />
The time element should accept just a year and a month.<br />
;ISO8601 syntax<br />
:YYYY-MM<br />
<br />
=== year month use cases ===<br />
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)<br />
** http://www.flickr.com/photos/tantek/archives/<br />
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)<br />
* output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]<br />
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)<br />
* Restyling dates for localisation and to follow user conventions<br />
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)<br />
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:<br />
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]<br />
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]<br />
<br />
=== year month discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[User:Tantek|Tantek]] I think the blog archives use case (where blogs often link to their archives by a specific month and year) is sufficient to justify adding this capability to the time element. Content hosting sites like Flickr also list archives by specific year/month, e.g. see http://www.flickr.com/photos/tantek/archives/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.<br />
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]<br />
* +1 [[User:Ocolon|Martin Janecke]] - This would be great to mark up relative dates ("next January I will …") that actually refer to an absolute date in the context of the text and the publication date of the text respectively.<br />
* ...<br />
</div><br />
<br />
=== year month related posts ===<br />
Related posts (listed with quotes directly related to year-month) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote><br />
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote><br />
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote><br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the <nowiki>[sic]</nowiki> it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.</blockquote><br />
<br />
== year week only ==<br />
The time element should accept just a year and a week number.<br />
;ISO8601 syntax<br />
:YYYY-WNN<br />
;use case research<br />
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.<br />
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
;reasoning<br />
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code><br />
<br />
See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] per good design of impedance matching date time inputs.<br />
* ...<br />
</div><br />
<br />
== month day only ==<br />
The time element should accept just a month and a day.<br />
;ISO8601 syntax<br />
:--MM-DD<br />
;use case research<br />
:http://microformats.org/wiki/birthday-examples#month_and_day_only<br />
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF - see external links<br />
:Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 "radiz" implied support for --MM-DD with the use case question: "How to use &lt;time&gt; with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per [http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF, e.g. birthdays, wedding anniversaries - see external links)<br />
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.<br />
* ...<br />
</div><br />
<br />
= HTML5 internal consistency =<br />
== impedance match new date time inputs ==<br />
The time element should be able to represent every granularity of times and dates that the new date time <code>&lt;input&gt;</code> elements allow. Here is a list of all the date time <code>&lt;input&gt;</code> elements along with the corresponding <code>&lt;time&gt;</code> element usage (if applicable)<br />
<br />
<pre><nowiki><br />
<input type="date"> - <time>YYYY-MM-DD</time><br />
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time><br />
<input type="month"> - not supported in current time element<br />
<input type="week"> - not supported in current time element<br />
<input type="time"> - <time>HH:MM:SS</time><br />
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time><br />
New proposed input elements:<br />
<input type="year"> - not supported in current time element<br />
<input type="month-day"> - not supported in current time element<br />
</nowiki></pre><br />
<br />
In particular the <code>&lt;time&gt;</code> element is missing support for the following date inputs:<br />
<br />
* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].<br />
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].<br />
<br />
In addition, if the new proposed [[input]] elements are accepted, the respective time element support should be added as well:<br />
<br />
* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].<br />
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]]<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]]<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]]<br />
* ...<br />
</div><br />
<br />
= Proposals extending scope =<br />
<br />
== Fuzzy dates ==<br />
The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and eras ("Edwardian", "bronze age", "Jurassic")".<br />
<br />
;Use cases:<br />
:1. "... an application that might input Wikipedia data and output an annotated visual timeline. For movements or trends rather than events, it would need to output rough dates and date ranges like 2001-2003, rather than exact dates."[http://www.zeldman.com/superfriends/guide/#time] <br />
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.<br />
:2. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]<br />
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion<br />
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]<br />
:4 ...<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)<br />
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.<br />
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)<br />
* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:<br />
** certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)<br />
** certainty attribute takes an ISO8601 duration.<br />
** alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful)<br />
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre><br />
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 Bruce Darcus says]: "[While] I definitely think the use case is important...<br />
**"...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] I like the concept, but the syntax should be less verbose and more precise.<br />
** "Circa" can be indicated with a tilde prefix "~"<br />
** Ranges can use [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).<br />
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.<br />
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== Calendar scale ==<br />
The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 emergent vCard 4 specification], to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using one of a set of pre-defined CALSCALE types.<br />
<br />
=== Calendar scale example ===<br />
Example:<br />
<br />
<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre><br />
<br />
=== Calendar scale processing ===<br />
User agents could be instructed to ignore any unrecognised CALSCALE value, treating the contents of the element as plain text for data-processing (but not styling) purposes. This would prevent, for example the processing of the above example by an agent written to deal only with Gregorian dates. (At some point, CSS should recognise CALSCALE, allowing authors to, say, style all Julian dates differently to Gregorian dates.)<br />
<br />
=== Calendar scale use cases ===<br />
Use case research:<br />
* The Wikipedia timeline example in [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element] proposes to map a timeline of dates from Wikipedia (e.g. 2001-2003 Gregorian). However, Wikipedia includes several thousand articles about or referring to <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - target site currently broken, but worked previously; a fix is promised shortly) can only map Wikipedia's Gregorian dates, because there is currently no way to mark up Julian dates in a machine-readable format. The use of CALSCALE as suggested would allow this implementation and others to map all of these dates. (Note that the implementation works with any site, not just Wikipedia, parsing hCalendar microformats.)<br />
* Julian dates in [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]: <br />
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.<br />
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar<br />
<br />
=== Calendar scale discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)<br />
* 0 [[User:Tantek|Tantek]] - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.<br />
* …<br />
</div><br />
<br />
=== Calendar scale related posts ===<br />
Related posts (listed with quotes directly related to Calendar scale) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like [(refers to prototype CALSCALE)] where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale<br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.<br />
<br />
= Syntax improvements for reducing DRY violations =<br />
<br />
We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).<br />
<br />
This experience yielded the microformats adoption of the DRY principle - '''D'''on't '''R'''epeat '''Y'''ourself - in application to (meta)dataformat designs and techniques.<br />
<br />
<br />
The &lt;time&gt; element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).<br />
<br />
This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the &lt;abbr&gt; element.<br />
<br />
Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related &lt;abbr&gt; problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).<br />
<br />
http://microformats.org/wiki/value-class-pattern#Date_and_time_values<br />
<br />
We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 &lt;time&gt; element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).<br />
<br />
Accordingly, please consider the following &lt;time&gt; syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.<br />
<br />
<br />
== composite nested time elements ==<br />
A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.<br />
<br />
This is intended as a cleaner way to provide functionality equivalent to the microformats [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])<br />
<br />
<pre><nowiki><br />
<time class="published" datetime="2009-12-13T17:43:29"><br />
Sunday, December 13th, 2009<br />
5:43pm<br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
and have the parent &lt;time&gt; element composite a complete datetime from the child &lt;time&gt; elements with separate date and time.<br />
<br />
The <em>separate</em> date and time <code>datetime</code> attribute values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the "same" value as the in-content text, thus resulting in incrementally more accurate data over time.<br />
<br />
This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== background ===<br />
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"<br />
datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).<br />
<br />
=== microformats value class pattern DRY advantage ===<br />
With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<span class="dtstart"><br />
<span class="value">18:00</span> on <br />
<span class="value">2010-08-05</span><br />
</span>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.<br />
<br />
Disadvantage: the loss of the HTML5 time semantic and related processing.<br />
<br />
=== simple nested time example improvement ===<br />
We'd like to have our <code>&lt;time&gt;</code> and date time separation as well, so this should work:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
=== summary of updated datetime algorithm ===<br />
In short: the algorithm for determining the "datetime" of a time element should:<br />
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)<br />
# check for nested &lt;time&gt; elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)<br />
# use the complete contents of the &lt;time&gt; element as its datetime value.<br />
<br />
Essentially, step 2 is added to enable composing nested child time elements.<br />
<br />
=== applicability to microdata ===<br />
All of the aforementioned advantages for microformats apply to microdata use of the &lt;time&gt; element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).<br />
<br />
=== nested time example with datetime attribute ===<br />
If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> information), thus reducing the risk of data divergence due to duplication.<br />
<br />
=== nested time example with two datetimes ===<br />
If the publisher prefers to publish a "localized" form of times, they can do that as well:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time datetime="18:00:00">6pm</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.<br />
<br />
The AM/PM proposal below further helps improve this example.<br />
<br />
=== nested time discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.<br />
* -1 [[User:Pigsonthewing|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time datetime="2005-10-05/2005-10-07"><br />
<time class="dtstart">October 5</time>-<br />
<time class="dtend">7</time><br />
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div></nowiki></pre><br />
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== am pm and coarser time parsing ==<br />
Right now time values inside a &lt;time&gt; element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)<br />
<br />
<pre><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time>5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.<br />
<br />
This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== am pm syntax summary ===<br />
<br />
In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).<br />
<br />
In short, the current &lt;time&gt; element only allows for the following time syntax:<br />
<br />
* HH:MM:SS - where HH is in 24 hour time.<br />
<br />
This proposal expands the allowed time syntax to:<br />
<br />
* HH:MM:SSam<br />
* HH:MM:SSpm<br />
* HH:MMam<br />
* HH:MMpm<br />
* HHam<br />
* HHpm<br />
<br />
=== am pm syntax details ===<br />
* '''periods, white-space, case-insensitivity.''' "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").<br />
* '''implied 00 minutes and seconds.''' When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;<br />
* '''handling of 12am and 12pm.''' "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).<br />
<br />
=== simple am pm example ===<br />
A simple example:<br />
<br />
<pre><nowiki><br />
I went to the cafe at <time>6pm</time>.<br />
</nowiki></pre><br />
<br />
Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.<br />
<br />
=== am pm example with nested time elements ===<br />
Example (uses aforementioned composite nested time element proposal as well)<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>6pm</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: again, this reduces DRY violations, in this case further improving upon the composite nested time elements case.<br />
<br />
=== am pm discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - in practice we in the microformats community have found that enabling users to markup am/pm times leads to many more cases where we can avoid violating DRY and thus encourage greater accuracy over time for such content. I think the HTML5 &lt;time&gt; element presents us with the opportunity to more cleanly markup times (than what we've been able to do with the aforementioned microformats value-class-pattern), and thus we should do so.<br />
* 0(query) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.<br />
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
=== am pm FAQ ===<br />
==== noon and midnight ====<br />
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?<br />
<br />
'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.<br />
<br />
==== am pm i18n ====<br />
'''Question:''' How does this internationalise "am" and "pm", for languages which do not use them? <br />
<br />
'''Answer:''' For languages that do not use "am" or "pm", the am pm proposal does not confer any additional advantage.<br />
<br />
= Minor editorial fixes =<br />
<br />
== Update hCalendar example ==<br />
<br />
Summary: please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.<br />
<br />
=== Current example ===<br />
<br />
The HTML5 spec currently has this hCalendar example:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>:<br />
<time class="dtstart" datetime="2007-10-05">October 5</time> -<br />
<time class="dtend" datetime="2007-10-20">19</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
<br />
(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)<br />
</nowiki></pre><br />
<br />
This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.<br />
<br />
=== Updated example ===<br />
<br />
Here is a suggested update:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time class="dtstart" datetime="2005-10-05">October 5</time>-<br />
<time class="dtend" datetime="2005-10-07">7</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
</nowiki></pre><br />
<br />
The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue dtend issue] for details).<br />
<br />
= Miscellaneous proposals =<br />
<br />
==Choose different default date==<br />
The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.<br />
<br />
A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* 0 (comment) [[User:Pigsonthewing|Andy Mabbett]] - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?<br />
* -1 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.<br />
* ...<br />
</div><br />
<br />
= Issues without specific proposals =<br />
==Specification ambiguities==<br />
The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.<br />
<br />
Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.<br />
<br />
<br />
= See Also =<br />
* [[input]] - the input element, related proposals expanding upon the new datetime inputs.<br />
<br />
= External links =<br />
<br />
== Tag ==<br />
Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time <!-- links to follow --><br />
<br />
== Prior discussion ==<br />
<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]<br />
* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith<br />
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]<br />
<br />
== Resources ==<br />
<br />
* [http://www.loc.gov/standards/datetime/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)<br />
** [http://www.loc.gov/standards/datetime/proposals.html EDTF proposals] (use-cases)<br />
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]<br />
** mailing list was datetime-comments@w3.org. - anyone have archives URL?<br />
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)<br />
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]<br />
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates<br />
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]<br />
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]<br />
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]<br />
* Dublin Core terms, e.g. <br />
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal<br />
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]<br />
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created<br />
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]<br />
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Time_element&diff=5407Time element2010-08-22T12:16:00Z<p>Ocolon: /* year month use cases */ added use cases of relative dates in texts, which still refer to an absolute YYYY-MM date</p>
<hr />
<div>Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].<br />
<br />
<br />
HTML5's new &lt;time&gt; element presents a huge opportunity to improve the publishing of datetime information on the web, the biggest opportunity since the introduction of hCalendar and other time-based microformats.<br />
<br />
However, the &lt;time&gt; element currently has several shortcomings that both prevent it from being used in numerous use-cases, and are suboptimal for authoring and data longevity.<br />
<br />
Please read the following proposals for improving the &lt;time&gt; element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.<br />
<br />
<br />
Thanks for your consideration,<br />
<br />
[[User:Tantek|Tantek]] (and other proposal authors).<br />
<br />
<br />
Please add new proposals to the end of the most relevantly related section, or if you're not sure where (or if there is no related section), at the end of the [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.<br />
<br />
=Date granularity=<br />
== year only ==<br />
The time element should accept just a year.<br />
;ISO8601 syntax<br />
:YYYY<br />
=== year only use cases ===<br />
use case research:<br />
* http://microformats.org/wiki/birthday-examples#year_only<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]<br />
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)<br />
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]<br />
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:<br />
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]<br />
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]<br />
*Citations from a bibliography which list two or more works by the same author disambiguate them by year<br />
*Commerce<br />
** "a piece of jewellery hallmarked 1933"<br />
** "a 1973 Chevy"<br />
*Sport<br />
**2008 Olympics<br />
**1966 World Cup<br />
*Awards<br />
**"1973 Oscar for best film"<br />
**"1988 Nobel Peace Prize"<br />
*Restyling dates for localisation and to follow user conventions<br />
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)<br />
* Relative dates in texts: news websites and blogs often use phrases such as<br />
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],<br />
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]<br />
<br />
=== year only discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.<br />
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]<br />
* ...<br />
</div><br />
<br />
=== year only related posts ===<br />
Related posts (listed with quotes directly related to year only) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote><br />
<br />
== year month only ==<br />
The time element should accept just a year and a month.<br />
;ISO8601 syntax<br />
:YYYY-MM<br />
<br />
=== year month use cases ===<br />
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)<br />
** http://www.flickr.com/photos/tantek/archives/<br />
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)<br />
* output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]<br />
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)<br />
* Restyling dates for localisation and to follow user conventions<br />
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)<br />
* Relative dates in text: news websites, blogs and statistical institutes often use phrases like:<br />
** "in June 2010, the turnover […] decreased by 10.5% compared to the same month of the previous year." [http://www.nsi.bg/eventen.php?n=568]<br />
** "George W. Bush leaves office in January next year" [http://afp.google.com/article/ALeqM5hm2kKrBzl5p5Psm-EryzKK_m8H_A]<br />
<br />
=== year month discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[User:Tantek|Tantek]] I think the blog archives use case (where blogs often link to their archives by a specific month and year) is sufficient to justify adding this capability to the time element. Content hosting sites like Flickr also list archives by specific year/month, e.g. see http://www.flickr.com/photos/tantek/archives/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.<br />
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]<br />
* ...<br />
</div><br />
<br />
=== year month related posts ===<br />
Related posts (listed with quotes directly related to year-month) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote><br />
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote><br />
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote><br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the <nowiki>[sic]</nowiki> it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.</blockquote><br />
<br />
== year week only ==<br />
The time element should accept just a year and a week number.<br />
;ISO8601 syntax<br />
:YYYY-WNN<br />
;use case research<br />
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.<br />
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
;reasoning<br />
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code><br />
<br />
See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] per good design of impedance matching date time inputs.<br />
* ...<br />
</div><br />
<br />
== month day only ==<br />
The time element should accept just a month and a day.<br />
;ISO8601 syntax<br />
:--MM-DD<br />
;use case research<br />
:http://microformats.org/wiki/birthday-examples#month_and_day_only<br />
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF - see external links<br />
:Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 "radiz" implied support for --MM-DD with the use case question: "How to use &lt;time&gt; with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per [http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF, e.g. birthdays, wedding anniversaries - see external links)<br />
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.<br />
* ...<br />
</div><br />
<br />
= HTML5 internal consistency =<br />
== impedance match new date time inputs ==<br />
The time element should be able to represent every granularity of times and dates that the new date time <code>&lt;input&gt;</code> elements allow. Here is a list of all the date time <code>&lt;input&gt;</code> elements along with the corresponding <code>&lt;time&gt;</code> element usage (if applicable)<br />
<br />
<pre><nowiki><br />
<input type="date"> - <time>YYYY-MM-DD</time><br />
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time><br />
<input type="month"> - not supported in current time element<br />
<input type="week"> - not supported in current time element<br />
<input type="time"> - <time>HH:MM:SS</time><br />
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time><br />
New proposed input elements:<br />
<input type="year"> - not supported in current time element<br />
<input type="month-day"> - not supported in current time element<br />
</nowiki></pre><br />
<br />
In particular the <code>&lt;time&gt;</code> element is missing support for the following date inputs:<br />
<br />
* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].<br />
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].<br />
<br />
In addition, if the new proposed [[input]] elements are accepted, the respective time element support should be added as well:<br />
<br />
* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].<br />
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]]<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]]<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]]<br />
* ...<br />
</div><br />
<br />
= Proposals extending scope =<br />
<br />
== Fuzzy dates ==<br />
The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and eras ("Edwardian", "bronze age", "Jurassic")".<br />
<br />
;Use cases:<br />
:1. "... an application that might input Wikipedia data and output an annotated visual timeline. For movements or trends rather than events, it would need to output rough dates and date ranges like 2001-2003, rather than exact dates."[http://www.zeldman.com/superfriends/guide/#time] <br />
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.<br />
:2. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]<br />
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion<br />
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]<br />
:4 ...<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)<br />
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.<br />
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)<br />
* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:<br />
** certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)<br />
** certainty attribute takes an ISO8601 duration.<br />
** alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful)<br />
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre><br />
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 Bruce Darcus says]: "[While] I definitely think the use case is important...<br />
**"...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] I like the concept, but the syntax should be less verbose and more precise.<br />
** "Circa" can be indicated with a tilde prefix "~"<br />
** Ranges can use [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).<br />
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.<br />
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== Calendar scale ==<br />
The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 emergent vCard 4 specification], to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using one of a set of pre-defined CALSCALE types.<br />
<br />
=== Calendar scale example ===<br />
Example:<br />
<br />
<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre><br />
<br />
=== Calendar scale processing ===<br />
User agents could be instructed to ignore any unrecognised CALSCALE value, treating the contents of the element as plain text for data-processing (but not styling) purposes. This would prevent, for example the processing of the above example by an agent written to deal only with Gregorian dates. (At some point, CSS should recognise CALSCALE, allowing authors to, say, style all Julian dates differently to Gregorian dates.)<br />
<br />
=== Calendar scale use cases ===<br />
Use case research:<br />
* The Wikipedia timeline example in [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element] proposes to map a timeline of dates from Wikipedia (e.g. 2001-2003 Gregorian). However, Wikipedia includes several thousand articles about or referring to <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - target site currently broken, but worked previously; a fix is promised shortly) can only map Wikipedia's Gregorian dates, because there is currently no way to mark up Julian dates in a machine-readable format. The use of CALSCALE as suggested would allow this implementation and others to map all of these dates. (Note that the implementation works with any site, not just Wikipedia, parsing hCalendar microformats.)<br />
* Julian dates in [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]: <br />
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.<br />
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar<br />
<br />
=== Calendar scale discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)<br />
* 0 [[User:Tantek|Tantek]] - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.<br />
* …<br />
</div><br />
<br />
=== Calendar scale related posts ===<br />
Related posts (listed with quotes directly related to Calendar scale) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like [(refers to prototype CALSCALE)] where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale<br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.<br />
<br />
= Syntax improvements for reducing DRY violations =<br />
<br />
We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).<br />
<br />
This experience yielded the microformats adoption of the DRY principle - '''D'''on't '''R'''epeat '''Y'''ourself - in application to (meta)dataformat designs and techniques.<br />
<br />
<br />
The &lt;time&gt; element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).<br />
<br />
This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the &lt;abbr&gt; element.<br />
<br />
Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related &lt;abbr&gt; problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).<br />
<br />
http://microformats.org/wiki/value-class-pattern#Date_and_time_values<br />
<br />
We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 &lt;time&gt; element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).<br />
<br />
Accordingly, please consider the following &lt;time&gt; syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.<br />
<br />
<br />
== composite nested time elements ==<br />
A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.<br />
<br />
This is intended as a cleaner way to provide functionality equivalent to the microformats [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])<br />
<br />
<pre><nowiki><br />
<time class="published" datetime="2009-12-13T17:43:29"><br />
Sunday, December 13th, 2009<br />
5:43pm<br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
and have the parent &lt;time&gt; element composite a complete datetime from the child &lt;time&gt; elements with separate date and time.<br />
<br />
The <em>separate</em> date and time <code>datetime</code> attribute values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the "same" value as the in-content text, thus resulting in incrementally more accurate data over time.<br />
<br />
This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== background ===<br />
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"<br />
datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).<br />
<br />
=== microformats value class pattern DRY advantage ===<br />
With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<span class="dtstart"><br />
<span class="value">18:00</span> on <br />
<span class="value">2010-08-05</span><br />
</span>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.<br />
<br />
Disadvantage: the loss of the HTML5 time semantic and related processing.<br />
<br />
=== simple nested time example improvement ===<br />
We'd like to have our <code>&lt;time&gt;</code> and date time separation as well, so this should work:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
=== summary of updated datetime algorithm ===<br />
In short: the algorithm for determining the "datetime" of a time element should:<br />
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)<br />
# check for nested &lt;time&gt; elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)<br />
# use the complete contents of the &lt;time&gt; element as its datetime value.<br />
<br />
Essentially, step 2 is added to enable composing nested child time elements.<br />
<br />
=== applicability to microdata ===<br />
All of the aforementioned advantages for microformats apply to microdata use of the &lt;time&gt; element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).<br />
<br />
=== nested time example with datetime attribute ===<br />
If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> information), thus reducing the risk of data divergence due to duplication.<br />
<br />
=== nested time example with two datetimes ===<br />
If the publisher prefers to publish a "localized" form of times, they can do that as well:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time datetime="18:00:00">6pm</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.<br />
<br />
The AM/PM proposal below further helps improve this example.<br />
<br />
=== nested time discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.<br />
* -1 [[User:Pigsonthewing|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time datetime="2005-10-05/2005-10-07"><br />
<time class="dtstart">October 5</time>-<br />
<time class="dtend">7</time><br />
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div></nowiki></pre><br />
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== am pm and coarser time parsing ==<br />
Right now time values inside a &lt;time&gt; element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)<br />
<br />
<pre><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time>5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.<br />
<br />
This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== am pm syntax summary ===<br />
<br />
In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).<br />
<br />
In short, the current &lt;time&gt; element only allows for the following time syntax:<br />
<br />
* HH:MM:SS - where HH is in 24 hour time.<br />
<br />
This proposal expands the allowed time syntax to:<br />
<br />
* HH:MM:SSam<br />
* HH:MM:SSpm<br />
* HH:MMam<br />
* HH:MMpm<br />
* HHam<br />
* HHpm<br />
<br />
=== am pm syntax details ===<br />
* '''periods, white-space, case-insensitivity.''' "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").<br />
* '''implied 00 minutes and seconds.''' When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;<br />
* '''handling of 12am and 12pm.''' "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).<br />
<br />
=== simple am pm example ===<br />
A simple example:<br />
<br />
<pre><nowiki><br />
I went to the cafe at <time>6pm</time>.<br />
</nowiki></pre><br />
<br />
Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.<br />
<br />
=== am pm example with nested time elements ===<br />
Example (uses aforementioned composite nested time element proposal as well)<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>6pm</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: again, this reduces DRY violations, in this case further improving upon the composite nested time elements case.<br />
<br />
=== am pm discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - in practice we in the microformats community have found that enabling users to markup am/pm times leads to many more cases where we can avoid violating DRY and thus encourage greater accuracy over time for such content. I think the HTML5 &lt;time&gt; element presents us with the opportunity to more cleanly markup times (than what we've been able to do with the aforementioned microformats value-class-pattern), and thus we should do so.<br />
* 0(query) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.<br />
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
=== am pm FAQ ===<br />
==== noon and midnight ====<br />
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?<br />
<br />
'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.<br />
<br />
==== am pm i18n ====<br />
'''Question:''' How does this internationalise "am" and "pm", for languages which do not use them? <br />
<br />
'''Answer:''' For languages that do not use "am" or "pm", the am pm proposal does not confer any additional advantage.<br />
<br />
= Minor editorial fixes =<br />
<br />
== Update hCalendar example ==<br />
<br />
Summary: please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.<br />
<br />
=== Current example ===<br />
<br />
The HTML5 spec currently has this hCalendar example:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>:<br />
<time class="dtstart" datetime="2007-10-05">October 5</time> -<br />
<time class="dtend" datetime="2007-10-20">19</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
<br />
(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)<br />
</nowiki></pre><br />
<br />
This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.<br />
<br />
=== Updated example ===<br />
<br />
Here is a suggested update:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time class="dtstart" datetime="2005-10-05">October 5</time>-<br />
<time class="dtend" datetime="2005-10-07">7</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
</nowiki></pre><br />
<br />
The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue dtend issue] for details).<br />
<br />
= Miscellaneous proposals =<br />
<br />
==Choose different default date==<br />
The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.<br />
<br />
A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* 0 (comment) [[User:Pigsonthewing|Andy Mabbett]] - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?<br />
* -1 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.<br />
* ...<br />
</div><br />
<br />
= Issues without specific proposals =<br />
==Specification ambiguities==<br />
The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.<br />
<br />
Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.<br />
<br />
<br />
= See Also =<br />
* [[input]] - the input element, related proposals expanding upon the new datetime inputs.<br />
<br />
= External links =<br />
<br />
== Tag ==<br />
Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time <!-- links to follow --><br />
<br />
== Prior discussion ==<br />
<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]<br />
* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith<br />
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]<br />
<br />
== Resources ==<br />
<br />
* [http://www.loc.gov/standards/datetime/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)<br />
** [http://www.loc.gov/standards/datetime/proposals.html EDTF proposals] (use-cases)<br />
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]<br />
** mailing list was datetime-comments@w3.org. - anyone have archives URL?<br />
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)<br />
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]<br />
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates<br />
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]<br />
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]<br />
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]<br />
* Dublin Core terms, e.g. <br />
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal<br />
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]<br />
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created<br />
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]<br />
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Time_element&diff=5406Time element2010-08-22T11:59:46Z<p>Ocolon: /* year only use cases */ added relative dates with examples of "last year" and "next year" from news articles</p>
<hr />
<div>Summary: Research, data, use cases, issues, and enhancements related to the [http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element HTML5 <code>time</code> element].<br />
<br />
<br />
HTML5's new &lt;time&gt; element presents a huge opportunity to improve the publishing of datetime information on the web, the biggest opportunity since the introduction of hCalendar and other time-based microformats.<br />
<br />
However, the &lt;time&gt; element currently has several shortcomings that both prevent it from being used in numerous use-cases, and are suboptimal for authoring and data longevity.<br />
<br />
Please read the following proposals for improving the &lt;time&gt; element, grouped by category, and offer your opinions, use-cases, evidence and - hopefully - support in the respective discussion sections.<br />
<br />
<br />
Thanks for your consideration,<br />
<br />
[[User:Tantek|Tantek]] (and other proposal authors).<br />
<br />
<br />
Please add new proposals to the end of the most relevantly related section, or if you're not sure where (or if there is no related section), at the end of the [[Time_element#Miscellaneous_proposals|Miscellaneous proposals]] section.<br />
<br />
=Date granularity=<br />
== year only ==<br />
The time element should accept just a year.<br />
;ISO8601 syntax<br />
:YYYY<br />
=== year only use cases ===<br />
use case research:<br />
* http://microformats.org/wiki/birthday-examples#year_only<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY instances]<br />
* [http://en.wikipedia.org/w/index.php?title=Ethan_Stiefel&oldid=377074089 Wikipedia infobox with YYYY birthdate] (unknown MM-DD)<br />
* Copyright notices are often year-only; e.g. that at the foot of [http://www.rspb.org.uk/groups/suttoncoldfield/]<br />
* In biological taxonomy, a species', genus' or other rank's ''authority'' (the person who named it, and the year they did so) always includes a whole-year date value. For example:<br />
**Barn Owl, ''Tyto alba'' (Scopoli, 1769) [http://en.wikipedia.org/wiki/Barn_owl]<br />
**Strigiformes (Wagler, 1830) [http://en.wikipedia.org/wiki/Owl]<br />
*Citations from a bibliography which list two or more works by the same author disambiguate them by year<br />
*Commerce<br />
** "a piece of jewellery hallmarked 1933"<br />
** "a 1973 Chevy"<br />
*Sport<br />
**2008 Olympics<br />
**1966 World Cup<br />
*Awards<br />
**"1973 Oscar for best film"<br />
**"1988 Nobel Peace Prize"<br />
*Restyling dates for localisation and to follow user conventions<br />
**2010 to 平22年 to 2010年 (all acceptable ways to represent 2010 in Japan)<br />
* Relative dates in texts: news websites and blogs often use phrases such as<br />
** "damages during last year's Gaza offensive" [http://www.un.org/apps/news/story.asp?NewsID=33559],<br />
** "recession next year almost inevitable" [http://www.reuters.com/article/idUSTRE65E5K520100615]<br />
<br />
=== year only discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2 years on Wikipedia] ("...global military conflict lasting from 1939 to 1945...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is often used to format date description for resume's Stackoverflow http://careers.stackoverflow.com/klmr I could list more cases in the wild. Like YYYY, YYYY-MM or YYYY-MM-DD its part of the http://www.w3.org/TR/NOTE-datetime profile.<br />
* +1 [[User:Oli|Oli Studholme]] This would be useful for semantically marking up years, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year). Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]<br />
* ...<br />
</div><br />
<br />
=== year only related posts ===<br />
Related posts (listed with quotes directly related to year only) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like ... “1935″ which are currently disallowed by the spec</blockquote><br />
<br />
== year month only ==<br />
The time element should accept just a year and a month.<br />
;ISO8601 syntax<br />
:YYYY-MM<br />
<br />
=== year month use cases ===<br />
* Blog/publishing archive pages - see Benward.me, ablognotlimited.com (need specific links to archive pages)<br />
** http://www.flickr.com/photos/tantek/archives/<br />
** [http://lists.whatwg.org/htdig.cgi/help-whatwg.org/ whatwg's own mailing list archives] (!)<br />
* output equivalent of <code>&lt;input type="month"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]].<br />
* use cases in VCARDDAV & EDTF - see external links<br />
* [http://en.wikipedia.org/wiki/Template:Start_date Wikipedia 'Start date' template] - thousands of [http://bit.ly/aKhmdQ YYYY-MM instances]<br />
* Credit/ debit card expiry dates, entered into, then republished for verification on, e-commerce sites (security concerns prohibit use of example URL)<br />
* Restyling dates for localisation and to follow user conventions<br />
** 2010-08 to 08-2010 to 平22年8月 to 2010年8月 (all acceptable ways to represent August 2010 in Japan)<br />
<br />
=== year month discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Faruk]] (per [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7145 Bug 7145 - Valid date strings should accept ambiguous inputs, like "2009" or "2007-01"]) One example is the very common archive view found on most blogs, which contain distinct links or headers for each year, each month per year, and often each date within a chosen or highlighted month. Currently, the <code>&lt;time&gt;</code> element only allows for <code>datetime</code> values as precise as a specific day, e.g. YYYY-MM-DD.<br />
* -1 [[Hixie]] - "Without clear use cases, I don't intend to change the spec here." (ibid)<br />
* +1 [[User:Tantek|Tantek]] I think the blog archives use case (where blogs often link to their archives by a specific month and year) is sufficient to justify adding this capability to the time element. Content hosting sites like Flickr also list archives by specific year/month, e.g. see http://www.flickr.com/photos/tantek/archives/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV & EDTF - see external links)<br />
* +1 [[User:Philipj|Philip Jägenstedt]] - for marking up [http://musicbrainz.org/release/aa82c130-c734-4d9c-b06a-5bba9b44295d.html release dates on e.g. MusicBrainz] where the date is given as YYYY, YYYY-MM or YYYY-MM-DD.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - for marking up [http://en.wikipedia.org/wiki/World_war_2#Japanese_invasion_of_China month+year on Wikipedia] ("In July 1937, Japan captured the former Chinese imperial capital of Beiping...").<br />
* +1 [[User:GlennJones|Glenn Jones]] - This is the most commonly used format date description for Resume's. Linked-in use it http://www.linkedin.com/in/steveganz and Stackoverflow http://careers.stackoverflow.com/klmr I could list many more cases in the wild.<br />
* +1 [[User:Oli|Oli Studholme]] As with the year example above, this would be useful for semantically marking up year-month dates, as in Japan there’s an additional era-based method of representing years (and even Japanese people find it difficult to convert between them), and it would allow the browser to automatically display the user-preferred format. It would also also enable browser-based localisation (adding a 年 after the year, and 月 after the month). Having this data semantically notated would help make the use in Japan of 2-digit years on credit cards and in e-commerce more accessible. Finally it would be useful for marking up future imprecise dates (e.g. events being planned), allowing someone to add these dates to a calendar automatically (rather than marking up teh events plus manually adding them to a calendar). [ref: [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028025.html email to WHATWG]]<br />
* ...<br />
</div><br />
<br />
=== year month related posts ===<br />
Related posts (listed with quotes directly related to year-month) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">hCalendar microformats are already used to mark up imprecise dates (“June 1977″; “2009″). ISO8601 already supports them. Why not HTML5?</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up ... dates like “July 2008″ ... which are currently disallowed by the spec</blockquote><br />
* [http://www.brucelawson.co.uk/2009/marking-up-a-blog-with-html-5-part-2/#time 2009-03-06 Marking up a blog with HTML 5 (part 2) : Time] blog post by Bruce Lawson: <blockquote>I suggest the spec be amended to allow dates like "July 1966"</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/ 2009-08-20 HTML 5: what’s hot, what’s not] blog post by Bruce Lawson - see section on TIME which explicitly mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-whats-hot-whats-not/">The time element is still hamstrung by not being able to markup ... dates like “December 1935″</blockquote><br />
* [http://adactio.com/journal/1604/ 2009-08-30 HTML5 and me] blog post by Jeremy Keith - see section on "time" which explicitly mentions <blockquote cite="http://adactio.com/journal/1604/">make a piece of information like “April 1912” machine-readable</blockquote><br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the <nowiki>[sic]</nowiki> it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″.</blockquote><br />
<br />
== year week only ==<br />
The time element should accept just a year and a week number.<br />
;ISO8601 syntax<br />
:YYYY-WNN<br />
;use case research<br />
:no examples in the wild currently. If anyone knows of any sites which publish references to specific weeks of a year, either by name / expression (e.g. "first week of the year") or by specific number (e.g. "weeks 1-26"), please provide URLs and quotes of example content.<br />
:output equivalent of <code>&lt;input type="week"&gt;</code>, see [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
;reasoning<br />
:to provide the output equivalent of <code>&lt;input type="week"&gt;</code><br />
<br />
See [[Time_element#impedance_match_new_date_time_inputs|impedance match new date time inputs]] above.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] per good design of impedance matching date time inputs.<br />
* ...<br />
</div><br />
<br />
== month day only ==<br />
The time element should accept just a month and a day.<br />
;ISO8601 syntax<br />
:--MM-DD<br />
;use case research<br />
:http://microformats.org/wiki/birthday-examples#month_and_day_only<br />
:[http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF - see external links<br />
:Facebook - allows users to elect to show their birthday as, for example, "17 December", with no year.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] (per [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element])<br />
* +1 "radiz" implied support for --MM-DD with the use case question: "How to use &lt;time&gt; with a date in astrology?" in the article http://html5doctor.com/your-questions-answered-6/<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per [http://www.ietf.org/mail-archive/web/vcarddav/current/msg00999.html use cases discussed in VCARDDAV] & EDTF, e.g. birthdays, wedding anniversaries - see external links)<br />
** [http://portablecontacts.net/draft-spec.html#anchor16 Portable contacts allows this] using a "0000" year value.<br />
* ...<br />
</div><br />
<br />
= HTML5 internal consistency =<br />
== impedance match new date time inputs ==<br />
The time element should be able to represent every granularity of times and dates that the new date time <code>&lt;input&gt;</code> elements allow. Here is a list of all the date time <code>&lt;input&gt;</code> elements along with the corresponding <code>&lt;time&gt;</code> element usage (if applicable)<br />
<br />
<pre><nowiki><br />
<input type="date"> - <time>YYYY-MM-DD</time><br />
<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time><br />
<input type="month"> - not supported in current time element<br />
<input type="week"> - not supported in current time element<br />
<input type="time"> - <time>HH:MM:SS</time><br />
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time><br />
New proposed input elements:<br />
<input type="year"> - not supported in current time element<br />
<input type="month-day"> - not supported in current time element<br />
</nowiki></pre><br />
<br />
In particular the <code>&lt;time&gt;</code> element is missing support for the following date inputs:<br />
<br />
* input type="month" - this would be satisfied by the [[Time_element#year_month_only|time element year month proposal]].<br />
* input type="week" - this would be satisfied by the [[Time_element#year_week_only|time element year week proposal]].<br />
<br />
In addition, if the new proposed [[input]] elements are accepted, the respective time element support should be added as well:<br />
<br />
* input type="year" - this would be satisfied by the [[Time_element#year_only|time element year proposal]].<br />
* input type="month-day" - this would be satisfied by the [[Time_element#month_day_only|time element month day proposal]].<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]]<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]]<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]]<br />
* ...<br />
</div><br />
<br />
= Proposals extending scope =<br />
<br />
== Fuzzy dates ==<br />
The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and eras ("Edwardian", "bronze age", "Jurassic")".<br />
<br />
;Use cases:<br />
:1. "... an application that might input Wikipedia data and output an annotated visual timeline. For movements or trends rather than events, it would need to output rough dates and date ranges like 2001-2003, rather than exact dates."[http://www.zeldman.com/superfriends/guide/#time] <br />
::Implemented, see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links], (target site currently broken, but worked previously; a fix is promised shortly), but can only map precise dates, because there is currently no way to mark up fuzzy dates in a machine-readable format. The acceptance of this proposal would allow this implementation and others to map all such dates. Note that the implementation works with any site, not just Wikipedia, by parsing hCalendar microformats.<br />
:2. [http://hypermedia.research.glam.ac.uk/kos/star/time-periods/ Time periods in astronomy]<br />
:: building on the English Heritage Periods list and Timelines thesaurus - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=3927 Douglas Tudhope's mailing list post] and prior discussion<br />
:3. [http://www.fish-forum.info/i_apl_e.htm http://www.fish-forum.info/i_apl_e.htm Archaeological Periods list] via [http://www.fish-forum.info/i_apl.htm Archaeological Periods list meta page] - see [https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1008&L=FISH&F=&S=&P=1738 Nick Boldrini's mailing list post]<br />
:4 ...<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)<br />
**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.<br />
* +1 [[User:eatyourgreens|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)<br />
* 0 (comments) [[User:Tantek|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:<br />
** certainty attribute, empty or missing is equivalent to "0" (absolute certainty presumably)<br />
** certainty attribute takes an ISO8601 duration.<br />
** alternatively it might make more sense to introduce a compound time structure for ranges such as the use case example of 2001-2003. Here is a strawman markup example (feel free to pick alternative markup, but re-using nested time elements for portions of a range seem useful)<br />
*** <pre><nowiki><range><time>2001</time>-<time>2003</time></range></nowiki></pre><br />
* +1 [http://listserv.loc.gov/cgi-bin/wa?A2=ind1008&L=datetime&T=0&X=4659876DD4D919D154&Y=andy%40pigsonthewing.org.uk&P=765 Bruce Darcus says]: "[While] I definitely think the use case is important...<br />
**"...I'm of the very strong opinion that an extended data-time format ought to be self-contained, and so not rely on format-specific extensions like X/HTML attributes. One ought to be able to use the same representation in an HTML attribute, or a JSON or RDF value, and losslessly convert among them. For that reason, I very much prefer the current [http://www.loc.gov/standards/datetime/features.html#300 draft idea in EDTF of doing "2000?" or "2000~".]"<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] I like the concept, but the syntax should be less verbose and more precise.<br />
** "Circa" can be indicated with a tilde prefix "~"<br />
** Ranges can use [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time interval syntax], like "2007/2008" or "2007-2008" which is also allowed (according to section 4.4.2).<br />
* 0 [[User:itpastorn|Lars Gunther]] One of the benefits of the time element is machine parsability. I can't see what benefit it adds for non-parsable text. There are bigger fish to fry.<br />
**The proposal is to make such dates machine parsable. [[User:Pigsonthewing|Pigsonthewing]] 09:54, 17 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== Calendar scale ==<br />
The time element should accept a calendar scale (CALSCALE; default is GREGORIAN) per (and to facilitate interoperability with) the [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 emergent vCard 4 specification], to allow for the the mark-up of non-Gregorian (e.g. Julian) dates, using one of a set of pre-defined CALSCALE types.<br />
<br />
=== Calendar scale example ===<br />
Example:<br />
<br />
<pre><nowiki><time datetime="1330-06-01" calscale="julian">1 June 1330</time></nowiki></pre><br />
<br />
=== Calendar scale processing ===<br />
User agents could be instructed to ignore any unrecognised CALSCALE value, treating the contents of the element as plain text for data-processing (but not styling) purposes. This would prevent, for example the processing of the above example by an agent written to deal only with Gregorian dates. (At some point, CSS should recognise CALSCALE, allowing authors to, say, style all Julian dates differently to Gregorian dates.)<br />
<br />
=== Calendar scale use cases ===<br />
Use case research:<br />
* The Wikipedia timeline example in [http://www.zeldman.com/superfriends/guide/#time HTML5 Super Friends Technical Details: time element] proposes to map a timeline of dates from Wikipedia (e.g. 2001-2003 Gregorian). However, Wikipedia includes several thousand articles about or referring to <em>pre</em>-Gregorian era events, usually using the Julian calendar, such as the birth and death of [http://en.wikipedia.org/wiki/Julius_ceasar Julius Ceaser] and, in the same article, the Ides of March (15 March) 44 BC. The existing timeline implementation (see [http://en.wikipedia.org/w/index.php?title=Bob_Brettle&oldid=376645341#External_links] - target site currently broken, but worked previously; a fix is promised shortly) can only map Wikipedia's Gregorian dates, because there is currently no way to mark up Julian dates in a machine-readable format. The use of CALSCALE as suggested would allow this implementation and others to map all of these dates. (Note that the implementation works with any site, not just Wikipedia, parsing hCalendar microformats.)<br />
* Julian dates in [http://ourgeorgiahistory.com/year/1577 timeline of Georgia]: <br />
* General: non-Gregorian dates are published in documents about museum artifacts, history, archaeology, genealogy etc. and in archives of historic documents.<br />
* See also various use cases under [[#Fuzzy dates]], above for eras pre-dating the Gregorian calendar<br />
<br />
=== Calendar scale discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[User:Pigsonthewing|Andy Mabbett]] (Per use cases in VCARDDAV, EDTF & TEI - see external links)<br />
* 0 [[User:Tantek|Tantek]] - Update: I have mixed feelings about this. On one hand, despite years of the presence of the CALSCALE feature in iCalendar etc., there are no implementations (AFAIK) of non-GREGORIAN CALSCALE values in iCalendar etc. user agents, thus there is no reason to believe that specifying it in HTML5 would actually encourage any other user agents to implement it either. On the other hand the Wikipedia long-term timeline use case <em>does</em> appeal to me so overall I've upgraded my opinion on this from -1 to 0 neutral.<br />
* …<br />
</div><br />
<br />
=== Calendar scale related posts ===<br />
Related posts (listed with quotes directly related to Calendar scale) :<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ 2009-02-23 Dates and coordinates in HTML5] blog post by Andy Mabbett - <blockquote cite="http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/">The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like [(refers to prototype CALSCALE)] where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply [date in plain text] if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.</blockquote><br />
* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale<br />
* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with &lt;time&gt; is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.<br />
<br />
= Syntax improvements for reducing DRY violations =<br />
<br />
We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location).<br />
<br />
This experience yielded the microformats adoption of the DRY principle - '''D'''on't '''R'''epeat '''Y'''ourself - in application to (meta)dataformat designs and techniques.<br />
<br />
<br />
The &lt;time&gt; element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This duplication can result in inaccurate data (e.g. [http://microformats.org/discuss/mail/microformats-dev/2010-August/000663.html]).<br />
<br />
This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the &lt;abbr&gt; element.<br />
<br />
Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related &lt;abbr&gt; problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements).<br />
<br />
http://microformats.org/wiki/value-class-pattern#Date_and_time_values<br />
<br />
We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 &lt;time&gt; element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter).<br />
<br />
Accordingly, please consider the following &lt;time&gt; syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time.<br />
<br />
<br />
== composite nested time elements ==<br />
A time element should permit child time elements which may contain only partial date time information which can then be composed into more complete date time information.<br />
<br />
This is intended as a cleaner way to provide functionality equivalent to the microformats [http://microformats.org/wiki/value-class-pattern#Date_and_time_values value-class-pattern date and time values pattern].<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith])<br />
<br />
<pre><nowiki><br />
<time class="published" datetime="2009-12-13T17:43:29"><br />
Sunday, December 13th, 2009<br />
5:43pm<br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
and have the parent &lt;time&gt; element composite a complete datetime from the child &lt;time&gt; elements with separate date and time.<br />
<br />
The <em>separate</em> date and time <code>datetime</code> attribute values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the "same" value as the in-content text, thus resulting in incrementally more accurate data over time.<br />
<br />
This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== background ===<br />
Currently the &lt;time&gt; element forces you to duplicate and hide date time information if you want to avoid displaying the not-very-friendly full ISO datetime:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"<br />
datetime="2010-08-05T18:00:00">18:00 on 2010-08-05</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Note the date and time information is duplicated (violating DRY, placing the content at risk of divergence).<br />
<br />
=== microformats value class pattern DRY advantage ===<br />
With the microformats value-class-pattern date and time values pattern you could instead mark this up like this:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<span class="dtstart"><br />
<span class="value">18:00</span> on <br />
<span class="value">2010-08-05</span><br />
</span>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantages: no duplication of time and date data! (avoiding DRY violation) If you need to update the info, you only have to update it in one place, thus reducing the chances of inforot.<br />
<br />
Disadvantage: the loss of the HTML5 time semantic and related processing.<br />
<br />
=== simple nested time example improvement ===<br />
We'd like to have our <code>&lt;time&gt;</code> and date time separation as well, so this should work:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
=== summary of updated datetime algorithm ===<br />
In short: the algorithm for determining the "datetime" of a time element should:<br />
# check for an explicit 'datetime' attribute (allowing a local to element override regardless of child elements)<br />
# check for nested &lt;time&gt; elements, and if any are found, compose their values into a more complete date and time (use the first date found if any, then the first time found, if any. thus latter dates or times are gracefully ignored)<br />
# use the complete contents of the &lt;time&gt; element as its datetime value.<br />
<br />
Essentially, step 2 is added to enable composing nested child time elements.<br />
<br />
=== applicability to microdata ===<br />
All of the aforementioned advantages for microformats apply to microdata use of the &lt;time&gt; element as well. microformats are used in the above examples as that is the type of content (including the value class pattern) that is being published today (e.g. see http://microformats.org/wiki/events - the markup on that page itself).<br />
<br />
=== nested time example with datetime attribute ===<br />
If the publisher prefers to publish a "localized" form of dates (rather than the previous simple example with the most overall internationally human-friendly/readable YYYY-MM-DD ISODate), they can still do so:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>18:00</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The advantage here over the current time element is that the DRY violation is <em>limited</em> to only the date information (instead of date <em>and time</em> information), thus reducing the risk of data divergence due to duplication.<br />
<br />
=== nested time example with two datetimes ===<br />
If the publisher prefers to publish a "localized" form of times, they can do that as well:<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time datetime="18:00:00">6pm</time> on <br />
<time datetime="2010-08-05">August 5th, 2010</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: The two separate <code>datetime</code> attributes (containing just the time and just the date) are <em>more</em> human-readable than a single datetime attribute containing both, and thus there is a slightly better chance that the few humans that check would correctly determine whether the times and dates in the datetime attributes represent the same value as the content of the element.<br />
<br />
The AM/PM proposal below further helps improve this example.<br />
<br />
=== nested time discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - I'd really like to be able to more cleanly markup dates and times than the best we have been able to do so far with microformats (the aforementioned value-class-pattern), and HTML5 presents us with the potential to do so.<br />
* -1 [[User:Pigsonthewing|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.<br />
* +1 [[User:asbjornu|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time datetime="2005-10-05/2005-10-07"><br />
<time class="dtstart">October 5</time>-<br />
<time class="dtend">7</time><br />
</time>, at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div></nowiki></pre><br />
** Appreciate the support of the proposal. To clarify, the modified markup example provided won't work as microformats processors will look for "dtstart" information only inside that time element and its children, and find an English abbreviation, or just a number without context in the case of "dtend". This modification also moves the duplicate ISO8601 machine date data <em>farther</em> from the individual human readable components which increases the chance of drift (more distance between data duplicates = more drift between the duplicates over time). [[User:Tantek|Tantek]] 19:39, 11 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
== am pm and coarser time parsing ==<br />
Right now time values inside a &lt;time&gt; element are required to specify hours in 24 hour time. We want the time element to accept am/pm times as well.<br />
<br />
In short, instead of this (actual example derived from markup of blog post [http://adactio.com/journal/1632/ HTML5 watch by Jeremy Keith], with nested time elements per previous proposal)<br />
<br />
<pre><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time datetime="17:43:29">5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
We want to be able to do this:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<time class="published"><br />
<time datetime="2009-12-13">Sunday, December 13th, 2009</time> <br />
<time>5:43pm</time><br />
</time><br />
</nowiki></pre><br />
<br />
It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction.<br />
<br />
This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5.<br />
<br />
=== am pm syntax summary ===<br />
<br />
In our experience with the microformats value class pattern date and time values we've found it is relatively easy to both specify and implement (multiple implementations) parsing of (potentially coarser) am and pm values to permit a broader set of values to marked up directly (rather than with a separate datetime/title attribute).<br />
<br />
In short, the current &lt;time&gt; element only allows for the following time syntax:<br />
<br />
* HH:MM:SS - where HH is in 24 hour time.<br />
<br />
This proposal expands the allowed time syntax to:<br />
<br />
* HH:MM:SSam<br />
* HH:MM:SSpm<br />
* HH:MMam<br />
* HH:MMpm<br />
* HHam<br />
* HHpm<br />
<br />
=== am pm syntax details ===<br />
* '''periods, white-space, case-insensitivity.''' "am" and "pm" mean "am or a.m." and "pm or p.m." with optional leading ("6 pm") and intermittent ("6 p. m.") white-space; and are case-insensitive ("6 PM").<br />
* '''implied 00 minutes and seconds.''' When :SS or :MM:SS is omitted, infer :00 or :00:00, respectively.;<br />
* '''handling of 12am and 12pm.''' "12am" is treated as "00:00:00" (midnight at the start of the day). "12pm" is treated as "12:00:00" (noon).<br />
<br />
=== simple am pm example ===<br />
A simple example:<br />
<br />
<pre><nowiki><br />
I went to the cafe at <time>6pm</time>.<br />
</nowiki></pre><br />
<br />
Advantage: by specifying am and pm times that can be parsed directly from the contents of the <time> element, we reduce the need to violate DRY (can omit an explicit datetime attribute) in more cases, and thus encourage higher fidelity time data over time.<br />
<br />
=== am pm example with nested time elements ===<br />
Example (uses aforementioned composite nested time element proposal as well)<br />
<br />
<pre><nowiki><br />
<p class="vevent"><br />
<span class="summary">I went to the cafe</span> at <br />
<time class="dtstart"><br />
<time>6pm</time> on <br />
<time>2010-08-05</time><br />
</time>.<br />
</p><br />
</nowiki></pre><br />
<br />
Advantage: again, this reduces DRY violations, in this case further improving upon the composite nested time elements case.<br />
<br />
=== am pm discussion ===<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* +1 [[Tantek]] - in practice we in the microformats community have found that enabling users to markup am/pm times leads to many more cases where we can avoid violating DRY and thus encourage greater accuracy over time for such content. I think the HTML5 &lt;time&gt; element presents us with the opportunity to more cleanly markup times (than what we've been able to do with the aforementioned microformats value-class-pattern), and thus we should do so.<br />
* 0(query) [[User:Pigsonthewing|Andy Mabbett]] - see above for concerns over date formatting.<br />
** queries moved to am pm FAQ section with answers. - [[User:Tantek|Tantek]] 16:57, 6 August 2010 (UTC)<br />
* ...<br />
</div><br />
<br />
=== am pm FAQ ===<br />
==== noon and midnight ====<br />
'''Question:''' How does this cater for "noon" and "midnight", and the [http://en.wikipedia.org/wiki/12-hour_clock#Confusion_at_noon_and_midnight ambiguity] over "12am" and "12pm"?<br />
<br />
'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.<br />
<br />
==== am pm i18n ====<br />
'''Question:''' How does this internationalise "am" and "pm", for languages which do not use them? <br />
<br />
'''Answer:''' For languages that do not use "am" or "pm", the am pm proposal does not confer any additional advantage.<br />
<br />
= Minor editorial fixes =<br />
<br />
== Update hCalendar example ==<br />
<br />
Summary: please update the hCalendar example with the following fixes which make it consistent with hCalendar 1.0 with resolved issues.<br />
<br />
=== Current example ===<br />
<br />
The HTML5 spec currently has this hCalendar example:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>:<br />
<time class="dtstart" datetime="2007-10-05">October 5</time> -<br />
<time class="dtend" datetime="2007-10-20">19</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
<br />
(The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.)<br />
</nowiki></pre><br />
<br />
This appears to have been copy/pasted from a past version of the [http://microformats.org/wiki/hcalendar#Examples hCalendar spec] that was both mid-update (the dates are incorrect/inconsistent), and notes an issue which has since been resolved.<br />
<br />
=== Updated example ===<br />
<br />
Here is a suggested update:<br />
<br />
<pre style="background:#efe"><nowiki><br />
<div class="vevent"><br />
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<time class="dtstart" datetime="2005-10-05">October 5</time>-<br />
<time class="dtend" datetime="2005-10-07">7</time>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</div><br />
</nowiki></pre><br />
<br />
The parenthetical paragraph about end date inconsistency has been removed since hCalendar 1.0 has resolved that issue (see [http://microformats.org/wiki/dtend-issue dtend issue] for details).<br />
<br />
= Miscellaneous proposals =<br />
<br />
==Choose different default date==<br />
The statement that valueAsDate IDL attribute should return the value 1970-01-01 plus the appropriate time when the time element contains no date creates a problem that there are likely to be time elements that explicitly contain that date.<br />
<br />
A better choice would be a value that is highly unlikely to be encountered, and would be implausible as an actual date in most applications, perhaps 9999-12-31.<br />
<br />
<div class="discussion"><br />
Opinions / discussion:<br />
* 0 (comment) [[User:Pigsonthewing|Andy Mabbett]] - 9999-12-31 may well occur in real applications (projected comet sightings, say). Can we return either an invalid date (perhaps 9999-02-31) or an error code?<br />
* -1 [[User:Tantek|Tantek]] - I don't see any other default date as being significantly different.<br />
* ...<br />
</div><br />
<br />
= Issues without specific proposals =<br />
==Specification ambiguities==<br />
The specification requires that time be expressed as UTC (or another time zone with a specified offset from UTC). However, the representation of leap seconds is not specified. Further, the algorithms to convert between string and number are flawed, because the number is described as "number of milliseconds elapsed from midnight UTC on the morning of 1970-01-01" but the actual number of milliseconds includes all kinds of strange decisecond offsets during the period 1961-01-01 to 1972-01-01. Also, UTC did not exist before about 1960.<br />
<br />
Unix timekeeping has a long history of terrible definitions, and Unix notions of time should be totally rejected and expunged.<br />
<br />
<br />
= See Also =<br />
* [[input]] - the input element, related proposals expanding upon the new datetime inputs.<br />
<br />
= External links =<br />
<br />
== Tag ==<br />
Blog posts, Twitter updates etc. may be tagged HTML5time or #HTML5time <!-- links to follow --><br />
<br />
== Prior discussion ==<br />
<br />
* [http://pigsonthewing.org.uk/dates-and-coordinates-in-html5/ Dates and coordinates in HTML5] - blog post by [[User:Pigsonthewing|Andy Mabbett]]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-February/018639.html whatwg mailing list discussion of the above, Feb 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018685.html further whatwg mailing list discussion of the above, Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018759.html Another mailing list thread Mar 2009]<br />
** [http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-March/018888.html Spec editor's response to the above threads and further discussion, late Mar 2009]<br />
* [http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-November/024184.html 2009-11-26 Use cases for the time element] whatwg email by Jeremy Keith<br />
* [http://html5doctor.com/the-time-element/ HTML5 Doctor: The Time Element]<br />
<br />
== Resources ==<br />
<br />
* [http://www.loc.gov/standards/datetime/ Extended Date Time Format efforts] based at the USA's Library of Congress (Covers unspecific dates; date periods and non-Gregorian dates)<br />
** [http://www.loc.gov/standards/datetime/proposals.html EDTF proposals] (use-cases)<br />
* [http://www.w3.org/TR/NOTE-datetime W3C Date and Time Formats discussion note]<br />
** mailing list was datetime-comments@w3.org. - anyone have archives URL?<br />
* [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11 vCard Format Specification draft-ietf-vcarddav-vcardrev-11] (latest draft as at July 2010)<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-4.3 Section 4.3, date & time]<br />
** [http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-11#section-5.7 Section 5.7, CALSCALE] (specifies Gregorian or other (e.g. Julian) calendar)<br />
*** [http://www.ietf.org/mail-archive/web/vcarddav/current/msg01307.html VCARDDAV discussion of CALSCALE]<br />
* [http://www.tei-c.org/Guidelines/P4/html/ref-DATE.html TEI dates], widely used by archives and libraries to mark up texts, including non-Gregorian ISO8601 & uncertain/ approximate dates<br />
** [http://www.tei-c.org/Guidelines/P4/html/CO.html#CONADA TEI dates+times]<br />
* [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601 (Wikipedia article)]<br />
* [http://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar Proleptic Gregorian calendar (Wikipedia article)]<br />
* Dublin Core terms, e.g. <br />
**<code>dcterms:temporal</code> at http://dublincore.org/groups/collections/collection-application-profile/#coldctermstemporal<br />
*** [http://www.nmm.ac.uk/collections/feeds/docs/ example using dcterms:temporal]<br />
**<code>dcterms:created</code> http://dublincore.org/groups/collections/collection-application-profile/#coldctermsdcterms:created<br />
* [http://www.w3.org/TR/owl-time/ Time Ontology in OWL]<br />
** [http://www.semanticoverflow.com/questions/836/use-a-custom-datatype-or-a-property-for-approximate-dates Use a custom datatype or a property for approximate dates?] - discussion of the above.</div>Ocolonhttps://wiki.whatwg.org/index.php?title=User_talk:Nick&diff=5403User talk:Nick2010-08-21T19:03:48Z<p>Ocolon: notify Nick of a comment on one of his proposals</p>
<hr />
<div>== canonical-wwwnone ==<br />
<br />
I've commented on your proposal for a RelExtensions <code>canonical-wwwnone</code> at [[Talk:RelExtensions#canonical-wwwnone|Talk:RelExtensions]]. It would be great, if you could have a look at it. (Just writing here hoping this will trigger an e-mail notification so you come to know.) Thanks! -- [[User:Ocolon|Ocolon]] 19:03, 21 August 2010 (UTC)</div>Ocolonhttps://wiki.whatwg.org/index.php?title=Talk:RelExtensions&diff=5399Talk:RelExtensions2010-08-21T09:40:39Z<p>Ocolon: point at an error in the descriptions of canonical-wwwnone, propose dropping canonical-wwwnone in favor of the more powerful canonical-domain</p>
<hr />
<div>== Memorandum of understanding ==<br />
<br />
* http://wiki.whatwg.org/wiki/RelExtensions<br />
<br />
This Web page and associated Web services, if any, are provided with the understanding that providing them is cheap and relatively reliable, and that the URIs for these resources will not change after HTML5's completion, unless circumstances outside of the administrator's control force such a change.<br />
<br />
Organisations that believe these pages to be of vital importance are encouraged to put aside funds for the defence of this page should the need arise.<br />
<br />
--[[User:Hixie|Hixie]] 23:40, 10 December 2007 (UTC)<br />
<br />
== XFN noise ==<br />
<br />
Could XFN relations be separated? I'm under impression that they inflate the list.<br />
:I think that they should be removed, or moved to a microformat list where they would be named eg <code>xfn.friend</code>. I also want to emphasize that I dislike XFN as it implies to complex relation, that can be hard to resolve. For example "the maintaner of that document had that relation to the maintaner of the referenced document when the document was last edited/created" is not a good example of a relation. If we assume one knows the maintainer of the current document, how is one to know who the maintainer of the referenced document is? Someone could also be confused by the name of the relation and think that the current resource if a friend of the author…<br />
<br />
== Re: shortlink ==<br />
<br />
shortlink has also been proposed (on the blagosphere) as shorter and shorturl<br />
<br />
== On canonical-domain, canonical-wwwnone, and canonical-first ==<br />
<br />
Responding to your summary on the last reversion:<br />
<br />
Two were analogous services, as noted, not the exact services. The concepts were discussed by Google and were justified there.<br />
<br />
For canonical-wwwnone, for the concept underlying it, Google says this at the linked page under "Set your preferred domain":<br />
"Setting your preferred domain tells Google which version of your site's URL (http://www.example.com or http://example.com) you prefer.<br />
"If you set your preferred domain as http://example.com, we'll treat links to http://www.example.com exactly the same as links to your preferred domain."<br />
<br />
Since Google supports this by requiring the site owner to tell Google through a tool apparently not on the website owner's site, I proposed a method apropos to all search engines that wish to implement it.<br />
<br />
For canonical-domain, while the same Google page supports only intradomain canonicalization, it does support that (see under "Specify the canonical link for each version of the page"). I extended their concept to interdomain canonicalization, because many institutions have multiple domains for identical content or the same website. An owner of one website with multiple domains who wants to do well in search engine results would likely prefer that all external inbound links point to one domain but can't ask everyone else to edit their links without risking links being deleted and a lowering in search results, and just asking everyone is a bunch of work. My proposal reduces the workload and eliminates that risk while raising site credibility that helps with positioning in search engine results.<br />
<br />
Examples of domains that probably share sites (although I didn't drill down to check beyond the home pages and didn't have the plugin to view the home page/s on the first pair): <http://esbnyc.com/> and <http://empirestatebuilding.com/>, which might redirect, and <http://www.networksolutions.com/> and <netsol.com>, as I typed it, which redirects.<br />
<br />
While redirection is an easy solution, the site owner might prefer to display a message to users of one domain and not the other as part of educating the general public about the preferred domain (as used to be the case at yaho.com (one "o")). In that case, canonical-domain would inform search engines who wish to implement it while allowing the site owner to educate the part of the public that types the wrong name. For example, in New York City the agency that intervenes for abused children is still widely known by initials that have been abolished for 40 years (I heard it in conversation on the 15th of this month).<br />
<br />
However, I do see one defect with my proposal. Where a rel link works, a rev link can usually be expected to work, and rev for canonical-domain could be used to steal traffic from a competitor or other site. So I will add that rev must be meaningless.<br />
<br />
I will do the same for canonical-wwwnone, since I understand that it's possible, albeit unusual, to have separate websites for www and bare forms of the same domain, depending on the host's architecture, which means it's possible, albeit very unlikely, that the two websites could be under separate managers, and perhaps separate owners, who bitterly compete. So I will add that rev must be meaningless for that keyword, too.<br />
<br />
For canonical-first, I did not cite Google. Because it is possible to have a canonical set of pages and one noncanonical page in situations where the keywords alternate and print wouldn't be technically adequate or semantically apt, and the canonical set of pages might not fully occupy a directory, it might be more convenient to have canonical-first as shorthand. That's easier because only one page needs coding rather than two or more. Because it is shorthand, however, it is more dispensable, if people would like to reject it. I'm putting it back for the time being, i.e., for decision, since it seems to have been removed on the basis of the Google position, but I hadn't asserted that Google supported it. I will also add that rev must be meaningless for this keyword, too.<br />
<br />
Thank you.<br />
[[User:Nick|Nick]] 20:10, 20 September 2009 (UTC)<br />
<br />
== On footnote, note, and jump ==<br />
<br />
The footnote and jump both seem useful if a browser opens an additional window so that the main text or prejump text, respectively, remains visible, especially useful for endnotes after long texts. This is analogous to the behavior for sidebar [http://www.w3.org/TR/html5/history.html#link-type-sidebar (HTML5, working draft of 8-25-09, section 6.12.3.16)]. To that end, I'm renaming this proposed keyword ''note'', as a more generic name, and adding ''footnote'' and ''endnote'' to the description. I don't know what a sidenote is and, while I can guess, I don't recall it being used or mentioned in literature, a local central public librarian doesn't remember ever seeing one, my OOo 3.0.0 spellchecker rejects it, and a callout isn't a sidenote, although I suppose this link pointing to a callout would be okay. While I'm taking ''sidenote'' out of the synonymy, which is only for legacy support (I gather it wasn't a past rel keyword), I'm still adding it to the description, in case, to preserve the original proposer's intent.<br />
<br />
Thanks. [[User:Nick|Nick]] 00:33, 8 October 2009 (UTC)<br />
<br />
== canonical-wwwnone ==<br />
<br />
=== Error in the description ===<br />
<br />
Currently it says:<br />
<br />
<pre>The rel value is the form preferred for indexing, e.g., rel="http://example.net".</pre><br />
<br />
I am pretty sure this should be:<br />
<br />
<pre>The href value is the form preferred for indexing, e.g., href="http://example.net".</pre> [[User:Ocolon|Ocolon]] 09:40, 21 August 2010 (UTC)<br />
<br />
=== Redundancy ===<br />
<br />
[[User:Nick|Nick]], my impression is that your proposal <code>canonical-domain</code> already covers everything your proposal <code>canonical-wwwnone</code> achieves. Wouldn't it be better to concentrate on the more powerful <code>canonical-domain</code> and drop <code>canonical-wwwnone</code>? [[User:Ocolon|Ocolon]] 09:40, 21 August 2010 (UTC)</div>Ocolonhttps://wiki.whatwg.org/index.php?title=RelExtensions&diff=5394RelExtensions2010-08-20T16:55:17Z<p>Ocolon: added the proposal "latest-version"</p>
<hr />
<div>This page lists the allowed extension values for the rel="" attribute in HTML5. You may add your own values to this list, which makes them legal HTML5 rel values. We ask that you try to avoid redundancy; if someone has already defined a value that does roughly what you want, please reuse it. Note that rel tokens are ASCII-lowercase before comparison against canonical value, so the canonical values should be listed without uppercase ASCII letters.<br />
<br />
{| class=wikitable<br />
|-<br />
! rowspan=2 | Keyword<br />
! colspan=2 | Effect on...<br />
! rowspan=2 | Brief description<br />
! rowspan=2 | Link to more details<br />
! rowspan=2 | Synonyms<br />
! rowspan=2 | Status<br />
|- <br />
! link<br />
! a and area<br />
|-<br />
| accessibility<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains accessibility information for the linking document.<br />
| [http://www.brucelawson.co.uk/2009/rel-accessibility/ Bruce Lawson]<br />
| <br />
| Proposal<br />
|-<br />
| acquaintance<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be an acquaintance<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| ajax<br />
| not allowed<br />
| hyperlink<br />
| The link is controlled through javascript, and will load the page linked to though an ajax interface. Without javascript, it should behave as a normal "a" tag, and content change is done server side.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| alternate<br />
|colspan=6| See HTML5<br />
|-<br />
| archives<br />
|colspan=6| See HTML5<br />
|-<br />
| author<br />
|colspan=6| See HTML5<br />
|-<br />
| bookmark<br />
|colspan=6| See HTML5<br />
|-<br />
| canonical<br />
| hyperlink<br />
| not allowed<br />
| Robots (e.g., search engines) should treat the document containing the tag as a minor variation of the linked document, which may result in the removal of the former from a web index and in the consolidation of its quality signals in the latter.<br />
| [http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-domain<br />
| external resource<br />
| not allowed<br />
| More than one domain may have largely similar or identical content but only one of the domains should be indexed for search engines. E.g., a company may have short and long domain names for the same content.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-first<br />
| external resource<br />
| hyperlink<br />
| Where the canonical value should point to a group of pages, but the link can point to only one page, the group of pages can be clarified by choosing the first page in the group and assigning the URL for this rel link.<br />
For security against traffic theft, rev must be meaningless.<br /><br />
This is only shorthand for providing two link elements, one on the noncanonical page to a "canonical" page and the other on the canonical page to the "first" page of the group.<br />
Where the group of pages corresponds to a subdirectory and a canonical URL value can point to the subdirectory resulting in a user arriving at the subdirectory's index page which is part of the group, this shorthand is unnecessary and one rel="canonical" will suffice.<br />
| [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-human<br />
| external resource<br />
| hyperlink<br />
| Pages about a person across many websites can be associated based on name, nationality, birthplace, dates of birth and death, when flourished, and other identifiers.<br />
Search engines could more consistently aggregate same-person pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7681 W3C Bug 7681]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-organization<br />
| external resource<br />
| hyperlink<br />
| Pages about an organization across many websites can be associated based on name, headquarters site, and other identifiers.<br />
Search engines could more consistently aggregate same-organization pages with less confusion due to name similarity.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7682 W3C Bug 7682]<br />
| <br />
| Proposal<br />
|-<br />
| canonical-wwwnone<br />
| external resource<br />
| hyperlink<br />
| Both bare and www-prefixed domain names usually direct to the same site. Especially when external links to a site vary in the form used, search engine indexing concentrated on only one domain form may raise its credibility. The rel value is the form preferred for indexing, e.g., rel="http://example.net". Nothing to the right of the top-level domain is needed.<br />
For security against traffic theft, rev must be meaningless.<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=139066 Google's analogous service] and [[Talk:RelExtensions#On_canonical-domain.2C_canonical-wwwnone.2C_and_canonical-first|Talk for this page]]<br />
| <br />
| Proposal<br />
|-<br />
| chapter<br />
| hyperlink<br />
| hyperlink<br />
| Target document is a subdocument of the current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| section, subsection, appendix<br />
| Proposal<br />
|-<br />
| child<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a child of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-resident<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives in the same residence as the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| co-worker<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a co-worker of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| colleague<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a colleague of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contact<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a contact<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| contributor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) involved in the production of the content, but not his main author(s).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| crush<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a crush (i.e. has a crush on the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| date<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be a date (i.e. is dating the referenced person)<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| details<br />
| hyperlink<br />
| hyperlink<br />
| The referenced document contains additional (or complete) details about the current document (for example, a "read more..." hyperlink on a blog page that leads to the full posting).<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| dns-prefetch<br />
| external resource<br />
| not allowed<br />
| Force the DNS lookup of specific hostnames.<br />
| [https://developer.mozilla.org/En/Controlling_DNS_prefetching Mozilla DNS Prefetching], <br />[http://dev.chromium.org/developers/design-documents/dns-prefetching Chromium DNS Prefetching]<br />
| <br />
| Proposal<br />
|-<br />
| edit<br />
| hyperlink<br />
| hyperlink<br />
| Target document is an editable version of the current document.<br />
| [http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-11.html#new-link-relation Atom Protocol]<br />
| <br />
| Proposal<br />
|-<br />
| edituri<br />
| hyperlink<br />
| not allowed<br />
| a link to an RSD file describing how to edit the given page.<br />
| [http://cyber.law.harvard.edu/blogs/gems/tech/rsd.htm rsd]<br />
| <br />
| Proposal<br />
|-<br />
| enclosure<br />
| hyperlink<br />
| hyperlink<br />
| the destination of the hyperlink is intended to be downloaded and cached.<br />
| [http://microformats.org/wiki/rel-enclosure rel-enclosure]<br />
| <br />
| Proposal<br />
|-<br />
| enlarged<br />
| not allowed<br />
| hyperlink<br />
| For anchors that have one child image element, indicates that the linked document is an image file which is the same as the child image element of the link except a larger size (dimensions).<br />
| [http://dvdgoss.wordpress.com/2010/04/26/the-case-for-relenlarge-in-html5/ David Goss]<br />
| <br />
| Proposal<br />
|-<br />
| external<br />
|colspan=6| See HTML5<br />
|-<br />
| extension<br />
| hyperlink<br />
| hyperlink<br />
| Browser extension<br />
| [http://mozillalabs.com/jetpack/2010/05/12/indexing-and-auto-detecting-browser-extensions-on-the-web/ Mozilla Labs]<br />
| <br />
| Proposal<br />
|-<br />
| first<br />
|colspan=6| See HTML5<br />
|-<br />
| friend<br />
| hyperlink<br />
| hyperlink<br />
| the person represented by the current document considers the person represented by the referenced document to be a friend<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| glossary<br />
| hyperlink<br />
| hyperlink<br />
| Target document provides definitions for words in current document.<br />
| [http://www.w3.org/TR/html4/types.html#h-6.12 HTML4]<br />
| <br />
| Proposal<br />
|-<br />
| help<br />
|colspan=6| See HTML5<br />
|-<br />
| hub<br />
| hyperlink<br />
| not allowed<br />
| Indicates a URL which implements both sides of the PubSubHubbub protocol.<br />
| [http://code.google.com/p/pubsubhubbub/ PubSubHubbub]<br />
| <br />
| Proposal<br />
|-<br />
| i18nrules<br />
| hyperlink<br />
| not allowed<br />
| Target document provides ITS (Internationalization tag Set) rules for processing the current document.<br />
| [http://www.w3.org/TR/its/ ITS]<br />
| <br />
| Proposal<br />
|-<br />
| icon<br />
|colspan=6| See HTML5<br />
|-<br />
| index<br />
|colspan=6| See HTML5<br />
|-<br />
| jump<br />
| not allowed<br />
| hyperlink<br />
| Indicates a same page jump from the current fragment to another fragment. (E.g. sometimes online newspapers insert direct text saying "article continues below the image/advert" - they could instead use "jump" link. Ultimately, it indicates a page internal link.)<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| kin<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is part of the extended family of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| lang-alt-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in an alternative language. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| lang-orig-[ISO 639-1 code]<br />
| hyperlink<br />
| hyperlink<br />
| The linked document contains a version of the current document in the language the document was originally written in. "[ISO 639-1 code]" is replaced with the appropriate [http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes ISO 639-1 language code]. The ISO 639-1 code is used when the browser (or other user agent) wants to display either the full name of the language or a flag, as a visual aid for the end user.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| last<br />
|colspan=6| See HTML5<br />
|-<br />
| latest-version<br />
| hyperlink<br />
| hyperlink<br />
| The referenced document is the latest version of the current document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.txt], [http://tools.ietf.org/search/rfc5829#section-3.2 RFC5829]<br />
| <br />
| Proposal<br />
|-<br />
| license<br />
|colspan=6| See HTML5<br />
|-<br />
| logout<br />
| external resource<br />
| not allowed<br />
| The linked document provides a resource for the UA to request when all currently open documents of the same "group" are closed (to facilitate logging out the current user).<br />
| [[LogoutRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| me<br />
| hyperlink<br />
| hyperlink<br />
| the referenced document represents the same person as does the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| met<br />
| hyperlink<br />
| hyperlink<br />
| this person has met the referenced person<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| muse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person inspires the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| neighbor<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person lives nearby the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| next<br />
|colspan=6| See HTML5<br />
|-<br />
| next-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately following archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| nofollow<br />
|colspan=6| See HTML5<br />
|-<br />
| noreferrer<br />
|colspan=6| See HTML5<br />
|-<br />
| noprefetch<br />
| external resource<br />
| hyperlink<br />
| Denies prefetching (not fetching) as a cost-control option for website owners, especially where pages are dynamic, leading to prefetching of wrong and useless pages.<br /><br />
The link provides a per-page denial whereas a and area provide a per-element denial.<br /><br />
For link, attributes rel="noprefetch" denies prefetching of the page at the href URL and rev="noprefetch" denies prefetching of the page bearing the link.<br /><br />
For a and area, rel is as above and rev is meaningless.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7918 W3C Bug 7918]<br />
| <br />
| Proposal<br />
|-<br />
| note<br />
| not allowed<br />
| hyperlink<br />
| An in-page or out-page jump to a footnote. This encompasses ''note'', ''footnote'', ''endnote'', and ''sidenote''.<br />
| [[Talk:RelExtensions#On_footnote.2C_note.2C_and_jump|Talk]]<br />
| <br />
| Proposal<br />
|-<br />
| openid.delegate<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid.server<br />
| external resource<br />
| not allowed<br />
| OpenID 1.1 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-1_1.html#delegating_authentication OpenID specification]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.local_id<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication delegation<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| openid2.provider<br />
| external resource<br />
| not allowed<br />
| OpenID 2.0 authentication endpoint<br />
| [http://openid.net/specs/openid-authentication-2_0.html#html_disco OpenID Auth 2.0 section 7.3.3]<br />
| <br />
| Proposal<br />
|-<br />
| parent<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a parent of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| payment<br />
| hyperlink<br />
| hyperlink<br />
| A URI where payment is accepted.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations]<br />
| <br />
| Proposal<br />
|-<br />
| pgpkey<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the PGP public key file (which may contain multiple keys) of the author(s) of the page.<br />
| [http://purl.org/net/pgpkey/], [http://golem.ph.utexas.edu/~distler/blog/archives/000320.html]<br />
| <br />
| Proposal<br />
|-<br />
| pingback<br />
|colspan=6| See HTML5<br />
|-<br />
| prefetch<br />
|colspan=6| See HTML5<br />
|-<br />
| prev<br />
|colspan=6| See HTML5<br />
|-<br />
| prev-archive<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to the immediately preceding archive document.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc5005 RFC5005]<br />
| <br />
| Proposal<br />
|-<br />
| print<br />
| external resource<br />
| hyperlink<br />
| The referenced document is recommended for printing, even though the referent document is capable of being printed and both documents are of the same type, medium, and language. A typical case is where content spread over multiple pages is also available on a single page that is more convenient to print.<br />
This is semantically more specific than "canonical" and "alternate". Where type, medium, and/or language differ, consider "alternate"; where any of them differ but the purpose is printing, consider applying both values.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=7645 W3C Bug 7645]<br />
| <br />
| Proposal<br />
|-<br />
| profile<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link is a metadata profile for the current document<br />
| [http://www.w3.org/TR/html401/struct/global.html#profiles HTML Meta data profiles], <br />[http://www.w3.org/2003/g/glean-profile Example of profile in a-elements]<br />
| <br />
| Proposal<br />
|-<br />
| related<br />
| hyperlink<br />
| hyperlink<br />
| this referenced link identifies a resource related to the current document<br />
| [http://tools.ietf.org/html/rfc4287#section-4.2.7 Atom Syndication Format]<br />
| <br />
| Proposal<br />
|-<br />
| resource-package<br />
| external resource<br />
| not allowed<br />
| The linked document is a zipped resource package<br />
| [http://limi.net/articles/resource-packages/ Resource Packages]<br />
| <br />
| Proposal<br />
|-<br />
| reviewer<br />
| hyperlink<br />
| not allowed<br />
| The linked document is the page/email an agent (people or firm or...) responsible for reviewing the content.<br />
| [http://wiki.csswg.org/test/css2.1/format#reviewer]<br />
| <br />
| Proposal<br />
|-<br />
| script<br />
| not allowed<br />
| not allowed<br />
| Was proposed to replace &lt;script>. Use &lt;script> instead.<br />
| none<br />
| <br />
| Rejected<br />
|-<br />
| search<br />
|colspan=6| See HTML5<br />
|-<br />
| self<br />
| hyperlink<br />
| hyperlink<br />
| A URI that refers to a resource equivalent to the containing element.<br />
| [http://www.iana.org/assignments/link-relations/link-relations.xhtml Atom Link Relations], <br />[http://tools.ietf.org/html/rfc4287 RFC4287]<br />
| <br />
| Proposal<br />
|-<br />
| service<br />
| external resource<br />
| not allowed<br />
| Points to a resource describing a service API<br />
| [[ServiceRelExtension]]<br />
| <br />
| Proposal<br />
|-<br />
| shortlink<br />
| hyperlink<br />
| hyperlink<br />
| Identifies a shorter form of the URL for the current document, provided by the document owner.<br />
| [http://code.google.com/p/shortlink/wiki/Specification shortlink Specification]<br />
| <br />
| Proposal<br />
|-<br />
| sibling<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a sibling of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| sidebar<br />
|colspan=6| See HTML5<br />
|-<br />
| spouse<br />
| hyperlink<br />
| hyperlink<br />
| the referenced person is a spouse of the person represented by the current document<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| statechart<br />
| external resource<br />
| not allowed<br />
| A reference to an SCXML document that controls the application-flow of the current HTML document<br />
| [http://www.w3.org/TR/scxml/ SCXML]<br />
|<br />
| Proposal<br />
|-<br />
| stylesheet<br />
|colspan=6| See HTML5<br />
|-<br />
| sweetheart<br />
| hyperlink<br />
| hyperlink<br />
| this person considers the referenced person to be their sweetheart<br />
| [http://gmpg.org/xfn/11 XFN]<br />
| <br />
| Accepted<br />
|-<br />
| tag<br />
|colspan=6| See HTML5<br />
|-<br />
| technicalauthor<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the technical construction of the page (i.e. the HTML/CSS/PHP code), not for the content.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| timesheet<br />
| external resource<br />
| not allowed<br />
| SMIL Timesheet<br />
| [http://www.w3.org/TR/timesheets/#smilTimesheetsNS-Elements-Timesheet SMIL Timesheets 1.0]<br />
| <br />
| Proposal<br />
|-<br />
| translatedfrom<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email that has been translation source for the current document. It also indicates that the current document is a translation and not an original work.<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| translator<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) responsible for the translation of the page. It also indicates that the current page is a translation of an other document, which should be linked through a rel="translatedfrom".<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| up<br />
|colspan=6| See HTML5<br />
|-<br />
| us<br />
| hyperlink<br />
| hyperlink<br />
| The referenced document represents the same organisation as does the current document [cf rel-me]<br />
| <br />
| <br />
| Proposal<br />
|-<br />
| webmaster<br />
| hyperlink<br />
| hyperlink<br />
| The linked document is the page/email an agent (people or firm or...) available for requests about the content of the page.<br />
| <br />
| maintainer<br />
| Proposal<br />
|-<br />
| widget<br />
| hyperlink<br />
| hyperlink<br />
| Points to a widget.<br />
| [http://dev.w3.org/2006/waf/widgets/Overview.html#autodiscovery Widgets 1.0 Editor's draft]<br />
| <br />
| Proposal<br />
|-<br />
| wlwmanifest<br />
| hyperlink<br />
| not allowed<br />
| A link to a manifest for Windows Live Writer.<br />
| [http://msdn.microsoft.com/en-us/library/bb463263.aspx msdn]<br />
| <br />
| Proposal<br />
|}<br />
<br />
The "Effect on... link" column must either say "not allowed" if the rel value is not allowed on &lt;link> elements, "hyperlink" if the rel value creates a hyperlink, or "external resource" if the rel value creates a link to an external resource.<br />
<br />
The "Effect on... a and area" column must either say "not allowed" or "hyperlink".<br />
<br />
For the "Status" section to be changed to "Accepted", the proposed keyword must either have been through the [http://microformats.org/wiki/process Microformats process], and been approved by the Microformats community; or must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Rejected".<br />
<br />
For more details, see [http://whatwg.org/specs/web-apps/current-work/#linkTypes the HTML5 specification]. See also [http://microformats.org/wiki/existing-rel-values the Microformats wiki page on this matter].</div>Ocolonhttps://wiki.whatwg.org/index.php?title=MetaExtensions&diff=5393MetaExtensions2010-08-20T10:40:20Z<p>Ocolon: removed incorrectly used lang-attributes used in the markup of this page</p>
<hr />
<div>This page lists the allowed extension values for the name="" attribute of the &lt;meta> element in HTML5. You may add your own values to this list, which makes them legal HTML5 metadata names. We ask that you try to avoid redundancy; if someone has already defined a name that does roughly what you want, please reuse it.<br />
<br />
== Registered Extensions ==<br />
<br />
None so far. The spec defines five: [http://whatwg.org/specs/web-apps/current-work/#meta-application-name application-name], [http://dev.w3.org/html5/spec/Overview.html#meta-author author], [http://whatwg.org/specs/web-apps/current-work/#meta-description description], [http://whatwg.org/specs/web-apps/current-work/#meta-generator generator], and [http://dev.w3.org/html5/spec/Overview.html#meta-keywords keywords].<br />
<br />
== Proposals ==<br />
<br />
{|border=1 cellpadding=4 cellspacing=0<br />
! Keyword<br />
! Brief description<br />
! Link to more details<br />
! Synonyms<br />
! Status<br />
<br />
|-valign="top" <br />
| resolutions<br />
| Authoring web sites to use resolution independent images that display beautifully on high-resolution displays should be made as easy as possible for developers and should not require JavaScript to accomplish.<br />
<br />
To accomplish this, I propose a new HTML Meta Tag, <code>resolutions</code>, that can be used to specify that high-resolution versions of images linked to from the page are available and that the browser should use them in place of the lower-resolution default images if it detects that a user is using a high-resolution screen. The resolutions meta tag lists the device-pixel ratios supported by images in the page. <br />
<br />
So, for example…<br />
<br />
<code><pre><meta name="resolutions" content="2x"></pre></code><br />
<br />
… means that the developer is telling the browser that she has created 2x resolution images for the images linked to from the current page and named them with a @2x suffix. <br />
<br />
To illustrate, if her image tag is as follows…<br />
<br />
<code><pre><img src="/images/flower.jpg" alt="A flower"></pre></code><br />
<br />
… then she has two image files under /images: the low-resolution default (flower.jpg), and a higher-resolution (200%) version named flower@2x.jpg. <br />
<br />
(This is the same naming convention already used by Apple in its Cocoa Touch framework for automatically loading in higher-resolution versions of images.)<br />
<br />
Based on the meta tag, if the browser detects that the user is running at a <code>min-device-pixel-ratio</code> of 2.0, it will automatically ask for the 2x version of the image (flower@2x.jpg) instead of the default image as specified in the image tag. <br />
<br />
Finally, so as not to flood external sites with high-resolution image requests, this functionality would only work for local images specified via relative links.<br />
<br />
<h2>Multiple resolutions</h2><br />
<br />
The resolutions tag can also contain a list of supported device-pixel ratios so as to support even higher-resolution displays when and if they become available in the future. <br />
<br />
For example:<br />
<br />
<code><pre><meta name="resolutions" content="2x, 4x, 8x"></pre></code><br />
<br />
In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flower@2x.jpg, flower@4x.jpg, and flower@8x.jpg.<br />
<br />
<h2>Advantages</h2><br />
<br />
The advantages of this approach are several:<br />
<br />
<ol><br />
<li>Makes it very simple for developers to support high-resolution displays like the iPhone 4's Retina screen</li><br />
<li>Does not require JavaScript</li><br />
<li>Does not change the default way that things work (if the meta tag is not specified, the browser simply behaves as it always has).</li><br />
</ol><br />
<br />
| [http://aralbalkan.com/3355 Proposal for native browser support of high-resolution image substitution]<br />
[http://aralbalkan.com/3331 How to make your web content look stunning on the iPhone 4’s new Retina display]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| keywords-not<br />
| A comma-separated list of negative keywords that distinguish a closely-related theme from this page's true theme, to support Boolean NOT searches often more realistically than visible text can, especially when both themes share the same lexicon.<br />If keywords is no longer a supported name for a meta element, keywords-not is superfluous; however, debate has been revived on whether keywords should be supported or not; see the keywords entry in this Wiki.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6609 W3C Bug 6609]<br />
|<br />
| Proposal<br />
|-valign="top" <br />
| robots<br />
| A comma-separated list of operators explaining how search engine crawlers should treat the content. Possible values are "noarchive" to prevent cached versions, "noindex" to prevent indexing, and "nofollow" works as the link rel value with the same name. This meta name is already supported by every popular search engine.<br />The content value "NOODP" has been offered elsewhere, so I'm proposing it here. It blocks robots from using [http://www.dmoz.org Open Directory Project] descriptions of a website instead of Web pages' own meta descriptions. It may have been introduced by Microsoft.<br />The content value "NOYDIR" has been offered by Yahoo, so I'm proposing it here. It blocks Yahoo's robot from using the Yahoo directory's descriptions of a website instead of Web pages' own meta descriptions. Whether any other robot supports this is unknown but possibly no other search engine uses Yahoo's directory anyway.<br />
| [http://www.robotstxt.org/wc/exclusion.html#meta Robots exclusion protocol], [http://www.google.com/support/webmasters/bin/answer.py?answer=61050 Googlebot], [http://help.yahoo.com/help/us/ysearch/slurp/index.html Yahoo&#33; Slurp], and [http://about.ask.com/en/docs/about/webmasters.shtml Ask.com Teoma];<br />NOODP value: [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35264 Google], [http://help.yahoo.com/l/us/yahoo/search/indexing/indexing-11.html Yahoo], & [http://help.live.com/help.aspx?mkt=en-us&project=wl_webmasters#faq38 Microsoft (click "How does Live Search generate a description of my website?")], all as accessed 4-28-09;<br />NOYDIR value: [http://ysearchblog.com/2007/02/28/yahoo-search-support-for-noydir-meta-tags-and-weather-update/ Yahoo], as accessed 4-28-09<br />
| <br />
| Proposal<br />
|-valign="top" <br />
| page-datetime<br />
| Better ranking in search engine results for recency or relevance to an event date would be aided by a standard format robots can parse. Users would save search time by not having to load many pages to find which ones are new or date-relevant.<br />To supply a consistent and known format, the value for this keyword is a date-time expression formed in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />
| <br />
| <br />
| Proposal<br />
|-valign="top" <br />
| page-version<br />
| Pages may be revised several times daily. While date-time given to a granularity of a fraction of a second would often suffice, when a page has to be approved more than once before posting, any or no such time may be correct (without this keyword, a comment could be necessary but probably not parsable by an engine). In addition, versions regardless of date may show consecutiveness and can replace a date that must be vague. In that case, a version number may be more useful for searches and so a robot-parsable format is needed.<br />The keyword's value is stated in ASCII digits, is any nonnegative base-10 rational number expressed as an integer or a decimal, with any number of decimal places allowed, and may be padded with any number of leading zeros to support extraction for ASCII sorting.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />The versions 0 and 0.''n'', with ''n'' being to any number of places, signify beta versions, i.e., drafts, in the tradition of beta software, while versions 1 and higher ordinarily signify final-release versions. After a final-release version is released, a draft of a later version is not given a version number of 0 or 0.''n'', but is numbered higher than the last final-release version. It is suggested to page authors that draft status, if applicable, be shown in the visibly displayed text of the page, rather than that this meta tag be relied upon as the sole notice of draft status, as it may be inadequate notice if alone.<br />To assign a low page-version such as 0.''n'' or 1, the page's URL, if static, may be used as the relevant premise. Thus, if a page is copied or moved to a new URL, the author may choose to restart page-version numbering from 0.''n'' or 1. If a page's URL is dynamic, e.g., if created on the fly from a script, the page author may prefer to use as the relevant premise for assigning a low page-version such as 0.''n'' or 1 the URL of the script or other technology that generates the dynamic-URL page, placing this meta element containing this attribute within the script or other technology, not within the generating page's head element (the generating page's head element may have its own meta element with this attribute describing the generating page). If one page containing the script or other technology that generates another page has more than one means for generating dynamic-URL pages, each means should contain its own meta element with this attribute. Page-version is thus largely independent of the page's date, although both would likely advance roughly in parallel.<br />
| <br />
| <br />
| Proposal<br />
|-valign="top" <br />
| subj-. . .<br />
| To classify by subject a page's content, a standard subject taxonomy that will be recognized by a search engine or directory will help. Because many such high-quality taxonomies exist, only a prefix is proposed. Over time, particular taxonomies, in print or online, may be recognized here and keywords assigned for each.<br />The keyword will be constructed case-insensitively with subkeywords in the form subj-[nationAbbrev]-[taxonomy]-[edition][-optionalSubedition], e.g., subj-US-MeSH-2009online (perhaps). After "subj-", the second subkeyword will identify the nation where the taxonomy is published or offered as an aid in identifying the taxonomy and does not limit the subject coverage; e.g., a taxonomy published in Japan may be ideal for classifying Canadian botany or Peruvian economy.<br />As subject values may vary between editions of one taxonomy, an edition and optionally a subedition is to be identified in the third and optionally the fourth subkeywords. The subedition, if any, is any update or revision occurring between editions, such that a value drawn from that edition and subedition is stable. The means of identifying edition and subedition should be included in the registration of a keyword.<br />Examples of taxonomies from the U.S. include MeSH (medical) and the Library of Congress Subject Headings.<br />The value identifying a subject for a Web page will be drawn from the cited taxonomy's edition and subedition.<br />If the value should have a style to prevent ambiguity in interpretation, that style is to be registered here for that keyword. Multiple values are expressed with multiple meta elements, one value for each, since comma-separation is probably not compatible with all taxonomies.<br />If a value requires case-sensitivity to prevent confusion, the entry here registering the keyword must accommodate that need with the needs of HTML 5 with an appropriate rule. To that end, a proposal to allow case-sensitivity in meta tags under some circumstances has been offered in the W3C bug reporting system.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6854 W3C Bug 6854]<br />
| subject-. . .<br />
| Proposal<br />
|-valign="top" <br />
| geographic-coverage<br />
| The author may be the best expert on the geographic relevance of the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers and epidemiological studies which may mention locales only once.<br />Absence of the keyword defaults to a value of world (not universe), unless the search engine chooses to interpret the page or larger unit for some other value, probably based on other than just contact information given in the website.<br />The value for this keyword is a semicolon-separated list of one or more place-values, the order of which do not matter. One place-value will use commas to separate, in order, an optional standard natural language symbol applicable to the place-value (when omitted the language applicable to the page will control), a place-class, one or more place-subclasses if any, and one or more place name parts (where, e.g., in "Cape Town, South Africa", "Cape Town" is a place name part but "Town" is not). Spaces after semicolons and commas are optional; spaces within place-values are present when required for each place-value (e.g., "Quezon City", not an invented "QuezonCity").<br />To distinguish names that might otherwise be too similar, place-classes, all lower-case and hyphenatably spaceless, include ''outer-space'', ''region'' (on Earth and crossing or larger than a nation, e.g., southern hemisphere, polar region, temperate zone, or Asia), ''intntl-water'' (an 'international water body'), ''intntl-agcy'' ('international agency' or 'international collection', e.g., all U.N. member nations), ''nation'', ''within-nation'' (limited to only one political level down from nation, e.g., state, province, territory, possession, city not included within other political units of a nation, or any comparable unit), ''city'' (including town, village, hamlet, and any comparable political unit below the level of ''within-nation''), ''addr'' (including address, full-length street, building, institution, and neighborhood without political boundaries), ''pol-unit'' (''pol'' abbreviating 'political') (e.g., a place of disputed nationhood), ''hist-pol-unit'' (''hist'' abbreviating 'historical') (e.g., the Roman Empire), ''feature'' (e.g., river), ''num'' (e.g., latitude and longitude or outer-space equivalent in numbers), and ''ethereal'' (including thealogical/theological, fictional including from modern popular entertainment, and ancient secular mythical, but not including that which is asserted to be a state of mind or existence but not a place, such as nirvana). (Example for one hypothetical page: name="geographic-coverage" content="region, sub-Saharan Africa; nation, Panama; city, Panama, Panama; within-nation, Sao Paulo, Brazil; city, Sao Paulo, Sao Paulo, Brazil; within-nation, Mississippi, United States of America; region, Middle East; region, Midwest, United States of America; hist-pol-unit, Northwest Territory, United States of America; feature, river, Indus; outer-space, Indus; ethereal, ultima Thule; ethereal, Heaven; ethereal, Flatland; ethereal, Valhalla; en-US, addr, Hotel Valhalla, Fredrikstad, Norway; es, nation, Espana" (Indus is both a river and a constellation, illustrating the need for place-classes)).<br />Ambiguity of place-values should be avoided despite convenience in coding because search engines may each interpret them as they see fit, e.g., it would be hard for an engine to distinguish New York from New York.<br />For consistency of spelling, several authority lists should be settled upon, with legal, well-known, and disputed names and common abbreviations all being acceptable; but I'm not proposing one here now (relying on IANA's ccTLD list might be too complex to implement and still assure coding consistency, e.g., occasionally ccTLDs can be phased out and off of IANA's list) (a standard vocabulary possibly usable here is the [http://www.getty.edu/research/conducting_research/vocabularies/tgn/index.html Getty Thesaurus of Geographic Names Online], subject to licensing and charset choice); and promulgating authority lists may best be done publicly by search engine managements, who may disagree with each other.<br />Allowing Unicode for non-Roman alphabet-using locales is desirable, but at present that may raise technical problems, including computer security issues, that are not yet readily soluble.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage<br />
| The author may be the best expert on which time frame is most relevant to the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers that may focus on the 1800s but mention 1731 and 1912 perhaps unimportantly.<br />The value for this keyword is a date or time -- not a range and not vague, for which other keywords are proposed -- in a format in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, all the values so appearing are determinative. Multiple values are to be expressed with separate meta elements lest the note be revised in the future in a way incompatible with comma-separating a list.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage-start<br />
| This is identical to the keyword datetime-coverage except that it represents only the start. If this keyword is used without datetime-coverage-end (also proposed), its value is interpreted as starting a range without an end.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the start of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-start=1862, datetime-coverage-start=1914, datetime-coverage-end=1865, and datetime-coverage-end=1918, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage-end<br />
| This is identical to the keyword datetime-coverage except that it represents only the end. If this keyword is used without datetime-coverage-start (also proposed), its value is interpreted as ending a range without a start.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the end of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-end=1865, datetime-coverage-start=1914, datetime-coverage-end=1918, and datetime-coverage-start=1862, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage-vague<br />
| This is identical to the keyword datetime-coverage except that its value is not necessarily crisp. This keyword should be used only when datetime-coverage, datetime-coverage-start, and datetime-coverage-end are inappropriate, but there's no ban on using all four. Any text without a comma can be the value (e.g., Pleistocene, 1820s, Tuesdays, or before we were born); multiple values are comma-separated.<br />If this keyword is used with datetime-coverage, datetime-coverage-start, or datetime-coverage-end, the vague value should be exploited along with the value/s for the other keyword/s.<br />Should this keyword appear more than once, all are determinative.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| audience<br />
| To aid search engines in classifying and to aid directory compilers, an audience most appropriate for the page may be suggested. Subject matter may not be a good clue; for example, an analysis of children's literature may be directed to teachers.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated. Singular and plural forms have the same meaning.<br />Recognized values:<br />-- "all" and "everyone", which have the same meaning<br />-- "adult" and "mature" have the same meaning and are for content that only adults may access, but no one responsible for preventing a nonadult or the immature from accessing the page or its content should rely on either or both of these values to do so without other means (not the same as "grownup", which see)<br />-- "child" and "juvenile", which have the same meaning<br />-- "teen"<br />-- "grownup" is not identical to "adult" or "mature" in not implying a precise boundary but is approximately any person who may be able to understand and apply the content (e.g., car driving instruction that may be read by a minor not yet old enough to drive a car but who would likely benefit from somewhat early exposure to the instruction)<br />-- "parent" to include guardian and temporary caregiver<br />-- "teacher" to include professor and ad hoc instructor<br />-- "elementary school student" to include any student below high school<br />-- "high school student"<br />-- "elhi" to include any student in elementary school through high school<br />-- "college student" including graduate and professional school<br />-- "business" including management, finance, and prospective customers (this includes e-commerce and investor sites)<br />-- "health" including any health care provider including alternative and ad hoc<br />-- "patient" for any health care recipient<br />-- "lawyer" including judge, paralegal, and jailhouse lawyer<br />-- "law client" for any prospective recipient of a lawyer's service (not usually a social work client) with ''lawyer'' including paralegal and jailhouse lawyer but not necessarily judge<br />-- "craft" for any craftworker including laborer and artisan<br />-- "artist" including musician, actor, dancer, and sculptor and including creator and performer<br />-- "military" including paramilitary<br />-- "news" including any consumer of rapidly-developing news<br />-- "introductory" and "beginner", which have the same meaning<br />-- "intermediate" and "midlevel", which have the same meaning<br />-- "advanced" and "advance", which have the same meaning<br />-- "scholarly" and "scholar", which have the same meaning<br />-- "popular" generally referring to a writing style<br />-- "older" including retiree<br />-- "institution" including from corporation to conspiracy (such as for management advice)<br />-- "government" including agencies and prospective politicians<br />-- values using any integer or single-digit decimal in the form of "grade 8" or "grade 6.4" including to refer to a reading comprehension level (this generally will not exceed 12 and might be meaningless above 20 so higher values may be interpreted as the highest meaningful value)<br />-- "viewers" for when content (such as a movie) is intended almost entirely to be seen rather than read<br />-- "listeners" for when content (such as music) is intended almost entirely to be heard rather than read but not generally including text-to-speech support<br />-- "tts", "text-to-speech", or "text to speech", which three have the same meaning and which are for a page that has substantial support for TTS or that will be readily understood through TTS without need for such support (TTS is often aided by, e.g., pre-resolving pronunciation ambiguities in page coding)<br />-- values using any numbers in the form of "3-6 years old", whether a range or a single-number value<br />-- values using any decade in the form of "born in 1970s"<br />Unrecognized values such as "botanists", "Texans", and "writers who use red ink" may be used but at a risk that a search engine or directory editor will either fail to recognize it or will interpret it in unpredictable ways, or will in the future.<br />Spellings that are erroneous or slightly different from a recognized value may be interpreted by a search engine or directory editor as representing a recognized value.<br />The absence of the keyword defaults to a value of "all" but without overriding another indication arrived at by other means.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| creator<br />
| Searching for one content creator's work requires a standard robot-parsable format for the information. A personal name, institutional name, or other text entry is permissible.<br />One element represents only one creator. Multiple creators are to be represented with multiple tags.<br />Search engines may index by any component of a name, so a content creator need only enter a name once in one first-last or family-given order (e.g., Pat Thunderbird or Thunderbird, Pat, but not requiring both).<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| publisher<br />
| Searching for one content publisher's or page publisher's work requires a standard robot-parsable format for the information. This often differs from creator or author when the publisher is an institution. An institutional name, personal name, or other text entry is permissible.<br />One element represents only one publisher. Multiple publishers are to be represented with multiple tags, although multiple publishers are less common than multiple authors or creators; multiplicity is more likely for a legal name and a well-known name.<br />Search engines may index by any component of a name, so a publisher need only enter a name once in one order.<br />
| <br />
| <br />
| Proposal<br />
|-valign="top" <br />
| format-print<br />
| This is to allow a user agent to inform an operating system or a printer driver of the preferred print medium, such as the paper size.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated (multiple values might be appropriate because standard paper sizes vary around the world). Singular and plural forms have the same meaning.<br />Recognized values are limited to "letter", "A4", "legal", "A5", "B5", "monarch", "envelope 10" meaning size #10, "envelope 6-3-4" meaning size #6 3/4, values with integers and decimals in the form of "8.5 x 11" or "8.5x11" in which spacing of the "x" does not affect meaning, "paper", which means 'paper of the default color (usually white) and weight (usually 20-lb. stock)', "white", "yellow", "pink", "blue", "green", "violet", or "multicolor", which means a medium of the given color or mixed, "letterhead", "p2 letterhead" meaning 'letterhead intended for any page except the first', "watermark" meaning a 'special watermark such as an organization's own', and "plain" meaning 'not preprinted and not letterhead (it may have a paper manufacturer's watermark not related to letterhead)'.<br />Omitting "paper" when another recognized value is given defaults to an implied meaning of 'paper' with the other value; e.g., "letter" means 'letter paper'; the same principle applies to a medium's color (the default being white for paper and colorless for transparency) and plainness or lack thereof (the default being plain).<br />Other values should be proposed before being recognized here. Label sizes should be proposed here for labels that are not on backing sheets that fit one of the recognized values, e.g., labels on narrow rolls. Blueprint paper sizes should be proposed here. Media other than standard paper, such as onion skin, heavier paper, card, and clear or color transparency, should be proposed here.<br />The user agent may, with the user's or user sysadmin's permission (as by a menu-driven default), interpret a value to offer an alternative the user might accept and software and firmware other than the UA may interpret a value to the same end with or without permission, so this keyword is only suggestive; e.g., "letter" may be interpreted as "A4".<br />The absence of the keyword defaults to a value determined by other than the page, e.g., by the printer driver or the user agent.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| rights<br />
| As a page effectively appears in at least two forms, usually one as interpreted and displayed on a device and the other as source code, arguably intellectual property rights that must be asserted must be asserted in ways understandable in both contexts. For example, &amp;copy; is a raw representation that may legally fail as part of copyright notice to someone seeing source code and not the display, important when someone wants to copy source code for use elsewhere and may rely on a defense of innocent infringement (at least in U.S.). While such assertions can be made in a comment element, it may be helpful to have a tag that search engines can parse and index verbatim.<br />The value may include standard and nonstandard notices, invocations of licenses such as GFDL and ASCAP, and any other information. Content is defined as free-form, leaving the page author discretion for the entry.<br />Statements in one tag may discuss several portions of the page differently, e.g., with different licenses.<br />More than one license may be offered, along with the page's relationship to all.<br />Not all statements need be license grants. A statement may state whom to ask for reprint permission or may reserve all rights, for example.<br />Only one meta tag with this keyword may be present. Page authors must not use more than one. A UA finding multiple such tags on one page must ignore all of them.<br />The copyright symbol that would be generated by its character entity is not recommended for legal notice in source code when the word 'Copyright' may be used instead, because the entity may be read in raw form, but use is up to the page author. The same concept applies to any intellectual property rights symbol for which a suitable alternative is available, such as for trademark or service mark.<br />ASCII text would not suffice when a name or notice legally may have to be in a non-Roman alphabet, but no alternative may yet exist in HTML5.<br />Search engine storage may impose a length limit, but, because of legal consequences, if the value's length exceeds a given limit the search index should retain or interpret none of it but only refer to it.<br />The content string may only be copied verbatim in its full length, referred to, or ignored. It may not be, for example, paraphrased, truncated, interpreted, or classified except in addition to being copied verbatim in its full length.<br />Ignoring shall not void, nullify, or alter any rights stated in such tag.<br />For the synonymy, ''IP'', ''IP-rights'', and ''IP-right'' are not reserved; while the abbreviation ''IP'' 'intellectual property' is common among attorneys in the U.S., page authors will more likely be computerate, and the abbreviation may be wanted for 'Internet Protocol'.<br />
| [[Talk:MetaExtensions#rights:_why_reversion|Talk]]<br />
|<br />
| Proposal<br />
|-valign="top"<br />
| rights-standard<br />
| The purpose is to enable search engines and other cataloging services to compile the types of rights allocated to the work.<br />
<br />
Format: <br />
<pre><meta name="rights-standard" content="type;rights" /></pre><br />
<br />
The following are case-insensitive, except object ID.<br />
<br />
* type - item these rights apply to<br />
** (null) - everything; trailing semicolon is not included in this case <br />
** code - the HTML code (and embedded other?) of the page.<br />
** content - the entire content of the page<br />
** object - a specific object, (for example, an image).<br />
*** format is "object;" followed by the object ID; e.g., <code>object;left_middle-column</code><br />
* rights - what rights are assigned to the item<br />
** "coprYYYY" -- work is copyrighted as of YYYY year<br />
** "CC:" - Creative Commons; followed by any number (in any order) of additional attributes:<br />
*** "BY" - By Attribution<br />
*** "SA" - Share Alike<br />
*** "ND" - No Derivatives<br />
*** "NC" - No Commercial<br />
** "PD" - Public domain<br />
<br />
Examples:<br />
<br />
* Page content is CC By Attribution<br />
<meta name='rights-standard' content='content;cc:by' /><br />
<br />
* Page code is CC By Attribution, Share alike<br />
<meta name='rights-standard' content='code;cc:bysa' /><br />
<br />
* Object with ID "item_1" is CC By Attribution, no derivatives, no commercial; object with ID "item_2" is public domain.<br />
<meta name='rights-standard' content='object;item_1;cc:byndnc' /><br />
<meta name='rights-standard' content='object;item_2;pd' /><br />
<br />
* Everything on the page is copyrighted<br />
<meta name='rights-standard' content='copr2009' /><br />
<br />
| [[Talk:MetaExtensions#rights:_why_reversion]] <br />
<br />
[http://creativecommons.org/about/licenses Creative Commons types and attributes]<br />
|<br />
| Proposal<br />
|-valign="top" <br />
| MSSmartTagsPreventParsing<br />
| Microsoft introduced into Internet Explorer 6 Beta a feature that some website designers wished to preclude from applying in order to prevent public misunderstanding of their websites. The feature allowed a browser to add information but at a risk that users wouldn't know that it wasn't supplied by the website. This keyword was provided by Microsoft for those of us who wanted it.<br />Its value was "TRUE". Microsoft spelled the keyword with some capitals and the value in all capitals but whether capitalization was required for either is unknown; some opinions vary. Since it need be understood by only one browser, and that one a beta version, full standards compliance should not be assumed, and original case may be required. (This tag is used by Google: "<meta content='true' name='MSSmartTagsPreventParsing'/>" appeared (with internal quote marks as singles) in the source code for <http://googleblog.blogspot.com/2009/04/listening-to-google-health-users.html>, as accessed 4-27-09.)<br />Microsoft has apparently removed this instruction from its website on the ground that the beta version is no longer available and is not supported, but that doesn't assure that some users aren't still using the beta browser, perhaps inadvertently. Therefore, designers may wish to continue using the keyword and value and they are preserved here.<br />
| e.g., [http://www.theregister.co.uk/2001/06/25/web_sites_banish_those_winxp/ The Register (U.K.)], [http://cc.uoregon.edu/cnews/summer2001/summer2001.pdf Univ. Oregon (U.S.) (PDF p. 18)], & [http://trillian.mit.edu/~jc/demo/SmartTagsOff.html John Chambers (U.S.) (job résumé near root)], all as accessed 4-19-09<br />
| <br />
| Proposal<br />
|-valign="top" <br />
| dir-content-pointer<br />
| When several pages in a directory include main content, a table of contents, an index, and the like, a search engine may be able to organize results more usefully by identifying which is which with a standard vocabulary, helpful when different publishers use different conventions when displaying or printing content.<br />A value is free-form case-insensitive text without a comma and optionally with a trailing number. Multiple values are to be comma-separated (multiple values are appropriate when one document serves multiple purposes). Singular and plural forms have the same meaning.<br />Recognized values, which are pointer types to which numbers may be suffixed, are limited to "start" meaning 'the first page that should be seen by a user' (this may be anywhere in the directory and anywhere within content), "toc" meaning 'table of contents', "intro" including introductions, forewords, prefaces, and tables of figures, "abstract", "main", "bibliography" and "biblio", which have the same meaning, "index" which may mean 'sitemap' or not, "afterword" and "update" which have the same meaning and need not actually update, "credit" meaning 'credits and acknowledgments', and "author bio" meaning 'author's biography', including any information about the author including credentials and contact information. The number suffix may be spaceless or not.<br />When numbers are suffixed, a search engine or directory should arrange like items in numerical order in the results, with unnumbered items following like items that are numbered, e.g., intro 1, intro 2, main 1, main 2, main, main, and so on.<br />Each directory and each subdirectory has its own sequence.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| DC.<br />
| Dublin Core, maintained by Dublin Core MetaData Initiative (DCMI), is an extensive system with some overlap with non-DC names.<br />This reserves all strings that begin with DC and a dot. ''Not true; DC-HTML doesn't use hardwired prefixes, but defines the prefixes using link/@rel="scheme.prefix"''<br />
| [http://www.DublinCore.org DCMI]<br />
| <br />
| Proposal<br />
|-valign="top" <br />
| googlebot<br />slurp<br />msnbot<br />Baiduspider<br />ia_archive<br />TEOMA<br />twiceler<br />
| These names are claimed by Google, Yahoo, Bing (Microsoft), Baidu (apparently), Alexa (used also by Wayback Machine), Teoma, and Cuil, respectively, for their robots, so I'm proposing them here because we should register meta name values claimed essentially proprietarily.<br />For Baidu, the name is from third-party sources since Baidu.com's site is in Chinese.<br />For TEOMA, case is in the original.<br />E.g., <meta name="googlebot" content="noindex">; <META NAME="Slurp" CONTENT="NOODP"> (case in original); <META NAME="msnbot" CONTENT="NOODP"> (case in original); <META NAME = "TEOMA" CONTENT = "NOARCHIVE" > (case in original).<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=93710 Google example] & [http://help.yahoo.com/l/au/yahoo7/search/indexing/indexing-11.html Yahoo example], both as accessed 4-28-09; [http://help.live.com/help.aspx?mkt=en-us&project=wl_webmasters Microsoft example], as accessed 4-27-09; [http://www.alexa.com/help/webmasters Alexa] & [http://www.archive.org/about/faqs.php Wayback Machine], both as accessed 9-19-09; [http://about.ask.com/en/docs/about/webmasters.shtml Ask example], as accessed 4-27-09; [http://www.cuil.com/info/webmaster_info/ Cuil], as accessed 9-19-09<br />
| Slurp<br />MSNBot<br />
| Proposal<br />
|-valign="top" <br />
| bot-. . .<br />
| Robot owners, to allow page authors access to robotic capabilities, e.g., to deny them, should prefix "bot-" to the name of their robot, especially for proprietary bots.<br />Example: If a robot were to be named "dullbucklequiz", the name in the meta element would be "bot-dullbucklequiz".<br />The value "bot-" alone represents all bots so prefixed, like a wildcard.<br />Arguably, there's no need for a list here of any specific bots if http://user-agents.org or http://www.botsvsbrowsers.com/ (and perhaps other sites) is reliable.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top"<br />
|expires<br />
|<code>meta name='expires'</code> defines the expiration date of the page. This can be used for web pages in preparation for an upcoming event, e.g. a registration form for an exposition or competition, or other cases with a pre-set date when the document will no longer be valid, e.g. a product offer in a special sale or a support page for a product known not to be supported anymore from a given time onward.<br />
<br />
Search engines should respond to this meta tag in a reasonable way, i.e. by removing the page from their main search results after the expiration date (possibly still returning the result in a special search for expired pages as long as the page exists and is not explicitly excluded via <code>robots.txt</code> or <code>meta name='robots'</code> etc.) or simply by indicating to the user that this result is out-of-date.<br />
<br />
The content attribute should define the expiration date in accordance with http://www.w3.org/TR/NOTE-datetime . The meta tag should not be used for pages without expiration date. However, for historical reasons, search engines should also interpret other date formats where possible and should be prepared to find values such as "", "0", "no" and "never". Such non-date values are to be interpreted as no expiration date.<br />
<br />
Correctly formatted example:<br />
<code><pre><meta name='expires' content='2012-12-31T23:59Z'></pre></code><br />
<br />
This tag is not to be confused with and has a different meaning than <code>meta http-equiv='expires'.</code><br />
|<br />
|<br />
| Proposal<br />
|}<br />
<br />
== Failed Proposals ==<br />
<br />
{|border=1 cellpadding=4 cellspacing=0<br />
! Keyword<br />
! Brief description<br />
! Link to more details<br />
! Synonyms<br />
! Status<br />
|-valign="top" <br />
| cache<br />
| This doesn't actually work; use HTTP headers instead.<br />Value must be "public", "private", or "no-cache". Intended as a simple way to tell user agents whether to store a copy of the document or not. An alternate for HTTP/1.1's cache-control; for publishers without access to modifying cache-control.<br />
| none<br />
| <br />
| Unendorsed<br />
|}<br />
<br />
== Process ==<br />
<br />
For the "Status" section to be changed to "Accepted", the proposed keyword must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Unendorsed".<br />
<br />
For more details, see [http://whatwg.org/specs/web-apps/current-work/#concept-meta-extensions the HTML5 specification].</div>Ocolonhttps://wiki.whatwg.org/index.php?title=MetaExtensions&diff=5385MetaExtensions2010-08-20T01:20:48Z<p>Ocolon: added a proposal for "expires"</p>
<hr />
<div>This page lists the allowed extension values for the name="" attribute of the &lt;meta> element in HTML5. You may add your own values to this list, which makes them legal HTML5 metadata names. We ask that you try to avoid redundancy; if someone has already defined a name that does roughly what you want, please reuse it.<br />
<br />
== Registered Extensions ==<br />
<br />
None so far. The spec defines five: [http://whatwg.org/specs/web-apps/current-work/#meta-application-name application-name], [http://dev.w3.org/html5/spec/Overview.html#meta-author author], [http://whatwg.org/specs/web-apps/current-work/#meta-description description], [http://whatwg.org/specs/web-apps/current-work/#meta-generator generator], and [http://dev.w3.org/html5/spec/Overview.html#meta-keywords keywords].<br />
<br />
== Proposals ==<br />
<br />
{|border=1 cellpadding=4 cellspacing=0<br />
! Keyword<br />
! Brief description<br />
! Link to more details<br />
! Synonyms<br />
! Status<br />
<br />
|-valign="top" <br />
| resolutions<br />
| Authoring web sites to use resolution independent images that display beautifully on high-resolution displays should be made as easy as possible for developers and should not require JavaScript to accomplish.<br />
<br />
To accomplish this, I propose a new HTML Meta Tag, <code>resolutions</code>, that can be used to specify that high-resolution versions of images linked to from the page are available and that the browser should use them in place of the lower-resolution default images if it detects that a user is using a high-resolution screen. The resolutions meta tag lists the device-pixel ratios supported by images in the page. <br />
<br />
So, for example…<br />
<br />
<code><pre lang="HTML"><meta name="resolutions" content="2x"></pre></code><br />
<br />
… means that the developer is telling the browser that she has created 2x resolution images for the images linked to from the current page and named them with a @2x suffix. <br />
<br />
To illustrate, if her image tag is as follows…<br />
<br />
<code><pre lang="HTML"><img src="/images/flower.jpg" alt="A flower"></pre></code><br />
<br />
… then she has two image files under /images: the low-resolution default (flower.jpg), and a higher-resolution (200%) version named flower@2x.jpg. <br />
<br />
(This is the same naming convention already used by Apple in its Cocoa Touch framework for automatically loading in higher-resolution versions of images.)<br />
<br />
Based on the meta tag, if the browser detects that the user is running at a <code>min-device-pixel-ratio</code> of 2.0, it will automatically ask for the 2x version of the image (flower@2x.jpg) instead of the default image as specified in the image tag. <br />
<br />
Finally, so as not to flood external sites with high-resolution image requests, this functionality would only work for local images specified via relative links.<br />
<br />
<h2>Multiple resolutions</h2><br />
<br />
The resolutions tag can also contain a list of supported device-pixel ratios so as to support even higher-resolution displays when and if they become available in the future. <br />
<br />
For example:<br />
<br />
<code><pre lang="HTML"><meta name="resolutions" content="2x, 4x, 8x"></pre></code><br />
<br />
In this case, the developer would provide 2x, 4x, and 8x versions of all images. So, in the running example, she would make flower.jpg, flower@2x.jpg, flower@4x.jpg, and flower@8x.jpg.<br />
<br />
<h2>Advantages</h2><br />
<br />
The advantages of this approach are several:<br />
<br />
<ol><br />
<li>Makes it very simple for developers to support high-resolution displays like the iPhone 4's Retina screen</li><br />
<li>Does not require JavaScript</li><br />
<li>Does not change the default way that things work (if the meta tag is not specified, the browser simply behaves as it always has).</li><br />
</ol><br />
<br />
| [http://aralbalkan.com/3355 Proposal for native browser support of high-resolution image substitution]<br />
[http://aralbalkan.com/3331 How to make your web content look stunning on the iPhone 4’s new Retina display]<br />
|<br />
| Proposal<br />
<br />
|-valign="top" <br />
| keywords-not<br />
| A comma-separated list of negative keywords that distinguish a closely-related theme from this page's true theme, to support Boolean NOT searches often more realistically than visible text can, especially when both themes share the same lexicon.<br />If keywords is no longer a supported name for a meta element, keywords-not is superfluous; however, debate has been revived on whether keywords should be supported or not; see the keywords entry in this Wiki.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6609 W3C Bug 6609]<br />
|<br />
| Proposal<br />
|-valign="top" <br />
| robots<br />
| A comma-separated list of operators explaining how search engine crawlers should treat the content. Possible values are "noarchive" to prevent cached versions, "noindex" to prevent indexing, and "nofollow" works as the link rel value with the same name. This meta name is already supported by every popular search engine.<br />The content value "NOODP" has been offered elsewhere, so I'm proposing it here. It blocks robots from using [http://www.dmoz.org Open Directory Project] descriptions of a website instead of Web pages' own meta descriptions. It may have been introduced by Microsoft.<br />The content value "NOYDIR" has been offered by Yahoo, so I'm proposing it here. It blocks Yahoo's robot from using the Yahoo directory's descriptions of a website instead of Web pages' own meta descriptions. Whether any other robot supports this is unknown but possibly no other search engine uses Yahoo's directory anyway.<br />
| [http://www.robotstxt.org/wc/exclusion.html#meta Robots exclusion protocol], [http://www.google.com/support/webmasters/bin/answer.py?answer=61050 Googlebot], [http://help.yahoo.com/help/us/ysearch/slurp/index.html Yahoo&#33; Slurp], and [http://about.ask.com/en/docs/about/webmasters.shtml Ask.com Teoma];<br />NOODP value: [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=35264 Google], [http://help.yahoo.com/l/us/yahoo/search/indexing/indexing-11.html Yahoo], & [http://help.live.com/help.aspx?mkt=en-us&project=wl_webmasters#faq38 Microsoft (click "How does Live Search generate a description of my website?")], all as accessed 4-28-09;<br />NOYDIR value: [http://ysearchblog.com/2007/02/28/yahoo-search-support-for-noydir-meta-tags-and-weather-update/ Yahoo], as accessed 4-28-09<br />
| <br />
| Proposal<br />
|-valign="top" <br />
| page-datetime<br />
| Better ranking in search engine results for recency or relevance to an event date would be aided by a standard format robots can parse. Users would save search time by not having to load many pages to find which ones are new or date-relevant.<br />To supply a consistent and known format, the value for this keyword is a date-time expression formed in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />
| <br />
| <br />
| Proposal<br />
|-valign="top" <br />
| page-version<br />
| Pages may be revised several times daily. While date-time given to a granularity of a fraction of a second would often suffice, when a page has to be approved more than once before posting, any or no such time may be correct (without this keyword, a comment could be necessary but probably not parsable by an engine). In addition, versions regardless of date may show consecutiveness and can replace a date that must be vague. In that case, a version number may be more useful for searches and so a robot-parsable format is needed.<br />The keyword's value is stated in ASCII digits, is any nonnegative base-10 rational number expressed as an integer or a decimal, with any number of decimal places allowed, and may be padded with any number of leading zeros to support extraction for ASCII sorting.<br />Should this keyword appear more than once, only the first one so appearing is determinative.<br />The versions 0 and 0.''n'', with ''n'' being to any number of places, signify beta versions, i.e., drafts, in the tradition of beta software, while versions 1 and higher ordinarily signify final-release versions. After a final-release version is released, a draft of a later version is not given a version number of 0 or 0.''n'', but is numbered higher than the last final-release version. It is suggested to page authors that draft status, if applicable, be shown in the visibly displayed text of the page, rather than that this meta tag be relied upon as the sole notice of draft status, as it may be inadequate notice if alone.<br />To assign a low page-version such as 0.''n'' or 1, the page's URL, if static, may be used as the relevant premise. Thus, if a page is copied or moved to a new URL, the author may choose to restart page-version numbering from 0.''n'' or 1. If a page's URL is dynamic, e.g., if created on the fly from a script, the page author may prefer to use as the relevant premise for assigning a low page-version such as 0.''n'' or 1 the URL of the script or other technology that generates the dynamic-URL page, placing this meta element containing this attribute within the script or other technology, not within the generating page's head element (the generating page's head element may have its own meta element with this attribute describing the generating page). If one page containing the script or other technology that generates another page has more than one means for generating dynamic-URL pages, each means should contain its own meta element with this attribute. Page-version is thus largely independent of the page's date, although both would likely advance roughly in parallel.<br />
| <br />
| <br />
| Proposal<br />
|-valign="top" <br />
| subj-. . .<br />
| To classify by subject a page's content, a standard subject taxonomy that will be recognized by a search engine or directory will help. Because many such high-quality taxonomies exist, only a prefix is proposed. Over time, particular taxonomies, in print or online, may be recognized here and keywords assigned for each.<br />The keyword will be constructed case-insensitively with subkeywords in the form subj-[nationAbbrev]-[taxonomy]-[edition][-optionalSubedition], e.g., subj-US-MeSH-2009online (perhaps). After "subj-", the second subkeyword will identify the nation where the taxonomy is published or offered as an aid in identifying the taxonomy and does not limit the subject coverage; e.g., a taxonomy published in Japan may be ideal for classifying Canadian botany or Peruvian economy.<br />As subject values may vary between editions of one taxonomy, an edition and optionally a subedition is to be identified in the third and optionally the fourth subkeywords. The subedition, if any, is any update or revision occurring between editions, such that a value drawn from that edition and subedition is stable. The means of identifying edition and subedition should be included in the registration of a keyword.<br />Examples of taxonomies from the U.S. include MeSH (medical) and the Library of Congress Subject Headings.<br />The value identifying a subject for a Web page will be drawn from the cited taxonomy's edition and subedition.<br />If the value should have a style to prevent ambiguity in interpretation, that style is to be registered here for that keyword. Multiple values are expressed with multiple meta elements, one value for each, since comma-separation is probably not compatible with all taxonomies.<br />If a value requires case-sensitivity to prevent confusion, the entry here registering the keyword must accommodate that need with the needs of HTML 5 with an appropriate rule. To that end, a proposal to allow case-sensitivity in meta tags under some circumstances has been offered in the W3C bug reporting system.<br />
| [http://www.w3.org/Bugs/Public/show_bug.cgi?id=6854 W3C Bug 6854]<br />
| subject-. . .<br />
| Proposal<br />
|-valign="top" <br />
| geographic-coverage<br />
| The author may be the best expert on the geographic relevance of the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers and epidemiological studies which may mention locales only once.<br />Absence of the keyword defaults to a value of world (not universe), unless the search engine chooses to interpret the page or larger unit for some other value, probably based on other than just contact information given in the website.<br />The value for this keyword is a semicolon-separated list of one or more place-values, the order of which do not matter. One place-value will use commas to separate, in order, an optional standard natural language symbol applicable to the place-value (when omitted the language applicable to the page will control), a place-class, one or more place-subclasses if any, and one or more place name parts (where, e.g., in "Cape Town, South Africa", "Cape Town" is a place name part but "Town" is not). Spaces after semicolons and commas are optional; spaces within place-values are present when required for each place-value (e.g., "Quezon City", not an invented "QuezonCity").<br />To distinguish names that might otherwise be too similar, place-classes, all lower-case and hyphenatably spaceless, include ''outer-space'', ''region'' (on Earth and crossing or larger than a nation, e.g., southern hemisphere, polar region, temperate zone, or Asia), ''intntl-water'' (an 'international water body'), ''intntl-agcy'' ('international agency' or 'international collection', e.g., all U.N. member nations), ''nation'', ''within-nation'' (limited to only one political level down from nation, e.g., state, province, territory, possession, city not included within other political units of a nation, or any comparable unit), ''city'' (including town, village, hamlet, and any comparable political unit below the level of ''within-nation''), ''addr'' (including address, full-length street, building, institution, and neighborhood without political boundaries), ''pol-unit'' (''pol'' abbreviating 'political') (e.g., a place of disputed nationhood), ''hist-pol-unit'' (''hist'' abbreviating 'historical') (e.g., the Roman Empire), ''feature'' (e.g., river), ''num'' (e.g., latitude and longitude or outer-space equivalent in numbers), and ''ethereal'' (including thealogical/theological, fictional including from modern popular entertainment, and ancient secular mythical, but not including that which is asserted to be a state of mind or existence but not a place, such as nirvana). (Example for one hypothetical page: name="geographic-coverage" content="region, sub-Saharan Africa; nation, Panama; city, Panama, Panama; within-nation, Sao Paulo, Brazil; city, Sao Paulo, Sao Paulo, Brazil; within-nation, Mississippi, United States of America; region, Middle East; region, Midwest, United States of America; hist-pol-unit, Northwest Territory, United States of America; feature, river, Indus; outer-space, Indus; ethereal, ultima Thule; ethereal, Heaven; ethereal, Flatland; ethereal, Valhalla; en-US, addr, Hotel Valhalla, Fredrikstad, Norway; es, nation, Espana" (Indus is both a river and a constellation, illustrating the need for place-classes)).<br />Ambiguity of place-values should be avoided despite convenience in coding because search engines may each interpret them as they see fit, e.g., it would be hard for an engine to distinguish New York from New York.<br />For consistency of spelling, several authority lists should be settled upon, with legal, well-known, and disputed names and common abbreviations all being acceptable; but I'm not proposing one here now (relying on IANA's ccTLD list might be too complex to implement and still assure coding consistency, e.g., occasionally ccTLDs can be phased out and off of IANA's list) (a standard vocabulary possibly usable here is the [http://www.getty.edu/research/conducting_research/vocabularies/tgn/index.html Getty Thesaurus of Geographic Names Online], subject to licensing and charset choice); and promulgating authority lists may best be done publicly by search engine managements, who may disagree with each other.<br />Allowing Unicode for non-Roman alphabet-using locales is desirable, but at present that may raise technical problems, including computer security issues, that are not yet readily soluble.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage<br />
| The author may be the best expert on which time frame is most relevant to the content. Leaving that to search engine analysis may be too chancy without search engine optimization, which analysis is difficult to apply by algorithm to, e.g., historical papers that may focus on the 1800s but mention 1731 and 1912 perhaps unimportantly.<br />The value for this keyword is a date or time -- not a range and not vague, for which other keywords are proposed -- in a format in accordance with http://www.w3.org/TR/NOTE-datetime (albeit a note that's at W3C only for discussion). Any of the six levels of granularity in that note are acceptable, such as expressing only a year.<br />Should this keyword appear more than once, all the values so appearing are determinative. Multiple values are to be expressed with separate meta elements lest the note be revised in the future in a way incompatible with comma-separating a list.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage-start<br />
| This is identical to the keyword datetime-coverage except that it represents only the start. If this keyword is used without datetime-coverage-end (also proposed), its value is interpreted as starting a range without an end.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the start of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-start=1862, datetime-coverage-start=1914, datetime-coverage-end=1865, and datetime-coverage-end=1918, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage-end<br />
| This is identical to the keyword datetime-coverage except that it represents only the end. If this keyword is used without datetime-coverage-start (also proposed), its value is interpreted as ending a range without a start.<br />Should this keyword appear more than once, all the values so appearing are determinative, in which case each represents the end of a different range assumed to be nonnesting. Example: If four elements happen to be in the order of datetime-coverage-end=1865, datetime-coverage-start=1914, datetime-coverage-end=1918, and datetime-coverage-start=1862, assuming proper formatting, the ranges should be interpreted as 1862-1865 and 1914-1918.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| datetime-coverage-vague<br />
| This is identical to the keyword datetime-coverage except that its value is not necessarily crisp. This keyword should be used only when datetime-coverage, datetime-coverage-start, and datetime-coverage-end are inappropriate, but there's no ban on using all four. Any text without a comma can be the value (e.g., Pleistocene, 1820s, Tuesdays, or before we were born); multiple values are comma-separated.<br />If this keyword is used with datetime-coverage, datetime-coverage-start, or datetime-coverage-end, the vague value should be exploited along with the value/s for the other keyword/s.<br />Should this keyword appear more than once, all are determinative.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| audience<br />
| To aid search engines in classifying and to aid directory compilers, an audience most appropriate for the page may be suggested. Subject matter may not be a good clue; for example, an analysis of children's literature may be directed to teachers.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated. Singular and plural forms have the same meaning.<br />Recognized values:<br />-- "all" and "everyone", which have the same meaning<br />-- "adult" and "mature" have the same meaning and are for content that only adults may access, but no one responsible for preventing a nonadult or the immature from accessing the page or its content should rely on either or both of these values to do so without other means (not the same as "grownup", which see)<br />-- "child" and "juvenile", which have the same meaning<br />-- "teen"<br />-- "grownup" is not identical to "adult" or "mature" in not implying a precise boundary but is approximately any person who may be able to understand and apply the content (e.g., car driving instruction that may be read by a minor not yet old enough to drive a car but who would likely benefit from somewhat early exposure to the instruction)<br />-- "parent" to include guardian and temporary caregiver<br />-- "teacher" to include professor and ad hoc instructor<br />-- "elementary school student" to include any student below high school<br />-- "high school student"<br />-- "elhi" to include any student in elementary school through high school<br />-- "college student" including graduate and professional school<br />-- "business" including management, finance, and prospective customers (this includes e-commerce and investor sites)<br />-- "health" including any health care provider including alternative and ad hoc<br />-- "patient" for any health care recipient<br />-- "lawyer" including judge, paralegal, and jailhouse lawyer<br />-- "law client" for any prospective recipient of a lawyer's service (not usually a social work client) with ''lawyer'' including paralegal and jailhouse lawyer but not necessarily judge<br />-- "craft" for any craftworker including laborer and artisan<br />-- "artist" including musician, actor, dancer, and sculptor and including creator and performer<br />-- "military" including paramilitary<br />-- "news" including any consumer of rapidly-developing news<br />-- "introductory" and "beginner", which have the same meaning<br />-- "intermediate" and "midlevel", which have the same meaning<br />-- "advanced" and "advance", which have the same meaning<br />-- "scholarly" and "scholar", which have the same meaning<br />-- "popular" generally referring to a writing style<br />-- "older" including retiree<br />-- "institution" including from corporation to conspiracy (such as for management advice)<br />-- "government" including agencies and prospective politicians<br />-- values using any integer or single-digit decimal in the form of "grade 8" or "grade 6.4" including to refer to a reading comprehension level (this generally will not exceed 12 and might be meaningless above 20 so higher values may be interpreted as the highest meaningful value)<br />-- "viewers" for when content (such as a movie) is intended almost entirely to be seen rather than read<br />-- "listeners" for when content (such as music) is intended almost entirely to be heard rather than read but not generally including text-to-speech support<br />-- "tts", "text-to-speech", or "text to speech", which three have the same meaning and which are for a page that has substantial support for TTS or that will be readily understood through TTS without need for such support (TTS is often aided by, e.g., pre-resolving pronunciation ambiguities in page coding)<br />-- values using any numbers in the form of "3-6 years old", whether a range or a single-number value<br />-- values using any decade in the form of "born in 1970s"<br />Unrecognized values such as "botanists", "Texans", and "writers who use red ink" may be used but at a risk that a search engine or directory editor will either fail to recognize it or will interpret it in unpredictable ways, or will in the future.<br />Spellings that are erroneous or slightly different from a recognized value may be interpreted by a search engine or directory editor as representing a recognized value.<br />The absence of the keyword defaults to a value of "all" but without overriding another indication arrived at by other means.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| creator<br />
| Searching for one content creator's work requires a standard robot-parsable format for the information. A personal name, institutional name, or other text entry is permissible.<br />One element represents only one creator. Multiple creators are to be represented with multiple tags.<br />Search engines may index by any component of a name, so a content creator need only enter a name once in one first-last or family-given order (e.g., Pat Thunderbird or Thunderbird, Pat, but not requiring both).<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| publisher<br />
| Searching for one content publisher's or page publisher's work requires a standard robot-parsable format for the information. This often differs from creator or author when the publisher is an institution. An institutional name, personal name, or other text entry is permissible.<br />One element represents only one publisher. Multiple publishers are to be represented with multiple tags, although multiple publishers are less common than multiple authors or creators; multiplicity is more likely for a legal name and a well-known name.<br />Search engines may index by any component of a name, so a publisher need only enter a name once in one order.<br />
| <br />
| <br />
| Proposal<br />
|-valign="top" <br />
| format-print<br />
| This is to allow a user agent to inform an operating system or a printer driver of the preferred print medium, such as the paper size.<br />A value is free-form case-insensitive text without a comma. Multiple values are to be comma-separated (multiple values might be appropriate because standard paper sizes vary around the world). Singular and plural forms have the same meaning.<br />Recognized values are limited to "letter", "A4", "legal", "A5", "B5", "monarch", "envelope 10" meaning size #10, "envelope 6-3-4" meaning size #6 3/4, values with integers and decimals in the form of "8.5 x 11" or "8.5x11" in which spacing of the "x" does not affect meaning, "paper", which means 'paper of the default color (usually white) and weight (usually 20-lb. stock)', "white", "yellow", "pink", "blue", "green", "violet", or "multicolor", which means a medium of the given color or mixed, "letterhead", "p2 letterhead" meaning 'letterhead intended for any page except the first', "watermark" meaning a 'special watermark such as an organization's own', and "plain" meaning 'not preprinted and not letterhead (it may have a paper manufacturer's watermark not related to letterhead)'.<br />Omitting "paper" when another recognized value is given defaults to an implied meaning of 'paper' with the other value; e.g., "letter" means 'letter paper'; the same principle applies to a medium's color (the default being white for paper and colorless for transparency) and plainness or lack thereof (the default being plain).<br />Other values should be proposed before being recognized here. Label sizes should be proposed here for labels that are not on backing sheets that fit one of the recognized values, e.g., labels on narrow rolls. Blueprint paper sizes should be proposed here. Media other than standard paper, such as onion skin, heavier paper, card, and clear or color transparency, should be proposed here.<br />The user agent may, with the user's or user sysadmin's permission (as by a menu-driven default), interpret a value to offer an alternative the user might accept and software and firmware other than the UA may interpret a value to the same end with or without permission, so this keyword is only suggestive; e.g., "letter" may be interpreted as "A4".<br />The absence of the keyword defaults to a value determined by other than the page, e.g., by the printer driver or the user agent.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| rights<br />
| As a page effectively appears in at least two forms, usually one as interpreted and displayed on a device and the other as source code, arguably intellectual property rights that must be asserted must be asserted in ways understandable in both contexts. For example, &amp;copy; is a raw representation that may legally fail as part of copyright notice to someone seeing source code and not the display, important when someone wants to copy source code for use elsewhere and may rely on a defense of innocent infringement (at least in U.S.). While such assertions can be made in a comment element, it may be helpful to have a tag that search engines can parse and index verbatim.<br />The value may include standard and nonstandard notices, invocations of licenses such as GFDL and ASCAP, and any other information. Content is defined as free-form, leaving the page author discretion for the entry.<br />Statements in one tag may discuss several portions of the page differently, e.g., with different licenses.<br />More than one license may be offered, along with the page's relationship to all.<br />Not all statements need be license grants. A statement may state whom to ask for reprint permission or may reserve all rights, for example.<br />Only one meta tag with this keyword may be present. Page authors must not use more than one. A UA finding multiple such tags on one page must ignore all of them.<br />The copyright symbol that would be generated by its character entity is not recommended for legal notice in source code when the word 'Copyright' may be used instead, because the entity may be read in raw form, but use is up to the page author. The same concept applies to any intellectual property rights symbol for which a suitable alternative is available, such as for trademark or service mark.<br />ASCII text would not suffice when a name or notice legally may have to be in a non-Roman alphabet, but no alternative may yet exist in HTML5.<br />Search engine storage may impose a length limit, but, because of legal consequences, if the value's length exceeds a given limit the search index should retain or interpret none of it but only refer to it.<br />The content string may only be copied verbatim in its full length, referred to, or ignored. It may not be, for example, paraphrased, truncated, interpreted, or classified except in addition to being copied verbatim in its full length.<br />Ignoring shall not void, nullify, or alter any rights stated in such tag.<br />For the synonymy, ''IP'', ''IP-rights'', and ''IP-right'' are not reserved; while the abbreviation ''IP'' 'intellectual property' is common among attorneys in the U.S., page authors will more likely be computerate, and the abbreviation may be wanted for 'Internet Protocol'.<br />
| [[Talk:MetaExtensions#rights:_why_reversion|Talk]]<br />
|<br />
| Proposal<br />
|-valign="top"<br />
| rights-standard<br />
| The purpose is to enable search engines and other cataloging services to compile the types of rights allocated to the work.<br />
<br />
Format: <br />
<pre><meta name="rights-standard" content="type;rights" /></pre><br />
<br />
The following are case-insensitive, except object ID.<br />
<br />
* type - item these rights apply to<br />
** (null) - everything; trailing semicolon is not included in this case <br />
** code - the HTML code (and embedded other?) of the page.<br />
** content - the entire content of the page<br />
** object - a specific object, (for example, an image).<br />
*** format is "object;" followed by the object ID; e.g., <code>object;left_middle-column</code><br />
* rights - what rights are assigned to the item<br />
** "coprYYYY" -- work is copyrighted as of YYYY year<br />
** "CC:" - Creative Commons; followed by any number (in any order) of additional attributes:<br />
*** "BY" - By Attribution<br />
*** "SA" - Share Alike<br />
*** "ND" - No Derivatives<br />
*** "NC" - No Commercial<br />
** "PD" - Public domain<br />
<br />
Examples:<br />
<br />
* Page content is CC By Attribution<br />
<meta name='rights-standard' content='content;cc:by' /><br />
<br />
* Page code is CC By Attribution, Share alike<br />
<meta name='rights-standard' content='code;cc:bysa' /><br />
<br />
* Object with ID "item_1" is CC By Attribution, no derivatives, no commercial; object with ID "item_2" is public domain.<br />
<meta name='rights-standard' content='object;item_1;cc:byndnc' /><br />
<meta name='rights-standard' content='object;item_2;pd' /><br />
<br />
* Everything on the page is copyrighted<br />
<meta name='rights-standard' content='copr2009' /><br />
<br />
| [[Talk:MetaExtensions#rights:_why_reversion]] <br />
<br />
[http://creativecommons.org/about/licenses Creative Commons types and attributes]<br />
|<br />
| Proposal<br />
|-valign="top" <br />
| MSSmartTagsPreventParsing<br />
| Microsoft introduced into Internet Explorer 6 Beta a feature that some website designers wished to preclude from applying in order to prevent public misunderstanding of their websites. The feature allowed a browser to add information but at a risk that users wouldn't know that it wasn't supplied by the website. This keyword was provided by Microsoft for those of us who wanted it.<br />Its value was "TRUE". Microsoft spelled the keyword with some capitals and the value in all capitals but whether capitalization was required for either is unknown; some opinions vary. Since it need be understood by only one browser, and that one a beta version, full standards compliance should not be assumed, and original case may be required. (This tag is used by Google: "<meta content='true' name='MSSmartTagsPreventParsing'/>" appeared (with internal quote marks as singles) in the source code for <http://googleblog.blogspot.com/2009/04/listening-to-google-health-users.html>, as accessed 4-27-09.)<br />Microsoft has apparently removed this instruction from its website on the ground that the beta version is no longer available and is not supported, but that doesn't assure that some users aren't still using the beta browser, perhaps inadvertently. Therefore, designers may wish to continue using the keyword and value and they are preserved here.<br />
| e.g., [http://www.theregister.co.uk/2001/06/25/web_sites_banish_those_winxp/ The Register (U.K.)], [http://cc.uoregon.edu/cnews/summer2001/summer2001.pdf Univ. Oregon (U.S.) (PDF p. 18)], & [http://trillian.mit.edu/~jc/demo/SmartTagsOff.html John Chambers (U.S.) (job résumé near root)], all as accessed 4-19-09<br />
| <br />
| Proposal<br />
|-valign="top" <br />
| dir-content-pointer<br />
| When several pages in a directory include main content, a table of contents, an index, and the like, a search engine may be able to organize results more usefully by identifying which is which with a standard vocabulary, helpful when different publishers use different conventions when displaying or printing content.<br />A value is free-form case-insensitive text without a comma and optionally with a trailing number. Multiple values are to be comma-separated (multiple values are appropriate when one document serves multiple purposes). Singular and plural forms have the same meaning.<br />Recognized values, which are pointer types to which numbers may be suffixed, are limited to "start" meaning 'the first page that should be seen by a user' (this may be anywhere in the directory and anywhere within content), "toc" meaning 'table of contents', "intro" including introductions, forewords, prefaces, and tables of figures, "abstract", "main", "bibliography" and "biblio", which have the same meaning, "index" which may mean 'sitemap' or not, "afterword" and "update" which have the same meaning and need not actually update, "credit" meaning 'credits and acknowledgments', and "author bio" meaning 'author's biography', including any information about the author including credentials and contact information. The number suffix may be spaceless or not.<br />When numbers are suffixed, a search engine or directory should arrange like items in numerical order in the results, with unnumbered items following like items that are numbered, e.g., intro 1, intro 2, main 1, main 2, main, main, and so on.<br />Each directory and each subdirectory has its own sequence.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top" <br />
| DC.<br />
| Dublin Core, maintained by Dublin Core MetaData Initiative (DCMI), is an extensive system with some overlap with non-DC names.<br />This reserves all strings that begin with DC and a dot. ''Not true; DC-HTML doesn't use hardwired prefixes, but defines the prefixes using link/@rel="scheme.prefix"''<br />
| [http://www.DublinCore.org DCMI]<br />
| <br />
| Proposal<br />
|-valign="top" <br />
| googlebot<br />slurp<br />msnbot<br />Baiduspider<br />ia_archive<br />TEOMA<br />twiceler<br />
| These names are claimed by Google, Yahoo, Bing (Microsoft), Baidu (apparently), Alexa (used also by Wayback Machine), Teoma, and Cuil, respectively, for their robots, so I'm proposing them here because we should register meta name values claimed essentially proprietarily.<br />For Baidu, the name is from third-party sources since Baidu.com's site is in Chinese.<br />For TEOMA, case is in the original.<br />E.g., <meta name="googlebot" content="noindex">; <META NAME="Slurp" CONTENT="NOODP"> (case in original); <META NAME="msnbot" CONTENT="NOODP"> (case in original); <META NAME = "TEOMA" CONTENT = "NOARCHIVE" > (case in original).<br />
| [http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=93710 Google example] & [http://help.yahoo.com/l/au/yahoo7/search/indexing/indexing-11.html Yahoo example], both as accessed 4-28-09; [http://help.live.com/help.aspx?mkt=en-us&project=wl_webmasters Microsoft example], as accessed 4-27-09; [http://www.alexa.com/help/webmasters Alexa] & [http://www.archive.org/about/faqs.php Wayback Machine], both as accessed 9-19-09; [http://about.ask.com/en/docs/about/webmasters.shtml Ask example], as accessed 4-27-09; [http://www.cuil.com/info/webmaster_info/ Cuil], as accessed 9-19-09<br />
| Slurp<br />MSNBot<br />
| Proposal<br />
|-valign="top" <br />
| bot-. . .<br />
| Robot owners, to allow page authors access to robotic capabilities, e.g., to deny them, should prefix "bot-" to the name of their robot, especially for proprietary bots.<br />Example: If a robot were to be named "dullbucklequiz", the name in the meta element would be "bot-dullbucklequiz".<br />The value "bot-" alone represents all bots so prefixed, like a wildcard.<br />Arguably, there's no need for a list here of any specific bots if http://user-agents.org or http://www.botsvsbrowsers.com/ (and perhaps other sites) is reliable.<br />
| <br />
|<br />
| Proposal<br />
|-valign="top"<br />
|expires<br />
|<code>meta name='expires'</code> defines the expiration date of the page. This can be used for web pages in preparation for an upcoming event, e.g. a registration form for an exposition or competition, or other cases with a pre-set date when the document will no longer be valid, e.g. a product offer in a special sale or a support page for a product known not to be supported anymore from a given time onward.<br />
<br />
Search engines should respond to this meta tag in a reasonable way, i.e. by removing the page from their main search results after the expiration date (possibly still returning the result in a special search for expired pages as long as the page exists and is not explicitly excluded via <code>robots.txt</code> or <code>meta name='robots'</code> etc.) or simply by indicating to the user that this result is out-of-date.<br />
<br />
The content attribute should define the expiration date in accordance with http://www.w3.org/TR/NOTE-datetime . The meta tag should not be used for pages without expiration date. However, for historical reasons, search engines should also interpret other date formats where possible and should be prepared to find values such as "", "0", "no" and "never". Such non-date values are to be interpreted as no expiration date.<br />
<br />
Correctly formatted example:<br />
<code><pre lang="HTML"><meta name='expires' content='2012-12-31T23:59Z'></pre></code><br />
<br />
This tag is not to be confused with and has a different meaning than <code>meta http-equiv='expires'.</code><br />
|<br />
|<br />
| Proposal<br />
|}<br />
<br />
== Failed Proposals ==<br />
<br />
{|border=1 cellpadding=4 cellspacing=0<br />
! Keyword<br />
! Brief description<br />
! Link to more details<br />
! Synonyms<br />
! Status<br />
|-valign="top" <br />
| cache<br />
| This doesn't actually work; use HTTP headers instead.<br />Value must be "public", "private", or "no-cache". Intended as a simple way to tell user agents whether to store a copy of the document or not. An alternate for HTTP/1.1's cache-control; for publishers without access to modifying cache-control.<br />
| none<br />
| <br />
| Unendorsed<br />
|}<br />
<br />
== Process ==<br />
<br />
For the "Status" section to be changed to "Accepted", the proposed keyword must be defined by a W3C specification in the Candidate Recommendation or Recommendation state. If it fails to go through this process, it is "Unendorsed".<br />
<br />
For more details, see [http://whatwg.org/specs/web-apps/current-work/#concept-meta-extensions the HTML5 specification].</div>Ocolon