- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 7 Nov 2021 17:08:08 -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 Variables ------------- - RESOLVED: Publish an updated CR draft of css-variables (Issue #6783: Publishing css-variables) CSS Environment Variables ------------------------- - heycam will create a list of all remaining env variables that need to be added to the spec so they can be resolved on and the FPWD can be published. (Issue #6729: Publish css environment variables fpwd) CSS Writing Modes & Shadow Parts -------------------------------- - RESOLVED: Accept fantasai's proposal ( https://github.com/whatwg/html/issues/3699#issuecomment-951423468 ), get it written into spec, have tests updated to match (Issue #6609: Directionality inheritance into Shadow DOM) CSS Nesting ----------- - RESOLVED: Change nesting draft to use open/close brackets, and add a note to show that syntax vs. what Tab would prefer (Issue #4748: Syntax suggestion) - RESOLVED: Our preference is for a single syntax for nesting (Issue #4748) - RESOLVED: Don't have nesting om using its own interface; instead, just allow style rule to contain a list of style rule (Issue #4748) CSS Masking ----------- - RESOLVED: SVG clip-path bounding box units refer to CSS border-box of element to which applied (Issue #5786: "object bounding box" needs to be better defined for CSS boxes) - The spec editors were given an action to audit the spec for other ambiguities similar to the object bounding box one. - RESOLVED: clip-path and masking should follow same rules as backgrounds with regards to box-decoration-break (Issue #6383: Not clear how clip-path applies to fragmented elements) Media Queries 5 --------------- - RESOLVED: Take all the "don't implement this" notes out of MQ 5 (Issue #4834: Note/Issue on not shipping early proposals) - A note will be added to the video-* media queries to state that what is in the spec is likely wrong, but the group hasn't figured out the right approach yet. CSS Lists --------- - RESOLVED: Skip 0 increments when determining the starting value of a reverse counter (Issue #6738: Automatic start value of reversed list is affected by 'counter-increment: <counter> 0' nodes) ===== FULL MINUTES BELOW ====== Agenda: https://github.com/w3c/csswg-drafts/projects/25 Present: Rossen Atanassov Tab Atkins-Bittner David Baron Oriol Brufau Daniel Clark Elika Etemad Simon Fraser Megan Gardner Chris Harrelson Daniel Holbert Dael Jackson Brian Kardell Ian Kilpatrick Vladimir Levin Peter Linss Alison Maher Cameron McCormack Eric Meyer Tess O'Connor Florian Rivoal Alan Stearns Miriam Suzanne Scribe: dholbert CSS Variables ============= Publishing css-variables ------------------------ github: https://github.com/w3c/csswg-drafts/issues/6783 TabAtkins: As Chris said, we already have a pretty good test suite for variables TabAtkins: I think changes list is reasonably up to date. If not all there, mostly-there TabAtkins: Got it mostly ready a couple months ago. Let's take it over the finish line astearns: proposed resolution: publish an updated CR draft of css-variables RESOLVED: Publish an updated CR draft of css-variables CSS Environment Variables ========================= scribe: fantasai Publish css environment variables fpwd -------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6729 TabAtkins: As noted in the issue, the only real problem is that apple has a whole bunch of env variables that have yet to be submitted to spec TabAtkins: Don't want to publish fpwd without knowledge of all the variables that exist in the wild TabAtkins: both from a usability and a patent perspective astearns: Looked like 4 additional environment variables not in the spec? TabAtkins: More than 4 TabAtkins: Don't remember precise list... TabAtkins: Are we looking for a list to resolve on? astearns: Want to know scope of work to do to FPWD TabAtkins: Get that list in the spec, and have WG approve the list astearns: Anyone from Apple know whether list of shipping env variables are things that should go into the spec? heycam: Didn't look at the spec, so unsure how it matches WebKit heycam: but happy to take an action item to look into it ACTION heycam: Come up with list of WebKit environment variables for standardization astearns: Open separate issue for adding the environment variables, please CSS Writing Modes & Shadow Parts ================================ scribe: dholbert Directionality inheritance into Shadow DOM ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/6609 emeyer: What the WG needs to do is look at the concrete proposal that fantasai put in the whatwg thread emeyer: and resolve whether that's how directionality and shadow dom interact with each other emeyer: It's fantastically clear, fantasai ++ emeyer: whatwg wants to know how csswg thinks they should interact emeyer: fantasai has a proposal, we need to decide if that's what we want to sign on to <astearns> proposal: https://github.com/whatwg/html/issues/3699#issuecomment-951423468 <florian> seems right to me, and I fully trust fantasai to get this right TabAtkins: I have given this a read over, it's a slightly more detailed version of what I wanted to propose. Agree 100% with fantasai's proposal astearns: How does this proposal match existing tests emeyer: It may not; but existing tests were created based on the conversation in this thread. Need to update tests to match our resolution emeyer: I'll have some tests I need to change, not a problem astearns: Only problem could be if updated tests show browsers are failing in ways that keep them from being able to implement the proposal fantasai: They are currently failing to match the proposal; that's been known. Current behavior in browsers is not what we want astearns: We have looks like 3 reviews of the proposal which are thumbs up astearns: Proposed resolution is to accept fantasai's proposal, get it written into spec, have tests updated to match astearns: Objections? RESOLVED: Accept fantasai's proposal, get it written into spec, have tests updated to match astearns: Who is going to do spec edits? fantasai: It's a shadow dom spec issue, outside the scope of the csswg fantasai: Nothing we need to update in our own specs CSS Nesting =========== Syntax suggestion ----------------- github: https://github.com/w3c/csswg-drafts/issues/4748 TabAtkins: I'll give initial presentation, and then others can argue for their preferences TabAtkins: leaverou and fantasai have some concerns about the currently-proposed syntax, particularly that it has two variants TabAtkins: The way it's written now, you can nest a style rule inside of another style rule TabAtkins: you need to use ampersand TabAtkins: Alternately, if you want it somewhere other than at the start, you use the @nest syntax TabAtkins: Two suggestions in the thread. one: always require wrapping set of curly braces, to syntactically distinguish rules from properties TabAtkins: few other variants on that <fantasai> see Miriam's comment at https://github.com//issues/4748#issuecomment-924118287 TabAtkins: I objected, don't like it; it means any nested style rule ends up being indented two levels from its parent TabAtkins: Any non-trivial amount of nesting really blows out your margin, gets far over in your code editor TabAtkins: What I settled on at the end is just to always require an @nest rule. Throw away completely unlabeled rule, always use @nest TabAtkins: Possibly be able to have @nest without a selector and nest style rules inside of that TabAtkins: Not sure I like that part, OM will get a little messy, similar to how layer has two representations for same rule name TabAtkins: My initial proposal is that you remove the direct nesting and always make you use @nest rule fantasai: I think that I'd like to pick a syntax that's consistent, so there aren't multiple variations that are different. That's confusing fantasai: We should pick a syntax that's not noisy, since this is going to be used all over the place. This is a structural thing, and basic; I expect to see this a lot in the future fantasai: I don't have a problem with the extra indentation; that's an argument for not using very large indents, basically fantasai: leaverou raised some issues about how you'd handle the nested version of [...] mixed with selector lists, which is awkward <TabAtkins> Lea's comment: https://github.com//issues/4748#issuecomment-940160175 fantasai: I think the curly-brace syntax is fine, I understand you don't like it, want to hear from other people astearns: I'm not a big fan of the pure-symbol syntax, whether it's braces or ampersand. More difficult to notice, search for astearns: If everything required @nest, that seems easier to read, if slightly more difficult to type fantasai: You have to balance that against how basic is the syntax & how often it will be used fantasai: e.g. we don't have @Style for style rules; we just have selectors fantasai: We don't write begin/end; CSS syntax is built out of these symbols fantasai: We have other selectors like @font-face which aren't used all the time, so they have to be clear fantasai: Nesting syntax is closer to the former case, so most stylesheets will have a lot of it. So we don't need to have a keyword to make it searchable; it'll just be an obvious way to structure your CSS fantasai: People have been using nested selectors in preprocessors without any kind of keyword fantasai: Maybe we end up with a keyword, but I don't know that we need to fantasai: Having it all over your stylesheet, in front of every single rule, would be terribly noisy. They're not important fantasai: The markup should fade into the background astearns: Is that an argument for only doing open/closing braces? fantasai: If we're insisting on a keyword, we could do @nest with braces. If we have it in front of every selector, that would be noisy fantasai: If we're going to have curly braces, you might as well just put them there. don't need a keyword fantasai: As long as we're not requiring it in front of everything, it's less of an issue <TabAtkins> https://www.irccloud.com/pastebin/HyBOx2gA/ miriam: Not surprisingly, I agree with fantasai miriam: I like how clean and simple and unrepetitive it is astearns: Do you always get extra indentation, or is it possible to have a bare selector and then its decl block indented once? fantasai: It's up to your own indentation file & how you organize your code fantasai: The idea is, inside a selector, you put open and close curly braces in the same spot where you would put a declaration fantasai: and that indicates you're going to put some style rules <TabAtkins> https://www.irccloud.com/pastebin/nakoTt1z/ fantasai: and that's important for selector parsing [...] <miriam> the proposal we made in this comment: https://github.com//issues/4748#issuecomment-924118287 fantasai: At the top of the issue, there was a suggestion to use parenthesis, which is roughly what we're proposing here, except using curly braces fantasai: If you're not mixing declarations and style rules in the same selector block, you can just double-up your curly braces and indent one level fantasai: and that's pretty reasonable, but if you're mixing, you probably want to indent two levels for the case where you're including a selector <TabAtkins> (I find all the ways to avoid extra indents being easy to mess up, especially when editing later.) astearns: So we have two competing ideas astearns: I like the idea of having a single syntax, not an at-rule vs ampersand depending on syntax astearns: Sounds like either we use at-rule everywhere or open/close braces everywhere astearns: Not hearing consensus, I'm hearing "I could live with" TabAtkins: I really really don't like the double-indent TabAtkins: people can't easily adjust indentation files without messing with other code TabAtkins: [...] astearns: One argument for the bracketed version: it's easy to see what's being declared at each level of indentation astearns: You can read down a column and it's all the same sort of thing at a given level of indentation fantasai: If we don't just do curly-braces, you'll need to prefix every single selector with something fantasai: Don't want that to be @nest; that's too noisy fantasai: single symbol is not so bad, but then selector prelude in unnested style rules will be different from nested style rules which is also not great fantasai: nesting another block in there is the right way to go <florian> I'm mildly in favor of the braced syntax, but I don't feel terribly strongly either way heycam: Agree with fantasai heycam: Indentation is least important consideration of the things we're considering heycam: We often add @media or @supports rules and don't worry about additional indentation there heycam: I agree @nest syntax looks pretty noisy TabAtkins: @media usually isn't nested TabAtkins: I'm not worried about one level of indentation, but rather 3 levels TabAtkins: That's enough to trigger lint warnings in many systems astearns: I have a terrible idea astearns: each nested selector could start with three colons astearns: we've only used 2 so far! astearns: [sarcasm, I think :D ] astearns: Anyone who wants to publicly argue against bracket syntax? (aside from TabAtkins ) astearns: small number of folks on call, but let's try a small straw poll <miriam> {} <TabAtkins> @nest <smfr> {} <fantasai> {} <astearns> {} <florian> {} <vmpstr> {} <heycam> {} <hober> {} <dholbert> {} astearns: Are you ok with brackets, TabAtkins ? TabAtkins: I really want to show a normal stylesheet and how hugely indented it gets TabAtkins: Happy to take a provisional resolution for now astearns: What does SASS use? TabAtkins: Nothing, you just directly nest them in. Three deep = three indents astearns: And that's not possible for us? TabAtkins: There are certain selectors you can construct that look like property declarations TabAtkins: Requires too much lookahead for UAs to implement that <emeyer> +1 to seeing side by side code examples astearns: Should be a note in the spec astearns: proposed resolution: change nesting draft to use open/close brackets, and add a note to show that syntax vs. what Tab would prefer RESOLVED: Change nesting draft to use open/close brackets, and add a note to show that syntax vs. what Tab would prefer fantasai: We also should resolve to have a single syntax for nesting RESOLVED: Our preference is for a single syntax for nesting TabAtkins: One final question in this: right now, the spec defines the nested style rules to use a different OM class. the css nesting rule interface TabAtkins: If we're using a single syntax, then I don't think that makes a lot of sense? TabAtkins: They are in every possible way equivalent to a style rule TabAtkins: So my proposal is to just switch to use the existing CSS Style Rule interface in CSSOM astearns: So the only change is to change CSSOM to allow style rule to contain a list of style rules astearns: Proposed resolution: not have nesting om using its own interface; instead, just allow style rule to contain a list of style rules RESOLVED: Don't have nesting om using its own interface; instead, just allow style rule to contain a list of style rule CSS Masking =========== scribe: fantasai scribe's scribe: TabAtkins "object bounding box" needs to be better defined for CSS boxes -------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/5786 astearns: Conclusion from IRC conversation? chrishtr: Chrome uses just the border box of the element only chrishtr: Firefox includes descendants chrishtr: So Chrome seems to implement what we want, which is to use border box and not bounding box of descendants smfr: This resolution would affect Gecko; WebKit already matches dholbert: Unsure what we're doing exactly, but proposal sounds pretty reasonable astearns: So proposed resolution is to use the border-box for masking in SVG? fantasai: Is this changing the interpretation of the fill-box keyword? Or just the interpretation of what we do by default, and in what properties? chrishtr: I think it's changing interpretation of "object bounding box" for clip-path <chrishtr> clipPathUnits="objectBoundingBox" astearns: Is there a way to change to use something other than object bounding box? astearns: Is that only the default behavior or ...? smfr: fantasai's point is valid, we need to resolve ambiguities between when object bounding box is applied to CSS smfr: Problem with fill-box and border-box being different chrishtr: Can specify various boxes iank: Also bug/ambiguity, when fragmented iank: Need to clarify applying to each fragment independently astearns: Proposed resolution as stated is not everything we need to fix? fantasai: I think the fill-box keyword is mapped to the object bounding box, and also to the content box fantasai: So does that change, when fill-box is specified explicitly? fantasai: If it does get redefined, do we do so only for clip-path or for all places? fantasai: So we need to dig in and see if we were only affecting clip-path:<initial-value>, clip-path:fill-box, or <any-property>:fill-box heycam: For clip-path object bounding box, no way to switch to another box heycam: so if we are changing definition of 'fill-box', would need to consider in other contexts heycam: but at the moment, I don't think there's a way to explicitly select any of the other boxes astearns: There is in CSS, but maybe not in SVG heycam: I don't think those would affect how SVG clip path would be positioned astearns: Do we have a simple resolution and then action to audit? chrishtr: Let's resolve, and then ask editors to audit and come back to group astearns: sgtm astearns: What's the proposed resolution? chrishtr: If you set 'clip-path' to use object bounding box units in an SVG-based clip-path, it refers to bounding box of the element to which clip is applied * fantasai assumes = border box in CSS? chrishtr: border box proposed resolution: SVG clip-path bounding box units refer to CSS border-box of element to which applied RESOLVED: SVG clip-path bounding box units refer to CSS border-box of element to which applied ACTION: Editors to check if any other related ambiguities Not clear how clip-path applies to fragmented elements ------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/6383 scribe: dael heycam: There's nothing in the css masking spec that says how clippath interacts with box decoration heycam: Slight reference to break in section for mask image that implies it applies to masks on fragmented elements heycam: Did some testing with clip-path and found safari, firefox, and chrome different heycam: What I would expect is similar to what happens to borders where if you have background-decoration break slice you would slice up the clip and apply with different offsets heycam: break then evaluate size and position differently for each fragment <fantasai> +1 to honoring box-decoration-break as heycam described heycam: FF and Chrome similar in that they apply the clip-path computed based on one fragment, but using different elements. Webkit computes bounding box of all and evaluate clip-path. heycam: I think none are exactly what we want heycam: Wanted to see if you think it's reasonable or if clip-paths are different enough fantasai: Agree with matching to way backgrounds and borders are handled. Makes a lot of sense astearns: Seeing head nodding florian: Agree. If in long run need to distinguish we could add longhands iank: Note that you don't need fragmentation to trigger. Inline like a span with a clip-path triggers this fantasai: That's still fragmentation. iank: Sure astearns: Hearing consensus. Anyone against? chrishtr: iank do you have believe if this has impact on fragmentation in [missed] architecture? heycam: Basically behavior is same as box-decoration break. If you have box-decoration-break slice you compute box for unfragmented thing and slice clip-path and apply separately iank: What happens if you have a fragment that is varying width...this is the problem in...case is inline when you have a fragmented span. span can have different heights. What happens there? heycam: What happens with backgrounds? fantasai: Spans don't have different heights on different lines because set by first available font fantasai: As far as backgrounds and block level fragmentation it's defined in break. You recalc your size on each fragment. Maintain a concept of progress through element <fantasai> https://www.w3.org/TR/css-break-3/#varying-size-boxes astearns: Background is sliced...compute for unfragmented and then you slice it up. First fragment ends up shorter does the background resize per fragment after slicing? fantasai: For slicing you do layout first. Then you assemble it. You've accounted for the spacing. You have an oval clip-rect. You do the fragmentation, layout, and then draw background around that fantasai: It's not that you layout as if there was no fragmentation. That would be different spacing chrishtr: Does the same problem, heycam, apply to other visual effects? masking, filters, and so on? heycam: Masking and clipping seem they should do the same. Filters I had not considered heycam: Gut feeling is that filters feel a little more different and it's not so obvious we should apply same rules. Maybe not the case chrishtr: alisonmaher, thoughts? alisonmaher: I didn't work too much with this part of fragmentation. Keeping consistent feels like it would make sense astearns: Sounds like there are some complications to work out. astearns: General consensus that masking should follow same as backgrounds with regards to box-decoration-break astearns: Anyone objections to trying this out? RESOLVED: masking should follow same rules as backgrounds with regards to box-decoration-break astearns: Definitely clip-path. Masking should be the same RESOLVED: clip-path and masking should follow same rules as backgrounds with regards to box-decoration-break astearns: We can think on filters separately. Might be better to try and reason for clip-path and see if it would work first Media Queries 5 =============== Note/Issue on not shipping early proposals ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4834 fantasai: MQ 5 is peppered with this is not ready to impl but it's shipping. We shouldn't have notes saying don't do this when everyone is doing it. We shouldn't do that because makes it more likely people will ignore the notes astearns: Proposal: Take off all the notes? fantasai: That's my starting proposal. fantasai: If there's anything not shipping we can argue to have it astearns: Anyone argue for notes to keep? astearns: If there are any we should have that people not on the call want we can add astearns: Proposed: Take all the don't implement this notes out of MQ 5 astearns: Objections? RESOLVED: Take all the don't implement this notes out of MQ 5 CSS Lists ========= Automatic start value of reversed list is affected by 'counter-increment: <counter> 0' nodes ----------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6738 TabAtkins: This is...set up is weird TabAtkins: Some time ago we told html it was okay to style the disclosure triangle on a details using list item. That way they can use marker pseudo TabAtkins: The definition in html spec says it's a display list item. because it auto increments the counter it also says counter-increment list-item 0. TabAtkins: This means a page with a whole lot of summaries they're incrementing an unnamed counter TabAtkins: Came up here with a reversed item counter. Question was what value to start at and there was performance issue in FF with an element named summary and there was a hang TabAtkins: The question was how we could make this work better. Only reason summary interacts with list-item counter is anything with display: list-item must interact TabAtkins: The way algorithm was written to calculate the starting counter value for reversed list counts the 0 increments. TabAtkins: Mats suggests we skip those because it would avoid weird performance and if you are ever explicitly 0 increment a counter you must set as 0 so if you do it you are probably indicating the is not something that should interact TabAtkins: He concludes best to have 0 counters not count. I suggest we adopt this. For purpose of list skip 0 increment when calc starting increment TabAtkins: oriol has some comments this is a little weird but once Mats pointed out perf issue we thought it wasn't a big deal TabAtkins: So we're fine with the change. Unless anyone has an argument they should count we'll accept that astearns: Opinions? astearns: If Mats and oriol agree I'm inclined to agree too astearns: Prop: Do what Mats says? Or summary? TabAtkins: Skip 0 increments when determining the starting value of a reverse counter astearns: Objections? RESOLVED: Skip 0 increments when determining the starting value of a reverse counter TabAtkins: Pointing out, Mats pointed out it's weird we told HTML list it's okay to use display list-item here. He would have preferred to use marker without making it a list-item. Separate issue linked to be able to do that. <fantasai> https://github.com/w3c/csswg-drafts/issues/6781 TabAtkins: If you have interest in that, reference that issue oriol: Another note, when discussing this I found other issues in the algo. I can file them as different issues since they're orthogonal. astearns: Yes, please do that Media Queries 5 =============== Note/Issue on not shipping early proposals ------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/4834 florian: As far as I'm aware the video-* MQ are not implemented and they do have an existential issue so maybe warning should stay there. Unless they are shipping? I think the warning is right astearns: Yes and no. Have other things in other specs with issues florian: This is a it may be completely wrong issue. If it's shipping, fine, but if it's not shipping astearns: I'm inclined to not put the warning in so we could get implementation experience. If resolution of issue is this was bad people can take it out. That's the risk of impl something in a spec not in CR florian: Useful to highlight we don't know what's right but think this is wrong fantasai: I think that's fine. But also if someone is shipping something with the warning people should talk to the WG before shipping, shouldn't just leave the spec and impl disagreeing astearns: I think it makes sense to have a note in the spec saying we have an issue and this may change florian: Okay. I'll take that into account
Received on Sunday, 7 November 2021 22:08:52 UTC