Re: Ensuring "undefined" means undefined for aria-current

Maybe we can also put in some globally applicable text that the value
"undefined" in a token attribute is only ever allowed to mean undefined.
This would future proof us against future attributes with the same problem.

Aaron



On Mon, Jul 24, 2017 at 12:52 PM Rich Schwerdtfeger <richschwer@gmail.com>
wrote:

> +1
>
> Rich Schwerdtfeger
>
>
>
>
> On Jul 24, 2017, at 12:20 PM, Joanmarie Diggs <jdiggs@igalia.com> wrote:
>
> Hey all.
>
> As I pointed out on the list [1], if aria-current is undefined because
> no value is specified, aria-current is false. But if aria-current is set
> to the value "undefined", aria-current is true. It was never (ever,
> ever) intended for undefined and "undefined" to be opposite values. And
> normally they aren't. We just have an oddball case with aria-current
> because the spec states the following for aria-current:
>
> "Any value not included in the list of allowed values should be treated
> by assistive technologies as if the value true had been provided."
>
> It is my proposal that we fix this oversight by making the following
> change:
>
> Existing text: "If the attribute is not present or its value is an empty
> string, the default value of false applies and the aria-current state
> MUST NOT be exposed by user agents or assistive technologies."
>
> Proposed text: "If the attribute is not present or its value is an empty
> string or <code>undefined</code>, the default value of false applies and
> the aria-current state MUST NOT be exposed by user agents or assistive
> technologies."
>
> I believe the above changes are editorial because surely no one thinks
> the string literal value "undefined" should mean the complete opposite
> of an undefined value. (Right? Right?? <smiles>)
>
> Feedback encouraged.
> --joanie
>
> [1] https://lists.w3.org/Archives/Public/public-aria/2017Jun/0058.html
>
>
>