- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Nov 2020 00:29:21 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Move -webkit- prefixed aliases into flexbox?`, and agreed to the following: * `RESOLVED: Add an appendix to flexbox spec for the webkit prefix properties` * `RESOLVED: Add these to the appendix as MUST or MAY depending on impl and SHOULD NOT for authors. Add details about how they're not simple aliases` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Move -webkit- prefixed aliases into flexbox?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5634<br> <dael> TabAtkins: Currently the whatwg compat spec defines the aliases from old wk prefixes for flexbox b/c required for compat. gsnedders asking to move out of compat and into flexbox<br> <dael> TabAtkins: IN general we're okay with putting compat in a spec<br> <dael> TabAtkins: I'm fine<br> <dael> TabAtkins: I would like to put in appendix as fantasai pointed out<br> <dael> TabAtkins: Two things, should we move? If yes, what level of wording<br> <dael> astearns: Add an appendix to flexbox spec for the prefix properties<br> <dael> RESOLVED: Add an appendix to flexbox spec for the webkit prefix properties<br> <dael> TabAtkins: Not consistent with 2019 usage for legacy. We lean toward MUST. Images has SVG with MUST but writing mode was MAY. WE should make consistent but figuring out is separate issue<br> <dael> TabAtkins: For now I'd like a MUST since that seems the more consistently used. Later can have issue to make all consistent<br> <dael> florian: Makes sense and having MUST as default since we wouldn't spec it if it wasn't necessary<br> <dael> fantasai: Yeah, but if you're css renderer who isn't doing web content you won't care<br> <dael> heycam: I think it makes sense MUST. -webkit-appearance type there could be impl with problems but I don't think this is a case<br> <iank_> q+<br> <astearns> ack iank_<br> <dael> fantasai: THere is a renderer who isn't compat with web but does flexbox. I don't want to make them non-comformant<br> <dael> iank_: When you move this into flexbox make sure youd on't list as aliases, they're more complex then that. Compat spec was lying a bit there.<br> <dael> TabAtkins: You're saying compat spec is incorrect?<br> <dael> iank_: My quick reading of it I believe so. My understanding of how we impl is if you've got display-webkit-box you don't look at wk ordanal and then order, you only look at ordinal. You look at one set of properties as a whole. It's a higher level switch. Compat spec says they're alias which is incorrect<br> <dael> heycam: I don't remember off the top of my head but Daniel did it<br> <dael> TabAtkins: We'll resolve it when we do edits<br> <dael> iank_: Yeah, just an FYI. I can give more detail and hacks when you're writing<br> <dael> heycam: WPT doesn't have tests on -webkit-flex things so tests would be good.<br> <dael> fantasai: If they're not imply I'm rather against a MUST for non-web<br> <dael> TabAtkins: I'd propose putting as a MUST for web exposed impl and MAY or SHOULD for others<br> <dael> fantasai: Sure. Go with MAY<br> <dael> astearns: Prop: Add these to the appendix as MUST or MAY depending on impl and SHOULD NOT for authors. Add details about how they're not simple aliases<br> <dael> florian: If you support is may or must depending on context but if you do you have to do it how iank_ desc?<br> <dael> fantasai: Yeah<br> <dael> astearns: Concerns? Obj?<br> <dael> RESOLVED: Add these to the appendix as MUST or MAY depending on impl and SHOULD NOT for authors. Add details about how they're not simple aliases<br> <dael> astearns: If we uncover any differences between how blink and gecko support these it would be good to tease it out<br> <dael> TabAtkins: Yep<br> <dael> heycam: Might be good to file an issue to capture the discussions<br> <dael> astearns: I'm happy to have first attempt go into spec and if there are concerns we should open an issue<br> <dael> heycam: Okay<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5634#issuecomment-722049318 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 November 2020 00:29:23 UTC