[whatwg] Status bars and progress indicators

On Mon, 22 Nov 2004, Matthew Thomas wrote:
> 
> If UAs don't already return alternate text of child elements as part of 
> textContent, I suggest filing bugs on those UAs. I see nothing in the 
> DOM 3 spec saying they shouldn't, and not to do so seems to breach the 
> spirit of the HTML spec. But you'd know more about that than I do.

It seems to breach DOM3 Core:

   http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-textContent

...but I think we should introduce a new DOM attribute that returns the 
"semantic" textContent of elements, in particular for dir="", <bdo>, and 
<img alt="">. See the note in:

   http://whatwg.org/specs/web-apps/current-work/#the-textcontent

I imagine I'd change the spec to use this attribute throughout instead of 
using textContent where it uses it now (and for things like <progress>).


On Mon, 22 Nov 2004, viktor wrote:
>
> the code:
> 
> <progress type="bar" name="loaderA" action="page_to_load.php"
> direction="horizontal" maxvalue="100" minvalue="0" />
> 
> type:
>    bar
>    status-bar
>    numeric
>    numeric-bar
>    numeric-status
>   name:
>    item name reference
>   action:
>    page, file, behavior to attach the progress meter
>   direction:
>    horizontal
>    vertical
>   maxvalue
>    maximun value
> 
> min value
>    minimun value
> 
> the pages can handle some type of meta tag or server header response attached
> to the name of the progress meter      <meta progress="loaderA" value="50" />
> 
> with dynamic lenguajes can handle like this:
> 
> <?php
> header("progress:loaderA:50");
> ?>

This seems somewhat more complicated than I would like. It also seems a 
bit too presentational -- for complete control over what the progress bar 
looks like, I'd feel more comfortable pointing authors to XBL or CSS.

Could you elaborate what you mean regarding the dynamic header part? Why 
would DOM manipulation not be enough?


On Tue, 23 Nov 2004, Brad Fults wrote:
> >>
> >> <indicator id="engineTemp">
> >>   <slice id="engineTempCold" min="0" max="140" />
> >>   <slice id="engineTempGood" min="141" max="220" />
> >>   <slice id="engineTempHot" min="221" /> </indicator> ...
> >> indicator#engineTemp { indicator-style-type: vertical-bar } 
> >> indicator#engineTemp slice#engineTempCold { background-color: #00f } 
> >> indicator#engineTemp slice#engineTempGood { background-color: #0f0 } 
> >> indicator#engineTemp slice#engineTempHot { background-color: #f00 }
> >
> > This seems like overkill for what is essentially just a little bar to 
> > show the relevant of a search result or the percentage use of 
> > someone's quota.
> 
> The point is that whether or not showing search result relevance or a 
> user's quota usage is 90% of the cases where an indicator is needed, 
> there is no reason to limit a widget at design time to 90% of its actual 
> scope.

There's one reason, which is simplicity. Having one element is orders of 
magnitude simpler to understand, use, and implement than a multi-element 
design. (As an example, consider that <select> has to be handled specially 
in the HTML _parser_, whereas something like <output> just falls out of 
the default handling rules.)


> There are certainly needs for an indicator widget where there are 
> varying degrees of importance and/or levels of values within the 
> indicator, hence the "slice".

Are there? I'm not sure what the use cases for that are.

The main use cases I have heard of (and seen on the Web) so far are:

  * Showing hit relevancy on a search result page.
  * Showing relative "pagerank" or equivalent.
  * Showing a review score (e.g. IMDB review average score).
  * Showing quota status (e.g. mailbox % free).
  * Showing relative traffic levels on an analytics page.
  * Showing relative weapon power levels in a game.

In all of these cases, there are at most three segments: low, medium, and 
high, and in fact in all cases you could get away with having at most two 
segments (i.e. just having a "low" or "high" marker).


> Putting levels as arbitrary as "good", "bad", and "medium" is 
> irresponsible and doesn't take into account other valid uses for the 
> widget, nor future considerations.

What are these use cases? Do they form the 90% case, or the 10% case?


> > On a gauge it is very common to see a line beyond which the indication 
> > is "bad" (or "low", or "high", whichever). I don't think I've ever 
> > seen a gauge with a level beyond which the result was "shoes" or 
> > "Bolivia".
> 
> The point was to highlight the arbitrariness of "low" and "high" or 
> "good" and "bad". I can immediately think of cases where a heat 
> indicator would have at least five levels of values that need to be 
> separated.

What would those five levels be? Why wouldn't two levels be enough?


> There are hundreds of other possibilities and if an indicator widget is 
> to be built, it should be generic enough to handle all logical needs for 
> indication.

No, it should be simple enough to be implemented and used. We're not 
trying to address all cases, we're trying to address most cases.

Given that it is impossible to design a feature in such a way that it 
addresses everyone's needs at once, we should design it in such a way that 
it addresses the majority of cases, and does so in a way that it is simple 
enough for users not to get wrong.


> This is very much the same reason that you wouldn't see SVG specifying 
> an element called <circle-with-2px-red-border-and-a-caption-on-the-right 
> />.

Using SVG as a source of ideas and arguments for good language design is 
probably a mistake.


On Tue, 23 Nov 2004, Brad Fults wrote:
> 
> My proposed solution (or direction toward a solution) is no harder to 
> implement.

Your solution has multiple elements. The alternative has one element. 
There is an order of magnitude increase in complexity (in the spec, in the 
implementation, and in usage) when you start allowing or requiring more 
than one element to achive an effect.


> It's a difference between hard-coding a 2- or 3-level indicator and 
> making one that can have an arbitrary number of children. This isn't 
> rocket science at all, but rather something that's already been done in 
> many other parts of HTML (e.g. select/option).

<select>/<option> is _extremely_ complicated to implement. It has its own 
special hard-coded HTML parse mode, for instance.

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

Received on Monday, 20 March 2006 21:13:41 UTC