==== improving new features ====
* <code>sandbox</code> feature on <code><iframe></code> should be considered for removal.
** needs security review
** will be a lot of work to implement
** may not actually solve the problem it is intending to solve
** get more input from Jonas Sicking
* <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.
* 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.
* 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.
==== lower priority improvements ====
* <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.
* <code>sandbox</code> feature on <code><iframe></code> should be considered for removal.
** needs security review
** will be a lot of work to implement
** may not actually solve the problem it is intending to solve
** get more input from Jonas Sicking
=== DOM API vendor prefixing ===