Update "undefined" definition in section 6.2.4 Value (within 6.2 Characteristics of States and Properties) #2172
Conversation
rahimabdi
changed the title
rahimabdi
added
the
editorial
There was a problem hiding this comment.
I also wonder if we need to make more clear that an "undefined" value does not mean the string "undefined", like you brought up in the meeting today (during new PR triage: https://www.w3.org/2024/05/02-aria-minutes.html#t02). Are you making a separate issue for this specifically? Depending on the solution there, it might affect this PR.
Commenting for now because I haven't made up my mind about whether it's ok to explicitly list the examples, or if we should just point people to the tables, I wonder what the other reviewers think.
| @@ -10013,7 +10013,7 @@ <h3>Value</h3> | |||
| <dt id="valuetype_tristate">tristate</dt> | |||
| <dd>Value representing <code>true</code>, <code>false</code>, <code>mixed</code>, or <code>undefined</code> values. The default value for this value type is <code>undefined</code> unless otherwise specified.</dd> | |||
| <dt id="valuetype_true-false-undefined">true/false/undefined</dt> | |||
| <dd>Value representing <code>true</code>, <code>false</code>, or <code>undefined</code> (not applicable). The default value for this value type is <code>undefined</code> unless otherwise specified. For example, an element with <sref>aria-expanded</sref> set to <code>false</code> is not currently expanded; an element with <sref>aria-expanded</sref> set to <code>undefined</code> is not expandable.</dd> | |||
| <dd>Value representing <code>true</code>, <code>false</code>, or <code>undefined</code> (not applicable). Unless otherwise specified, the default value for this value type is <code>undefined</code>. Note that the value <code>undefined</code> conveys a state- or property-dependent behavior including but not limited to lack of support (e.g., <sref>aria-checked</sref>, <sref>aria-pressed</sref>), equivalence with the value <code>false</code> (e.g., <sref>aria-multiselectable</sref>), behavior determined by the user agent (e.g., <sref>aria-hidden</sref>) or non-applicability (e.g., <sref>aria-selected</sref>). | |||
There was a problem hiding this comment.
Wow this really shows how inconsistent we have been with the use of undefined 😅
I wonder if we should include the examples, or leave it at Note that the value undefined conveys a state- or property-dependent behavior, consult the values table of the relevant state or property to understand the meaning of an undefined state or property.
| @@ -10013,7 +10013,7 @@ <h3>Value</h3> | |||
| <dt id="valuetype_tristate">tristate</dt> | |||
| <dd>Value representing <code>true</code>, <code>false</code>, <code>mixed</code>, or <code>undefined</code> values. The default value for this value type is <code>undefined</code> unless otherwise specified.</dd> | |||
| <dt id="valuetype_true-false-undefined">true/false/undefined</dt> | |||
| <dd>Value representing <code>true</code>, <code>false</code>, or <code>undefined</code> (not applicable). The default value for this value type is <code>undefined</code> unless otherwise specified. For example, an element with <sref>aria-expanded</sref> set to <code>false</code> is not currently expanded; an element with <sref>aria-expanded</sref> set to <code>undefined</code> is not expandable.</dd> | |||
| <dd>Value representing <code>true</code>, <code>false</code>, or <code>undefined</code> (not applicable). Unless otherwise specified, the default value for this value type is <code>undefined</code>. Note that the value <code>undefined</code> conveys a state- or property-dependent behavior including but not limited to lack of support (e.g., <sref>aria-checked</sref>, <sref>aria-pressed</sref>), equivalence with the value <code>false</code> (e.g., <sref>aria-multiselectable</sref>), behavior determined by the user agent (e.g., <sref>aria-hidden</sref>) or non-applicability (e.g., <sref>aria-selected</sref>). | |||
There was a problem hiding this comment.
I think it's actually even more complex than this :/. For example, el.ariaChecked = undefined is going to default to the same as false for most roles, only excluding option and treeitem. I think it may be better to not reference specific attributes here. Even for something like aria-pressed, if HTML ever ends up creating a toggle button element, then aria-pressed being undefined would not mean it is not supported. It might be simpler to stick with only one relatively safe example (e.g. the aria-expanded one in the original text), then clarify that for specific behavior, authors should check the tables for that attribute?
I do also think I agree with Valerie that it'd be helpful to clarify that undefined here refers to the value, which is set by either leaving the attribute off entirely or explicitly setting e.g. element.ariaExpanded = undefined, and is not equivalent to the string "undefined" in e.g. aria-expanded="undefined". What do you think?
There was a problem hiding this comment.
I think "undefined" needs to be yanked out of the <code> unless it explicitly means the string value "undefined".
As a user of the spec, this is what I might expect (fake example) so I could make sense of it:
Values include
yeah,nah,undefined, or undefined (by setting no value).
There was a problem hiding this comment.
@aardrian would it help if this section had a link to the IDL reflection section just after it, in addition to text clarifying that undefined is not the string + the (by setting no value) parenthetical?
It does get weirder, in that while you can explicitly set e.g. el.ariaThing = undefined, getting it returns null 🤷🏻♀️
There was a problem hiding this comment.
Thank you @aardrian @smhigley. As @spectranaut noted, it's currently ambiguous if the value undefined is the string "undefined" or undefined as in not present (or the value undefined). For example, see Note 2 under aria-hidden:
As of ARIA 1.3, aria-hidden="false" is now synonymous with aria-hidden="undefined".
I'm also observing that attr = "undefined" passes HTML validation (W3C Validator). Is this intended or a bug?
There was a problem hiding this comment.
@rahimabdi yeah, I believe that's a pretty straightforward mistake in the spec. I made a test page to output the browser-mapped values when ARIA attributes are set to the string "undefined", not set at all, or set programmatically to undefined: https://jsfiddle.net/pobwvgs9/
I checked it in Chrome, Edge, Safari, and Firefox on macOS and Windows (Safari only on mac), and all of them had different results for the string "undefined". The results for not-defined and programmatic = undefined values are what I'd expect & what matches the spec, while the string "undefined" are not.
My proposal would be that we go through the spec and remove any instances accidentally using string ="undefined", and add the clarification of the string not being the same as the value.
As an aside, I do get an error for ="undefined" in the W3C Validator, maybe they have some bugs in the attributes you tested?
|
Awaiting resolution on #2177 before updating PR with new For future work on this PR (and to address feedback above):
|
Closes #2156
This PR clarifies ambiguity in the varying behaviors of the
undefinedvalue for ARIA states and properties by providing a broader definition of "undefined" in section 6.2.4 Value.Preview | Diff