Re: Feedback on the current editor's draft

On Fri, 7 Aug 2009, Adrian Bateman wrote:
>
> * <section cite="url">
> * <nav>
> * <article cite="url" pubdate="dateTime">
> * <aside>
> * <hgroup>
> * <header>
> * <footer>
> 
> It's not clear why these new elements in particular are necessary.

They are, more or less, filling the most common requests from Web 
developers based on what the most common class="" attribute values are. 
Their main purpose is to simplify authoring and styling.


> 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?

I'm sure many are missing. We did some research a number of years ago, 
though, which supported this particular set as being the top 10 or so 
elements based on usage of the class="" attribute.


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

The <section> element is for sectioning content, not for citing content 
from other sources. The latter purpose is handled by <blockquote>, <q>, 
and <cite>. The cite="" attribute on <section> is really just a 
convenience for people writing aggregators; it allows HTML documents to be 
used as feeds directly (if some conventions are followed) instead of 
requiring a separate Atom feed to be provided.


> Is <nav> intended to be used to indicate something to AT user agents?

That isn't it's primary purpose, but it is a possible useful side-effect 
of using the element, yes.


> If so, should this be called out?

I have added a note to this effect.


> The definition of <header> seems similar.

I don't see what value <header> could bring ATs; could you elaborate?


> <aside> seems very arbitrary.

Sidebars are actually pretty common in HTML documents, at least based on 
the research we did a few years ago.


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

They aren't intended as media-specific elements, indeed.


> * <dialog>
> 
> Do we really need this new element? It seems arbitrary.

This element was introduced primarity to end the debate around how to mark 
up dialog, a debate that has raged pretty much continually in various 
authoring forums since HTML4 suggested in passing that <dl> might or might 
not be suitable for this purpose.


> * <mark>
> * <time date="" time="" timezone="">
> * <progress value="" max="" position="">
> * <meter value="" min="" max="" low="" high="" optimum="">
> 
> Again, are these the right set of new tags? If new elements are needed 
> do we know if this is the correct set?

These elements were introduced to address specific use cases (e.g. <time> 
to address an accessibility issue in the Microformats space, <mark> to 
address the abuse of various other elements when highlighting search 
results from scripts, etc).


> For example, where is the money or currency element for specifying 
> monetary values with currency?

What's the use case for specifying money or currency in a 
machine-readable fashion using a dedicated element rather than a 
Microformat or Microdata vocabulary?


> <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 attributes are valuable because they are significantly easier to 
mutate from script. On the long run, once this element is widely 
supported, we will not need to have any content inside the element.

The element is valuable because currently authors have no good solution 
for progress bars, and therefore they abuse the existing elements, 
creating CSS-dependent solutions that are inaccessible and hard to 
maintain.


> 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.

The styling issue is awaiting implementation experience. The plan is to 
either add pseudo-elements and define the behaviour of properties in those 
cases, or to rely on XBL2 bindings to handle this case.


> * <keygen>
> 
> 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.

Opera, Firefox, and Safari all support this element, so we need to define 
how it works.


> * <input type="date|time|datetime|local-datetime">
> 
> 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.

If the author wants to micromanage the time zone, then the datetime-local 
type should be used, with a separate <select> drop-down for the time zone 
(or some similar UI). If the author wants to rely on the UA to handle the 
time zone UI, then the datetime type should be used. This seems to handle 
the case you describe.


> * <datagrid>
> 
> 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.

I've removed this section for now.


> * <bb type="">
> 
> 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.

I'll handle this in response to the thread on the subject.


> * <menu type="" label="">
> 
> 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.

I agree that we need to find a styling solution; I am awaiting 
implementation experience to determine what the best solution on this 
front should be.


> * The contenteditable attribute (7.8)
> * The UndoManager interface (7.11.3)
> 
> 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.

I would love to, however, I've no idea how to make it more detailed 
without being too detailed in terms of allowing UAs to have whatever UI 
they like.


> 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.

Do you think we should remove this section?


On Mon, 10 Aug 2009, Lars Gunther wrote:
> 
> As for the other new structural elements:
> 
> They were said to be based upon data mining of ids and classes. The most 
> often used ones were these.

The elements were added to the spec before the research, actually, but the 
research showed that very little needed to change to make HTML5 fit the 
most commonly used class names.


> Are there any data that people who used e.g. "aside" as a class before 
> WHAT WG picked it up and turned it into an element, did so in a 
> consistent manner? Might it not be the case that there was an awful lot 
> of <div class="aside"> but a multitude of meanings?

It was mostly class=sidebar, I believe. I'm sure there were lots of subtle 
differences in how it was used; a number of sites were spot-checked, 
however, and I'm relatively confident that the interpretation was sound.


> Ergo: The fact that there was a lot of usage of specific id or class 
> names can not be taken as an indicator per se that there exists a 
> "cowpath" to pave.
> 
> Can anyone provide scientific data concerning this?

I'm not aware of any more research than what has been presented already 
over the past few years; if anyone is interested in doing more research, I 
encourage you to do so. Philip has shown that it doesn't require data 
centers to do this work.


On Wed, 12 Aug 2009, Henri Sivonen wrote:
> > 
> > Could there be a more generic way to cite content coming from other 
> > sources than introducing a <section> element?
> 
> I don't support the cite attribute on any element, because it's 
> "invisible" metadata by default in browsers. I think sources should be 
> pointed at by <a href> that Just Works even in legacy UAs.

The Atom conversion spec also allows <a href=... rel=bookmark> to be used 
instead of <article cite>. However, that doesn't address all the relevant 
use cases -- in particular, Chaals said he wanted hidden metadata to 
identify the source of sections of pages he edits.

If there is a desire to not have this attribute, however, I'm quite happy 
to remove it.


> > * <dialog>
> > 
> > Do we really need this new element? It seems arbitrary.
> 
> This element addresses a permathread but only creates new permathreads. 
> I think the original permathread should be resolved by explicitly 
> blessing the use of <dl> for marking up conversation and removing the 
> <dialog> element.

I think allowing the use of <dl> for dialogs is a nonsensical overloading 
of <dl>'s semantics as a dictionary of name/value pairs.


> > <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 text is fallback for legacy UAs. The value of the attributes is 
> localizability of the text where the decimal separator isn't the dot. 
> Personally, I'd prefer to remove the element content parsing and always 
> make the progress bar rendering depend on the attributes.

I guess we could do that; what do other people think?


On Wed, 12 Aug 2009, Jonas Sicking wrote:
> 
> Are <meter>s really common enough to warrant their own markup?

No, but they're common enough that if we don't provide dedicated markup, 
authors will abuse <progress> for that purpose, which is worse.


> Another data point might be if platform UI libraries commonly provide a 
> gauge widget?

Mac OS X provides three different ones, if I recall correctly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 14 August 2009 10:05:15 UTC