W3C home > Mailing lists > Public > www-style@w3.org > November 2019

[CSSWG] Minutes Telecon 2019-11-20 [css-ui] [css-values-4] [css-grid] [css-flexbox] [css-transforms-2]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 Nov 2019 18:43:15 -0500
Message-ID: <CADhPm3uvzHhjPOd=3hF_WsgZH+sVTZ1S5fqe=2tvGDyyFSokzQ@mail.gmail.com>
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.
=========================================


Scheduling
----------

  - The next F2F is in about 2 months so anyone planning on going
      should make travel plans.
  - There is an email on the private list to coordinate which calls
      need to be canceled around the end of year holidays. Another one
      will be sent to see if we need to cancel next week due to US
      Thanksgiving travel.

CSS UI
------

  - RESOLVED: Remove implementation warning and add a note about
              possible changes to list of values for webcompat.
              Wording at editors discretion (Issue #1250: Remove
              warning about 'appearance')

CSS Values 4
------------

  - RESOLVED: All math functions aggressively simplify their
              calculations as far as possible for a given
              value-computation stage. (Issue #4399: What should
              non-calc() math functions serialize to when they're
              fully resolved?)
  - RESOLVED: If numeric simplification of a math function results in
              a single value, the serialization is that value wrapped
              in `calc()` (Issue #4399)
  - Work will continue on defining how unit canonicalization works

CSS Grid & CSS Flexbox
----------------------

  - RESOLVED: Accept edit in
https://github.com/w3c/csswg-drafts/commit/0db00e1870bcb74bd820f89beed168514d9a6ec5
             (Issue #4065: Blockification section should use the
             computed value, not the box of the element)
  - A separate issue will be opened to look and see if the same issue
      exists in the Houdini Layout API

Transforms 2
------------

  - RESOLVED: Working group is fine with translate, rotate, and scale
              shipping (Issue #4515: The readiness of shipping
              individual transform properties - translate, rotate,
              scale)
  - RESOLVED: Move the 3D Transforms to a level 3 of Transforms
  - After the call there was IRC chat that concluded separating the
      individual properties from 3D Transforms would remove value from
      the individual properties and will likely need to be revisited.

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Nov/0008.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Javier Fernandez
  Simon Fraser
  Dael Jackson
  Chris Lilley
  Peter Linss
  Stanton Marcum
  Myles Maxfield
  Simon Pieters
  Anton Prowse
  Manuel Rego Casasnovas
  François Remy
  Florian Rivoal
  Devin Rousso
  Jen Simmons
  Alan Stearns
  Eric Willigers

Scribe: dael

Scheduling
==========

  astearns: Are there any changes people would like to the agenda?
  astearns: I'd like to add that we do have a F2F in ~2 months. People
            should start making plans for travel.
  astearns: There's also an update on the private list about a dev
            meetup. If anyone has something to present please start
            talking to people about it

  Rossen: Also wanted to draw attention to the schedule for holidays.
          Started a thread on the private mailing but haven't seen
          engagement
  <fantasai> proposed schedule wfm
  Rossen: Given 25th Dec and 1 Jan are on Wednesdays it means we have
          2 weeks off from calls. Wanted to see if people needed extra
          time before or after
  Rossen: If you have strong desire to take the 18th off we should
          decide soon
  astearns: Thanks Rossen
  astearns: Anyone with additional constraints should bring them up.

  astearns: I don't see TabAtkins on yet
  astearns: Then let's skip calc() until he's on

CSS UI
======

Remove warning about 'appearance'
---------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-492759907

  florian: I can unless whomever added it wants it
  florian: Design of appearance property is proceeded by a warning
           that we don't know if it's webcompat. What's specified is a
           combination of none and auto and a few compat things. It
           seems that design works and people are trying to implement.
           I have been asked to remove the warning.
  florian: I support removing the warning. If we agree I will remove
           the giant note that says this isn't good to implement

  dbaron: Who has shipped support?
  florian: I think Google is trying to ship support for this. I don't
           know the state
  florian: I think Mozilla is also trying
  tantek: Presumably someone is trying to ship or else it wouldn't be
          a compat problem
  florian: It was a compat concern. The work zcorpan did showed it was
           likely to be web compatible. We never know until everything
           is finished
  tantek: Comment says it's for webcompat. The legacy keywords are for
          web compat
  florian: The spec is for web compat
  tantek: Then that means someone must have implemented it.
  fantasai: Is zcorpan on?
  florian: It was designed in order to handle web compat. zcorpan
           researched it and I believe he concluded it was. It has not
           shipped
  <fantasai> +1

  Rossen: Any reason not to remove the warning? Warning was pending
          someone attempting to impl. Seems there are attempts to impl
          and experiment. If that's the case let's remove warning
  fremy: Makes sense. If there's a problem when people impl we can
         change the spec. No reason to think there is so we can remove
         the note.
  dbaron: I'd prefer to leave something but remove the warning it's
          not okay to ship. I think we should still have a warning
          saying we're not sure this is going to work.
  Rossen: Are we sure anything will work before we ship?
  dbaron: I think we're particularly unsure
  <fremy> this => Rossen: Are we sure anything will work before we
          ship it?

  astearns: Could change to something that says set of values other
            than none needs to be evaluated. Need to figure out if
            this is the correct set
  florian: Agree but we have spent time investigating. It won't be
           over until shipped, but it's not that it hasn't started
  astearns: Something like as far as WG understands this is the set of
            non-none values, but more input is welcome
  tantek: I think your first wording is right, but change the tense to
          be that we are evaluating and continuing to evaluate
  astearns: zcorpan evaluated and we came to a conclusion
  tantek: He says the list is being tweaked so I think that's not final
  florian: He requested the removal
  tantek: But I wouldn't dispute what he's saying
  <fantasai> Replace current wording with "ISSUE: We are evaluating
             Web-compat of this feature's list of values. Please send
             any relevant feedback to the CSSWG" ?
  <fantasai> or maybe even s/ISSUE/NOTE/

  astearns: Proposal: We have a note suggesting people impl and try
            this out, but we are open to more input on what the
            necessary set of values are. Let the editors wordsmith
            that.
  dbaron: Sounds fine
  astearns: fantasai suggests it's an issue not a note?
  fantasai: No opinion, I just wanted to put wording
  fantasai: Leaving to the editor and moving on is okay
  * fantasai doesn't mind either way
  tantek: Because it's an open question still about normative text I
          think it deserves to be an issue. Note implies nothing
          normative will change
  <fantasai> let's resolve on issue, since Tantek cares, and move along
  astearns: We often put notes in L3 drafts saying things might change
            in L4
  astearns: Would you object to leaving as a note tantek?
  tantek: I can live. Just indicating preference

  astearns: Proposal: Remove implementation warning and add a note
            about possible changes to list of values for webcompat.
            Wording at editors discretion

  RESOLVED: Remove implementation warning and add a note about
            possible changes to list of values for webcompat. Wording
            at editors discretion

CSS Values 4
=============

What should non-calc() math functions serialize to when they're fully
    resolved?
---------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4399#issuecomment-554535978

  TabAtkins: I brought up a question about when a non-calc() math
             function is fully resolved what should it be serialized
             as? We have old calc rules that say if you do 1px+1em you
             combine at computed value and serialize as 17px. If you
             have min(10px, 20px) what should it serialize as? We can
             resolve it to 10px or should we preserve it was a min
             calculation?
  TabAtkins: I'm neutral to where we go. Current text simplifies
             everything as far as possible which might land on a plain
             number. Simon preferred preserving root node's identity.
  TabAtkins: I can do that, not a big deal in spec text. Just some
             annotation. I want to know what the other impl opinions
             are
  <AmeliaBR> Do we ever need to keep at least a function wrapper for
             the same reasons as `calc(-10px)` needs to keep a wrapper?
  smfr: Need to have a distinction between specified and computed.
        Most of my questions were about specified value. Text about
        simplification implies it's on specified value.
  smfr: How much simplification happens on the specified value and
        then what happens on computed. I prefer computed simplified as
        much as possible to a bare value if possible. Specified value
        is how much do you want to round trip or is it okay to
        collapse redundant mins?
  <AmeliaBR> Agree with smfr: if simple serialization converts
             `calc(200px/4)` to `50px`, then it makes sense to do the
             same with simple mathematical min/max

  TabAtkins: In spec I do full simplification on specified. I realize
             from your comment I'm too aggressive. Still have the
             question about what is the best to do with a min that has
             identical units? Does it retain its structure at spec
             value time?
  TabAtkins: I can go either. I can do light that combines identical
             units like old calc did or I can do more aggressive and
             not canonicalize units.
  emilio: Browsers do canonicalize units, right?
  TabAtkins: At specified value I don't think calc(1in) becomes px
  emilio: calc(1px+1q) I get 10.something px.
  smfr: Different units get canonicalized
  TabAtkins: So the tests from smfr were wrong?
  smfr: Lots of non-compat behavior. WPT have a mixture of behaviors
        so I don't think we should go on what those tests are doing

  smfr: One of the considerations for specified value is are there
        authoring tools that expect nested calc to be preserved. I
        know glazou was concerned back in 2017 because it would break
        authoring tools.
  TabAtkins: At time we resolved getting rid of nested calc was fine.
             The loss to authoring tools was considered to be fine due
             to simplifications in impl and easier for end user.
  TabAtkins: Don't want to revisit that if possible. Still a range of
             stuff we can do. I don't want to preserve more than the
             old calc. I prefer preserve as little as possible

  fantasai: calc if nested is equivalent to parenthesis. Switching min
            or max is a little different. Not quite the same situation
  TabAtkins: I would argue same as distributing multiplication across
             properties. That's a re-write of algebraic structure
             which seems similar to simplifying away a min
  * emilio agrees with TabAtkins

  fremy: I was hearing emilio and I found Chrome behavior is weird. If
         you set border calc(1inch) you get back calc(1inch) but
         calc(1in+1px) you get 97px. I think ther'es not web compat
         and we an do what feels right
  TabAtkins: That's super weird, that feels like us going we're done
             and can exit early
  <fantasai> fremy, post testcase?
  <emilio> fantasai: document.body.style.left = "calc(1q)";
           document.body.style.left
  <fremy> fantasai well my favorite test website is down...
  <fremy> but ok
  <emilio> Firefox behaves the same as Chrome here, but agreed it
           feels weird
  <emilio> fremy: fwiw what happens on Firefox is that as soon as we
           need to canonicalize `<length>`s we simplify both to px
  <fremy> @ fantasai emilio : testcase : https://jsfiddle.net/aj7qL95r/

  TabAtkins: Proposal: Since calc in general does do aggressive
             simplification we preserve that through the new math
             expressions. At specified value time we simplify down.
             Maybe preserve root node at specified time, but that's
             thrown away at computed value time
  TabAtkins: Does that sound fine and, if so, which way on the root
             node?
  smfr: Prefer preserve the root node. If you have calc with a nested
        min and you could reduce, I don't know if you should
  smfr: Keeping root node as a function is right. And simplify as much
        as possible for computed
  TabAtkins: Will argue to get rid of nested things. min is a binary
             operator square root is. Preserving the later things as
             functions seems inconsistent to me
  smfr: That implies if you have a calc with min inside you'd replace
        the calc with a min?
  TabAtkins: No, the root node retains at specified value.
  smfr: Doesn't change function type?
  TabAtkins: Yeah. Preserved. Everything under simplifies as much as
             possible. calc(min(px,%)) stays. calc(min(px,px))
             simplifies
  emilio: I'm fine with dropping root, but I don't mind

  AmeliaBR: I agree with arguments, but I think we lost them a long
            time ago. I don't like that we do a lot of math
            simplification at serialization with calc, but we do.
            calc(10px/3) reads back as calc(3.333px).
  AmeliaBR: Similar logic in the other functions seems to be a
            consistency thing. Important to keep the wrapper that says
            this is a math function because rules about clamping.
  AmeliaBR: That would presumably happen with other math functions
            too. If you say in spec value min(10px,20px) it should
            still read back with functional wrapper of min(10px) as
            simplified.
  AmeliaBR: You want to keep because what happens if it's min and a
            value is negative and negative is invalid in that context.
            We need the wrapper
  TabAtkins: If you forget the root node it serializes as a calc.
  AmeliaBR: Do we turn all simplified math functions into a calc
            wrapper is the question?
  TabAtkins: Yep
  AmeliaBR: Then yeah, simplifying...if the result is a single value
            it makes sense as a single value with a calc wrapper
            rather than preserve min/max when we can't do that with
            other functions

  astearns: We're proposing to simplify functions like we do calc and
            change calc specified value to retain the wrapper
  TabAtkins: Changing the new stuff.
  TabAtkins: The root node of a calculation tree retains it's identify
  astearns: If root is calc function?
  TabAtkins: Then it's a calc
  TabAtkins: That's preserved in specified. At computed it goes away.
  astearns: Functions simplify the way calc does. Outer most function
            context is maintained for new functions.
  AmeliaBR: I have a problem with the second. Should we get the first
            resolved?
  TabAtkins: I'll write proposed resolution
  <TabAtkins> Proposed resolution 1: All math functions aggressively
              simplify their calculations as far as possible for a
              given value-computation stage.
  astearns: Objections or continued discussion on proposed resolution
            1?

  RESOLVED: All math functions aggressively simplify their
            calculations as far as possible for a given
            value-computation stage.

  astearns: TabAtkins will you type the 2nd?
  <TabAtkins> Proposed resolution 2: At specified-value time, the root
              of a calculation tree retains knowledge of what type of
              function it is and serializes accordingly, even if it
              could be simplified to a single number. (At
              computed-value time, they'll turn into a plain number if
              possible.)
  AmeliaBR: Problem with root of calc tree retaining knowledge is some
            function types are math operators like power. If you
            simplify square root of 4 it means erase function wrapper
  TabAtkins: The be precise here I would not simplify root node, start
             simplification at children of root node
  AmeliaBR: If I have sqrt(4) inside a calc it's simplified, but sqt4
            is not simplified?
  TabAtkins: Correct. It's either all or none. I don't want to keep
             min but not sqrt
  <TabAtkins> calc(sqrt(4)) => calc(2); sqrt(4) => sqrt(4)
  AmeliaBR: Considering sqrt and power anything simplified to a single
            value simplifies to that wrapped in a calc.
  TabAtkins: That's in the spec today. smfr expressed desire to keep
             root node around. Easy to do spec wise.
  smfr: I think AmeliaBR is suggesting sqrt(2) that becomes
        calc(1.41...). You replace sqrt with calc.
  TabAtkins: That's spec today
  <AmeliaBR> yes, serialization of `sqrt(4)` would be `calc(2)`

  florian: Does spec say [missed]
  TabAtkins: No
  florian: I think that's what AmeliaBR is suggesting
  TabAtkins: AmeliaBR are you suggesting extra calcs?
  AmeliaBR: If we need a wrapper use cal
  florian: calc(sqrt(4)) what is that?
  florian: calc(2) or calc(calc(2))
  <AmeliaBR> Also `min(10,20)` serializes as `calc(10)`
  AmeliaBR: You just need the outer wrapper
  florian: That is current spec

  AmeliaBR: I think we're at the point where everyone understands, but
            not consensus on strategy
  TabAtkins: I think we've converged. I was arguing smfr wants exact
             ID but that's not the case. We fully simplify. At
             specified value time we need to wrap it in a calc if it's
             single number. So no change to current rules for
             calculation trees
  smfr: Root function might be a calc. Might still be a min/max
  TabAtkins: Yes, if you can resolve min it's a min.
  smfr: I like that calc is way to signal out of range things
  TabAtkins: We can go with no change to current rules for calculation
             trees if no objection?
  AmeliaBR: I'm writing down a version
  <AmeliaBR> Proposed resolution: if numeric simplification of a math
             function results in a single value, the serialization is
             that value wrapped in `calc()`
  smfr: Current rules is ambiguous.
  TabAtkins: New version of spec shouldn't be ambiguous. I'll put in a
             note that it stays a calculation tree is clear. It's in
             spec, but easy to go past.
  smfr: I meant there are 3 specs and not sure which people are
        talking about.
  smfr: ED right?
  TabAtkins: Yeah

  astearns: TabAtkins is AmeliaBR proposed resolution what you're
            thinking about?
  TabAtkins: Fine
  TabAtkins: End result is no change, but the explicit wording works
  smfr: Spec could be if you encountered bare math you open calc
  TabAtkins: I'll work with you in the issue to make it super clear
  smfr: Still want clarity on unit canonicalization happens
  TabAtkins: We'll continue that in issue
  astearns: Objections to if numeric simplification of a math function
            results in a single value, the serialization is that value
            wrapped in `calc()`

  RESOLVED: If numeric simplification of a math function results in a
            single value, the serialization is that value wrapped in
            `calc()`

  astearns: Please do continue about unit canonization in the issue

CSS Grid & CSS Flexbox
======================

Blockification section should use the computed value, not the box
    of the element
-----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4065

  astearns: TabAtkins put this on?
  TabAtkins: This should be quick. We made edits to the issue a few
             weeks ago. Checked with emilio and he's good. Final call
             for objections from anyone that's reviewed. It's CR so we
             need resolution
  TabAtkins: We rephrased blockification to talk about display values
             rather than rely on box tree. Behavior difference is
             minuscule but makes it easier for implementations and
             more similar to other cases.
  TabAtkins: If someone hasn't reviewed we can delay now or revisit in
             future
  <fremy> Just took a look, LGTM

  astearns: Looks like we have 3 reviews. Anyone want more time?
  oriol: Not an objection. I think Houdini custom layout has same
         problem and needs update.
  TabAtkins: Probably because Ian copied the text. Can you open an
             issue pointing at this one and we'll take care of that
  astearns: Proposed: Accept edit in
https://github.com/w3c/csswg-drafts/issues/4065

  RESOLVED: Accept edit in https://github.com/w3c/csswg-drafts/issues/4065

CSS Grid
========

Overflow with auto-repeat and minmax()
--------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4043

  astearns: fantasai do you want this?
  TabAtkins: I'm happy to do it
  TabAtkins: We missed where if you do a minmax function and a repeat
             autofill or autofill we previously based it on max track
             sizing function. You had to give a real length.
             minmax(100px, 50px) we would tile columns based on
             filling 50px and then at layout they're all too big.
  TabAtkins: We now floor the max with the min. Need review from impl
             if they want. Otherwise should be relatively rubber stamp.
  astearns: This has had review. Anyone want time?
  astearns: Objection to Accept change in
https://github.com/w3c/csswg-drafts/issues/4043 ?

  RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/4043

CSS Grid
========

How should spaces be treated in markers?
----------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4448

  TabAtkins: I haven't reviewed
  * fantasai suggests item 9
  <fantasai> that might be time-sensitive?

CSS Transforms 2
================

The readiness of shipping individual transform properties - translate,
    rotate, scale
----------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4515

  astearns: Gecko is ready to ship. Any concerns about that?
  <fantasai> I would like us to get the spec to CR soonish
  <fantasai> would it make sense to drop the 3D Transforms section
             to L3
  <fantasai> ?
  <fantasai> and then make L2 be 2D transforms + this feature?
  astearns: [reads fantasai IRC] should we drop 3d transforms for that?
  <fantasai> Just push to level three
  smfr: Transforms 1.5 which is 1+individual functions
  TabAtkins: I'm fine with punting items to L3

  astearns: Is there another impl of individual functions soon?
  <fantasai> We're not in CR yet, so it's about the spec, not impl
             status
  fremy: I think they were behind a flag in old Edge
  <fantasai> if spec for individual functions is done, let's push it
             to CR and defer the rest to L3
  astearns: I wouldn't mind moving the 3D transforms. Wondering what
            other small things will drop to L3.
  fremy: Old Edge has a flag to enable individual transforms. So we
         have impl to move the spec forward

  <fantasai> Propose several resolutions
  <fantasai> First resolution, clear these to ship
  <fantasai> 2nd resolution, push everything other than these features
             (unless someone thinks there's something else close to
             CR) to L3

  smfr: Interaction with motion path I'm forgetting about?
  astearns: Can anyone answer that yes or no?
  <fantasai> I don't think so
  emilio: Motion path adds transform-ish stuff but the order is well
          defined.
  myles: There's an order. Apply transform properties and then motion
         path. Might have it flipped, but it's well defined. No
         interaction
  astearns: First proposed resolution is clear these to ship
  astearns: Not hearing concerns. Objections to Working group is fine
            with translate, rotate and scale shipping?
  <TabAtkins> Yeah, the total effective transform is <motion-path>
              <translate> <rotate> <scale> <transform>

  RESOLVED: Working group is fine with translate, rotate, and scale
            shipping

  astearns: 2nd is move the 3d transforms out to a new level. Any
            concerns?
  <AmeliaBR> ship, ship, ship! Take down the flag & sail that ship!

  <dbaron> also transform-origin somewhere in there
  <TabAtkins> (with perspective/transform-origin bodged into the
              <transform> bit there)
  <TabAtkins> Or wait, dbaron's right, transform-origin goes before
              <translate> and after <transform>
  <dbaron> also perspective is a little bit fun

  RESOLVED: Move the 3D transforms to a level 3 of Transforms

  astearns: I think we should take it up in a call soon about taking
            L2 Transforms to CR
  astearns: I don't think that's something for 4 minutes
  <fantasai> probably need to wait for edits :)
  <fantasai> also maybe republish both as WD/FPWD
  astearns: IRC question about transform-origin?
  TabAtkins: No, just chatting about effect, but it's well understood

Scheduling
==========

  astearns: Thanks everyone for calling in.
  myles: Is next week on?
  TabAtkins: I'm on vacation
  myles: I am too
  * fantasai is available
  <smfr> regrets
  tantek: Regrets
  Rossen: I think many US folks are going to be on vacation
  astearns: Let's take it to private list
  <dbaron> should we do a yes/no doodle or something like that?
  Rossen: Let's take it to the list with other meeting/time off
          discussion
  astearns: Sounds good. Thanks everyone

Transforms 2 - Post Call IRC
============================

  <ericwilligers> With moving 3D transforms to L3, are we saying
                  individual transforms would be in L2 but as 2D
                  properties? I don't think anyone would want to ship
                  them as 2D.
  <astearns> hmm - good question, ericwilligers
  <dbaron> perhaps that suggests moving 3-D to level 3 doesn't
           actually help anything?
  <TabAtkins> Ah, true
  <TabAtkins> astearns: Can we do an async re-do of the resolution on
              the www-style list, then, making it clear that the WG is
              fine with shipping the individual transforms ahead of L2
              being CR?
  <astearns> I'll comment on the issue
  <astearns> The ship resolution was independent of pushing L2 to CR
  <AmeliaBR> Yeah, those transforms resolutions are not so good in
             retrospect. It would be a big hassle to spec a 2D-only
             version of the individual transform property. And it
             would be a much bigger hassle to split the
             implementations and ship 2D versions unflagged but keep
             3D versions flagged (especially since the rest of 3D
             isn't flagged), so probably best to keep them all
             together.
Received on Wednesday, 20 November 2019 23:43:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:17 UTC