ARIAMixin has many integer attributes with string types and uses DOMString? incorrectly

[annevk]

It would be nicer if these were reflected as numbers. E.g., aria-level.

cc @alice @domenic

[domenic]

If we do this (we probably should), then a choice needs to be made for each one, between the different types of reflection:

• long
• long limited to only non-negative numbers
• unsigned long
• unsigned long limited to only non-negative numbers greater than zero
• unsigned long limited only to non-negative numbers greater than zero with fallback
• unsigned long clamped to the range [min, max]
• double
• unrestricted double
• double limited to numbers greater than zero
• unrestricted double limited to numbers greater than zero

Probably don't consider the long ones.

[alice]

I have a vague memory of discussing this and concluding that string reflection was the way to go, but I don't remember any details. @cookiecrook may remember?

[alice]

Listing out non-string types per the ARIA value types (not including token types or true/false/undefined):

• aria-atomic (true/false, i.e. empty string is invalid but missing value default is false)
• aria-busy (true/false)
• aria-colcount (integer >= -1, although zero would be weird)
• aria-colindex (integer >= 1)
• aria-colspan (integer >= 1 - this is weirdly inconsistent with aria-rowspan)
• aria-disabled (true/false)
• aria-level (integer >= 1)
• aria-modal (true/false)
• aria-multiline (true/false)
• aria-multiselectable (true/false)
• aria-posinset (integer >= 1)
• aria-readonly (true/false)
• aria-required (true/false)
• aria-rowcount (integer >= -1)
• aria-rowindex (integer >= 1)
• aria-rowspan (integer >= 0 - weirdly inconsistent with aria-colspan)
• aria-setsize (integer >= -1)
• aria-valuemax (integer)
• aria-valuemin (integer)
• aria-valuenow (integer)

The true/false ones are interesting, since they're almost but not quite boolean.

[annevk]

From Domenic It sounded like there was a preference for true/false values to be enumerated values so they can be extended in the future. I kinda wish they would not have used true and false as values then, but so be it. So those probably have to remain strings, though limited to known values would be nice.

HTML's colSpan and rowSpan are unsigned long and colSpan there also has to be at least 1, whereas rowSpan is at least 0. I don't really know the background.

(It seems HTML uses long (for allowing -1) and unsigned long (when non-negative) pretty consistently.)

[alice]

Chatting with @cookiecrook about this just now - he is going to do some research and try to remember why we went with string reflection originally.

[cookiecrook]

Initial experimentation was in AOM threads.
WICG/aom#120

More meaty, long history thread inside ARIA tracker starts here:
#691 (comment)

Most relevant comment is this one:
#691 (comment)

Excerpt:

Changed all long values to DOMString, since long cannot be nullable.
Changed all double values to DOMString, since double-to-string conversion is lossy and imprecise.

And we pulled a few more IDL props prior to shipping ARIA 1.2 to make way for element reflection.
#834

[annevk]

Why is long not nullable? Pretty sure it is.

And reflection of double to string is defined in HTML and used by a large number of features. The rationale given doesn't seem like a good reason to establish a new API pattern.

[domenic]

There is no reflection for nullable long defined in HTML. Instead, when the attribute is not present, a default value is used. (Usually 0 or -1.)

I agree that ARIA sticking to that would be better than inventing a new convention.

[annevk]

As I mentioned on IRC, there's no nullable string for reflection either (other than for enumerated attributes), so if that's the argument I'm confused.

[cookiecrook]

@domenic wrote:

I agree that ARIA sticking to that would be better

Sticking to what would be better? String reflection as-is?

[domenic]

No, sorry, sticking to using default values (like 0 or -1), like all other reflected numeric HTML attributes do.

[cookiecrook]

Ok then, let's work out the edge cases.

1. As Alice mentioned, some ARIA attrs are true booleans (@aria-modal), others are true/false/mixed, and still others are true/false/undefined, where the unset value is different that either true or false. One example is @arial-pressed. When used on role="button" the existence of the attribute means it's a toggle button in a pressed (true) or unpressed (false) state. The undefined default (absence of the the attr) means it's a standard non-toggle button. (This might be superseded by the next item.)

2. Several of the aria attributes are enumerable token values: such as @aria-invalid. Its values are currently true, false, spelling, and grammar though this list is intended to be expandable in future versions of ARIA. If I understand correctly, this would require defining new IDL value types as I attempted in the original issue here: Add ARIA property string reflection on Element #691 (comment)

3. Many of the number values (@aria-valuenow, etc.) are not integers, but floating point doubles. Double-to-String reflection is lossy due to floating point math. Is this acceptable? Perhaps, but it will surprise some web authors.

4. Most ARIA attributes can be adopted by the host language as providing equivalent semantics to the host language attribute. @required and @aria-required is an example. A conflicting value between the two results in UA resolution, based on some rules in the host language and ARIA. IIRC, a reflecting these as something other than String may result in both reflecting the same value... Is this acceptable, and if so, is there existing precedent in IDL?

[domenic]

1. true/false/mixed and true/false/undefined sound like enumerated attributes to me, so yeah, subsumed into (2).

2. We have a model for reflecting enumerated attributes. This doesn't require a new IDL value type; DOMString is good for that.

3. Double-to-string reflection is well-established on the web platform with a number of existing examples in HTML. This is the main issue at hand, I think.

4. I'm not sure I understand this, but I'll try to answer. The reflection from typed JS properties (aka IDL attributes) to HTML attribute strings is a bidirectional, mechanical process, that is performed independently for any two attributes. The reflection doesn't change behavior because two attributes are related. And the types of the JS properties (IDL attributes) being strings versus numbers or any such doesn't change this.

[cookiecrook]

The reflection doesn't change behavior because two attributes are related. And the types of the JS properties (IDL attributes) being strings versus numbers or any such doesn't change this.

Okay. I recall there were some cases where the existence of the ARIA attribute would "win" over the native, non-nullable boolean, but even if I recall that correctly, I suppose we could set those instances as true/false/undefined enumerables rather than true/false booleans. I think that may resolve any conflict.