| 07:48 | <annevk> | Domenic: wrapping in https://github.com/whatwg/infra/pull/403 is wrong |
| 07:49 | <Domenic> | Oh, I'm sorry :( |
| 07:49 | <annevk> | I'm also still not entirely sure how this will work out, but I guess we can try it for a while |
| 08:36 | <annevk> | Does Bikeshed still use Shepherd? I thought Shepherd did crawling more often now but it seems a change to WebSockets yesterday hasn't been picked up yet |
| 09:12 | <annevk> | Oh, it seems to have happened now |
| 16:11 | <annevk> | Does anyone happen to recall debate or discussion that made the HTML specification avoid "positive numbers" in a number of places? Was it solely due to 0 or is there some other reason I'm not thinking of? |
| 16:12 | <annevk> | We have definitions such as "non-negative numbers greater than zero" which as Domenic remarked and I tend to agree with, are a bit much, and could prolly be "positive numbers"? |
| 16:49 | <annevk> | Domenic: do you understand how https://html.spec.whatwg.org/#accessibility-semantics works? It seems to just forward setter steps given values? Shouldn't there be some normalization happening as per reflect semantics? (How that setup works for Element as opposed to ElementInternals also seems somewhat fraud.) I'm trying to look into fixing some of the issues around this, in particular number reflection, but it seems more might be needed. |
| 17:29 | <annevk> | I found https://github.com/whatwg/html/pull/4658 and I guess that means I'm supposed to understand it, but even the example seems wrong. E.g. this._internals.ariaChecked = this.checked;. ariaChecked is a "tristate" that can be in four states. But here it just forwards the value of the checked getter which does getAttribute('checked'). That will end up mismatching in most cases I think... |
| 17:30 | <annevk> | Oh, https://github.com/web-platform-tests/wpt/pull/18223/files was the sole test linked. :/ |
| 19:38 | <zcorpan> | annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=7211 |
| 21:06 | <wanderview> | hmm... when I build html spec locally today I can't click on a concept definition to get a list of references for some reason... the prod version works fine for that, though |
| 21:06 | <wanderview> | I have no local changes |
| 21:07 | <Andreu Botella> | hmm... when I build html spec locally today I can't click on a concept definition to get a list of references for some reason... the prod version works fine for that, though /html-dfn.js, so you have to run it on a server |
| 21:08 | <Andreu Botella> | rather than loading the file: URL |
| 21:12 | <wanderview> | thanks, ./build.sh --serve worked |
| 21:12 | <wanderview> | I wonder why file:// URL would breaking loading a script, though |
| 21:12 | <wanderview> | seems like that should work with a relative subresource, etc |
| 21:12 | <Andreu Botella> | because of the initial slash |
| 21:13 | <wanderview> | oh, I see... its not using a relative URL |
| 21:14 | <Andreu Botella> | I think it's using a URL relative to the domain because the HTML spec source is used for /, /multipage/*.html and for /dev |
| 21:14 | <Andreu Botella> | so a single relative path wouldn't work |
| 23:44 | <Domenic> | Domenic: do you understand how https://html.spec.whatwg.org/#accessibility-semantics works? It seems to just forward setter steps given values? Shouldn't there be some normalization happening as per reflect semantics? (How that setup works for Element as opposed to ElementInternals also seems somewhat fraud.) I'm trying to look into fixing some of the issues around this, in particular number reflection, but it seems more might be needed. DOMString?, so there was no real reflection normalization logic. Note that aria-* attributes never use "limited to only known values" or similar; they're just pass-throughs. |
| 23:45 | <Domenic> | It looks like now some are Element? and FrozenArray<Element>? and so it's broken |
| 23:45 | <Domenic> | And certainly if you change any of them to numeric values that will also be broken |
| 23:46 | <Domenic> | I don't think anything in ARIA defines how, e.g., ariaActiveDescendantElement works, how it interacts with aria-activedescendant="", etc. |
| 23:46 | <Domenic> | It looks like there is some reflection for https://w3c.github.io/aria/#idl_element , hmm, interesting. |
| 23:47 | <Domenic> | But nothing actually consults the attr-associated element which HTML reflection defines |