| 08:19 | <sideshowbarker> | PSA: https://github.com/w3c/spec-maintenance — and in particular, the spec list at https://github.com/w3c/spec-maintenance#specs Would love patches with additions to that list of specs — or suggestions here about what to add — and also in general, would love to have feedback about the problem statement (or patches), and help with getting some momentum going on this |
| 08:23 | <annevk> | sideshowbarker: this framing seemingly excludes "hit testing" or image formats, which have no real specification, but should probably be included. |
| 08:23 | <annevk> | https://wiki.whatwg.org/wiki/Specs/todo |
| 08:24 | <annevk> | (We're making progress on Form control styling though.) |
| 08:38 | <akaster> | https://w3c.github.io/editing/docs/execCommand and https://console.spec.whatwg.org/ fit the bill imo |
| 08:39 | <akaster> | console re: table (#21) and %c formatting. execCommand for... obvious reasons I'd say |
| 08:43 | <sideshowbarker> | Thanks — made some refinements/additions along those lines |
| 08:44 | <sideshowbarker> | Thanks — will add those now |
| 08:56 | <sideshowbarker> | Added |
| 08:59 | <sideshowbarker> | annevk: High-level about the framing: If there’s a better term than “spec maintenance”, I’m happy to change that. I’m not wedded to any of this. At this point, it’s just trying to articulate the actual problem(s), and having some concrete cases to point to. Just trying to get something more going — to describe the problem and who’s feeling the pain from the problem, and exactly what kind of pain |
| 09:01 | <annevk> | Don't really have concrete thoughts so far, but sounds like a great thing to make some progress on! |
| 09:01 | sideshowbarker | heads off for a while to cook dinner |
| 09:56 | <Noam Rosenthal> | Not sure how to word it but UI events are a bit undermentained... e.g. they still don't have a processing model and the events somehow magically make it into the event loop |
| 09:57 | <Noam Rosenthal> | sideshowbarker: ^^^ wrt your unmaintained spec list |
| 10:48 | <sideshowbarker> | Thanks — 💯% agreed that’s one that should be included; added now |
| 14:49 | <smaug> | Why does the popup in HTML spec move to bottom left when clicking something on it. So annoying. At least it isn't animated like in some other specs though. |
| 15:27 | <annevk> | smaug: because it can no longer be anchored to the definition as that's unlikely to still be in the viewport |
| 15:29 | <annevk> | smaug: I suppose it could be kept in the same place, but then it likely overlaps... Prolly best discussed in an issue if you want to drive some change. |
| 15:38 | <smaug> | oh, perhaps someone has had different use case in mind vs how I use it |
| 15:39 | <smaug> | I click a thing and then from the popup I open new tabs. And it is a bit annoying that when I ctrl+click first link in the popup, a tab is opened in background but at the same time popup moves to different place |
| 15:42 | <annevk> | Ah, maybe we can detect cmd+click and contextmenu separately? Changing the anchoring is only relevant if you go through all of the references inline. I never actually thought to open those links in a new tab. |
| 15:42 | <annevk> | Worth filing an issue on. |
| 15:53 | <jmdyck> | In the HTML spec, what is <span data-x=""> for? |
| 15:55 | <Ms2ger> | X-references |
| 15:59 | <jmdyck> | Hm, don't think so. E.g., in 4.8.4.4.9, the first example has <span data-x="">XYZ Corp</span>, but that's not a cross-ref to anything. |
| 16:00 | <zcorpan> | jmdyck: empty string means to not cross-reference anything |
| 16:01 | <jmdyck> | Right. So why create a <span> if it's not going to do anything? |
| 16:02 | <jmdyck> | like, i could understand a <span data-x=""> if it also had some other attributes |
| 16:04 | <jmdyck> | (e.g. <span data-x="" class="XXX">) |
| 16:07 | <jmdyck> | Or I could understand it if span got special styling, but that doesn't appear to be the case. |
| 16:08 | <jmdyck> | (e.g., in that example, XYZ Corp isn't rendered differently. Not for me, anyhow.) |
| 16:14 | <jmdyck> | (It looks like span does have special styling in ul.domTree, so leave aside those occurrences.) |
| 16:29 | <jmdyck> | I think maybe they're vestigial. |
| 16:37 | <smaug> | Luke Warlow: am I missing something or does https://github.com/whatwg/html/pull/10954/files handle somehow 'connected' trees only in attribute change case, but any trees in insertion steps |
| 16:37 | <smaug> | keithamus: ^ |
| 16:39 | <smaug> | Basically, if dialog element is inserted to some random not-connected element, dialog setup would run, but when removing open attribute then, dialog cleanup wouldn't happen |
| 17:48 | <keithamus> | smaug: that makes sense. We should check if it's in a document tree and has a browsing context. That should be sufficient, right? |
| 17:49 | <smaug> | likely 🙂 the setup is complicated. Need to then also check how things like requestClose() work if the element isn't in document, or not in browsing context connected document. Right now it just asserts that there is a close watcher |
| 17:57 | <keithamus> | I'll try to get some tests down tomorrow. |
| 19:21 | <Luke Warlow> | So you're right it is missing something (because chromium still was), chromium has been updated to handle it but you're also right that there's still a crash case. This will need some further thought. I think requestClose() will need some handling in the disconnected case (possibly an early return possibly a throw?) |
| 19:22 | <Luke Warlow> | In the case that we make a dialog and the append it to a disconnected div and then append that div into the document body do the dialogs insertion steps get ran again? |
| 19:47 | <keithamus> | I wonder; is the easiest thing to avoid asserting that the close watcher exists, and instead create it if it doesn’t? Obviously for some instances that will mess with history activation but in the case of request close I don’t think it matters, right? |
| 19:48 | <Luke Warlow> | The easiest thing I think is to just not spec and implement requestClose the way it's currently written |
| 19:54 | <Luke Warlow> | If we updated dialog.requestClose() to be this, it would just work. We could also then drop dialog's |