According to the specs, a progress element can be indeterminate. It might be interesting to let the authors access indeterminate progress elements given that they might want to style them differently.
Created attachment 512129 [details] [diff] [review]
For what it's worth, this is going to conflict with the various patches in bug 313351, and bug 598833. I can handle merging if this lands first, I guess, but just wanted to give you a heads-up.
And wait. Why do you need that AfterSetAttr gunk?
(In reply to comment #3)
> And wait. Why do you need that AfterSetAttr gunk?
Eh, I don't indeed: indeterminate state only depends on one attribute's value. This should make the merge issue smaller. Thanks for the noticing ;)
Created attachment 512147 [details] [diff] [review]
Updated patch. Boris, you won the right to review it :)
Comment on attachment 512147 [details] [diff] [review]
s/determinated/determined/ and looks good. And yeah, now you're only conflicting with code I haven't written yet. ;)
I wonder if we shouldn't use :-moz-indeterminate instead of :indeterminate here.
I've open a bug against HTML specs to have it specified:
Though, I should probably send an email somewhere to ask for a better specification of the indeterminate pseudo-class in CSS. I wonder if CSS3-UI couldn't simply override what Selectors say (it doesn't really say anything actually, the only specs is a Note....).
David, what is your feeling about comment 7? Boris is ok to not prefix it (according to our IRC conversation).
Backed out in http://hg.mozilla.org/mozilla-central/rev/dd9ba28d2bd9 to resolve bug 655860.
The regression wasn't caused by these patches. Re-landed:
I'm ok with unprefixed.
Also listed on Firefox 6 for developers.