| 05:36 | <jgart> | hi |
| 06:00 | <annevk> | Domenic: seems like the checkbox example might be broken regardless? I guess I'll file some issues to start |
| 06:02 | <annevk> | zcorpan: thanks! I guess it's fair to wonder whether positive includes zero given that negative zero is a thing |
| 06:02 | <annevk> | Hopefully mrego can help with the ARIA mess a bit |
| 07:20 | <rego> | so if I'm understanding correctly the problem is with this section https://html.spec.whatwg.org/#accessibility-semantics |
| 07:21 | <annevk> | rego: yeah, it's not clear how element references work for that |
| 07:22 | <annevk> | But also, it's not immediately clear how the ARIA specification uses the reflect infrastructure to expose the element references to AT |
| 07:22 | <annevk> | Thus far I think ARIA relied on attribute -> AT property mapping of some sort, but that wouldn't work here |
| 07:24 | <annevk> | I guess there's also a slight problem that things like https://w3c.github.io/aria/#aria-activedescendant don't acknowledge the empty string as a possible value when set through script |
| 07:25 | <annevk> | rego: I'm happy to help with fixing some of this btw, trying to understand the scope of the problem first and what kind of solution might be required to support both Element and ElementInternals classes |
| 07:25 | <rego> | mmm, I see a bunch of things then... I don't really know how ARIA connects the attributes with AT |
| 07:25 | <rego> | but yeah, with element reflection, the attribute is no longer the source of true |
| 07:25 | <rego> | so there can be a bunch of things that need to get updated |
| 07:26 | <annevk> | I'll be back in an hour or so and will start filing some issues then as a start (taking into account anything you leave here for me) |
| 07:27 | <rego> | I guess there's also a slight problem that things like https://w3c.github.io/aria/#aria-activedescendant don't acknowledge the empty string as a possible value when set through script aria-describedby and the ones pointing to a list of ids, not sure if using an empty string for them is also defined |
| 07:28 | <rego> | I don't have a lot to add, I'll need to check things, but I guess at least we should fill issues in ARIA and in HTML, and see what we can do in each of them |
| 07:28 | <rego> | if you're filling those issues add me on CC |
| 07:43 | <rego> | it looks like relationships with AT are defined in other specs like accname or core-amm, and not in ARIA itself |
| 07:44 | <rego> | for example this PR is trying to fix this issue in accname: https://github.com/w3c/accname/pull/170 |
| 08:00 | <rego> | anyway yeah, probably it makes sense ARIA mentions something about this specifically, to specify that even if the attributes can have an empty string, there can be a relationship set in ariaXXXElements that needs to be exposed to AT |
| 08:02 | <rego> | in addition it looks like steps in ARIA mixing section need to be updated for Element/FrozenArray<Element> too: https://w3c.github.io/aria/#ARIAMixin |
| 09:07 | <annevk> | rego: thanks for the pointer to accname, I left a comment on that PR and also filed an issue for ElementInternals |
| 09:08 | <annevk> | I suspect what we want is that ElementInternals gets to share in the infrastructure reflect defines |
| 09:18 | <rego> | should we also file something in ARIA? so empty values for those attributes are allowed and also we mention the actual source of true, which is no longer the attribute |
| 09:32 | <annevk> | rego: thanks for the reminder: https://github.com/w3c/aria/issues/1842 |
| 09:47 | <rego> | what do you think about https://w3c.github.io/aria/#dfn-ariamixin-getter-steps ? doesn't need an update too? isn't that quite related to https://html.spec.whatwg.org/#accessibility-semantics |
| 10:01 | <annevk> | rego: yeah it might, I'm honestly not sure yet what we should do (got distracted by a number of other things) |
| 10:01 | <rego> | yeah I'm not sure either, but both sections seem very related, and probably both need updated... |
| 10:35 | <Domenic> | OK... I think it's ready... https://github.com/whatwg/html/pull/6315#pullrequestreview-1158013824 |
| 10:45 | <annevk> | Oh wow. I'm a bit swamped the next couple of weeks unfortunately, but that's awesome. |
| 10:46 | <annevk> | rego: if we make reflect more generic whereby it can support get/set operations that depend on the type of object that has the IDL attribute, we can make it work I think |
| 10:47 | <annevk> | rego: that would result in largely staying with string-like values in the end that accname would then have to map to numbers and such as needed |
| 10:48 | <annevk> | rego: element-references would continue to use the infrastructure of reflect, but we'd generalize that to work for ElementInternals as well (as in, it also defines these new attr-element thingies for ElementInternals) |
| 10:49 | <annevk> | rego: the main problem I see is that this is a lot of work with regards to updating reflect to make this actually work (I think once we do it we could get rid of ARIAMixin getter/setter steps as we'd just define everything through reflect) |
| 11:17 | <annevk> | I typed it out in https://github.com/whatwg/html/issues/8442. Feedback or thumbs up appreciated. |
| 11:31 | <rego> | will try to check it |
| 21:05 | <snek> | i am looking at some websocket tests in wpt. the harness code here has stuff for h2 and https, but my reading of the documentation says none of these tests would ever be run in https or h2 environments, just http and service worker? |
| 23:24 | <sideshowbarker> | annevk: (or anybody) https://stackoverflow.com/questions/74227809/what-schemes-can-appear-in-the-origin-header-sent-by-a-fetch-compliant-browser |
| 23:27 | <snek> | i think assuming just http/https is safe |
| 23:28 | <snek> | i just had a fun dive into browser network internals for some websocket stuff and they all pretty much assume this |
| 23:33 | <sideshowbarker> | snek: yeah that’s my impression as well — just would be good to have some authoritative part of some spec to cite (some part of the Fetch spec, I guess it would need to be) |