Meeting minutes
New Issue Triage
spectranaut_: Will handle the prettier error in the editors meeting
spectranaut_: there is some discussion and a suggestion
bryan: should probably be discussed
spectranaut_: would be easier to discuss from a PR If there is a clear direction
spectranaut_: aaron provided the mappings
spectranaut_: might be a good first issue for someone who wants to get involved in mappings
smockle: Would like to take that on
Last new issue is a doc issue. Rahim assigned himself
<discussion of respec>
New PR Triage
spectranaut_: would like reviews - is editorial and a good small issue to review
Rahim & Curt volunteer to review
scott: follow on to not using the title attribute for name prohibited. This required to create a new grouping in the HTML-AAM Acc namre computation
scott: added a prohibited name section and some revisions to other sections
scott: would like implementors to push ahead with non-landmark footer/header roles before adding those to the prohibitied section
spectranaut_: adding Rahim
scott: suggest aaron
spectranaut_: will result in implementation changes so should ask implementors
spectranaut_: added reviewers
OliverH: clickable can be added to anything
spectranaut_: this is triage so we're not opening that now
WPT Open PRs
spectranaut_: no new ones
Deep Dive/TPAC planning
spectranaut_: lets go through the list and see if we still need to deep dive them
spectranaut_: lots of discussion
giacomo-petri: still needs discussion
giacomo-petri: will try to organize to see if we can discuss during TPAC
jamesn: can we F2F candidate this one?
spectranaut_: are folks interested in discussing this
sarah: is the topic flowto or how to make flowcharts work
scott: flowto will not really solve that problem
sarah: a bunch of work needs to be done up front
spectranaut_: lets remove deep dive issue as no one is pushing it forward
remove deep dive from this
also remove deep dive from w3c/
remove this too
Clarify spec treatment of value "undefined" (i.e., as equivalent to invalid value, initial condition for state/property usage)
Rahim: link to deep dive minutes
Rahim: in the issue - a couple of specifics here
Rahim: Is an invalid value treated the same thing as an undefined value?
Rahim: Should the spec explicitly state that the undefined value/string is not an initial condition for authors to use (e.g., aria-expanded="undefined") in expectation of a downstream ARIA state change?
spectranaut_: w3c/
spectranaut_: is an invalid string the same as undefined
spectranaut_: what does undefined mean for a switch?
spectranaut_: that is the only place invalid is discussed
keithamus: a little confused - are we talking about "undefined" or the JS primitive of undefined?
keithamus: is this IDL reflections or HTML attributes
Rahim: I think both
Rahim: multiple ways to set these things
keithamus: there is no undefined primitive in HTML - using setAttribute always a string
IDL is subtly different
keithamus: how the HTML spec deals with enumerated attributes
Rahim: there is no clarity about the invalid value default and missing value default
keithamus: the attribute reflection rules around IDL mapping
keithamus: effectively 1110 needs a bit of a cleanup of the various IDLs - once we go through each attribute then can map out the invalid and missing states. The DOM string IDL reflection then becomes valid
Rahim: undefined value and string are not the same thing
sohara: that part of the spec was written before IDL existed for aria
sohara: we should just know that undefined as a string couldn't be that
sohara: we need to investigate what browsers are doing with the undefined string right now
keithamus: undefined as an attribute maps to something useful in aria?
sarah: have done the investigation
sarah: there are now a bunch of issues but will find it
sarah: the string undefined is not being treated as the value undefined
sohara: does the undefined string do anything useful in aria?
sohara: noticed that it at least primed the browser
sohara: if i change the state of a button with expanded undefined then the browser would expose the state change
sohara: very corner case where found it actually had some implementation practicallity
<smockle> https://
<smockle> https://
smockle: undefined behaviour in different browsers
<sarah> keithamus you're right, setAttribute + undefined does set the string 'undefined' for the aria-* attributes I tested, I think I was mixing it up with IDL reflection
keithamus: undefined to prime the browser. Browsers have a concept if something exists on a node. It is reasonable to put that in the bucket of these are invalid states. You could probably prime the browser with foo
<sarah> i.e. el.setAttribute('aria-expanded', undefined) results in <el aria-expanded="undefined">, and el.ariaExpanded = undefined not
Rahim: wanted to add that a confusion was it wasn't clear how it was being specificied - markup vs setAttribute vs IDL - authors may expect the same behaviour
keithamus: IDL is the special case as JS has a concept of undefined but HTMl doesn't
keithamus: assumes strings and puts in the quotes for you
keithamus: HTML and setAttribute assume stringzs
keithamus: if you set null in IDL will have a missing value
Rahim: HTML reflection is much clearer
keithamus: HTML IDL reflections are very clear. The ARIA mixin
keithamus: TLDR we need to define missing and invalid value defaults for each of the attributes
keithamus: we may need to define a custom algorithm for some of the IDL mappings
sarah: string vs value undefined - not seeing any difference in actual mapped APIs
sarah: not seeing any different for invalid value vs undefined
spectranaut_: are we getting closer to an answer
sarah: agree with keith that the string is an invalid value not a missing value
<Rahim> Keith and I were assigned this: w3c/
Rahim: believe this will cover the issue we are discussing
keithamus: going to be difficult to achieve due to existing code which may depend on this behaviour
spectranaut_: will mark this as a duplicate of 2281
<spectranaut_> jamesn: it sounds like a use case that there might be errors from validators on
jamesn: invalid values would fail validators for the priming use case
<spectranaut_> jamesn: suggests specing it