- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 7 Nov 2021 17:08:28 -0500
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= CSS Contain ----------- - RESOLVED: Elements with ancestors of content-visibility:hidden will have no boxes while in top layer. If removed from top layer they get their box back (Issue #6728: Top layer interactions with content-visibility: hidden) - RESOLVED: If the subtree of an element contains a top-layer element it is relevant to the user (Issue #6727: Consider top layer elements 'relevant to the user' for content-visibility: auto) - There is agreement that issue #4598 (Static ranges and css-contain) is a problem that should be solved and the solution should be as limited in scope as possible. The result would need to be observable to the author so they can respond and the current proposal doesn't have that observability. The discussion will continue on github to develop a solution. - RESOLVED: Accept iank's proposal ( https://github.com/w3c/csswg-drafts/issues/6426#issuecomment-941205671 ) to guarantee full layout algorithm is always forward moving (Issue #6426: Ancestor Layout Loops with Single-Axis Containment) - Once the edits for issue #6426 are in the spec, a request will be made for FPWD of Contain 3. CSS Transforms -------------- - RESOLVED: Publish WD for Transforms L2 - RESOLVED: Add dbaron as co-editor of Transforms L1 CSS Cascade ----------- - RESOLVED: Add the cssom rules as .name and .namelist (Issue #6576: Cascade Layers need CSSOM support) - RESOLVED: It [revert-layer] would revert the style attribute and nothing else (Issue #6743: revert-layer keyword in style attribute) - RESOLVED: revert-layer reverts animation origin and nothing else (Issue #6749: revert-layer keyword in keyframes) CSS Highlight API ----------------- - RESOLVED: Republish Highlight API CSS Values ---------- - RESOLVED: Punt attr() and toggle() to Level 5 (Issue #6753: Punt attr() and toggle() to Level 5) ===== FULL MINUTES BELOW ====== Agenda: https://github.com/w3c/csswg-drafts/projects/25 Scribe: dael CSS Contain =========== Top layer interactions with content-visibility: hidden ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/6728 vmpstr: Content-visibility: hidden skip their contents meaning they don't paint. When element is in top layer changes topology of the tree so element is hoisted to root level vmpstr: Proposal is we should say it doesn't paint or generate layout box vmpstr: Could ensure it does generate and paint, but precludes a lot of the optimization vmpstr: Another is we refuse to allow in top layer, but also seems inconsistent smfr: The top layer spec says that top layer elements, containing block is initial contain block. Hoisted out of anything they're inside of. Why is content-visibility different? vmpstr: It's hoisted out of all containment. There's no way to optimize performance of this because then have to always keep rendering up to date. Not sure how common case is. I was hoping this could have the same rule as display:none smfr: That means we need a new concept in css that not containing block or z-order TabAtkins: Just say descendants don't generate boxes liked display:none. smfr: How does that impact rest of the dialog? TabAtkins: You can't focus something that doesn't have a box. That gets skipped smfr: I guess same as calling show dialog on display:none TabAtkins: yes TabAtkins: I put a comment in the issue. Except explicit difference in spec, anything that diverges from display:none should be looked at with suspicion. If there's no reason for difference should be same as display:none chrishtr: I agree with that outcomequeue chrishtr: Wanted to clarify tricky situation is you have an element skipped by virtue of having and ancestor. You have a skipped thing with an unskipped ancestor which is bad. That's why Vlad said we'd lose optimizations. If you treat like display:none where it has a box but if in top layer it becomes like display:none chrishtr: Consistent and simple. I don't think there's a concept to hoist something to the top of tree and make it visible Rossen: Validating an assumption, none of the content elements are a11y, right? vmpstr: Correct. Can be targets of aria label, but not exposed Rossen: Cool Rossen: Sounds like a good approach. Other thoughts? smfr: content-visibility: auto implications? vmpstr: That's the next issue Rossen: What is resolution? Rossen: Option 1? vmpstr: Yes chrishtr: If there is a content-visibility ancestor there is no box. It's in the top layer, but has no box Rossen: Prop: Elements with ancestors of content-visibility:hidden will have no boxes while in top layer. If removed from top layer they get their box back Rossen: Objections? <smfr> is the “it’s in the top layer” observable? Rossen: smfr does the irc question you have need to be covered? smfr: chrishtr said in the top layer, is that observable? If so, through dom? chrishtr: Discussed if it was observable, but not sure vmpstr: Right, I don't know the answer to this chrishtr: Might be if you try...don't know smfr: If it has a backdrop is that display:none too? vmpstr: yeah, it would be same chrishtr: Backdrop pseudo spec has an immediately proceeding box. And there's not box. Might need to clarify text but should be same Rossen: Objections? RESOLVED: Elements with ancestors of content-visibility:hidden will have no boxes while in top layer. If removed from top layer they get their box back Consider top layer elements 'relevant to the user' for content-visibility: auto ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/6727 vmpstr: Text says we skip the contents if the element is not relevant to user. Defines relevant as things that have focus or selection vmpstr: Proposal is add if content-visibility:auto descendant is in top level it is relevant and not skipped chrishtr: Unskips content? vmpstr: Yeah, if you have offscreen content-visibility:auto it would appear in the top layer and the subtree would be rendered chrishtr: Entire tree including offscreen is relevant and not skipped vmpstr: Can't optimize out because have to display in top layer. Can't use same detection for visibility because escapes paint containment vmpstr: If it escapes top layer assume it will be visible chrishtr: If you have description of content-visibility:auto and you full screen the entire subtree will be made visible vmpstr: Correct chrishtr: Including recursive ancestors. Okay. I think it's fine Rossen: Any other comments? Rossen: What's the proposed text? vmpstr: If the subtree of an element contains a top-layer element it is relevant to the user Rossen: Objections? RESOLVED: If the subtree of an element contains a top-layer element it is relevant to the user Static ranges and css-contain ----------------------------- github: https://github.com/w3c/csswg-drafts/issues/4598 dandclark: The problem that this issue is trying to address is if I have a highlight with a static range that crosses a contain boundary, if I remove a node holding one boundary point it causes entire highlight to not paint because it's not valid dandclark: Proposed solution is not to paint highlights that cross contain boundaries. Assumption is it's not a thing authors want dandclark: My understanding is some agreement from editors. Would like to confirm. Also suggestion from sanket this perhaps have same behavior for range to make it consistent to prevent dev confusion dandclark: Proposal would be highlights backed by rangers or static ranges should not be painted if cross a boundary florian: Good summary. Initial was just static but going for consistency why not. This could be paint containment only, but given no use cases we can make it all for simplicity fantasai: Wanted to ask what we'd do about when highlight is similar to selection which frequently crosses the tree fantasai: Contain is used for a lot of things and not clear to me we want to disallow selection type highlights. Something to consider florian: Good point. Need to look into in practice where is contain used. It's component-y. Probably not sprinkled through textual elements. But you're right selections cross boundaries. fantasai: I think you should not restrain for simplicity. I think you should if it's necessary for impl reasons to restrict <fantasai> minimal necessary restriction Rossen: dandclark to confirm, are you saying if I construct the range as you described in which case it will not be painted. From a dev PoV the range is observable; I can inspect it. But visually that is not going to paint based on circumstances range falls into Rossen: Sounds to me pretty unstable approach. To fantasai's point I can imagine flickering if I move the ranges. Would be great if there's a CSSOM or other eventing that interacts or rejects ranges. Strong rejection than avoid paint Rossen: That was it could be handled by author. It will be within the hands of developers <fantasai> +1 to Rossen's point, if we are rejecting a range it needs to be made obvious to the author <fantasai> not just a failure to paint Rossen: From user PoV agree with fantasai that selection today is doing this quite a bit florian: Two things we could do. 1: go back to having minimal which is static range only on paint containment only is invalid florian: On top of that we might want to add an event or observer that lets you discover something has happened. Hard to design that on the fly Rossen: Shouldn't. I think the feedback here is enough to go back and design stronger. florian: I think we could resolve on the type of range and containment, but not the whole story dandclark: I think we're coming to resolve on minimal restriction. For highlight backed by static ranges that cross a paint containment boundary are not painted Rossen: Opinions? florian: Support and then I think there's more to look into Rossen: I wouldn't object, but unsatisfying because opening a problem that makes the discovery of these ranges less obvious to author florian: There is an inherit contradiction between range and container. Not a problem in both direction, but range that's outside to inside a containment boundary and then you make the range not meaningful you want to stop painting. There is a contradiction somewhere Rossen: Yeah. A little unsatisfying. Consider you're the dev on this editing app with ranges and users are complaining they don't see highlight. How do you chase that? If not observable it will be hard to fix. Even if it's legitimate. fantasai: Author will be able to reproduce the error if they select the same range because would refuse to paint. But on the fly can't tell via JS florian: Another approach, though heavy, is if an author tries to create a range crossing an boundary or restyles to create boundary we forcibly split the range to outer and inner Rossen: It's a little better Rossen: But then again not sure a misspelled word is good if you highlight half of it florian: You wouldn't highlight half, but do both with separate ranges. Selection use case is more likely for this. Range for outer part of selection and range or inner part. If you change inner part to no longer make sense you would no longer highlight inner Rossen: I'm with you. Feels like we're designing on the fly. Authors will have all kinds of collections and if you create ranges under you need discoverability. I think there's work to be done here Rossen: Fine with the problem and recognizing we don't want to have these ranges. But if we resolve on something that's strictly worse perhaps we should work more florian: I want to preserve containment invariance. But how we do it needs more thinking Rossen: What if we put it back onto GH and when you work it out, sounds like you're starting to come up with solutions, work it out and then come back Rossen: Sound reasonable? florian: Think so dandclark: Want a gauge on dom observably vs UA trying to be helpful with console warnings. Are we feeling have to be dom observable? florian: I think it's not inherently wrong to want static ranges. Highlight can be anywhere. We should do something that lets author react when it happens Rossen: And being observable through script is key so they can take an action Rossen: Let's end here. I think there's good next steps. <br type=until 22 minutes after the hour> Ancestor Layout Loops with Single-Axis Containment -------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6426 miriam: It turns out this is hard. We knew that miriam: I tried to document 4 known instances where content changing size on 1 axis, generally block, has impact on available size for inline. So if we try and contain inline only get a loop miriam: Generally have a pattern where outer ancestor, element contained on inline axis, inside of that contents responding to container query miriam: With those three nested bits, a few of the issues are orthogonal writing modes. 2 other cases that are common. Ancestor is overflow scroll and the contents can trigger scrollbar on ancestor which changes inline space available miriam: Another is floats as they get taller or shorter how they stack might change miriam: In my first document I wrote out the brute force solutions. They're not ideal for users. iank's idea is better iank: I need to study one of these a bit more but they all fall into effectively we layout a child once with given space, read child height, and based on that give it a new available space. iank: Fundamentally need to make sure we never walk backwards. This is true today <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9775 iank: I pasted in irc an example ^ iank: Orange box and inside it has a child with an aspect-ratio. Consider width first, get height where we can't fix. Then consider second of 50px. All engines walk forwards like that. iank: We don't try and say now that I'm this height maybe I could fit back here after all florian: Do you mean this is the end of the line principle we don't need the pieces miriam highlighted or that it solves them all? iank: I think we state it and it solves them all. Orthogonal. We layout with one set of constraints, layout, adjust. We move forward. florian: I'm a bit concerned this is different than float. We should avoid making css accidentally stateful florian: Float, ancestors are not effected by float in the same way florian: Roughly I feel the way miriam proposed is annoyingly specific but need to do it to avoid vague or stateful iank: I don't think it's stateful. We have a bug on orthogonal, but with that case to compute intrinsic size for the orthogonal child we need to lay it out with some available size. iank: We layout with that size. May effect size of the parent. Now when we do layout pass we give orthogonal child different constraints and it lays out differently florian: That sounds true iank: If you can come up with a case you think is stateful happy to access iank: Orthogonal is hard because engines have a lot of bugs. miriam's example shows a bug florian: For scrollbar and padding do you think we can get away without hatchet miriam proposed? iank: I think so. Aspect-ratio is fine, floats is fine, I think classic scrollbars is fine as long as you add them in a particular way. We'll slowly add scrollbars to get to a state. I think it should be okay florian: I thought if you didn't have miriam's approach you would get a different result if you start on a 800 px window different result then if you start bigger and shrink iank: No, shouldn't be an issue. That's a browser issue and should be fixed. iank: If there is an ambiguous set of steps where we need more specific order we should do that iank: When forming a new context in relation to floats we had a specific order on how people should walk through. Pretty much everything else falls into that florian: If we go that way we can have a spec that's less magic but we need to be very precise so it's stable and interop iank: yes florian: Can someone implementing list the steps? Undefined would be bad iank: Depends what you mean by define iank: We don't have a spec for block layout but we have resolved how floats behave. iank: I can describe how this works for orthogonal children, I think that's well defined florian: My ask would be for the 4 cases miriam highlighted which I think are specific enough, could you either point to the spec language that make them non-problematic or propose sufficient spec text? iank: I can work with miriam on that Rossen: Sounds like we're forming consensus around going forward with reasoning captured in the issue by iank. Additional exercise to figure out where changes have to land Rossen: Anything else to add here? I see people on this issue chimed in florian: Great if we can go there. The things proposed are cludges we thought unavoidable. If they're avoidable, great Rossen: In terms of solution anything else to add here? dholbert: I think your example with aspect-ratio is a good case for something that behaves like this without needing container queries. Good extension of that iank: I think I can create examples as well with time Rossen: We call them test cases; please add them :) Rossen: Let's resolve on path forward. And it'll be iank for you to figure out where edits should go Rossen: Proposal: Accept iank's proposal to guarantee full layout algorithm is always forward moving florian: Sort of important to get to this in a timely manner. This discussion has been going on for years in GH. If there is a solution, great, but I'm worried we will force other browsers to reverse engineer Chrome or do something else if we don't write it chrishtr: Resolution to go with iank proposal? iank: Write it down at least for the examples. Part of the problem is large parts of some algorithms are undefined. Can spec how things should walk forward chrishtr: So parts of algo that intersect need to be written iank: Part of issue is float not well defined. List of side effects. Most recent for float layout is in a GH issue but not in spec. Pointing to the various places we've resolved iank: For intrinsic size we have it written florian: I don't think iank proposal is not self contained enough. It's an approach we need to look into more details. Rossen: Yes. We don't have specifics florian: We agree to try and solve that way. And we go that way and we come back to resolve on details Rossen: Have proposed path forward. Don't have details about specifics, but approach makes sense. You've made your point and people agree. fantasai: We had previously declined to publish fpwd because of this issue. If we get to a point we're okay with the issue we should publish fpwd previous proposal: Accept iank's proposal to guarantee full layout algorithm is always forward moving Rossen: That's the proposed resolution. Objections? RESOLVED: Accept iank's proposal to guarantee full layout algorithm is always forward moving FPWD for contain 3 ------------------ florian: We haven't done it yet, though iank: We've done it in that this is what chrome impl does today florian: Which is what I'm a bit uncomfortable with. Spec says do it, people have to guess Rossen: Let's not publish fpwd yet chrishtr: Once there's text in the spec that encodes the proposal in an algorithm is that sufficient? fantasai: I think we should put what iank described in contain 3. I think if dbaron signs off we can likely all be happy. I propose iank drafts text with florian help and have dbaron review florian: Agree. Even if we state as high level principles let's do that CSS Transforms ============== Republish transforms -------------------- <fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2021OctDec/0037.html dbaron: I sent a long message to group list pointing to changes and calling out 2 aspects dbaron: One was that one of the edits is only half done and I'd like to publish anyway because other half is complicated dbaron: Other is the set of changes that don't have WG resolution. I listed and described them. dbaron: Given those things in my email wanted to know if group was comfortable resolving to agree on the things there without resolutions and to publish a new WD <florian> looked good to me <astearns> +1 to publishing <smfr> i am fine with it Rossen: See a bunch of +1 to publishing Rossen: Objections? <fantasai> +1 to publishing, given smfr's approval RESOLVED: Publish WD for Transforms L2 <chrishtr> congratulations! dbaron: Second thing is to ask to be coeditor of transforms L1. I am not currently Rossen: Ask and you shall receive RESOLVED: Add dbaron as co-editor of transforms L1 CSS Cascade =========== Cascade Layers need CSSOM support --------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6576 <fantasai> https://github.com/w3c/csswg-drafts/issues/6576#issuecomment-943858864 miriam: My understanding is we wanted 2 interfaces, one for statement and one for block rules miriam: block rule has read only attribute of the name of the layer. statement would have read only frozen array of strings miriam: Does that cover it? fantasai: Question was what to call them: .name or .nametext vs .namelist TabAtkins: .names fantasai: .name and .names seems tricky TabAtkins: yeah fantasai: .namelist regardless of the other being .name or .nametext Rossen: .name is shorter fantasai: Great. resolve on that Rossen: Objections or suggestions? RESOLVED: Add the cssom rules as .name and .namelist revert-layer keyword in style attribute --------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6743 miriam: Similar. Question is what does it do in context where layer is not clear. In this case in style attribute. What happens? fantasai: Had recently switched style attribute to be its own origin. Natural fallout is it would revert the style attribute and nothing else. Rossen: Sounds reasonable chrishtr: Is that option 1? TabAtkins: Yes Rossen: Other ideas or objections? RESOLVED: It would revert the style attribute and nothing else <TabAtkins> basically same as doing 'revert-layer' in unlayered author styles revert-layer keyword in keyframes --------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6749 fantasai: Same question. Animations are their own origin fantasai: We have a special rule for revert keyword that causes animation origin to be part of author origin. For revert-layer makes sense to say it reverts animation origin and nothing else Rossen: opinions? objections? chrishtr: This is the recommendation from xiaochengh? chrishtr: Seems like? Rossen: He said he doesn't have strong opinion chrishtr: Okay Rossen: Not hearing objections RESOLVED: revert-layer reverts animation origin and nothing else CSS Highlight API ================== Publication ----------- <fantasai> https://www.w3.org/TR/css-highlight-api-1/ fantasai: We should publish since haven't since last year. Good to get it published <fantasai> last publication December 2020 Rossen: Sounds great astearns: Needs changes? florian: I think we had a resolution and I didn't follow up. Okay to double resolve RESOLVED: Republish highlight API CSS Values =========== Punt attr() and toggle() to Level 5 ----------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6753 fantasai: We think we should drop from L4. attr() and toggle() not quite solid. A bunch of the rest of the spec has been impl fantasai: Narrowing spec to prepare for CR Rossen: Objection? oriol: Question on this. I wonder if mix() should also be deferred. Added recently and issues about syntax fantasai: I think problem with mix() is need it to serialize interpolation of certain transforms. I think we should keep it and work out the issues oriol: Okay Rossen: Hearing no objections RESOLVED: Punt attr() and toggle() to Level 5
Received on Sunday, 7 November 2021 22:09:11 UTC