| 06:03 | <annevk> | Has anyone looked into why dfn.js or whatever we are using these days in HTML does not work on whatpr.org? |
| 06:05 | <annevk> | Okay, it seems like the problem is that it's looking for it in the wrong place. I wonder if it would be as simple as making those links point to html.spec.whatwg.org. |
| 08:45 | <annevk> | zcorpan: I think https://github.com/w3c/editing/pull/536 is correct, but would appreciate you taking a look. It would be really nice btw if that specification pointed to its GitHub repository (even though it's a mega-repo). |
| 08:52 | <zcorpan> | annevk: thanks, merged. I can add a link |
| 08:59 | <annevk> | Oh, html-dfn.js relies on xrefs.json. So solving that properly would actually be a bit of work. |
| 09:01 | <zcorpan> | https://github.com/w3c/editing/pull/537 |
| 09:02 | <annevk> | smaug: any concerns with me landing the BoundaryPointsRange mixin PR? |
| 09:02 | <annevk> | Aw, looks like I can't stamp there. |
| 09:05 | <smaug> | Trying to see how it gets used with OpaqueRange |
| 09:05 | <smaug> | I guess OpaqueRange will then also define startOffset/endOffset (but not *Containers) |
| 09:06 | <annevk> | smaug: I was thinking it'd define start/end to make it a bit clearer they are different, but yes |
| 09:06 | <smaug> | (yes, they should be start/endOffset, not just start/end. No need to make things too complicated using different terms for effectively the same thing) |
| 09:06 | <annevk> | Well I think they are different things. |
| 09:07 | <annevk> | If we ever had a type for BoundaryPoint, then we could add start/end to AbstractRange and it would return BoundaryPoint or an integer. |
| 09:08 | <smaug> | That would be confusing to return either boundary point or integer , no ? |
| 09:09 | <annevk> | It would depend on the concrete class what you get. For the concrete classes it'd be consistent. But as I understand it the proposal here is to return the boundary point as an integer. Not to return just the boundary point offset. |
| 09:09 | <smaug> | I think these things really are offsets. Offsets in some either virtual or non-virtual data construct |
| 09:10 | <annevk> | Well sure, but a boundary point is an offset too. In the case of range it just happens to consist of a node and an inner offset. |
| 09:11 | <smaug> | Sure |
| 09:13 | <smaug> | So, we have startContainer/endContainer as an additional (what is the word I'm looking for here...) starting point for the offset. OpaqueRange just conceptually has the same start/endContainer (for the API user), so those aren't needed. |
| 09:18 | <annevk> | But why should the API user be concerned with that? It seems conceptually cleaner if an OpaqueRange just has two flat boundary points. |
| 09:19 | <smaug> | I guess that is fine. (assuming they are called start/endOffset 🙂 ) |
| 09:23 | <smaug> | I can't immediately see lots of AbstractRange usage anywhere |
| 09:25 | <smaug> | But still pondering how much do we gain from the mixin vs just having nullable containers |
| 09:26 | <smaug> | One option is ofc also to keep existing ranges as they are now and add (AbstractRange or OpaqueRange) to highlight API and such |
| 09:28 | <jjaschke> | Hm I think it'd be weird to have nullable containers, but the nullability depending on the concrete class (nullable for OpaqueRange, not nullable for (Static)Range) |
| 09:28 | <annevk> | Right, that was my first suggestion (AbstractRange or OpaqueRange that is). I got the feeling the group preferred mixins because they wanted a shared super class? |
| 09:29 | <annevk> | (I don't like calling them start/endOffset because I think it will make people think of the containers, which would be wrong.) |
| 09:32 | <smaug> | (but there are no containers around...so which container to think about) |
| 09:32 | <smaug> | Are there other APIs where AbstractRange is used, I mean other than Highlight |
| 09:33 | <smaug> | Can't find any |
| 09:36 | <smaug> | Maybe (AbstractRange or OpaqueRange) in Highlight would be the cleanest? (I didn't want mixin, I would have created the super-abstract thingie 😛 ) |
| 09:37 | <annevk> | Highlight is the only example I know of. I don't mind adding typedef (AbstractRange or OpaqueRange) AnyRange; for the Highlight API. |
| 09:37 | <smaug> | sounds good to me. jjaschke ^ ? |
| 09:39 | <jjaschke> | Then we would have a new range type that doesn't inherit the range base type? |
| 09:39 | <smaug> | yes. Because OpaqueRange is different enough, I guess |
| 09:40 | <annevk> | Note that none of this has to reflect C++ or in fact how we organize the internal concepts in the specification. This is about what's exposed to JS. |
| 09:42 | <jjaschke> | It's still a range... What if we have AbstractRange { startOffset, endOffset }, OpaqueRange is a direct child, and then have an intermediate NodeRange { startContainer, endContainer }, and StaticRange and Range inheriting from that? |
| 09:42 | <jjaschke> | I guess that is pretty similar to the mixin idea |
| 09:42 | <jjaschke> | So not sure I'm adding too much value here 😅 |
| 09:59 | <annevk> | I kinda like that actually. That’s the new super class idea, but with better naming. |
| 10:02 | <annevk> | And I think it addresses the boundary point vs boundary point offset concern too. As only node ranges have more complex boundary points. smaug? |
| 10:04 | <smaug> | We could do that |
| 10:07 | <annevk> | Of course, the weird thing is that an opaque range is still a node range underneath and has to be updated just like a live range is. In terms of backing concepts this will be somewhat involved to make clean. |
| 10:18 | <smaug> | with custom elements it wouldn't need to be node range underneath. One could use it to create selection in canvas based UI... but now, how would that work with highlight API. It wouldn't? |
| 10:19 | <smaug> | jjaschke^ |
| 10:20 | <smaug> | or perhaps the controller side does need to pass container node always. That would prevent canvas use case, but that is fine |
| 10:30 | <annevk> | Yeah I think ultimately it has to be a node range. |
| 10:30 | <annevk> | Would work with the draw element stuff btw. |
| 10:45 | <annevk> | And to be clear the start and end containers can be different as well so the controller has to look a lot like Range essentially. With some way to also set the fake offsets. |
| 13:22 | <Stephen Chenney> | I wasn't aware of the canvas use cases for OpaqueRange. Is the idea to apply highlights etc to canvas text rendered via fillText and strokeText? |
| 13:23 | <Stephen Chenney> | For the HTML-in-Canvas thing selection stuff is all the same as if the HTML was outside the canvas. |
| 13:29 | <annevk> | Stephen Chenney: I think Olli was just spitballing |
| 14:01 | <annevk> | I summarized the range inheritance discussion here with some informal voting options: https://github.com/whatwg/html/issues/11478#issuecomment-4622847878 |
| 14:46 | <annevk> | jjaschke: did you implement https://github.com/whatwg/html/pull/12263 already? Curious if the test coverage is good. |
| 14:47 | <emilio> | annevk: curious, does https://github.com/whatwg/html/pull/12491 look controversial to you? It matches browser rendering, but via UA sheet rather than internal magic, much like we did for <input type=button> and co. |
| 14:47 | <emilio> | Saying because I'd like to land that change in Firefox to fix a regression, and ideally I'd update WPTs for the UA styles, but I can also land a reftest and follow-up :) |
| 14:51 | <annevk> | emilio: I think usually people prefer expressing things in the style sheet, so no, doesn't seem controversial. But I can't find equivalent rules for <input type=button>. |
| 14:52 | <emilio> | annevk: the selector that I'm tweaking to remove [type=image] as an exception would match type=button ;) |
| 14:52 | <emilio> | But type=button doesn't need content-box (clips border-box instead) |
| 14:59 | <annevk> | emilio: so what's the difference with 0 vs content-box (which also gets 0 I guess implicitly)? You can't specify padding? |
| 15:00 | <emilio> | annevk: if there is padding, <input type=image> clips to it, button doesn't. |
| 15:03 | <emilio> | annevk: (this reminds me that https://github.com/w3c/csswg-drafts/issues/13185 probably also needs HTML spec edits...) |
| 15:07 | <annevk> | emilio: yes it does. |
| 15:58 | <jjaschke> | Landed yesterday. I added a few tests, and tripped over a case today, for which I'll also add one. |
| 16:48 | <smaug> | dandclark: in case I didn't mention, IIRC referenceTarget tests are still missing cases where there are nested shadow DOMs and initially the relevant ID isn't there in some shadow DOM, but is added later (which should trigger updating references) |