W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: Feedback on the current editor's draft

From: Henri Sivonen <hsivonen@iki.fi>
Date: Wed, 12 Aug 2009 10:04:54 +0300
Cc: "public-html@w3.org" <public-html@w3.org>
Message-Id: <C2376B69-BF19-4A13-A557-AF1DF992729D@iki.fi>
To: Adrian Bateman <adrianba@microsoft.com>
On Aug 7, 2009, at 23:46, Adrian Bateman wrote:

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

The set based on common class names as of 2005 and is an almost-exact  
match to ARIA landmarks, which suggests the set captures common page  

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

As for the <section> element itself, being able to express the  
document outline with <h>/<section> is probably the most-requested  
XHTML2 feature in HTML5. (Except we call the heading <h1> as opposed  
to <h> to make it at least have some heading semantics in legacy AT.)

The sole usefulness of <hgroup> is in relation to the outline algorithm.

For the outline algorithm to be useful, I think it's important to use  
the prescribed algorithm when AT presents a document outline, and I  
think it's important to provide a selector for matching on the depth  
of an element in the outline. I think the (performant)  
implementability of such a selector is the major issue that needs to  
be reviewed about the outline algorithm.

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

I think the elements whose semantics match ARIA landmarks should be  
exposed to AT using exactly the same API that the UA uses for exposing  
the corresponding ARIA landmark. I also think this needs to be  
explicitly stated in the spec.

The value the those elements provide compared to <div class=nav> or  
<div role=navigation> is syntactic convenience for common constructs.  
That's all.

> <aside> seems very arbitrary.

Callouts are a common construct in magazines and on Web sites whose  
layout has been influenced by magazine layout.

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

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.

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

The time element specifically addresses the accessibility problems  
arising from the microformat abbr pattern. The time element is useless  
for marking up times that aren't part of microdata or microformats and  
that wouldn't benefit from CSS-based reformatting in the future.

Personally, I think the concept of localizing time strings for the  
user via CSS is dubious, because users who are able to read foreign  
Web pages probably assume that the dates they see on foreign pages  
have been written according to the foreign convention rather than  
their own. Therefore, reformatting dates in a way that swaps the order  
of month and day would just be confusing. I think the only value from  
reformatting would be the user ability to opt to sane ISO dates and 24  
hour clock while still letting the page to default to local  
conventions for readers who haven't opted out of legacy date and time  
notation. Considering that this benefit is rather marginal compared to  
its complexity, I think it leaves the microdata and microformat  
considerations as the only serious justification for <time>. If  
<currency> doesn't have similar use cases, we don't need to put it in  
the language.

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

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

Clearly, stylability of all UI widgets is very much in demand but not  
a solved problem across all UAs. I think procedurally, the issue  
belongs in the CSS WG, but I think the HTML-native UI widgets are at  
risk of being worked around by authors as long as the styling issue  
hasn't been thoroughly addressed.

> There are other ways of achieving these
> effects and ARIA provides mechanisms for annotating those for AT  
> users.

Implementing a progress bar and a gauge using ARIA is much more  
complex for authors than using a higher-level construct.

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

It appears that a browser needs to support either Netscape's or  
Microsoft's certificate enrollment mechanism in order to be compatible  
with enrollment pages out there. The Netscape mechanism is implemented  
in 3 out of the top 4 browser engines. As such, it seems like a part  
of the platform that needs to be specced.

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

I think the spec strikes the right balance having a mechanism for  
pointing a concrete point in time (UTC) and by having a way to pick a  
time or date without a time zone so that the time zone issues are left  
to the Web apps.

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

Henri Sivonen
Received on Wednesday, 12 August 2009 07:05:39 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:49 UTC