Feedback on the current editor's draft

As part of our planning for future work, the IE team is reviewing the
current editor's draft of the HTML5 spec and gathering our thoughts. We
want to share our feedback and discuss this in the working group. I will
post our notes as we collect them so we can iterate on our thinking more
quickly. At this stage we have more questions than answers but I believe
that discussing them in public is the best way to make progress.

I want to hear any thoughts, questions, or concerns that you have from
the notes below.

Thanks,

Adrian.
adrianba@microsoft.com


New section tags
================

* <section cite="url">
  Generic document/application section - cite attribute if content from
  another page.

* <nav>
  A section with navigation links (uses HTMLElement).

* <article cite="url" pubdate="dateTime">
  Independent part of page.

* <aside>
  Tangential content (uses HTMLElement)

* <hgroup>
  Indicates to application extracting header data to take first of a
  group of <h?> elements (uses HTMLElement).

* <header>
  Group of introductory or navigational aids (uses HTMLElement).

* <footer>
  Information about the previous section (uses HTMLElement).

Feedback
--------

It's not clear why these new elements in particular are necessary. Those
that use HTMLElement for their interface provide no extra functionality
beyond <div class="xxx"> or <span class="">. If they are necessary, do
we know if this is the correct set? Are there any missing?

Could there be a more generic way to cite content coming from other
sources than introducing a <section> element?

Is <nav> intended to be used to indicate something to AT user agents? If
so, should this be called out? If not, what value does it provide. The
definition of <header> seems similar.

<aside> seems very arbitrary.

<header>/<footer> don't appear to indicate anything about printing that
might reasonably be expected from those terms.


New grouping tag - <dialog> element
===================================

* <dialog>
  Conversation, meeting minutes, chat transcript, etc. (uses
  HTMLElement)

Feedback
--------

Do we really need this new element? It seems arbitrary.

New text-level tags
===================

* <mark>
  Marks a run of text highlighted for reference (uses HTMLElement).

* <time date="" time="" timezone="">
  Annotates text with a specific date or time.

* <progress value="" max="" position="">
  Completion progress of a task (either activity or progress)

* <meter value="" min="" max="" low="" high="" optimum="">
  A scalar measurement within a known range.

Feedback
--------

Again, are these the right set of new tags? If new elements are needed
do we know if this is the correct set? For example, where is the money
or currency element for specifying monetary values with currency?

<progress> suggests in the text that the attributes not be used and that
the current and maximum value should be included as text inside the
element. In which case, is there any value in the attributes (or the
element)?

The <progress> and <meter> elements don't seem to be adequately
specified to provide interoperable implementations. Page authors want
precise control over the layout of their pages and this doesn't appear
to be adequately accounted for. There are other ways of achieving these
effects and ARIA provides mechanisms for annotating those for AT users.

New forms tags
==============

* <keygen>
  Key/value pair generator control.

Feedback
--------

Windows has a broad set of controls for generating and enrolling in
certificates in flexible ways while ensuring that the keys/certs can be
used by other apps. <keygen> is based on an old Netscape implementation
and is very basic. It's not clear that it is widely adopted today (for
example see
http://www.blooberry.com/indexdot/html/tagpages/k/keygen.htm). We
supported this in our web enrolment pages in the past for compatibility
but in Win7 it is deprecated.

We have some concerns about including <keygen> in the spec. We're not
sure this is the right design to be encouraging given that it wasn't in
HTML 4.01.

* <input type="date|time|datetime|local-datetime">
  Input controls for selecting dates.

Feedback
--------

The date controls allow a data to be selected either in UTC (with a Z
suffix) or with no time-zone (where the value will be in whatever the
local time zone of the consumer is). The time control seems to suggest
that it is always in UTC.

Handling dates and times is notoriously complex, especially when
involving producers and consumers located in different time zones,
particularly with different periods of daylight saving time. We are
concerned that the controls specified don't provide sufficient control
over which time zone is being used. For example, my application
retrieves a date/time from a database complete with time zone
information. I want to send that to the user agent as the default value
for a date/time picker but I don't know which time zone the user is in.
I may need a way to allow them to pick a time in their own time zone or
another time zone (for example a place they will be visiting). It's not
clear from the spec the best way of managing this level of detail.

New interactive elements
========================

* <datagrid>
  Tree, list, or tabular data provided by script.

Feedback
--------

There are a number of libraries providing support for databinding using
script and HTML. We're not sure this is the correct design and we will
investigate further.

* <bb type="">
  User agent command including "make application".

Feedback
--------

Having a consistent installation experience for independent applications
is the key to their success. Supporting the instantiation of individual
apps through a page control provides too much programmable flexibility
that developers could use to hijack the end-user experience thus
creating an inconsistent process.

Events

The current specification places the tag in the body of the document and
implies it will continue to support all standard HTML 5 event handlers:

onabort, ondragover, onmousemove, onbeforeunload, ondragstart,
onmouseout, onblur, ondrop, onmouseover, onchange, onerror, onmouseup,
onclick, onfocus onmousewheel, oncontextmenu, onkeydown, onresize,
ondblclick, onkeypress, onscroll, ondrag, onkeyup, onselect, ondragend,
onload, onstorage, ondragenter, onmessage, onsubmit, ondragleave,
onmousedown, onunload

The potential risk of supporting all of these events is that websites
could hijack events and confuse users with inconsistent experiences. For
example, developers could create their own dialog that is displayed when
the onclick event takes place. This would be an additional dialog that
would be displayed in addition to the currently proposed consent dialog.

Scripting

We believe there is a risk in allowing an element of this nature to be
manipulated by script because it could create a scenario where
developers auto-select it as part of the onload page (to force their
website to be accessed as an individual app) and the user would see a
consent dialog without knowing why. This would remove the user from
being in control of the experience.

Tag on Page Body

Having the tag in the body as the main discovery mechanism is a concern
for us. We would like to see a model where the browser chrome is the
primary mechanism by which users install web apps or individual
applications. Our belief is that this will promote a more consistent
experience and could potentially remove the need for having a consent
dialog. This might be able to be accomplished by providing a link tag on
the header of the page to specify that this website could be used
independent of the browser:

<link rel="AppManifest" href="manifest.xml" type="application/xml">

We see the <bb> tag as an additional tag that could be added to provide
additional advertisement to the site with a private event that is
handled by the browser.

Additional Information

Furthermore, there might be additional information that web browsers may
require from the site, beyond its current URL and metadata information,
in order to enhance the launching and execution of the website as an
independent application. That is the reason we believe a manifest URL
needs to be provided.

For example, the <bb> tag specification assumes that the current page
the user is viewing will be the starting page for creating an
independent application. In some cases, the website may want to promote
a web app whose starting page is not the same as the one being viewed.

* <menu type="" label="">
  Context menu or toolbar.

Feedback
--------

Our experience suggests that web developers want precise user agent
independent control over the layout of their UI. Like the <progress> and
<meter> elements, we're concerned about the maturity of the spec for
achieving interoperability for a toolbar UI. We'd like to hear how other
browser vendors feel about platform specific implementation of this type
of control.

In contrast, specifying a context menu that is displayed in a platform
specific style might well be closer to what users expect than today's
menu where web developers try to achieve a balance between platforms.

User Interaction (section 7)
============================

* The contenteditable attribute (7.8)
* The UndoManager interface (7.11.3)

Feedback
--------

Internet Explorer has supported editing for a long time through
proprietary content editable and designMode functionality which has been
mimicked to varying degrees of success in other browsers for the purpose
of Interoperability on the Web. Editing involves many complex
heuristics, primarily involving tag splicing and merging that allow for
end-user predictability when changing fonts and formats while entering
and deleting, copying and pasting text. We are concerned that the
current HTML5 spec prose around editing is not sufficiently mature to be
able to be implemented.

Common editing operations such as "Break block" (under section 7.8.1)
leave the exact behavior of the implementation up to the UA. While
convenient, it does not seem to meet the interoperability requirements
and algorithm specificity that is pervasive through most other portions
of the spec. The standard reads simply: "The exact behavior is UA-
dependent, but user agents must not, in response to a request to break a
paragraph, generate a DOM that is less conformant than the DOM prior to
the request." We should consider whether the behavior can be specified
in greater detail.

In the Undo history section, the current spec calls out "There has got
to be a better way of doing this, surely". Specifically the notes in the
UndoManager interface section suggest the API isn't mature enough for
Last Call.

Received on Friday, 7 August 2009 20:49:11 UTC