- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Aug 2021 23:26:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-highlight-api] Specifying behavior for Highlights involving multiple documents`, and agreed to the following: * `RESOLVED: revert previous resolution and allow any ranges to be added to a registry. At paint time we only use ranges that are with the originating document` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-highlight-api] Specifying behavior for Highlights involving multiple documents<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6417#issuecomment-884332586<br> <dael> astearns: dandclark can you lead?<br> <dael> dandclark: This is a rerun of an issue I raised a couple weeks ago. Reached resolution but thought of an issue<br> <dael> dandclark: Summary is that if we have a couple of same domain iframes have a couple of registries and can add range from wrong window. Resolved to make impossible by throwing when you attempt to add highlight registry from another window<br> <dael> dandclark: This is trying to establish invarient where they only have ranges from same window. Issue might be is if I add range from same window and I moved to another window I have violated the invarient and it's not clear what to do<br> <dael> dandclark: No straightfoward way to block unless we check when we move<br> <TabAtkins> q+<br> <florian> q?<br> <dael> dandclark: like to revisit if throwing is right. If we can't maintain this invarient re-open allowing and during painting step they're skipped.<br> <astearns> ack TabAtkins<br> <dael> TabAtkins: If we can check what window they're from at painting time I'm not sure why it's problematic to check upon assignemnt to registry<br> <dael> dandclark: We can, but if at time assigned to registry it's correct but then I can take and position in a different window and it's too late to stop<br> <florian> q+<br> <dael> TabAtkins: Oh, didn't realize range could move like that<br> <dael> dandclark: Codesnip in the issue<br> <dandclark> https://github.com/w3c/csswg-drafts/issues/6417#issuecomment-884332586<br> <iank_> ranges are amazing like that.<br> <dael> florian: I haven't followed this closely, but it reminds me of interaction between ranges and css contain where range had one end outside and one within and the possibility that changing violates containment<br> <dael> florian: Had considered having in dictionary and ignoring it. I don't think we resolved there and it's still open<br> <astearns> ack florian<br> <smfr> q+<br> <florian> q-<br> <sanketj> q+<br> <astearns> ack smfr<br> <dael> smfr: Do we need to invent a new kind of range that's live but contained in a single document? Cannot move between docs?<br> <dael> TabAtkins: And restrict to only accept that type?<br> <dael> smfr: Range would associate to that document and throw if you call with a node from different doc?<br> <dael> TabAtkins: But we only allow that new type of range with this API?<br> <dael> smfr: Possibly<br> <dael> TabAtkins: If we didn't restrict not sure what we gain with the new range type<br> <dael> smfr: Yeah, only get benefits if you enforce using the new kind of range<br> <astearns> ack sanketj<br> <florian> the css-contain issue is : https://github.com/w3c/csswg-drafts/issues/4598<br> <dael> sanketj: I wanted to echo what florian was saying. Similarities with the contain boundary case where it doesn't make sesne for range boundry to check and it's allowed at paint and we decide then to allow<br> <dandclark> +1 to what sanketj said :)<br> <dael> sanketj: This should work same where we allow authors to place ranges where they want but when we paint we only paint those on same originating doc as the highlight registry. That's my preferred solution here<br> <Rossen_> q?<br> <GameMaker> +1 for sanketj/florian's solution as well<br> <Rossen_> q+<br> <dael> astearns: I think I prefer that solution as well. I can imagine this being whack a mole where we restrict things being added and someone comes up with a method of getting a range into a registry we hadn't thought of<br> <heycam> q+<br> <dael> astearns: Seems like it's fitting the problem better<br> <astearns> ack Rossen_<br> <dael> Rossen_: I agree with the path forward.<br> <dael> Rossen_: Before we resolve, sanketj or florian can you remind us what the OM or a11y model behind the ranges? How would they be exposed to assistive tech. xpose collection, only active, etc.?<br> <dael> florian: I think unresolved in spec. Maybe sanketj knows what was explored impl-wise<br> <dael> sanketj: I don't think we've reached exploring how to expose. OM-wise the highlight, range objects are OM types we're working with<br> <dael> Rossen_: I think it would be unfortunate if we reach too far into impl without considering those scenarios. I would suggest to start thinking through these<br> <dael> florian: You're right. It's been known for a while but it's about time we look into it<br> <astearns> ack heycam<br> <dael> heycam: Just realized I thinkw e have another instance of this which is selection object from getSelection. I don't remember what happens but maybe we can see what that does and perhaps do the same<br> <dael> astearns: Anyone know what happens for selection?<br> <dael> sanketj: I don't know how selection values update, but nothing blocks from being selected in another document. I'm not sure what happens when it does, though. Nothing stops it from being placed in arbitrary locations<br> <dael> astearns: previous resolution was throw on mismatches<br> <dael> astearns: I'm hearing prop is revert previous and allow any ranges to be added to a registry. At paint time we only use ranges that are with the originating document<br> <dlibby> q+<br> <dael> astearns: Any discussion on that prop resolution?<br> <astearns> ack dlibby<br> <dael> dlibby: We kept mentioning paint time. Is it more about how properties cascade? Or is it really checking when you paint?<br> <dael> TabAtkins: I suspect it will be some ranges are valid when in right document and painting will only paint valid ranges. And that would let you hook to a11y tools where they only get valid ranges<br> <dael> florian: And the cascade is for set of ranges for whole highlight so some invalid range doesn't change cascade<br> <dael> dlibby: that's right, thanks<br> <dael> astearns: Any more commets?<br> <dael> astearns: Obj?<br> <dael> RESOLVED: revert previous resolution and allow any ranges to be added to a registry. At paint time we only use ranges that are with the originating document<br> <dael> astearns: Thanks for bringing this up again dandclark<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6417#issuecomment-893041246 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 August 2021 23:26:42 UTC