Re: Seeking clarification for "undefined" as a literal value

Yes. The reason for undefined was that we could not assume that something was false by default - especially when in the case of a checkbox it could be “mixed”. 

If a property is required for a role it could be undefined. … You might be waiting for a server to tell you what the value is such as for preferences for a given user. 

I am a little confused about where you think the core-aam is unclear. 

Here is the current core-aam. The spec. clear states what the default values must be for states and properties and we have mappings associated with each value (which indicates the default):

http://rawgit.com/w3c/aria/master/core-aam/core-aam.html <http://rawgit.com/w3c/aria/master/core-aam/core-aam.html>

see aria-disabled. It indicates the default. The core-aam reflects the spec. 



Rich


Rich Schwerdtfeger




> On Jun 30, 2017, at 10:13 AM, Aaron Leventhal <aleventhal@google.com> wrote:
> 
> To be clear, I've never seen the "undefined" literal used in the real world, but it's good to get this right anyway.
> Are these correct:
> 
> - The author can explicitly set the "undefined" literal unless the property is required for the role.
> 
> - Setting "undefined" is equivalent to using the default value
> 
> - The default value itself may be "undefined" (like in aria-checked) or not (e.g. "false" for aria-disabled). Therefore, using "undefined"/undefined may result in undefined or a specific value depending on the property.
> 
> IMO the CORE-AAM could use more clarification. I don't find it covers these cases -- at least it's not clear to me.
> 
> Aaron
> 
> 
> 
> 
> On Fri, Jun 30, 2017 at 9:09 AM Joanmarie Diggs <jdiggs@igalia.com <mailto:jdiggs@igalia.com>> wrote:
> This does have interesting implications for (at least) aria-current.
> According to the ARIA spec:
> 
>     The aria-current attribute is an enumerated type. Any value not
>     included in the list of allowed values should be treated by
>     assistive technologies as if the value true had been provided. 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.
> 
> Thus the language is consistent with what Rich said, which means: If the
> value of aria-current is undefined (in the sense of a value having not
> been provided), the default of false applies, the element is not
> current, and the aria-current state must not be exposed. BUT, if the
> value of aria-current is "undefined" (a string literal), then we have a
> value not included in the list of allowed values, which should be
> treated as if aria-current were set to true (which means the
> aria-current state must be exposed by user agents).
> 
> The fact that the results of undefined and "undefined" are expected to
> be the complete opposite gives me a headache.
> 
> Also, looking at the Core AAM, aria-current is undefined is "not
> mapped":
> https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrentUndefined <https://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaCurrentUndefined>.
> I guess Joseph thinks undefined means not defined? (To be honest, that's
> how my brain works too.) And I guess we need to add both flavors of
> undefined to Core AAM?
> 
> --joanie
> 
> On 06/29/2017 01:47 PM, Rich Schwerdtfeger wrote:
> > Aaron,
> >
> > The spec. clearly states that (see aria-checked) that “undefined” is the
> > (default). If nothing is specified that is what is assumed the value is.
> > If the author has not set aria-checked on the role that supports the
> > aria-checked states then the default is undefined. When it says default
> > it is very clear. Had default not been indicated then I agree there
> > would be confusion.
> >
> > So, “undefined” is a valid value. … so is leaving the attribute off
> > altogether.
> >
> > In aria 1.0 here is a test example for aria-grabbed being set to
> > “undefined” from the Candidate Recommendation test harness:
> >
> > https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/roles-properties-global/roles-properties-global-main-aria-grabbed-undefined.html <https://dvcs.w3.org/hg/pfwg/raw-file/default/ARIA/1.0/tests/test-files/roles-properties-global/roles-properties-global-main-aria-grabbed-undefined.html>
> >
> > This passed candidate recommendation and therefor we had working
> > implementations.
> >
> > The important thing to remember is the default value. So, programmers
> > can leave it off altogether.
> >
> > Rich
> >
> >
> > Rich Schwerdtfeger
> >
> >
> >
> >
> >> On Jun 29, 2017, at 1:32 PM, Aaron Leventhal <aleventhal@google.com <mailto:aleventhal@google.com>
> >> <mailto:aleventhal@google.com <mailto:aleventhal@google.com>>> wrote:
> >>
> >> As I understand ARIA, a possible value of "undefined" means the
> >> attribute is not present. If undefined is also the default, then a
> >> value of "" is equivalent. However, I would not expect a user agent to
> >> process the literal string "undefined" as undefined.
> >>
> >> Was there an expectation somewhere that the literal string "undefined"
> >> should be treated as attribute not present?
> >>
> >> I feel that the ARIA 1.1 spec could be more clear here:
> >>
> >> 'The "undefined" value, when allowed on a state or property, is an
> >> explicit indication that the state or property is not set. The value
> >> is used on states and properties that support tokens, and the
> >> "undefined" value is a string that is one of the allowed tokens. It is
> >> also used on some states and properties that accept true/false values,
> >> when "undefined" has a different meaning than "false".'
> >>
> >> Perhaps when undefined is discussed it should not be put in quotes --
> >> to programmers this means literal string. Mostly, CORE-AAM does this,
> >> but it does have one place under disallowed values that discusses
> >> "undefined" as a literal string. It does not, however, discuss the
> >> "undefined" literal as an allowed value.
> >>
> >> Can someone provide more clarity for our implementation? I'd like to
> >> see more clarity in both specs.
> >>
> >> Thank you,
> >>
> >> - Aaron
> >>
> >>
> >>
> >
>