- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Oct 2019 05:31:49 -0400
- 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. ========================================= Charter update discussion ------------------------- - The charter has the proposed changes edited in and is ready to be announced: https://www.w3.org/2019/10/css-wg-charter.html Writing Modes ------------- - Issue #4357 (propagation from body to document element is annoying) will be covered next week, but in advance browsers are requested to review to see if they intend to make the change that's being questioned. CSS Values ---------- - RESOLVED: Accept the proposed changes: We move where simplification occurs from being consequence of serialization to happening on the underlying value (Issue #2245: Actually describe how/whether computed math functions are simplified from specified ones) CSS Sizing ---------- - RESOLVED: Accept proposal in favor of serializing with the calc expression (Issue #3757: Support <number> (and therefore calc) as a <ratio>) Transforms ---------- - RESOLVED: Allow percentages inside the scale (Issue #3399: Have scale function accept percentage value) - mwoodrow will create proposed spec text for issue #3322 (Should the overflow area take scroll position into account) based on how Gecko has written their code. - RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/3084 (Interpolation of perspective) no change - RESOLVED: 0 is allowed with 1px being the render time clamp (Issue #413: Zero value in perspective() function) ===== FULL MINUTES BELOW ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0000.html Present: Rossen Atanassov Tab Atkins David Baron Amelia Bellamy-Royds Brian Birtles Dave Cramer Kevin Ellis Elika Etemad Simon Fraser Daniel Holbert Dael Jackson Dean Jackson Sanket Joshi Philippe Le Hégaret Myles Maxfield Cameron McCormack Florian Rivoal Jen Simmons Matt Woodrow Regrets: Oriol Brufau Emilio Cobos Álvarez Christian Biesinger Thierry Michel Manuel Rego Casasnovas Christopher Schmitt Scribe: dael Rossen: Let's get started Rossen: As usual I'm going to call for changes to the posted agenda Rossen: We have way more than the capacity for one call, but we'll go in proposed order unless anyone has reason to change. Rossen: Any changes? smfr: We could skip 14, but no way we'd get that far Rossen: If we surprise ourselves we'll skip <fantasai> reordering makes sense to me dbaron: One comment, maybe we have a good set of people to discuss transforms. matt and smfr are here. Don't know if worth re-ordering Rossen: emilio sent regrets though and he raised the second issue Rossen: We'll see traction on text and if none move to transforms Charter update discussion ========================= <plh> --> https://www.w3.org/2019/10/css-wg-charter.html CSS WG Charter Rossen: plh sent proposed change to the current charter that was inspired/proposed mostly by florian Rossen: I think text changed is pretty great Rossen: CTA is to take a look at this. If you have reasons to object or propose additional changes now is it. Otherwise need horizontal review completed sooner <fantasai> I think the changes are much better plh: The changes shouldn't impact WG in operation. Unless someone raises a flag today I'm ready to announce new charter. Everything is in place and will be announced tomorrow. fantasai: Changes look good. Much more reflective of what we want to happen so we should approve <dbaron> changes relative to AC review draft look like https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fproposed-css-2019.html&doc2=https%3A%2F%2Fwww.w3.org%2F2019%2F10%2Fcss-wg-charter.html florian: Agree. We spent a while replacing it with something that makes sense. We should go ahead Rossen: And thank you florian and everyone involved plh: Then by tomorrow you guys will have a new charter. Rossen: Thank you very much. That is exciting. Rossen: Let's do more work based on that charter. Writing Modes ============= propagation from body to document element is annoying ----------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4357 Rossen: dbaron do you want to talk now or wait for emilio next week? Rossen: I'm happy to defer dbaron: I think better to defer to next week with emilio Rossen: One thing I would point out is we're in PR and he's raising issue against PR <dbaron> unless heycam or dholbert want to cover it florian: One brief comment for everyone else to prepare, this is how we propagate writing modes and related properties up. Changed it recently and it's either impl or on its was to impl in Gecko. emilio thinks Gecko can do the change but he's skeptical other browsers will do it florian: Please do some reflection. If we resolved against what people want to do that's annoying. For next time please not-Mozilla people know if you have intention of implementing CSS Values ========== Actually describe how/whether computed math functions are simplified from specified ones -------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/2245 TabAtkins: Mostly a matter of if everyone else is cool with me doing spec work <AmeliaBR> +1 to Tab's proposal as described in the issue (any simplifications required for serialization should happen at parsing / setting time so they also show up in Typed OM) TabAtkins: In the spec calc and math functions are simplified during serialization. Has implications for typed OM because if not simplified I have to represent in a full version of what parsed TabAtkins: Didn't matter before because serialization was the only way to observe internal values. Now we have 2 ways want to make sure spec is clear simplification is on underlying value and then both emit simplified values, but don't simplify on their own TabAtkins: Means we don't have to store another version of simplification for typed OM to emit TabAtkins: Unless there's a reason to keep pre-simplification tree I'm going to say simplification is during parsing and serialization spits out the simplified thing AmeliaBR: Agree with proposal. There are consequences for numeric precision. If you have calc with division and end result is not finitely represented we agree post simplification is the canonical presentation. That's how it works in browsers so it's acknowledging how it works dbaron: Confused in issue about which is computed vs specified values versus which is parsing vs serialization TabAtkins: That's because it's confused in spec. Simplification as spec now only happens as result of asking to serialize. There's nothing saying simplification happens earlier. Typed OM doesn't have a hook to get the value serialization has and turn into object. Want to make sure emitting same thing. computed vs specified doesn't matter here dbaron: No change to what spec values serialize to TabAtkins: Correct. Assuming we say they serialize in a simplified manner then yes no change. Just moving where in process it happens. Unobservable to old code dbaron: Worth checking that is the behavior. I didn't think it was AmeliaBR: It is the current. If you set in an inline style font-size=calc(10px/3) and you read back that style from a DOM, specified style, you get calc(3.3333px) dbaron: Then I'm fine Rossen: Hearing support. Any objections? RESOLVED: Accept the proposed changes: We move where simplification occurs from being consequence of serialization to happening on the underlying value TabAtkins: Also, all of the text about computed values, serialization, all that in calc is outdated. Dates from values 3 with simple calc stuff. Now we have algebra none works. TabAtkins: I'm filling in details and there's a link to those changes from the issue. Got a little more work to do on that, but I'll continue. Comments are appreciated. I'll fill in serialization. Goal is old calc is the same, need to handle the new stuff TabAtkins: Anyone planning to work on this I'd love it if you review as you impl and if there's mistakes or improvements let me know CSS Sizing ========== Support <number> (and therefore calc) as a <ratio> -------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3757 AmeliaBR: Finishing a discussion that was time clamp in Aug. Issue is about serialization issues. AmeliaBR: Aspect ratio is unique and this applies to MQ and property- defined where division is part of syntax not just part of calc. Brought questions on how to serialize AmeliaBR: Proposal I had was we treat numerator and denominator as separate components of the value. Each simplified as independent. If one is omitted the other becomes a default 1 AmeliaBR: Only issue I found since last discussion is right now both values required to be positive. Calc expressions that resolve to -value/-value you clamp them so it's 0/0 instead of negatives canceling. Might be worth doing clamping at used value as this is non-intuitive TabAtkins: Allowing individual numbers to be calcs is consequence to CSS syntax. All numbers can be calcs TabAtkins: Agree negatives not worth allowing. I don't see why two negatives should pop out. Even if they would cancel doesn't seem worthwhile. TabAtkins: Anything with single calc? AmeliaBR: Single calc is same as single number. I propose for serialization that's your numerator and insert the missing denominator as a 1 jensimmons: Agree but don't see practical case for negative over negative so if that's difficult I'm for disallowing AmeliaBR: Proposal as in my comment for Aug 28: Always serialize as number/number where the numbers might be calc expressions heycam: Against principle of shortest simplification, but fine for me. As long as we write that in spec fantasai: It is the shortest most backwards compat serialization heycam: Is it a thing with this property? AmeliaBR: Yes with the MQ. Keep property consistent with MQ <fantasai> regardless, should indeed be made explicit :) smfr: What about proposal to use units? AmeliaBR: Agreed not to do that, but can do it by putting it inside a calc smfr: Okay Rossen: Other comments? It's not perfect but sounds like best we can do Rossen: Objections to resolve in favor of serializing with the calc expression? RESOLVED: Accept proposal in favor of serializing with the calc expression <AmeliaBR> (that should really be "with the division", not a `calc()`!) CSS Lists ========= Should automatic list-item increment adjust for ol[reversed]? ------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/4181 fantasai: I think we should skip to transforms. Seems a lot of these are overflow and have right people for transforms TabAtkins: Agree Rossen: Question about text ones, are any of the text issues ones we should do on this call? florian: Interested in all, but none are urgent Transforms ========== Have scale function accept percentage value ------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3399 AmeliaBR: This was a community suggestion that scale transforms that current accept number also accept % values, transform-scale: 150% instead of 1.5 AmeliaBR: Question of author convenience and intuitiveness. We've done this recently for opacity. Just like that it would only effect parsing. Actual rendering wouldn't change. AmeliaBR: Question of if people think it's enough value to users to change parsing code Rossen: Any expectation for how computed serializes? AmeliaBR: I would assume convert to simple number TabAtkins: Given this is a place where number represents same as % I'm fine with it. It's low value, but low effort and I'm good with being more consistent across the language. TabAtkins: Idea is it would parse into a number internally and serialize as a number <heycam> +1 for consistency across all values that accept a proportion-like value AmeliaBR: smfr can correct, but I assume this is transforms 2. I don't think any rush to get that to PR so we have time to ship impl smfr: I think that's true. Would effect 2d transform functions. New in transforms 2. Fine with this Rossen: Objections to accept proposal Allow percentages inside the scale? RESOLVED: Allow percentages inside the scale Should the overflow area take scroll position into account ---------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/3322 mwoodrow: Had bugs with parallax scroll effects. You can scroll past content and get white area or can't scroll all content into view mwoodrow: Wondering is we should take into account when fixing scroll AmeliaBR: For 2d most browsers extend scrollbars to cover 2d translated position. AmeliaBR: Question is to do with 3d? mwoodrow: Yes, particularly hard with 3d where scrollable range changes based on scroll position dbaron: This is cases where scrolling moves things because of perspective AmeliaBR: What is spec proposal? Or just general recommendation to browsers? mwoodrow: Worth specifying you should be able to scroll to all of transformed values. I can try and translate Gecko work to words smfr: I think scroll height needs to be computed to make transformed elements visible to all scroll positions. Need to do computations to get max scroll height. No thing like that in css now heycam: Do you need to get extremes or all in between? mwoodrow: I do overflow at scroll position 0 and 1 and use that to calculate how fast transform moves and use that to calc when bottom edge scrolls into view AmeliaBR: Are you willing to try and draft some text? Maybe we can say tentatively sounds good pending seeing it written down? mwoodrow: Willing to have a go with that dbaron: Question of if other browsers interested/willing to impl Rossen: Is this always stable? If transform is based on scroll position and you're scaling AmeliaBR: It isn't transform based on scroll position. The flattened position of the element on screen after you flatten is based on scroll position based on how perspective position gets scrolled smfr: It's not stable, further you scroll the bigger the scroll height. I don't think you can compute max, you have to do something like Matt suggests with doing a computation on a fixed scrolling format dbaron: Max is to the position that would cause the bottom of the thing to scroll into view mwoodrow: and possibility of multiple transforms so it's the last piece of content Rossen: Hearing no pushback. Matt, you expressed willingness to try and put proposed text together. Let's do that, circle back in issue, and when you're ready we can discuss and resolve. mwoodrow: sgtm smfr: Before we go there, we could say we're not going to fix this and go simpler. You don't take perspective into account when compute scroll height. Is there content we know is broken? The parallax is for ambient backgrounds usually AmeliaBR: I suspect authors are playing with adding extra padding until get result they want Rossen: Matt do you have reports? mwoodrow: I had one where an author was trying to create parallax and ran into this. Rossen: smfr sounds like this could become a symptom. Are you opposed to addressing? smfr: Not theoretically opposed. Just thinking this could fall off priority list as this is a tricky chunk of code Rossen: But from a standards point of view try and address issue and let impl catch up smfr: Can address by saying we're not going to address this specifically. Is alternative so bad we won't handle it Rossen: I don't hear objection on merits of proposed behavior. Unless I misunderstand mwoodrow: Always had case when you have scrollable overflow you should be able to get to all elements. We should uphold that. Parallax is pretty popular Rossen: smfr would you be opposed to proceeding by having Matt draft proposal? smfr: No objection Rossen: Matt action is to you. Interpolation of perspective ---------------------------- github: https://github.com/w3c/csswg-drafts/issues/3084 smfr: emilio noticed perspective property and transform function interpolate different. Property is just length value. Function is matrix interpolation. Gives different results. I think he's right they should be same smfr: I'm not sure how they differ visually. Would be interesting to see if look really different or slightly different AmeliaBR: Probably different because one creates an inverse Rossen: Isn't the codepen in the issue enough? <Rossen> would this test case be enough? https://bug1488414.bmoattachments.org/attachment.cgi?id=9006258 smfr: That's just snapshotting one point, not showing animation AmeliaBR: Converting perspective function to matrix isn't consistent with other transforms. rotate we interpolate to a single value AmeliaBR: My preference would be to follow that pattern and interpolate the parameter to the perspective function rather then a matrix. Unless there's an impl reason why that can't work. Apparently FF used to do that and emilio changed to match spec AmeliaBR: On the other hand if we now have conforming impl maybe we stick with that Rossen: Do we have conforming implementations? smfr: Chrome and Safari match. Not FF. I think mwoodrow: Do you know what Chrome and Safari are doing? smfr: Not offhand AmeliaBR: According to issue they do what spec does and generate transform matrix from function and interpolate. According to linked FF bug which was fixed in FF63 FF is now doing same mwoodrow: So we do have matching impl now Rossen: Is proposed to punt on this and resolve no change? AmeliaBR: Not used enough to insist on a change Rossen: Objections to resolve close no change? smfr: Should we do this without emilio? Rossen: He can re-open if he wants to <birtles> it seems weird to me RESOLVED: Close https://github.com/w3c/csswg-drafts/issues/3084 no change Zero value in perspective() function ------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/413 AmeliaBR: The issue is that now spec says perspective parameter needs to be a positive non-0 which goes against general rule that we don't have indeterminate ranges that include everything except exact value. need firm closed range AmeliaBR: Eric put together a PR for exact wording. Proposal: it's a closed range that's UA determined for the end of the range AmeliaBR: No, his is specifically 0 is valid but when you give 0 then your matrix equivalent is the identity matrix. 0 is valid parsing value with clearly defined behavior <AmeliaBR> Eric's PR text: https://github.com/w3c/csswg-drafts/pull/4279/files smfr: Problem with 0 as identity you get discontinuity of animating from 0. 0 is no perspective and then you animate to non-0 and it's super close. It's like scale(0) which is non-invertible. perspective(0) should be like perspective(infinity) AmeliaBR: Expecting perspective(0) to be same as infinitely large which is no transformation. Does cause discontinuity when moving from that to a very small value dino: I don't think matters what we do. If you animate to 0 it's a horrible result. Rather it disappears or infinity...it looks bad AmeliaBR: Just important to have a clear rule dino: 0 = infinity is best user result even though it doesn't quite make sense Rossen: Where do we take this? AmeliaBR: Do we accept Eric W. proposed edits? dbaron: The discussion you were having made me feel like we'd be better saying it's UA defined close range at some amount slightly above 0 rather than say 0 is valid dino: Should be clamped a fair way above 0. If you want to do something good for user don't let them get close TabAtkins: 0 not valid or valid and clamped upward dbaron: I was saying not valid, but okay with clamp upward TabAtkins: In general that's an open range and I don't like that. Much prefer 0 is valid with a UA clamp to reasonable minimum. AmeliaBR: Agree we don't want UA dependent limits for parsing validity. Actual rendering clamping upwards seems reasonable TabAtkins: Letting 0 be equivalent to a minimum value UA clamps to, that's the best situation. That's our normal principle for these ranges AmeliaBR: TabAtkins will you make edits for this interpretation? TabAtkins: Yeah AmeliaBR: Other question is on impl and what do they do and who will change dino: webkit is willing to change. It's rendering time. CSS goes to 0, but won't paint as 0 TabAtkins: Agreed mwoodrow: I think gecko would be willing to change but I'd like to define it in the spec TabAtkins: 1px? mwoodrow: Fine myles: Need to say if 0 returned by getComputedStyle? TabAtkins: If it's a render time clamp getComputedStyle will be 0 AmeliaBR: As far as limit 1px should be valid and used on exact math. 0px not exact math and somewhere in there browsers are allowed to clamp rendering code TabAtkins: Right now I don't think...I think every browser does 1px and down below. Render depends on precision or when the rendering library barfs. I'm fine with UA defined limit with a suggestion of 1px. If we want defined 1px is a nice thing to hit florian: If we have a specific value it's not an open range anymore Rossen: Proposal is? TabAtkins: 0 is allowed with 1px being the render time clamp Rossen: Objections? RESOLVED: 0 is allowed with 1px being the render time clamp Rossen: That's the top of the hour. Thank you for calling in. We'll take the rest of the agenda for next week. Thank you and talk to you in a week
Received on Thursday, 3 October 2019 09:32:42 UTC