- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Nov 2021 23:11:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-highlight-api][css-contain] static ranges and css-contain`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-highlight-api][css-contain] static ranges and css-contain<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4598<br> <dael> dandclark: The problem that this issue is trying to addres sis if I have a highlight with a static range that crosses a contain boundry, if I remove a node holding one boundry point it causes entire highlight to not paint b/c it's not valid<br> <dael> dandclark: Prop solution is not to paint highlights that cross cotnain boundrys. Assumption is it's not a thing authors want<br> <florian> q+<br> <dael> dandclark: my understanding is some agreement from editors. Would like to confirm. Also suggestion from sanket this perhaps have same behavior for range to make it consistent to prevent dev confustion<br> <dael> dandclark: prop would be highlights backed by rangers or static ranges should not be painted if corss a boundry<br> <Rossen_> ack florian<br> <dael> florian: Good summary. Initial was jsut static but going for consistency why not. This could be paint containment only, but given no use cases we can make it all for simplicity<br> <dael> fantasai: Wanted to ask what we'd do about when highlight is similar to selection which frequently crosses the tree<br> <dael> fantasai: Contain is used for a lot of things and not clear ot me we want to disallow selection type highlights. Something to consider<br> <dael> florian: Good point. Need to look into in practice where is contain used. It's component-y. Probably not sprinkled through textual elements. But you're right selections cross boundries.<br> <dael> fantasai: I think you should not restain for simplicity. I think you should if it's necessary for impl reasons to restrict<br> <fantasai> minimal necessary restriction<br> <dael> Rossen_: dandclark to confirm, are you saying if I construct the range as you described in which case it will not be painted. From a dev PoV the range is observable; I can inspect it. but visually that is not going to paint based on circumstances range falls into<br> <dael> Rossen_: Sounds to me pretty unstable approach. to fantasai point I can imagine flickering if I move the ranges. Would be great if there's a CSSOM or other eventing that interacts or rejects ranges. Strong rejection than avoid paint<br> <dael> Rossen_: That was it could be handled by author. It will be within the hands of developers<br> <fantasai> +1 to Rossen_'s point, if we are rejecting a range it needs to be made obvious to the author<br> <fantasai> not just a failure to paint<br> <dael> Rossen_: From user PoV agree with fantasai that selection today is doing this quite a bit<br> <dael> florian: Two things we could do. 1: go back to having minimal which is static range only on paint containment only is invalid<br> <dael> florian: On top of that we might want to add an event or observer that lets you discover something has happened. Hard to design that on the fly<br> <dael> Rossen_: Shouldn't. I think the feedback here is enough to go back and design stronger.<br> <dael> florian: I think we could resolve on the type of range and containment, but not the whole story<br> <dael> dandclark: I think we're coming to resolve on minimal restriction. For highlithgt backed bys tatic ranges that cross a paint containment boundry are not painted<br> <dael> Rossen_: Opinions?<br> <dael> florian: Support and then I htink there's more to look into<br> <dael> Rossen_: I wouldn't object, but unsatisfying b/c opening a problem that makes the discovery of these ranges less obvious to author<br> <dael> florian: There is an inherit contradition between range and container. Not a problem in both direction, but range that's outside to inside a containment boundry and then you make the range not meaningful you want to stop painting. There is a contradiction somewhere<br> <dael> Rossen_: Yeah. A little unsatisfying. Consider you're the dev on this editing app with ranges and users are complaining they don't see highlight. How do you chase that? If not observable it will be hard to fix. Even if it's legitamite.<br> <dael> fantasai: Author will be able to reproduce the error if they select the same range b/c would refuse to paint. But on the fly can't tell via JS<br> <dael> florian: Another approach, though heavy, is if an author tries to create a range crossing an boundry or restyles to create boundry we forcably split the range to outer and inner<br> <dael> Rossen_: It's a little better<br> <dael> Rossen_: But then again not sure a mispelled word is good if you highlight half of it<br> <dael> florian: You wouldn't highlight half, but do both with separate ranges. Selection use case is more likely for this. Range for outer part of selection and range or inner part. If you change inner part to no longer make sense you would no longer highlight inner<br> <dael> Rossen_: I'm with you. Feels like we're designing on the fly. Authors will have all kinds of collections and if you create ranges under you need discoverablity. I think there's work to be done here<br> <dael> Rossen_: Fine with the problem and recongizing we don't want to have these ranges. But if we resolve on something that's strictly worse perhaps we should work more<br> <dael> florian: I want to preserve containment invarience. But how we do it needs more thinking<br> <dael> Rossen_: What if we put it back onto GH and when you work it out, sounds like you're starting to come up with solutions, work it out and then come back<br> <dael> Rossen_: Sound reasonable?<br> <dael> florian: Think so<br> <dael> dandclark: Want a gauge on dom obserable vs UA trying to be helpful with console warnings. Are we feeling have to be dom observable?<br> <dael> florian: I think it's not inheritly wrong to want static ranges. highlight can be anywhere. We should do something that lets author react when it happens<br> <dael> Rossen_: And being observable through script is key so they can take an action<br> <dael> Rossen_: Let's end here. I think there's good next steps.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4598#issuecomment-960281043 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 November 2021 23:11:48 UTC