| 01:56 | <sirisian> | Question about differing behavior in FF and Chrome when focusing outside of a contenteditable with inline-block vs grid. Click below the contenteditable: https://jsfiddle.net/swk91rpx/ Notice for grid it finds the first text content and places the cursor in it in Chrome. I suspect this is a bug in Chrome as I think this happened with inline-block 7 years ago and was changed. Anyone familiar with this topic and could clarify the expected behavior so I know where to file this. (For all I know this edge-case is right for chrome and FF is the one handling it wrong). |
| 07:41 | <annevk> | Anton Maliev: that might be correct, yeah; problem is that not everything has been refactored and we have been running into some issues with this abstraction |
| 07:42 | <annevk> | Anton Maliev: filing an issue and copying inexorabletash and asuth might be a good start |
| 07:44 | <annevk> | sirisian: filing an issue against all of https://github.com/w3c/contentEditable/issues/new, Chromium, and Gecko seems like a good start |
| 07:44 | <annevk> | sirisian: unfortunately the spec is not maintained so this has to be addressed on a case-by-case basis and likely slowly |
| 10:02 | <Andreu Botella> | That might also be a hit testing issue, rather than a contenteditable issue |
| 10:03 | <Andreu Botella> | and hit testing isn't really fully specified anywhere |
| 10:17 | <zcorpan> | zcorpan: so an <img alt=""> should behave the same, for sizes="auto"-testing purposes, as an <img src="5-second-ttfb.jpeg" /> or whatever. Because the default object size of both a loading image and an "img element that represents nothing and the user agent does not expect this to change" are both 0x0. |
| 10:19 | <zcorpan> | zcorpan: although according to the loading image definition, images in this state "may trigger fallback rendering". Is there anything in the "concrete object size ignoring natural dimensions" spec that forbids fallback rendering dimensions from being used? |
| 11:15 | <annevk> | Adam Rice: since Mattias Buelens seems to be out, do you have any thoughts on https://github.com/whatwg/streams/pull/1264? Otherwise I'm gonna approve splitting the test out for now so Youenn is unblocked |
| 14:39 | <Eric Portis (he/him)> | zcorpan: re: you not following, yes -- ignore me, I was confused. Even if the fallback representation is showing, that only adds an intrinsic size, it doesn't change the default or specified sizes. What does Chromium do? Is "your test" part of the WPTs? |
| 14:55 | <zcorpan> | Eric Portis (he/him): https://software.hixie.ch/utilities/js/live-dom-viewer/saved/11743 |
| 14:57 | <zcorpan> | Eric Portis (he/him): since the second element gets full width, chromium treats it as a non-replaced element instead of a replaced element with 0x0 natural dimensions. Haven't written a wpt for this |
| 19:33 | <ntim> | Hi! Can someone please merge https://github.com/whatwg/html/pull/9397 ? |
| 19:41 | <jub0bs> | Apologies, freddy. Work got in the way. I'll shoot you an email as soon as I have more time. |
| 22:27 | <Jeffrey Yasskin> | FYI, https://github.com/w3ctag/design-principles/pull/441 about how to monkeypatch well merged to https://w3ctag.github.io/design-principles/#cant-avoid-monkey-patching. I think it describes what this group wants from monkeypatches, but if I got anything wrong, feel free to comment on the PR, and I'll try to fix it. (or you can always send your own PR of course.) |
| 22:39 | <Eric Portis (he/him)> | annevk: Safari 17's Accept header when making image fetches seems to be: image/webp,image/avif,image/jxl,image/heic,image/heic-sequence,video/*;q=0.8,image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5 (124 bytes). IIUC from https://github.com/whatwg/fetch/issues/862 and https://fetch.spec.whatwg.org/#cors-safelisted-request-header, the limit before a preflight is required is 128 bytes. Is that an impending problem, or (more likely) am I misunderstanding how CORS works? |
| 22:43 | <Eric Portis (he/him)> | zcorpan: Ah! I had only been testing with no src attribute, which behaves differently than an attribute with no value. Fun! |
| 22:44 | <Eric Portis (he/him)> | zcorpan: Anyways, I think I finally have my mental model straight on this. Hoping to write something up about it soon; I'll definitely ping you for review once I do. |