[whatwg] Spec comments, sections 3.1-4.7

[Tab Atkins Jr.]

On Wed, Aug 12, 2009 at 7:43 PM, Aryeh Gregor<Simetrical+w3c at gmail.com> wrote:
>> The point of <progress> is to add progress bars. Right now people hack
>> them in highly non-accessible ways using images and all kinds of crazy
>> things. This lets them avoid that while also getting a platform-native
>> look and feel.
>>
>> The point of <meter> is to make sure people don't abuse <progress> for
>> showing meters.
>
> I see.  I guess if you're using a screen reader or have images
> disabled, loading bars in some web apps would be completely absent.  I
> haven't noticed many progress bars on the web, but I guess if I used
> web apps other than Gmail more then maybe I'd see the need for this
> better.

You see them a lot more in the indeterminate form, as a 'spinner'
image or the like.  Of course, in that form an intelligent person can
just slap a "Loading..." @alt on the image.

I suspect, though, that there are a lot of places you currently don't
see a progress bar solely because it's a bit of a pain to do.  Any
place where progress is being made and displayed is a potential
candidate.  In one of the many intranet applications I write and
maintain for my company, I'm using <progress> right now to indicate
how far someone is in providing translations for our program.  I'm
waiting for browsers to catch up and actually display the element, but
in the meantime the fallback content is fine.

>> Yeah, styling of complex widgets like progress bars and other widgets is
>> somewhat dependent on us deploying a technology like XBL2. This is
>> something that we need to resolve in general. Once we have more
>> implementation experience, I expect we'll add some pseudo-elements and
>> define how the CSS model applies.
>
> Hmm, okay.  I don't think pretty much anyone will be using these
> elements until something like this is in place, though.  And possibly
> not after that if it's not easy enough to use.

Eh, it's not all that bad.  I'll be happy when I get XBL2, but until
then I'm fine with platform-native displays.  People hack around it
any case, by providing js libraries that transform your good markup
into more easily styleable markup (while maintaining accessibility).

> (I notice Gmail doesn't appear to even use form buttons.  Inspecting
> the Send button on this page shows a stack of several nested divs with
> various obscure classes and styles applied.  And, indeed, it seems
> like that's so they could change the appearance.)

That's because of GWT, actually, Google's homebrew Java library that
allows them to produce web content in Java.  I'm guessing it goes with
that approach because, even though it's basically impossible for a
human to understand, it's easier to machine-create with a stable
cross-platform appearance.

~TJ