- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Apr 2020 17:00:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `subtree-visibility CSS property`, and agreed to the following: * `RESOLVED: Move subtree-visibility into CSSWG` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: subtree-visibility CSS property<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4843<br> <dael> chrishtr: Like to know if there's any other things to discuss on this property before settling on it<br> <dael> chrishtr: Agree syntax is okay and adopt it<br> <dael> AmeliaBR: Requesting approval of current spe text?<br> <dael> chrishtr: Yeah, linked in issue<br> <AmeliaBR> https://wicg.github.io/display-locking/index.html<br> <dael> fantasai: You have a draft. We can agree this is largely what we want. There's a pile of open issue before sign off but I don't think that's what you're asking for.<br> <dael> chrishtr: Like to know about general agreement on draft spec<br> <dael> AmeliaBR: This is WICG spec so officially adopt as CSS?<br> <dael> chrishtr: Yes or we handle like contain-intrinisic-size<br> <dael> cbiesinger: It's in sizing 4 isn't it?<br> <dael> fantasai: It's always been there.<br> <dael> chrishtr: I see. My bad. Okay.<br> <dael> Rossen_: Do we have at least 2 impl interested in moving this to CSS out of WICG?<br> <dael> Rossen_: My udnerstanding is one requirement to move out of WICG is it should be fairly stable which I think you're signaling. Other is that there are at least 2 implementor commitments to impl.<br> <dael> chrishtr: Confused since various other css have been written without that commitment.<br> <dael> Rossen_: It's WICG rules, not CSS. I'm fine to move this to CSS which is where work belongs.<br> <dael> Rossen_: Is that something group wants to do?<br> <dael> florian: WICG charter does not have strict rule on 2 implementors. They like it, but it's not a strict requirement.<br> <dael> fantasai: My position is if we're going to work on this in CSS we should move it in and do FPWD. If there are other browser vendors that believe this is bad instead of it's not a priority those concerns need to be raised.<br> <florian> +1 to fantasai<br> <dael> Rossen_: I think we can try and do that here and now. I believe we have 4 majro browsers represented.<br> <dael> Rossen_: Any objections to move the work into CSS as an official ED?<br> <dael> smfr: Mozilla has a position that says it's under review and notes a problem where it allows you to detect a11y enabled. Our internal review reveals we have concerns on the API but do not have a decision on it.<br> <smfr> https://github.com/mozilla/standards-positions/issues/135<br> <dael> smfr: I would encourage chrishtr to look at MOzilla feedback and add security/privacy section.<br> <dael> chrishtr: Those comments are out of date. Have conversations with Mozilla. There is security and privacy now and concerns are resolved.<br> <smfr> https://wicg.github.io/display-locking/index.html#priv-sec<br> <dael> smfr: Section is empty as far as I can tell<br> <dael> chrishtr: In explainer. Sorry. I agree needs to be added.<br> <dael> Rossen_: With that addition smfr are you okay with moving it to CSSWG?<br> <dael> smfr: I think so. We don't have intent to impl soon but don't object to the problem being solved.<br> <dael> Rossen_: You don't object to work being don't<br> <dael> smfr: Yeah, I think so<br> <dael> Rossen_: Objections to move subtree-visibility out of WICG?<br> <dael> dbaron: A bunch of other people from MOz have been looking and working with chrishtr so not sure current state. Not sure our position on interest to impl. But I think it's reasonable for the discussions to be in CSS WG<br> <dael> Rossen_: I'm hearing comments in favor with asterisk there's more work to be done. Given this is a CSS feature I think authors will get value of CSSWG being engaged.<br> <dael> Rossen_: Is Vlad a group member? To retain we need to move him over<br> <dael> TabAtkins: I'll help chrishtr with that<br> <dael> chrishtr: I'll work on that and security and privacy section next.<br> <dael> fantasai: Comment about renaming to subtree-visibility. I don't think it's nec for spec to match property name. Property might get renamed. It should be about what is concept of spec. Not property name. Just for shortname consideration.<br> <dael> dbaron: Display locking made sense for waht used to be there, not what's currently in.<br> <dael> fantasai: The shortname which is the file name.<br> <dael> AmeliaBR: It goes in the URL<br> <dael> chrishtr: I see. URL should agree with name of property?<br> <dael> fantasai: It doesn't have to<br> <dael> Rossen_: Can name spec display locking if that makes sense to explain feature, or something else, but it doesn't have to be property name.<br> <dael> florian: And there's an open issue on property name but doesn't block naming spec whatever we want.<br> <dael> chrishtr: Should I just pick a name and we rename later? We like URLs to be consistent.<br> <dael> fantasai: Talk with TabAtkins and others, look for a good short name, bring it to the call. Nice to start with a good name but we can set up redirects if we change.<br> <dael> Rossen_: Let's see if we can resolve. I've called for objections and didn't hear any. I think conversation reflects feedback about naming, editors, and privacy section. Once more, objections to move subtree-visibility into CSSWG?<br> <dael> RESOLVED: Move subtree-visibility into CSSWG<br> <dael> chrishtr: Great. Please take a read through and see if there's any way to improve spec or handle unhandled cases.<br> <dael> chrishtr: Example inkoverflow issue raised by Mozilla we were able to resolve.<br> <dael> Rossen_: Yep. I think being under CSSWG you'll get more engagement.<br> <dael> chrishtr: Excellent<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4843#issuecomment-611075162 using your GitHub account
Received on Wednesday, 8 April 2020 17:00:22 UTC