- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Mar 2021 16:42:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-highlight-api] Priority by number or some other method`, and agreed to the following: * `RESOLVED: leave custom highlight properties in the api as in spec` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-highlight-api] Priority by number or some other method<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4591<br> <emilio> vmpstr: yeah, flackr commented on the issue, should've figured that one out, d'oh :)<br> <dael> sanketj: Within these custom highlight overlays there's defualt order based on order registered. Highlights added later are painted on top<br> <dael> sanketj: Problem we're trying to solve is what if author want earlier registered on top<br> <dael> sanketj: Couple of options<br> <dael> sanketj: 1 is what we have in spec which is define priority property on highlight OM type. Number you can set >0 to give priority<br> <dael> sanketj: ex: If you have foo and bar highlights and bar registered later, bar paints on top. If you want foo on top set priority=1 and we would get that effect<br> <dael> sanketj: Another approach is not use priority but use highlight registery as source of true. Introduce additional APIs liek insertBefore which lets you change the order. Don't need additional concept, but means we can't re-use API surface. Seems like a lot of overhead<br> <dael> sanketj: Not super happy about that approach. I prefer what's in spec. Want other thoughts<br> <fantasai> +1 to not using CSS property<br> <dael> sanketj: On more aproach listed is similar to first but use a css property for priority. Don't think it works b/c it sets individual pseudos not for the overlay. Shouldn't be able to stack per pseudo element differently<br> <dael> florian: Agree. I don't think anybody loves similar to z-index but everything else seems worse<br> <dael> florian: Separate issue, if we go with number is it int or float and are negatives allowed<br> <dael> sanketj: Right. If we have time we can go in to that. Want to get resolution of should we allow a number at all<br> <dael> astearns: Side convo between fantasai and TabAtkins on IRC<br> <dael> fantasai: I just asked TabAtkins what he thinks. I'mnot super familiar.<br> <dael> fantasai: Question, between options 1 and 3 if there was some kind of standard interface for a lengthless type set what would your preference be?<br> <dael> sanketj: If we had something we could reuse?<br> <dael> fantasai: Yeah. One of hesitations is we would need custom impl. If that wasn't the case, what is preference?<br> <dael> sanketj: Highlight registry seems more about registration. Seems weird to manipulate that b/c then it's about control not jsut registering. I think I'd still prefer priority by number<br> <dael> florian: Agree. Having explicit manipulation would be clumnky. Maybe a little more powerful. but if you're developing all highlights you pick a number. If using libraries you'll be satisfied with neither direct numbers or direct manipulation<br> <dael> florian: I think the simpler thing is better<br> <dael> florian: Maybe you want some sort of constraints but we don't want to bake that into browser. That's on 3rd party library<br> <dael> fantasai: I think that order used as registered is tiebreaker is useful. Within library you can register back to back and they'll file together. With other method that's trickier<br> <dael> astearns: If you have 2 and concerned about way they overlap you register with numbers that have relationship you like. As others are registered that doesn't change order you register in<br> <dael> florian: You can register both at 733 in the right order and even if someone uses that number they won't be able to interjuct between<br> <dael> florian: I think there's been a bit of back and forth and no one loves numbers, but everything else is worse in some way<br> <dael> fantasai: Seems reasonable<br> <dael> astearns: Positive int or allowing float so you can fit inbetween<br> <dael> plinss: Going back for a second. If answer is this will not satisfy anybody why don't we do the manager?<br> <dael> florian: You'll need a manager if you haev multiple lib with multiple highlights. If you jsut write 3 yourself you give a number and you're fine<br> <dael> sanketj: Agree<br> <dael> fantasai: If the lib accept a param you can pass in a number unless you want to interleave. If you pass in to register at 6 that's straight forward.<br> <dael> plinss: Isn't that a common case? Isn't it common libraries won't bother to care about others that always use highlights<br> <dael> plinss: In order for multi lib to work they have to be aware of each other. I don't think that's common case<br> <dael> sanketj: Common to have spell check ext to have highlights, paging to have highlights. Uncoordinated use cases. For that there's no good solution. They could manipulate priority or the highlight registry. I don't think anyone is trying to solve that problem that a manager would do.<br> <dael> sanketj: Trying to provide a middle ground so uncoordinated access is not an issue and let authors manage the highlights they want<br> <dael> florian: Even if lib don't coordinate you can do it after they set. Only if they're trying to fight each other. You can fix it for them if they don't care<br> <dael> GameMaker: Cane we change priority after?<br> <dael> florian: It's an attribute you can set<br> <dael> GameMaker: Okay<br> <dael> plinss: Not the hill I want to die on, but concerned platoform has half solutions that require 3rd party library to work consistently. Don't want to add another<br> <dael> florian: I don't think you need a manager<br> <dael> astearns: Since plinss won't die on the hill, sounds like we have consensus to add to API as a priority<br> <dael> florian: Can we resolve on that? Sep issue for number<br> <dael> sanketj: There are. Not on agenda.<br> <dael> florian: They're separable<br> <dael> astearns: Prop: Keep what is in the spec for priority<br> <dael> astearns: Obj to leave custom highlight properties in the api as in spec<br> <dael> RESOLVED: leave custom highlight properties in the api as in spec<br> <dael> astearns: Lots of other items on agenda. Hash out number type in issues?<br> <dael> sanketj: Yes, we can do that<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4591#issuecomment-805981898 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 March 2021 16:42:23 UTC