| 07:29 | <Panos Astithas> | Meeting minutes: https://docs.google.com/document/d/1V6_s_VsaWcI9J-ZATbIKKijn59JbVmRMsHXYyH29sho/edit |
| 07:34 | <annevk> | If folks are interested in attending, the meeting information can be found at https://www.w3.org/events/meetings/efdf2435-c675-41ea-9af2-9fa6443e504c/ |
| 07:34 | <hsivonen> | Are any break times known in advance? |
| 07:35 | <hsivonen> | Sevilla lunch time perhaps? |
| 07:36 | <annevk> | hsivonen: https://github.com/whatwg/meta/issues/284 has the agenda, breaks are between the items |
| 07:36 | <hsivonen> | Thanks |
| 07:36 | <annevk> | So the first break would be at 11AM in ~ 1.5h. We haven't started yet though. |
| 07:39 | <zcorpan> | Can remote folks hear us ok? |
| 07:40 | <krosylight | pto until 2023-09-10> | Yup |
| 07:40 | <hsivonen> | I can hear folks in the meeting room |
| 07:41 | <zcorpan> | https://whatwg.org/code-of-conduct |
| 09:39 | <keithamus> | https://docs.google.com/document/d/1V6_s_VsaWcI9J-ZATbIKKijn59JbVmRMsHXYyH29sho/edit minutes for those who want the link |
| 09:55 | <Panos Astithas> | https://w3c.github.io/aria/ still has 1.3 |
| 10:05 | <jarhar> | issue about this topic: https://github.com/openui/open-ui/issues/571#issuecomment-1696637459 |
| 10:12 | <mfreed> | https://github.com/openui/open-ui/issues/787 |
| 10:12 | <mfreed> | https://github.com/openui/open-ui/issues/552 |
| 10:13 | <mfreed> | https://github.com/w3c/csswg-drafts/issues/9284 |
| 10:15 | <bkardell> | we've had this in css for a long time, but irrc there were concerns around it https://drafts.csswg.org/css-images-4/#funcdef-element |
| 10:19 | <jarhar> | current issue: https://github.com/whatwg/html/issues/9373 |
| 10:30 | <annevk> | mfreed: one minor suggestion, maybe lightclose so we don't introduce a second term for closing |
| 10:36 | <Hidde de Vries> | fwiw I've been calling the opposite of 'light dismiss' 'explicit dismiss' , might be another word we could opt for as the opposite of light close / dismiss |
| 10:53 | <hober> | "Everything is a lot." — annevk |
| 10:58 | <annevk> | Hidde de Vries: I would not mind implicitclose, I don't think we want "dismiss" as a novel term as it won't be immediately recognizable as "close" to all people |
| 10:59 | <annevk> | Hidde de Vries: although lightclose and softclose seem easier to spell, which is another consideration |
| 12:28 | <hsivonen> | Is there a joint meeting currently ongoing with CSS? In the CSS Zoom, I don't see the meeting room on the call and I can't hear any sound. |
| 12:28 | <Andreu Botella (at TPAC Sep 11 - 15)> | we haven't started yet |
| 12:28 | <annevk> | Yeah, people are walking into the room nowish |
| 12:29 | <hsivonen> | OK |
| 12:32 | <Panos Astithas> | Zoom link for the joint session with CSSWG: https://w3c.zoom.us/j/7729314923?pwd=YVhPRzNvQmdNVDF2RjFYMzdyMXB4UT09 |
| 12:32 | <mfreed> | The camera is still off, correct? |
| 12:37 | <mfreed> | Guess the answer was no, and that I needed to restart Zoom. |
| 12:38 | <krosylight> | So we are using IRC now? Can someone give me the link? |
| 12:39 | <krosylight> | Thanks |
| 12:41 | <mfreed> | https://irc.w3.org/ |
| 12:42 | <hober> | #css on irc.w3.org |
| 12:52 | <TabAtkins> | Hmmmm, if we want to have an attribute that always outputs a particular interface type from the getter, but wants to accept a dictionary type for the setter, is that at all possible? |
| 12:53 | <TabAtkins> | It looks like the answer is no, dictionary types aren't allowed in an attribute type, since the implication is that the attribute type is both the getter output and the setter input (and you can't use dictionaries in output types) |
| 12:54 | <TabAtkins> | (I suspect the answer is that, right now, it's required to type the attribute as any and handle the conversions by hand.) |
| 12:56 | <annevk> | TabAtkins: IDL has an open issue to split getters and setters (plus maybe have convenient syntax for when they're the same); we should still do that |
| 12:56 | <TabAtkins> | ah, cool. so "no, but later yes" |
| 12:56 | <annevk> | hai |
| 13:49 | <annevk> | zcorpan: https://github.com/w3c/csswg-drafts/issues/9301#issuecomment-1719284356 |
| 15:29 | <Domenic> | TIL document.open(); document.close() is a "turn off mutation events" flag in Chrome/Safari. |
| 15:42 | <smaug> | That is interesting. I wonder what is the historical reason for that. |
| 15:55 | <annevk> | The specification requires flipping it on and then off. And maybe they just forgot to turn it on again? |
| 16:05 | <Domenic> | I think the specification is more recent though |
| 16:06 | <Domenic> | Ah, no, that part was untouched in the rewrite https://html.spec.whatwg.org/commit-snapshots/c9e804f04d03a0658bfa689cb0f368a4d2e37936/?C=M&O=A#dom-document-open |
| 16:07 | <Domenic> | Firefox doesn't quite follow the spec either, it turns them off until document.close() turns them back on, instead of the spec which requires turning them off just for the removal step. |
| 16:07 | <Domenic> | (or in the new spec, the "replace all" step) |
| 20:55 | <smaug> | how did you test that? Note, all the events listeners are supposed to be removed |
| 22:21 | <smaug> | ah, it is a bit different. Listeners added after document.open() are called, if one modifies the DOM using normal methods, but .write() itself doesn't seem to notify DOM side, so no events are fired with .write(). |