- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Apr 2018 08:24:41 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `:selection style propagation`, and agreed to the following resolutions: * `RESOLVED: ::selection is cleared for shipping unprefixed even though multiple impl do not follow the spec.` * `RESOLVED: Switch to using inheritance instead of cascade.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: :selection style propagation<br> <dbaron> and so does CSS 2.1 https://www.w3.org/TR/CSS21/cascade.html#specificity<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/2474<br> <dael> emilio: No one does what spec says. So I think we should change the spec or all impl.<br> <dael> rune_: This has been a topic for multiple F2F. I think we covered it in 2010.<br> <dael> rune_: dbaron has best overview.<br> <dael> dbaron: Selection was spec in selectors 3, but didn't say what it meant. A bunc hof browsers impl something, then we tried to look at what people wanted and expected and I made a list of requirements of what it should do. I think we picked one but no one adjusted.<br> <dael> rune_: I'm not sure we picked one.<br> <dael> dbaron: I don't know. Maybe we didn't. Way selection works in most browsers isn't useful.<br> <dael> florian: I think based on thebackground fantasai spec a thing that makes sense and is useful, but it's not what browsers do today.<br> <dael> dbaron: Other question is is the thing spec compat with what's on the web today.<br> <dael> florian: I think underlying is should we try and make it useful. If we establish that's the goal by applying to qualifying selectors we accept we're willing to go into that level of complexity. If we don't accept hte premise let's not bother. Current spec had the assumption that we wanted to bother. Is that true?<br> <dael> dbaron: The thing in the spec attempts to do useful thing sfor selections and styles. Also there we features we wanted to build on top of ::selection so we can do things like styling spell check region that are on top of this feature.<br> <dael> fantasai: We added grammar and spell check.<br> <dael> emilio: Annoying part of how it's spec is you need to start resolving status to the top.<br> <dael> fantasai: There's different ways of getting same result. THere was an alternative way to have selection inherit from itself in a sep tree.<br> <dael> emilio: You have to resolve the entire tree which is different then what browsers do. I could say that, but I care about browser compat.<br> <dael> emilio: Whoever changes the impl first needs to be aware they might break.<br> <dael> florian: I don't know. It will do it wrong if you try and use it outside :selection<br> <dael> tantek: I'd rather see data on actual use.<br> <dael> TabAtkins: Argument is any current usage that would be effected is almost certainly broken.<br> <dael> tantek: You'd be fine with blink changing ::selector<br> <dael> TabAtkins: I would be fine with our impl to change, it would be better for users. Only global selection is useful right now and that wouldn't change.<br> <dael> emilio: Seems like it would make select-all sort of slow. You need to style whole page again.<br> <tantek> s/::selector/::selection<br> <dael> TabAtkins: recascade<br> <dael> emilio: You pay the cost of selecting the whole page.<br> <dael> fantasai: Don't have to recascade<br> <dael> TabAtkins: Track a full cascade<br> <dael> fantasai: ::selection has 4 properties.<br> <dael> TabAtkins: True.<br> <dael> emilio: But then special casing that.<br> <dael> fantasai: Then you just...instead of using cascading you can use inheritence through selection tree.<br> <dael> rune_: That's what presto used to do.<br> <dael> emilio: Somewhat like blink and webkit do for visible<br> <dael> rune_: Works for limited number of property<br> <dael> fantasai: Has to be limited because non-layout effecting.<br> <dael> TabAtkins: Most are already inherited. Others can be shifted.<br> <fantasai> https://drafts.csswg.org/css-pseudo/#highlight-cascade<br> <dael> fantasai: And I think there's an open issue about describing it to use inheritence.<br> <dael> fantasai: WE can do it either cascde or inheritance but you get same behavior. Main difference is if you fail.<br> <dael> fantasai: Most of the time authors are not setting the inherit keyword. Behavior between cascading and inheritance is that the inherit keywod behaves differently<br> <dael> emilio: Synth prop that are usuallyr eset but are not inherited for purpose of selection...I don't know.<br> <dael> TabAtkins: Happy to desc like that.<br> <dael> emilio: Seems hard.<br> <dael> TabAtkins: Spec text should be fine.<br> <dael> tantek: first-line has similar issues<br> <dael> TabAtkins: NOt a great example<br> <dael> tantek: Older and has more tests<br> <dael> florian: Less constrained because compat. Can effect layout.<br> <dael> tantek: If you look at the ::selection and apply them to first-line you can come up with a reasonable list.<br> <dael> florian: That the set of properties for ::selection is more constrained means you can use more mech.<br> <dael> tantek: But from user/author it's not clear it should be different then first-line<br> <dael> fantasai: I think first-line is not related because it's trying to solve different constraints<br> <dael> TabAtkins: Pretend everything is inherited make sense?<br> <dael> emilio: Will people change?<br> <dael> TabAtkins: WE should try.<br> <tantek> ::selection is only trying to solve a subset of the constraints of ::first-line, which is why it is related and worth looking at<br> <dael> florian: Is it priority or disagreement? If browsers agree but don't prioritize there are people that have fixing browsers as a bug. If the browsers will accept that behavior that's different then we would not want to do this.<br> <dael> emilio: If there's no committment to impl.<br> <dael> florian: I'm saying that there might be and a patch might be written.<br> <dael> dbaron: Other option is put a note in a spec saying it hasn't been impl and we want feedback to see if it would work out and desc the other thing.<br> <dael> florian: Other thing being only global is useful?<br> <dael> dbaron: Yeah.<br> <dael> fantasai: It's easy to describe current impl. That's easy to desc in 2 sentences and add another for why it doesn't work well.<br> <dael> fantasai: I'm with TabAtkins we should try and make it more useful and if that's in terms of inhertence that's fine.I'm with TabAtkins that impl correctly is unlikely to break anybody.<br> <dael> fantasai: I would say if you impl in a way that makes it work no one will be made at Mozilla not doing it right. You have a problem that it's prefixed in your impl. You've got compat on the basic case that works so you should unprefix. Separately then make it useful.<br> <dael> tantek: Reasonable approach. We heard existing unprefix impl are willing to change so that adds weight to Moz can unprefix assuming we're willing to change.<br> <dael> fantasai: Prop: Mozilla should unprefix ::selection impl and the spec should describe how ::selection of a child gets its parent's styles via an incoherence based mechanism<br> <dael> florian: Our process prevents Mozilla from unprefixing and we need to allow.<br> <dbaron> s/incoherence/inheritance/<br> <dael> fantasai: WE generally rec you only ship if you're reasonably complient and people are not and we're saying it's okay.<br> <dael> fantasai: ::selection is cleared for sipping unprefixed even though multiple impl do not follow the spec.<br> <dael> Rossen: Obj?<br> <dael> RESOLVED: ::selection is cleared for shipping unprefixed even though multiple impl do not follow the spec.<br> <dael> fantasai: Currently ::selection of a child is desc with cascade. There are edge cases that will behave different with inherit.<br> <dael> fantasai: Prop: is switch to describing using the ihenretenace rather then the cascade.<br> <dael> Rossen: Current resolution is about cleared for shipping so we need the second resolution to change the spec.<br> <dael> Rossen: Obj?<br> <dael> RESOLVED: Switch to using inheritance instead of cascade.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2474#issuecomment-380369965 using your GitHub account
Received on Wednesday, 11 April 2018 08:24:47 UTC