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

[CSSWG] Minutes Telecon 2019-10-02 [writing-modes] [css-values] [css-sizing] [css-transforms]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 3 Oct 2019 05:31:49 -0400
Message-ID: <CADhPm3vKEPjWMYzhWyWONCzNa783bhN-Yc1f_Mg4+uocTg0pFg@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.
=========================================


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

This archive was generated by hypermail 2.3.1 : Thursday, 3 October 2019 09:32:42 UTC