W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2009

[Bug 7711] The "strong native semantics" are worded very similarly -- but not quite the same -- for input type=Number, input type=range, and progressbar.

From: <bugzilla@wiggum.w3.org>
Date: Wed, 30 Sep 2009 07:32:13 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1MstfZ-0003SR-QW@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7711


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

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




--- Comment #4 from Ian 'Hixie' Hickson <ian@hixie.ch>  2009-09-30 07:32:13 ---
> So the value of <input type=number>six</input> is implementation-defined;
> browsers are allowed to interpret it as 6 (or 43.7) if they wish, and
> compatibility is not expected?

No, not at all. There is no value (more precisely, the value is the empty
string). However, there's no numeric value to convey to the AT using
aria-valuenow; if this was an explicit HTML DOM we were talking about, the
element would have no aria-valuenow attribute.


I haven't added an explicit note that the aria-valuenow attribute is omitted in
the cases you mention, because _everything_ is omitted unless stated otherwise
explicitly. I don't really see how to make that clearer without just hitting
the reader over the head with it, as it were, and that would just make the spec
even more painful to read.


-- 
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 Wednesday, 30 September 2009 07:32:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:01 UTC