[Webkit-unassigned] [Bug 35937] Support for HTMLProgressElement

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35937





--- Comment #17 from Darin Adler <darin at apple.com>  2010-03-11 11:07:19 PST ---
(In reply to comment #11)
> (In reply to comment #9)
> > If they are not [Reflect] they still do need to change the attribute you would
> > get with getAttribute, not just a hidden internal value.
> > 
> > HTMLInputElement has a max attribute. Are you sure this should be different in
> > this respect? To convince me, you need to demonstrate the expected behavior
> > with test cases and then show me either another browser or HTML5 specification
> > to make it clear the behavior it tests is correct.
> The reason I wanted to keep these 2 parameters as members is that otherwise,
> every time we paint the progress bar, we would need to convert them from
> strings and verify their validity. What do you think?

I think this is not a good design.

If you are caching values to make repaint efficient, you can do it differently
and better:

    1) The cached value should be in the renderer, not the DOM. It can be
recomputed as needed, cached, and the DOM can make calls to invalidate when the
parameters change.

    2) The cached value should be a single integer, not a pair of floating
point numbers, and this it can be used to avoid repainting when there are DOM
changes that don't affect the display. Thus an insignificant value change could
be optimized. Or a case where both value and max are changed, but the displayed
progress level does not change.

Whether there is a cache or not, however, is not the primary question here. The
question is observable behavior. If you set the max, it's important that
getAttribute("max") reflect the new maximum. And since setAttribute lets you
set the max attribute to any arbitrary string, the code needs to handle that.
You should have test cases showing how that works.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.