[Bug 11937] Progress element should be indeterminate if the value attribute isn't a valid float

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11937

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #6 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-05-09 22:49:49 UTC ---
(In reply to comment #5)
> > Well don't forget that all those cases where value="" is present but you're
> > saying should be treated as indeterminate are cases where the element is
> > invalid anyway, so authors really shouldn't be doing any of them anyway.
> 
> But they are going to do that :)

Sure, but probably not intentionally. I don't see why we'd try to second-guess
what they mean here; they are as likely to want a value=0 determinate bar as an
indeterminate one, IMHO.


> > Re :indeterminate, it seems easier to define :indeterminate just as a matter of
> > whether an attribute is present or not than require that the UA parse the
> > attribute to determine it.
> 
> We are already requesting that kind of stuff for :in-range and :out-of-range
> which only apply if min and max have a valid value. In addition, for the ease
> of implementation, .value is a double so it's very likely that the UA knows if
> the value is a valid double or not.

Granted.


> > Plus, Opera and WebKit already do this...
> 
> The progress element isn't used that much and Opera and Webkit implementations
> already have a few differences with the current specifications. I do not think
> we should worry about that.

I do worry about it. Nobody is bug free, but adding more bugs isn't a way to
get to a bug-free state.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

> Actually, now that :indeterminate is in the specifications, I wonder why we
> still need the current behavior. You said it was useful to check if the
> progress is indeterminate but now, why is it? I do not believe changing the
> specs would cost anything at this point so being conservative seems worthless.

I don't see any value in the change you are asking for. It doesn't simplify
life for authors, it doesn't simplify life for implementors, it doesn't
simplify life for spec writers, and it isn't more "pure". There are no use
cases for it, the cases where it would happen are all cases that are
non-conforming anyway, it doesn't add any new features, it doesn't seem to
solve any problems... I just don't see the point. It's not a matter of being
conservative, it's just that I don't see what's wrong with what we have now.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 9 May 2011 22:49:52 UTC