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

<meter> and <progress> (was RE: Implementor feedback on new elements in HTML5)

From: Adrian Bateman <adrianba@microsoft.com>
Date: Tue, 1 Sep 2009 08:29:31 -0700
To: Maciej Stachowiak <mjs@apple.com>, HTMLWG WG <public-html@w3.org>
Message-ID: <9EF3B2C14D3B794EB33689E0E1BDFEEA3EF9FFC999@NA-EXMSG-C120.redmond.corp.microsoft.com>
On Monday, August 31, 2009 9:46 PM, Maciej Stachowiak wrote:
> - New interactive controls: <meter>, <progress>
>   These elements seem useful and a good idea. These controls are useful
> in native UI and often get hand-rolled by JavaScript libraries. We would
> like to expose a default native look, but with full author stylability
> for these. The only odd requirement is the use of inline text content in
> the elements to represent the state of the control. Specifying inline
> textContent may be a clever way to pass the initial state, but it seems
> very clunk as an interface for dynamically updating the state of the
> progress bar. Using the max and value IDL attributes of <progress> seems
> like it would be much easier for authors, and it seems like a problem
> that these only reflect the markup attributes and not the full state of
> the control (if the state is currently defined by text content). Likewise
> for the 6 attributes on <meter>. Assembling up to 6 numbers into a
> textContent string, which then does not cause the convenient DOM
> attributes to update, seems very clinky.

As I've mentioned a couple of times, I don't support the parsing of the content of progress and meter elements. This is likely to be fragile in practice and a bug trap for web developers. It is likely that most of this content will be generated by script (either client or server side) and I am concerned that it will be easy for web developers to accidentally break working code without realising during maintenance.

I don't think the parsing of the content is worth the added complexity either for implementors or for web developers. The attributes are simple and predictable.


On Monday, August 31, 2009 10:30 PM, Maciej Stachowiak wrote:
> On Aug 31, 2009, at 10:14 PM, Jonas Sicking wrote:
> > I think it's a very good point that these two elements need to be
> > author stylable in order to become useful for authors. I suspect
> > people in many cases won't use them until they can be styled. Would be
> > great to see a proposal from apple on CSS properties for styling
> > these.
> >
> > I am however yet unconvinced that <meter> will really be used enough
> > to warrant inclusion in the spec and implementation in UAs. It has
> > been pointed out to me that some platform toolkits does indeed include
> > a similar feature, but I can't really think of many websites or
> > applications where I've seen them used.
> >
> > Also, as someone not from Liberia, Burma or the United States, I find
> > the name very confusing. I usually associate the term 'meter' with the
> > unit of length. In fact, the first time I saw the element I thought it
> > was more related to <time> than to <progress>, i.e. some way to mark
> > up distances.
> 
> I think <progress> is much more generally useful. Apple's Mail uses the
> Cocoa/AppKit equivalent of the <meter> element in the search interface.
> This may give me a misleading impression of how generally useful it is to
> applications.

<meter> does seem like a corner case - I'm also not convinced it would be broadly used. <progress> seems like a reasonable control - it supports both the progress and activity use cases that Windows also provides. I agree with Jonas that it's unlikely to get broad adoption without styling support.

Cheers,

Adrian.
Received on Tuesday, 1 September 2009 15:32:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:48 GMT