Re: <progress> element and attributes vs. content

On Fri, Aug 14, 2009 at 12:29 PM, Adrian Bateman<adrianba@microsoft.com> wrote:
> On Friday, August 14, 2009 6:07 AM, Smylers wrote:
>> Ian Hickson writes:
>>
>> > On Fri, 7 Aug 2009, Adrian Bateman wrote:
>> >
>> > > Personally, I'd prefer to remove the element content parsing and
>> > > always make the progress bar rendering depend on the attributes.
>> >
>> > I guess we could do that; what do other people think?
>>
>> When I gave a conference presention introducing HTML 5 the content
>> parsing of <progress> was one of two points to get spontaneous applause
>> from the audience (the other was the HTML 5 doctype).
>>
>> The audience were programmers, so I guess the notion of 'don't repeat
>> yourself' appealed -- not having to specify the same thing in both the
>> fallback text and the attributes, and risking one being updated without
>> the other.
>
> The comment attributed to me was actually written by Henri but I do agree with it.
> http://lists.w3.org/Archives/Public/public-html/2009Aug/0573.html
>
> Is the progress element intended to draw a control and also show the contained text? I presume not. We often see the Windows progress/activity bar annotated with a percentage shown as text and I suspect developers will want to achieve something similar on the web.
>
> If the progress element doesn't draw the contained text then web developers may often want the value in mark-up after the element. They will then have to deal with the case when the browser doesn't support the progress element, is showing the contents as fall-back text, and they don't want the text to display twice.

Well, we don't have any UA experience with the element yet, but I see
a lot of progress bars on the desktop display either the percentage or
the explicit value/max on top of the bar.

As Ian said, though, we'll be able to address this stuff properly
either through new CSS pseudoelements or through a transformative
language like XBL2.

> I'm also concerned about how fragile the content parsing rules may turn out to be in practice.

I first used <progress> just a short while ago.  I was putting in some
text that showed progress through something in an intranet app I was
coding, and remembered <progress>.  The text I was already using is
perfectly handled by the parsing rules without a single change.  I've
subsequently looked at other progress displays in my apps, and every
one of them can be parsed successfully.

This is anecdotal, but to me it appears that they're rather robust, at
least for English.

> I agree with Henri - I would also prefer to remove the content parsing and have the display based only on the attributes. I think the notion of only updating the content is a nice idea but may actually make things more complex in practice. If the progress element only depends upon the attributes, web developers can decide whether the control is just providing extra information (where it doesn't require any fall-back text) or whether then need to include fall-back. They can also decide whether they want the fall-back text to update with the progress control.

Webdevs can already make that choice, though - as you indicate in your
examples ([snipped]), you can always just write an empty <progress>
and put text next to it if the progress bar is only intended to
provide a fancy display rather than vital information.  There's
nothing harmed by parsing the fallback; on the other hand, *not*
parsing the fallback makes it much more likely that devs like me will
set the fallback once, then forget about it and only update the
attributes later.

~TJ

Received on Friday, 14 August 2009 17:47:16 UTC