IRC log of aria on 2021-10-28
Timestamps are in UTC.
- 14:02:32 [RRSAgent]
- RRSAgent has joined #aria
- 14:02:32 [RRSAgent]
- logging to https://www.w3.org/2021/10/28-aria-irc
- 14:02:34 [Zakim]
- RRSAgent, make logs Public
- 14:02:35 [Zakim]
- please title this meeting ("meeting: ..."), jamesn
- 14:02:41 [MURATA]
- present+
- 14:03:13 [kzms2]
- kzms2 has joined #aria
- 14:03:19 [jamesn]
- meeting: proposed two ARIA roles for ruby
- 14:03:24 [jamesn]
- chair: JamesNurthen
- 14:04:43 [Breixo_Pastoriza]
- Breixo_Pastoriza has joined #aria
- 14:05:02 [cyns]
- cyns has joined #aria
- 14:06:33 [jamesn]
- recording the presentation portion of the meeting so no scribing for this part
- 14:07:17 [plh]
- plh has joined #aria
- 14:07:35 [plh]
- present+
- 14:08:24 [aaronlev]
- present+
- 14:08:29 [jamesn]
- present+
- 14:09:02 [cyns]
- present+
- 14:09:12 [jcraig]
- present+
- 14:10:18 [jcraig]
- link for the two GitHub issues mentioned?
- 14:11:22 [jamesn]
- https://github.com/w3c/aria/issues/1619
- 14:11:35 [jamesn]
- https://github.com/w3c/aria/issues/1620
- 14:15:50 [melsumner]
- melsumner has joined #aria
- 14:20:06 [jcraig]
- q+
- 14:21:56 [jamesn]
- scribe: aaronlev
- 14:22:40 [jcraig]
- aaronlev: chrome 89 reads base text.
- 14:22:52 [aaronlev]
- aaronlev: Are there any cases where you would want to just read the base text?
- 14:23:55 [aaronlev]
- murata: 20% of the time (for interlinear nodes), read both
- 14:24:05 [aaronlev]
- murata: other 80% read only base text
- 14:24:19 [aaronlev]
- aaronlev: why not text above, <rt>, if it has more pronunciation info?
- 14:24:34 [jamesn]
- link to slides - https://onedrive.live.com/view.aspx?resid=4106E423DCEF597E!284274&ithint=file%2cpptx&authkey=!AILL3MjWadzvv9I
- 14:24:56 [aaronlev]
- murata: reading phonetic ruby can be dangerous
- 14:25:37 [jamesn]
- q+
- 14:27:44 [aaronlev]
- jcraig: agrees with fantasai about exploring native html attribute, e.g. rt="phonetics"
- 14:28:05 [aaronlev]
- jcraig: would missing attribute be sufficient to assume the inverse value?
- 14:28:23 [aaronlev]
- jcraig: or should missing me undefined, and a guess would be best
- 14:28:39 [aaronlev]
- MURATA: have not analyzed best approach
- 14:29:05 [aaronlev]
- MURATA: do not yet have opinion on this question
- 14:29:09 [aaronlev]
- q+
- 14:29:11 [jamesn]
- ack jcraig
- 14:30:10 [aaronlev]
- jcraig: in ARIA this might be something like aria-use-for-pronunciation
- 14:30:40 [aaronlev]
- jcraig: it feels like it should be a native attribute
- 14:31:21 [aaronlev]
- jamesn: would you expect something different to be exposed to ATs based on the semantic?
- 14:31:25 [aaronlev]
- jamesn: how is Braille affected
- 14:31:47 [aaronlev]
- MURATA: in the case of non-phonetic ruby, the AX tree should have both texts
- 14:32:28 [aaronlev]
- jamesn: the primary use is for different TTS rather than different meaning
- 14:32:34 [jcraig]
- q+ to respond to "accessibility tree should display the phonetic difference"
- 14:32:55 [aaronlev]
- MURATA: i just need a standard mechanism
- 14:33:04 [aaronlev]
- jamesn: not sure role is correct, i recommend an html attribute
- 14:33:09 [jcraig]
- ack jamesn
- 14:33:10 [cyns]
- +1 to html attribute
- 14:35:17 [aaronlev]
- aaronlev: chrome uses aria-details, which puts control in users hands today
- 14:35:44 [aaronlev]
- aaronlev: we could use role="note" on <rt> to indicate it's non-phonetic, and this seems to be sensible in a semantic sense
- 14:36:09 [jamesn]
- ack aaronlev
- 14:36:42 [jamesn]
- q+ to ask if there is ever a case to ONLY read the ruby
- 14:36:47 [jcraig]
- Ruby for the speaker https://www.w3.org/TR/ruby/
- 14:36:58 [aaronlev]
- juanita: joining late, gets description of the different types of ruby, asks about how the role="note" markup would work
- 14:37:18 [MURATA]
- +q
- 14:38:07 [aaronlev]
- jcraig: wanted to clarify that all the content should be somewhere in the a11y tree?
- 14:38:10 [aaronlev]
- jcraig: wanted to clarify that all the content should be somewhere in the a11y tree
- 14:38:19 [aaronlev]
- (jcraig do i have that right?)
- 14:38:50 [JG]
- JG has joined #aria
- 14:39:00 [aaronlev]
- jcraig: would the semantic only be useful for accessibility? that's a key difference between ARIA and native markup -- ARIA is for stuff that's only useful for a11y
- 14:39:36 [aaronlev]
- jcraig: if it's useful for anything else I think it would be clear that it shouldn't be ARIA
- 14:39:46 [jamesn]
- ack jc
- 14:39:46 [Zakim]
- jcraig, you wanted to respond to "accessibility tree should display the phonetic difference"
- 14:39:48 [aaronlev]
- MURATA: have not thought of or found any non-a11y use for the semantic
- 14:40:25 [aaronlev]
- MURATA: planning to publish wiki article as a W3C note
- 14:40:36 [aaronlev]
- q+
- 14:40:38 [cyns]
- q+ to ask if color coding of phonetic vs. non-phonetic for language learners might be a use case
- 14:42:05 [jamesn]
- ack me
- 14:42:05 [Zakim]
- jamesn, you wanted to ask if there is ever a case to ONLY read the ruby
- 14:43:19 [MURATA]
- GIKUN
- 14:43:37 [jamesn]
- https://github.com/Japan-Daisy-Consortium/documents/wiki/Text-to-Speech-of-Electronic-Documents-Containing-Ruby:-User-Requirements#4-interlinear-notes-2
- 14:45:23 [aaronlev]
- jamesn: obviously there are missing semantics, maybe there should be a different element, or an attribute
- 14:45:32 [aaronlev]
- jcraig: i don't think it needs to be a different element
- 14:46:12 [cyns]
- <rt type="para"> (default), <rt type="gikun">, <rt type="general">
- 14:46:15 [aaronlev]
- jamesn: if it's native it has a much higher likelihood of author use
- 14:46:18 [aaronlev]
- jcraig: agree
- 14:46:33 [jamesn]
- q- MURATA
- 14:46:39 [jamesn]
- ack aaronlev
- 14:48:11 [jcraig]
- aaronlev: user can decide in chrome whether to speak ruby base, ruby annotations, or both
- 14:49:08 [jcraig]
- aaronlev: exposing the semantics for user choice should be the first priority, right?
- 14:49:19 [jamesn]
- ack cyns
- 14:49:19 [Zakim]
- cyns, you wanted to ask if color coding of phonetic vs. non-phonetic for language learners might be a use case
- 14:49:35 [jcraig]
- q+ to clarify 1619 vs 1620
- 14:50:00 [aaronlev]
- cyns: i put some suggestions above
- 14:50:02 [jcraig]
- q+ to respond to aaron's comment
- 14:50:50 [JG]
- q+
- 14:51:12 [jcraig]
- q+ to consider in the context of the ssml/pronunciation topics earlier
- 14:51:14 [aaronlev]
- cyns: agree screen reader should have heuristics to be able to try to guess which to use, as a repair
- 14:51:43 [jcraig]
- ack me
- 14:51:43 [Zakim]
- jcraig, you wanted to clarify 1619 vs 1620 and to respond to aaron's comment and to consider in the context of the ssml/pronunciation topics earlier
- 14:51:43 [JG]
- scribe: jg
- 14:51:44 [jamesn]
- ack jcraig
- 14:53:57 [aaronlev]
- pronunciation, pronunciation-advanced, note
- 14:54:15 [aaronlev]
- pronunciation-learners, pronunciation-advanced, note
- 14:54:22 [JG]
- James: We have this ongoing pronunciation conversation. Someone suggested we use Ruby for this. To clarify 16.20 to 16.19 this is effectively one issue. We need more semantics in Ruby because there are multiple meanings. Some our pronunciation-related and some are accessibility related.
- 14:54:31 [jamesn]
- q+ to respond as to why they are different issues
- 14:54:54 [JG]
- ...16.19 is about displaying those two cases
- 14:54:59 [jamesn]
- ack jamesn
- 14:54:59 [Zakim]
- jamesn, you wanted to respond as to why they are different issues
- 14:55:47 [JG]
- James: I believe is purely for visual display changes. You should not read the pronunciation hint. The other is which meaning to read -- or both
- 14:56:26 [cyns]
- q+ to ask if there might be a case where a tts doesn't know the katakana and would need to use the phonetic ruby as a fallback?
- 14:56:31 [JG]
- ...if we do something in HTML, we'll need to provide something in ARIA
- 14:57:08 [JG]
- James: Ruby is for phonetics, but this usage is not phonetic. Both are phonetics, but one is not displayed.
- 14:57:48 [aaronlev]
- type="phonetics-learners" | "phonetics-advanced" | "note"
- 14:58:11 [JG]
- JamesN: If you pronounce the phonetics, you get an incorrect pronunciation.
- 14:58:27 [jamesn]
- ack JG
- 14:58:52 [jcraig]
- ruby rendering is well supported
- 14:59:35 [JG]
- JamesC: Ruby is reasonably supported in browsers and really common in Japanese books. Ruby accessibility is not as well supported
- 15:00:32 [jcraig]
- q?
- 15:00:35 [JG]
- cyns: There may be a fallback use case as well
- 15:00:37 [jcraig]
- ack cyns
- 15:00:37 [Zakim]
- cyns, you wanted to ask if there might be a case where a tts doesn't know the katakana and would need to use the phonetic ruby as a fallback?
- 15:01:22 [aaronlev]
- q+ to say that please consider having the mapping be a superset of what Chrome already does, since we already solved many of these problems
- 15:01:23 [JG]
- JamesC: We need to respond to the issue and close it
- 15:02:20 [JG]
- RRSAgent, make minutes
- 15:02:20 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html JG
- 15:03:37 [JG]
- JamesN: We need a way forward for 1.2.
- 15:04:27 [JG]
- RRSAgent, make minutes
- 15:04:27 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html JG
- 15:04:30 [jamesn]
- rrsagent, make minutes
- 15:04:30 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html jamesn
- 15:20:16 [jcraig]
- s/We need to respond to the issue and close it/We need to respond to the issue and ultimately close it once it's pointed to a new tracker in HTML or DPUB/
- 15:20:26 [jcraig]
- rrsagent, make minutes
- 15:20:26 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html jcraig
- 15:21:40 [jcraig]
- s/rt="phonetics"/<rt type="phonetic"> or similar/
- 15:23:42 [jcraig]
- s/wanted to clarify that all the content should be somewhere in the a11y tree?/wanted to respond to Murata's comment that the ruby phonetic distinction should be exposed in the accessibility tree/
- 15:25:19 [jcraig]
- s/wanted to clarify that all the content should be somewhere in the a11y tree/regardless of whether this is a native Ruby attribute or ARIA, it will need be exposed in the accessibility APIs/
- 15:25:48 [jcraig]
- s/would the semantic only be useful for accessibility?/so would the semantic *only* be useful for accessibility?/
- 15:27:50 [jcraig]
- s/ARIA is for stuff that's only useful for a11y/ARIA is only exposed to assistive technology, and is not used for mainstream display differences like Murata is suggesting such as hiding the "para" pronunciation hints by default/
- 15:27:54 [jcraig]
- rrsagent, make minutes
- 15:27:54 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html jcraig
- 15:31:42 [jcraig]
- s/We need a way forward for 1.2./(Topic change) Re: IDL we need a way forward for 1.2./
- 15:31:44 [jcraig]
- rrsagent, make minutes
- 15:31:44 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html jcraig
- 16:00:16 [gregwhitworth]
- gregwhitworth has joined #aria
- 16:05:12 [bkardell_]
- bkardell_ has joined #aria
- 16:05:32 [Jory]
- Jory has joined #aria
- 16:05:35 [bkardell_]
- present+
- 16:05:59 [jamesn]
- meeting: ARIA IDL meeting
- 16:06:17 [joanie]
- present+ Joanmarie_Diggs
- 16:06:28 [jamesn]
- zakim, pick a victim
- 16:06:28 [Zakim]
- Not knowing who is chairing or who scribed recently, I propose plh
- 16:06:30 [jcraig]
- present+
- 16:06:41 [bkardell_]
- scribenick: bkardell_
- 16:07:33 [jcraig]
- Topic: https://github.com/w3c/aria/issues/1598
- 16:08:02 [gregwhitworth]
- present+
- 16:08:38 [bkardell_]
- jamesn: when we published aria 1.2 draft, we published based on changes requested from various folks in HTML WG - that there was no such thing as nullable strings in HTML. In testing we learned that there are nullable DOM strings and not vice versa... we believe that is actually what we want, so we are in a strange dilema
- 16:09:16 [bkardell_]
- jamesn: we're in a strange situation where we have reverted the spec and we have implementations that are different. We are at an impasse at where we should go to make everyone happy
- 16:09:17 [jamesn]
- q?
- 16:09:26 [aaronlev]
- q-
- 16:09:40 [bkardell_]
- jamesn: does anyone want to clarify more
- 16:11:11 [bkardell_]
- jcraig: Annvk and domenic dinicola were objecting to the pull request, we were hoping they would come today... cyns had reached out to domenic, and I'm not sure where that stands right now... unfortunately she's not able to discuss right now as she's in the car
- 16:11:13 [jamesn]
- “If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is in its missing value default state then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value
- 16:11:13 [jamesn]
- in a transparent, case-preserving manner.”
- 16:11:57 [jamesn]
- https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflect
- 16:12:28 [bkardell_]
- jamesn: this is where HTML defines how to reflect various kinds of values in attributes
- 16:13:10 [jcraig]
- s/dinicola/denicola/
- 16:13:30 [jcraig]
- s/we were hoping they would come today/and said they would attend today/
- 16:14:11 [bkardell_]
- jcraig: I'm unsure the experience of others on the call and their experience in IDL - anyone on who can help advise us here?
- 16:14:20 [bkardell_]
- gregwhitworth: I haven't kept up with this unfortunately
- 16:15:31 [bkardell_]
- gc: we debated long and hard - we actually went back and forth between the two. I will go back and look more and we will comment on the issues...
- 16:15:58 [JG]
- JG has joined #aria
- 16:16:01 [bkardell_]
- gc: I forgot what we landed on, but I will try to dig up notes and add 2c
- 16:16:21 [bkardell_]
- jcraig: do you have an implemented nonnullable string?
- 16:16:43 [bkardell_]
- gc: we have .... something.
- 16:17:14 [jcraig]
- s/nonnullable/nullable reflected/
- 16:17:18 [bkardell_]
- gc: in lightning web components we do something - I remember hitting this issue and it leading to lots of discussion
- 16:17:35 [jcraig]
- s/something/something internal in salesforce/
- 16:18:00 [jcraig]
- q+
- 16:18:02 [bkardell_]
- jamesn: I guess we should wait for cyns on this and move on for now
- 16:19:29 [jamesn]
- https://github.com/w3c/aria/issues/1598#issuecomment-954000170
- 16:20:31 [bkardell_]
- jamesn: apologies to folks, we were really hoping to get this unblocked because it is the issue that is holding us up... would be really happy to hear any other ideas about how we get past this, otherwise we can move on
- 16:22:14 [bkardell_]
- cyns: I have a draft in a google doc, I will share it here in the presentation but I dont want it minuted because it is temporary and won't continue to exist...
- 16:23:06 [bkardell_]
- cyns: I took the text from alice's pr and modified ita bit... it has gona on a whole lot
- 16:23:18 [bkardell_]
- cyns: I think there were _hundreds_ of comments on the issue, many meetings
- 16:23:36 [bkardell_]
- cyns: the majority were around reflected attributes...
- 16:25:01 [bkardell_]
- cyns: the concern with 'sprouting' is that if you were to say it sprouts an attribute, there were a lot of bad options. the least bad was to not reflect in that direction - to not change the DOM attribute. It's a little complicated - the main downside of this approach is that the DOM in the inspector could be out of sync in some cases
- 16:25:19 [jcraig]
- s/around reflected attributes.../around sprouting attributes.../
- 16:26:01 [bkardell_]
- (cyns presents)
- 16:27:04 [bkardell_]
- jcraig: just to make sure it is clear - when cyns described DOM as being out of sync -- nothing is really out of sync, but you can't see it as clearly by existing norms, as a content attribute... it's kind of "partial reflection" or "one way reflection" to some degree
- 16:27:45 [jcraig]
- s/but you can't see it /but web authors inspecting the DOM can't see it /
- 16:27:59 [bkardell_]
- cyns: indeed, it is a little complicated, but I dont think it is much of a problem in practice. we will probably have to provide author advice -- here we're focused on the HTML spec which is very implementer focused
- 16:28:52 [bkardell_]
- jamesn: it's complicated. I'm actually going to step back to the previous part... do you think this is what they are looking for - for the nullable thing?
- 16:29:01 [bkardell_]
- cyns: yes
- 16:29:24 [bkardell_]
- jamesn: where can I find that in the spec?
- 16:29:40 [gregwhitworth]
- q+
- 16:29:41 [bkardell_]
- cyns: this text would be added to section 2.6 of the specification
- 16:29:55 [jcraig]
- q-
- 16:30:16 [bkardell_]
- cyns: we would need to add something similar for how null behaves.
- 16:30:52 [JG_]
- JG_ has joined #aria
- 16:31:02 [bkardell_]
- cyns: I can take on writing that, but probably not until next month - if someone wants to volunteer because they want to move it sooner, they can
- 16:31:14 [bkardell_]
- jamesn: I don't see this for all of the standard types though?
- 16:31:20 [jamesn]
- ack gre
- 16:31:48 [bkardell_]
- gregwhitworth: question about the 1-dimensional reflection... are there use cases that we lose besides the developer inspection of the dom
- 16:31:59 [leobalter]
- leobalter has joined #aria
- 16:31:59 [jcraig]
- q+
- 16:32:11 [bkardell_]
- cyns: not that I remember... triple equals doesn't work in some cases, but we decided together that was probably ok
- 16:32:37 [bkardell_]
- gregwhitworth: but there aren't author use cases that we can think of that fall off the table...?
- 16:33:30 [bkardell_]
- jcraig: maybe we could step back and give an example of why this couldn't be reflected. one of the main examples of this is we can't give an idref between documents, like pointed inward in a shadow dom context
- 16:33:46 [bkardell_]
- jcraig: so there's no way to reflect that in the DOM
- 16:33:59 [bkardell_]
- q+
- 16:34:07 [jcraig]
- ack me
- 16:34:24 [bkardell_]
- cyns: are there cases where you have labels inside of a shadow dom?
- 16:35:03 [jcraig]
- aria-activedescendant etc too
- 16:35:20 [bkardell_]
- gc: labels inside a shadow dom... we're looking at this as a per-component basis, so far there is some element outside the shadow which will want to link into the button
- 16:36:01 [bkardell_]
- gc: we have things to figure out how to do it
- 16:36:03 [jamesn]
- q?
- 16:36:25 [bkardell_]
- cyns: something we've been talking about AOM discussions is whether we can have a name calculation that allows you to reference that
- 16:36:28 [bkardell_]
- q-
- 16:37:06 [bkardell_]
- gc: thinking outloud... like with slots, they aren't actually 'moved in', they continue to exist in the light dom, we just create linkage.... maybe we can draw inspiration from that
- 16:37:45 [bkardell_]
- cyns: another use case we talked about is being able to apply attributes to a custom element and determine which of those things that goes to, that is a lot more like slots
- 16:38:20 [bkardell_]
- cyns: but this is all "down"... we've not discussed how to go out of the shadow, if there is a reason to expose something on the container from inside
- 16:38:37 [bkardell_]
- gregwhitworth: on that I dont know why we wouldn't just use name calculation rules
- 16:38:58 [bkardell_]
- cyns: those are pretty complicated, I'm not sure if someone on the call wants to comment
- 16:39:12 [bkardell_]
- gregwhitworth: that's why I (?)
- 16:40:02 [gregwhitworth]
- s/that's why/that's why I don't want authors creating their own computed name due to its complexity. We should just have an API on shadowRoot or something that returns the computed name for the shadow
- 16:40:58 [bkardell_]
- cyns: how hard would it be to calculate the name of that shadow dom as if it were a whole document and present a way that the outside could use it
- 16:42:26 [bkardell_]
- jcraig: this is a topic we've discussed for many many hours in AOM meetings and in other places... I think we had talked about a way for the component owner to do that as a property of the shadow rather than have the engine try to ... I hesitate to try to dig into this more here and speculate at another solution during this call
- 16:42:48 [bkardell_]
- cyns: having the author do it is also not without downside
- 16:43:09 [jcraig]
- s/engine try to /engine try to infer what the label should be /
- 16:43:36 [bkardell_]
- aaronlev: was the question whether work this should be on the engine side or on the author side?
- 16:43:40 [jcraig]
- s/during this call/during this call since many of the engaged parties aren't in attendance/
- 16:44:04 [jcraig]
- s/engaged parties/engaged implementing engineers/
- 16:44:10 [bkardell_]
- jamesn: It seems we need to fix attname for shadow roots anyway... at that point, sure why wouldn't you expose it on the component... it seems like a reasonable thing to do
- 16:44:20 [jcraig]
- rrsagent, make minutes
- 16:44:20 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html jcraig
- 16:44:24 [bkardell_]
- cyns: I think we have been avoiding ti, because it is hard
- 16:44:40 [bkardell_]
- jamesn: it kind of works in browsers, we have to write down what we are doing
- 16:45:22 [bkardell_]
- aaronlev: are we talking about when is aria labelled by pointing from one side of the shadow to the other? there is no format for ids that allow that
- 16:45:30 [bkardell_]
- q+
- 16:46:13 [bkardell_]
- aaronlev: random idea - there are chars that aren't allowed in IDs, we could use those maybe to make some way to do it
- 16:46:38 [bkardell_]
- jamesn: if I reference a component with an idref, then nothing gets returned?
- 16:46:49 [bkardell_]
- aaronlev: not inside the shadow content
- 16:47:01 [bkardell_]
- jamesn: but just the web component itself
- 16:47:15 [gregwhitworth]
- <div aria-labeledby="foo"></div><custom-element id="foo"></custom-element>
- 16:47:16 [bkardell_]
- cyns: the equivalent of pointing to an iframe element
- 16:47:25 [bkardell_]
- aaronlev: so can we walk in from there?
- 16:47:45 [bkardell_]
- jamesn: in dev tools, it does seem to walk down into the thing, I'm just not sure
- 16:48:09 [bkardell_]
- aaronlev: yes, it can walk down through the AX objects, if we have a computed name we expose it might be leaking information we probably shouldn't be
- 16:48:18 [gregwhitworth]
- <div aria-labeledby="foo"></div><custom-element><div id="foo"></div></custom-element>
- 16:48:18 [gregwhitworth]
- is what aaronlev is saying won't work
- 16:48:27 [gregwhitworth]
- q+
- 16:48:28 [bkardell_]
- cyns: it might accidentally work in a way that is breaking shadow boundaaries
- 16:48:44 [bkardell_]
- aaronlev: it's not the only use case though, right - we need to point both ways, right?
- 16:49:00 [jcraig]
- ack bkardell
- 16:49:02 [jamesn]
- ack bkardell_
- 16:49:27 [gregwhitworth]
- bkardell_: I was on the queue a while back and I wanted to reiterate here that there have been a ton of discussions on these topics
- 16:49:37 [gregwhitworth]
- bkardell_: most people have trouble keeping up with where we are now
- 16:49:47 [gregwhitworth]
- bkardell_: we shouldn't try to solve here
- 16:50:07 [gregwhitworth]
- bkardell_: maybe some of us should produce a consumable summary and weigh in with what has already happened, been shot down, etc
- 16:50:10 [gregwhitworth]
- q-
- 16:50:25 [gregwhitworth]
- bkardell_: I recall there was a proposal and there was an import/export idea to express this
- 16:50:29 [gregwhitworth]
- bkardell_: a lot of idea
- 16:51:27 [bkardell_]
- cyns: yeah - so the two things we have concensus on are these two things in the agenda... not sprouting in these cases, and to allow you to put aria on the custom element and have a way to tie that to a paricular elemenet in a shadow root
- 16:51:48 [bkardell_]
- cyns: I think that one seems pretty straightfoward and uncontroversial
- 16:52:03 [bkardell_]
- cyns: how do people feel about the lack of content attribute synchronizing?
- 16:52:14 [jcraig]
- q+
- 16:52:17 [bkardell_]
- Jory: would this cause problems with testing tools?
- 16:53:21 [bkardell_]
- jcraig: it is available, testing tools can use it - but if they make assumptions that are only in the DOM that won't be accurate alone
- 16:53:36 [bkardell_]
- q+
- 16:53:50 [jcraig]
- ack me
- 16:54:19 [jcraig]
- s/DOM/DOM as content attributes/
- 16:54:33 [jcraig]
- bkardell_: is available, but as a new feature
- 16:54:59 [jcraig]
- bkardell_: none of the testing tools are perfect. they all have false positives and false negatives.
- 16:55:37 [bkardell_]
- cyns: some examples would be helpful I think
- 16:55:43 [jcraig]
- bkardell_: calling out the false results will help expose the shortcomings of the testing tools and could help with the resolution
- 16:56:16 [bkardell_]
- cyns: are there other things that would be useful beyond seeing examples and what the input and output is
- 16:56:25 [bkardell_]
- gregwhitworth: examples would be very helpful, yes
- 16:56:38 [bkardell_]
- jamesn: this code (on the screen) is destined for the HTML spec?
- 16:56:40 [bkardell_]
- cyns: yes
- 16:57:17 [bkardell_]
- gregwhitworth: since I think ultimately the goal is to land - is what you are showing here the solution to bi-directional references?
- 16:57:32 [bkardell_]
- cyns: I think it is the best of all of the bad options
- 16:58:06 [bkardell_]
- gregwhitworth: our team at salesforce will review it if you send this to the list with examples, as you suggested, and get feedback
- 16:58:50 [jcraig]
- thanks for attending gregwhitworth
- 17:01:06 [jcraig]
- FTI Dominic just responded at https://github.com/w3c/aria/issues/1598#issuecomment-954027895
- 17:01:23 [jcraig]
- s/FTI/FYI/
- 17:07:21 [jamesn]
- revised proposal? "If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is missing then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value in a
- 17:07:21 [jamesn]
- transparent, case-preserving manner.”
- 17:07:55 [jamesn]
- revised proposal? "If a reflecting IDL attribute is a nullable DOMString attribute, then, on getting, if the corresponding content attribute is not present then the IDL attribute must return null, otherwise, the IDL attribute must get the value in a transparent, case-preserving manner. On setting, if the new value is null, the content attribute must be removed, and otherwise, the content attribute must be set to the specified new value in a
- 17:07:55 [jamesn]
- transparent, case-preserving manner.”
- 17:12:37 [jcraig]
- q+
- 17:12:44 [bkardell_]
- q-
- 17:13:11 [gregwhitworth]
- q+
- 17:14:20 [jcraig]
- ack me
- 17:14:29 [cyns]
- cyns has joined #aria
- 17:14:32 [cyns]
- q?
- 17:15:49 [cyns]
- q+
- 17:17:18 [jcraig]
- ack cyns
- 17:17:28 [gregwhitworth]
- q-
- 17:19:55 [bkardell_]
- bkardell_: I laid that out in order to better understand whether you thought maybe we were doing things we shoudn't right now, or not doing things right now we should
- 17:21:52 [gregwhitworth]
- q+
- 17:22:56 [cyns]
- https://open-ui.org/
- 17:24:38 [jamesn]
- https://github.com/w3c/aria/issues/1598
- 17:32:57 [jamesn]
- q+
- 17:33:10 [jamesn]
- q- gregwhitworth
- 17:51:21 [jamesn]
- rrsagent, make minutes
- 17:51:21 [RRSAgent]
- I have made the request to generate https://www.w3.org/2021/10/28-aria-minutes.html jamesn
- 17:51:25 [aaronlev]
- do we have another call in 10 minutes?
- 19:16:49 [jongund]
- jongund has joined #aria
- 20:31:07 [github-bot]
- github-bot has joined #aria