[whatwg] Status bars and progress indicators

Ian Hickson wrote:
> 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).

mmm, I've seen a *lot* of gauges that have a "low" threshold and a "critical"
threshold. I don't know what you mean by "get away with".

I agree that Mikko's points about "good" and "bad" are important.

To set the scale for a three-segment gauge you need to know
   - min value
   - max value
   - lower threshold
   - upper threshold
   - optimum

Min/max set the range, the thresholds segment it, and the optimum tells
you where it's green, with red and orange (if applicable) falling out from

+1 for <gauge> over the rest. It's both accurate and precise imo.

> On Tue, 23 Nov 2004, Brad Fults wrote:
>>My proposed solution (or direction toward a solution) is no harder to 
> 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.

I wonder how much of that is due to the optional end tag on <option>...
The "order of magnitude increase in complexity" due to multiple elements
strikes me as accurate, though.

Just as a note on presentation requirements for CSS or XBL or whatever:
this thing needs to handle graphical 3.5/5 stars and things like that.


Received on Monday, 20 March 2006 22:06:08 UTC