- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Apr 2022 23:17:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-content] Implementing content:none on elements is not web-compatible`, and agreed to the following: * `RESOLVED: none does not compute to normal` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-content] Implementing content:none on elements is not web-compatible<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6503<br> <dael> dholbert: Basically we arrived at a point where wondering if content:none and normal should be 2 alues as computed style or if it should be alias<br> <dael> dholbert: Seems everyone impl as 2 values. I think that's new information<br> <dael> dholbert: I think we want to stick with that unless reason to change<br> <dael> dholbert: Some subtilty around how none resolves to normal and browsers disagree a bit but I think it's mostly known bugs.<br> <florian> q+<br> <dael> dholbert: I think this issue is no change, but not 100% sure. oriol has done more investigation and left useful comments. Curious his thoughts<br> <dael> oriol: The thing is that in Blink while content:noen and normal are diff computed values you cannot observe it from webpages. One resolves to the other. Possible this could change. When I impl none I didn't want to risk compat but I didn't try.<br> <dael> oriol: In WK there's a recent change from Jan where if set content:none gCS provices none. Otherside get normal. So get diff in WK and they didn't have to revert so seems it's web compat<br> <dael> oriol: I think FF impl and that's web exposed. So maybe can consider different and say resolve to themselves<br> <astearns> ack florian<br> <dael> florian: I think historically the 2 main contexts were regular elements where content:none did nothing and before and after pseudo. marker forces difference where normal isn't empty but none is.<br> <dael> florian: From there I think should try for as distinct as we can. if we have compat issues we can do to the extent required but should keep separate by default<br> <dael> astearns: dholbert you suggested close no change?<br> <dael> dholbert: I had forgotten what oriol mentioned. I tend to think we should wait to see how the WK change survives. If they can keep as distinct in gCS that's the simpliest and I'm sure easy change for Gecko and Blink<br> <dael> dholbert: Potentially resolve in favor of that but might be premature since WK has recently shipped so I don't know how much exposure it has got<br> <florian> [seems reasonable to me]<br> <dael> astearns: Make no resolution and leave issue open for now?<br> <dael> dholbert: Yeah. Might re-agenda+ for another question. i think original request to make them compute to same I think have decided we don't need to. now question of if we can keep them distinct<br> <florian> s/before and after pseudo/before and after pseudo where "normal" was empty/<br> <dael> dholbert: I can add a summary on the issue<br> <dael> astearns: Could resolve we're not going to have them compute to each other<br> <dael> dholbert: Happy on that since it matches existing impl<br> <dael> astearns: Prop: none does not compute to normal<br> <dael> astearns: Will leave issue open with summary from dholbert on what we need to see with time<br> <dael> astearns: Obj?<br> <dael> RESOLVED: none does not compute to normal<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6503#issuecomment-1090913308 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 April 2022 23:17:47 UTC