==== improving new features ====
* expand <code><time></code> and new date/time <code><input></code> elements to be consistent and reflect more real world use cases
** impedance match. handle the same set of year, month, date, time variants/subsets.** more inputs/times. expand both time/input to handle additional real world cases
*** YYYY
*** YYYY-MM
*** --MM-DD
* improve <code><time></code> element to support uses analogous to the "value class pattern" date and time separation use case (compose nested <code><time></code> elements into a single date and time)
** perhaps even use a <code><time></code> to compose multiple nested date/time <code><input></code> elements for specific date/time components into a single date and/or time.
* <code><meter></code> - poorly named. would prefer something like "gauge" but that's potentially hard(er) to spell. this is a bit bikesheddy though so not a high priority.
* <code><summary></code> (inside <code><details></code>)
** need a more specific name. summary is too generic sounding of an element name for this special usage. Similar to the problem with <code><address></code> (special use - for contact information for the document, but used as a generic "address" for street addresses).
** alternatively make a generic <code><summary></code> element - make it an actual summary inside <code><article></code> or <code><body></code>, as well as inside <code><details></code>. Another advantage is that this is close to the semantic of the Atom "summary" element, and the hAtom microformat 'entry-summary' property.
=== DOM API vendor prefixing ===