[CSSWG] Minutes Telecon 2019-10-23 [css-values-4] [css-transforms-2] [css-text-3]

  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 Values 4

  - The use case presented in issue #4329 (Add vhc value) to address
      the shifting viewports in mobile when the nav bar hides is one
      that the working group wants to address. However, there was
      concern that enough time hadn't been spent on understanding all
      the possible cases that need to be addressed and the pros and
      cons of each potential solution. jensimmons will take the lead
      on making sure the necessary research is done to reach a

CSS Transforms

  - There was support expressed for changing the semantics of having
      transform-style: preserve-3d on the root element such that it
      means that anything that's preserved as 3-D up to the root
      element would be rendered in actual 3-D to address issue #4242
      (Proposal new transform-style: detached) but there were people
      missing from the call so a resolution will be reached later.
  - RESOLVED: For the individual transform properties if they spec a
              value that can be expressed as 2d we treat as 2d and
              serialize accordingly (Issue #3305: Is it necessary to
              serialize all 3 components of translate given the 3rd
              component is 0px)
  - RESOLVED: Require transform functions to be downgraded to 2d if
              possible (Issue #3305)
  - RESOLVED: We return the values the animation is working on while
              the animation is going and that includes the endpoints
              per the definition in web animations (Issue #3920:
              Serialization of individual transform when the animation
              is at 0% or 100%)
  - RESOLVED: Reject this proposal (Issue #589: Let 'transform-origin'
              and 'transform' take comma-separated lists)

CSS Text 3

  - Florian created examples and a PR to resolve issue #4422 (Bidi and
      pre-wrap end of line spaces). fantasai will make some changes to
      the PR and a call for resolution will happen next week.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0025.html

  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Dave Cramer
  Kevin Ellis
  Elika Etemad
  Robert Flack
  Simon Fraser
  Dael Jackson
  Sanket Joshi
  Brian Kardell
  Peter Linss
  Anton Prowse
  Florian Rivoal
  Devin Rousso
  Christopher Schmitt
  Jen Simmons
  Alan Stearns

  Rachel Andrew
  Tantek Çelik
  Brian Kardell
  Manuel Rego Casasnovas

Scribe: dael

CSS Values 4

Add vhc value
  github: https://github.com/w3c/csswg-drafts/issues/4329

  fantasai: Topic is not add a vhc as much as it is solve the problem.
            Issue is that on mobile we have multiple notions of
            viewport. Viewport units are defined in regards to
            viewport but on most browsers there's a disappearing
            address bar
  <fantasai> https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html
  fantasai: To avoid content from constantly shifting have made that
            not respond to appear/disappear of address. Problems is
            defaults being impl makes viewport behavior where 100vh
            assumes address bar is not visible. That's not initial
  fantasai: Lots of websites design to fit within visible are upon a
            page load or to have things visible/invisible upon load.
            Getting that things supposed to be on screen using vh are
            not visible due to changing height.
  fantasai: Need to solve the problem. Multiple options, could take
            multiple of them.
  fantasai: Want to hear what others think

  AmeliaBR: Recap proposals from issue. 1 is don't add any new syntax
            but encourage any browser with the disappearing nav bar
            effect to size vh to value when chrome is visible.
  AmeliaBR: Sometimes you'll have more than 100vh visible but on
            initial load it will fit the screen. That's a guidance to
            UA without changing language
  AmeliaBR: Original posted suggested alternate unit proportional to
            the smaller viewport
  fantasai: Third is make the current vh unit to fit the initial load
            and then add a unit that allows author to take full height
            of viewport if they want. Inverse of the initial proposal
  fantasai: Advantage with that is current keyword is the safer value
  AmeliaBR: Final option is to not add a unit and then add environment
            variables for disappearing effect so it's similar to inset

  florian: Another aspect to problem; it's not just the title, but
           appearance and disappearance of keyboard. Currently
           keyboard resizes viewport, but maybe that should only
           change visual viewport. That's a good idea, but title bar
           can't do that
  smfr: I don't think we should derail with keyboard. What you
        described florian is iOS where it does not change layout height
  florian: If you think it's separate let's keep that out

  smfr: Did any proposals include a unit that changes value when
        chrome hides? vh that changes
  smfr: It's an option
  TabAtkins: From author feedback they do not want that because layout
             jiggle while it moves
  AmeliaBR: Doesn't behave nicely with things that disappear on
            scroll. For UX and rendering reasons. For other things
            like keyboard where it's more discrete it's reasonable.
  smfr: I'm all for avoiding layout jiggle. Seems that pages may be
        designed such that chrome disappears when you're at bottom
  florian: I think it would be weird to build a page that way

  jensimmons: This is something I've heard a lot, the sentiments in
              this issue. Like many parts of CSS the loudest voices
              can be most negative. We should work on this and give
              consideration for all use cases and not jump too quickly
              and not resolve quickly for what loudest voices say. I'd
              be happy to work on this and think it through. We need
              to think about how to animate if they want that. This is
              more complex. But we should tackle
  smfr: Related all would match, 100vh, 100% body, window.innerHeight
        would all mean same thing. Currently don't. Don't know if they
        can but it should be a goal
  <jensimmons> +1 to everything should match
  smfr: Do we know if Android has a similar behavior to iOS where
        100vh is the chrome hidden state?
  <smfr> here’s a testcase: http://smfr.org/css/viewport-units.html
  fantasai: Blink has 100vh and 100% on html body meaning different
            things. 100vh matches Safari. They would like 100% html
            match but that's currently being a work around for vh not
            considering address bar
  fantasai: One of the devs that worked on this in Blink said they
            wanted to argue for 100vh not including address bar but
            they had to match Safari
  jensimmons: Seems like WG took approach for UAs to fill in details
              and each browser took a different approach and it's not
              really working and we should come in and specify, but
              with a range of options for authors so they can do what
              they want

  astearns: Anything else on this to discuss or do we have jensimmons
            work on the use cases to consider?
  fantasai: I'm happy to kick it to jensimmons to think. It's
            important and we should not drop, but we can talk later
  astearns: Anything else people want added to discussion?
  astearns: I think smfr list of things that should be equivalent is
  AmeliaBR: Another option on issue was someone suggesting box sizing
            like property where authors choose what vh units are
            relative to. It's another thing to think of
  fantasai: Probably 2 pairs of units would be cleaner and less likely
            to result in accidental errors
  myles: 2 units might be better cause can use both at the same time.
         Mode switch you can't use both at same time
  <dbaron> Using both at the same time is probably very hard to do
           correctly, though.
  AmeliaBR: Good arguments.
  AmeliaBR: Lots of options and use cases. Getting through pros and
            cons for each sounds sensible
  astearns: Let's continue in GH. jensimmons I'll assign it to you?
  jensimmons: Okay
  astearns: We'll discuss again on the call when it's at a good point.

CSS Lists

Should automatic list-item increment adjust for ol[reversed]?
  github: https://github.com/w3c/csswg-drafts/issues/4181

  TabAtkins: I'd like to delay for a week. I just pinged to
             implementation and the person to look is on vacation. I'm
             not comfortable talking before he's back next week.
  astearns: fantasai anything we can get through?
  fantasai: Not urgent

CSS Transforms

Proposal new transform-style: detached
  github: https://github.com/w3c/csswg-drafts/issues/4242

  AmeliaBR: Use case is for 3d environmental displays, VR and AR.
            Having a way to spec css content should be displayed in 3d
            in that environment without getting flattened to web page
  AmeliaBR: Rik's proposal was to add a new keyword to transform-style
            property that would indicate this stays in 3d separate
            from plane of browser rendering
  AmeliaBR: Another option from dbaron is to just use existing
            transform-style:preserve-3d but if you say it on the body
            or root and rendering environment can preserve the 3d
            rendering gets to the overall rendering environment
  AmeliaBR: Question is would it be web compat or is there content
            that would look bad if it's not flattened?
  TabAtkins: I generally support dbaron proposal absent compat data
             showing it's bad
  florian: I also support it in part for a weird thing with the other
           way. If you have a small iframe and the page doesn't intent
           3d but the iframe does leak 3d you could have intrusive ads
           even that the page didn't want. If you put it on the root
           the hosting page does what it wants
  smfr: Don't think we should get too far without Rik
  astearns: That's fair. Rik can read this and I'll ping him about
            joining a call
  AmeliaBR: If you know anyone working on 3d in immersive environments
            get them to look at the issue

Is it necessary to serialize all 3 components of translate given the
    3rd component is 0px
  github: https://github.com/w3c/csswg-drafts/issues/3305

  TabAtkins: Question was the individual transform for translate spec
             distinction between 2d and 3d. If you explicitly give 2d
             it always does 2d, 3d is always 3d even if z is 0.
             Question of if it violates shortest serialization.
             Originally thought no because 3d has a meaning, but after
             looking any differences left we treat as bugs
  TabAtkins: We're fine serializing as 3d. Fine with doing what heycam
  TabAtkins: Does have minor changes because some difference as you do
             3d animation as you pass through 0 if you pause right
             there it looks a little different. Considered minor by
             those in thread

  dbaron: No longer animation difference between 2 value and 3 value
  TabAtkins: If you pause a 3d transform while it's animating and at a
             state where it's 2d transform it will serialize
             differently. We're fine with that for now and consider it
             a bug being fixed
  dbaron: I thought another difference was animation behavior
          depending on if you spec 2 or 3 values. My memory is a bunch
          of the is it 2d or 3d are related to interpolation
  AmeliaBR: If before and after states one is 2d and one is 3d they
            won't match us as being consistently the same. If one of
            them uses 3 values and 3rd is 0 I don't know how it's
  AmeliaBR: With this proposal the 3 value disappears at computed and
            interpolates as a 2d
  TabAtkins: dbaron do you have an example for your concern?
  dbaron: If you're trying to interpolate between translate and matrix
          and if the translate is 2d or 3d might effect if
          interpolation goes into 3rd dimension. But interpolation
          rules have changed so I'm not sure current state
  TabAtkins: Think I'm in the same boat.
  dbaron: Basically want to make sure when you said there aren't
          significant differences you ran it by someone who is up to
          date on the interpolation rules
  TabAtkins: Eric W and chris have been in support
  dbaron: Okay
  astearns: Would it be emilio on gecko's side?
  dbaron: Possibly birtles, but I'm not sure.
  dbaron: Possibly hiro
  astearns: dbaron would you be okay resolving?
  dbaron: I'm okay

  AmeliaBR: I want to mention that this complicates how transforms are
            specified for svg which does make distinction between 2d
            transforms being regular layout vs 3d transforms being an
            isolating, flattening effect.
  AmeliaBR: We haven't had a lot of implementors following spec to
            distinguish for SVG so might not be breaking. We do need
            people to commit to following through and cleaning up
            those areas of the spec and how do they work if we don't
            have clear consistent way to define 2d transform and 3d
  TabAtkins: Yeah. Other evidence, Eric points out all 4 engines
             serialize scale 3d with 1 z value as a 2d matrix. In
             general engines are loose even when you explicitly say
             3d. Remaining errors with z-axis translate we're fine
             treating as a bug

  astearns: Proposal?
  TabAtkins: Option 1: For individual transform properties should they
             make 2d vs 3d distinction vs number of properties. We
             propose go on the value of the z value
  TabAtkins: In general should transforms be more permissive about 3d
             functions without 3d requiring transform being equivalent
             to 2d. Have a mixture of behaviors, Blink is in favor of
             downgrade to 2d when possible model
  TabAtkins: Individual transform is easier.
  astearns: Proposal: When there is a 3d value the transform
            properties are only 3d if the value is not 0
  TabAtkins: If the transform can be expressed as a 2d we serialize as
             a 2d
  astearns: Just serialization then?
  AmeliaBR: More then serialization. It means that the round tripping
            is if you serialize and re-parse it's 2d so we don't want
            it to behave different whether you set the 3rd parameter
            or leave as default
  TabAtkins: A translate with 3 values but z is 0 should not trigger
             full compositing
  astearns: Trying to figure out how to state option 1
  TabAtkins: For the individual transform properties if they spec a
             value that can be expressed as 2d we treat as 2d and
             serialize accordingly

  RESOLVED: For the individual transform properties if they spec a
            value that can be expressed as 2d we treat as 2d and
            serialize accordingly

  astearns: Second?
  TabAtkins: Apply the above to all transform functions in normal
             transform property and then figure out implications for
             serialization and interpolation
  AmeliaBR: Have some sort of resolution conditional on people doing
            web compat tests and get feedback from more authors?
  TabAtkins: I'd rather not resolve if we're waiting for that.
  AmeliaBR: At this point without a clear text of all places it'll
            impact it's hard to get author feedback
  AmeliaBR: I'm a little worried about web compat depending on fine
  TabAtkins: I suspect this will be hard to get author feedback
             because it's technical and tiny. Compat-wise sure. Blink
             is okay with eating the compat, but if others are
             uncomfortable we can wait
  AmeliaBR: You're right feedback won't happen until it's pushed.
  astearns: I expect that making this change to figure out compat
            problems requires a resolution? Or would Blink experiment?
  TabAtkins: We'd like spec text, but in a proposal is okay. So we can
             point to that's what we're doing
  fantasai: We can resolve and say checking web compat
  AmeliaBR: Not sure anywhere it makes sense to talk about this as at
            risk. I guess it's not a CR change
  AmeliaBR: Widely impl but not officially stable
  TabAtkins: Yes
  AmeliaBR: Make the change with the awareness we might get author
            screams and have to revert

  astearns: Proposal: Require transform functions to be downgraded to
            2d if possible
  astearns: And we'll see what web compat shakeout is. Objections?
  smfr: Just for serialization?
  TabAtkins: Not sure the distinction. What would be different between
             yes and no to that
  smfr: I guess not interpolation because 2d and 3d matching
  TabAtkins: Preserves compositing if you're in an animation
  AmeliaBR: 2d gets upgraded to 3d to match endpoint
  smfr: webkit uses it as a trigger
  TabAtkins: That's what we're willing to stop doing
  astearns: Any concerns smfr?
  smfr: No, worth experimenting
  astearns: Objections?

  RESOLVED: Require transform functions to be downgraded to 2d if

Serialization of individual transform when the animation is at 0%
    or 100%
  github: https://github.com/w3c/csswg-drafts/issues/3290

  astearns: Also from heycam.
  AmeliaBR: Overview. When interpolating transform functions you often
            first need to do processing to upgrade function into a
            form that interpolates with other end. At exact moment
            when at beginning or end of animations or in frozen
            animation state is serialization using the upgraded
            functions or is it using the original as specified
            functions for the endpoint
  AmeliaBR: There are wpt tests that do it one way and someone
            expected the other. Not sure who does what
  dbaron: This can influence transitions, like if you reverse when
          it's filling you might get different behavior. I've seen
          that in the past, though maybe rules have been fixed to
          avoid some of those cases
  smfr: I wouldn't expect function upgrading for animation would
        effect serialization.
  AmeliaBR: The issue is specifically about individual transforms and
            upgrading the none keyword. Not sure how it compares to
            functions in transform property. I would expect consistency
  dbaron: I was thinking of transform property, not individual
          transform properties.
  AmeliaBR: My fault for skimming too quick
  smfr: I understand now the endpoint there's ambiguous about if you
        use upgraded functions

  TabAtkins: Individual transform properties, given the previous
             resolution that we should serialize to lowest state I
             think this answer the question. Not for none but the ones
             that are 3d to 2d there is an upgrade in the middle. If a
             none value should serialize as the null value or not when
             it's an endpoint
  astearns: We should resolve on the endpoints not upgrading first?
  AmeliaBR: There is a switch in between a none value and any other
            value has side effects. Despite previous resolution actual
            transform side effects are clearly defined. translate: 0 0
            has side effects that translate: none does not. Can't just
            ignore that as a rule
  AmeliaBR: If you're in an animation from a transform to another
            value the side effects persist as long as the animation.
            Makes sense as long as animation persists you have an
            explicit value instead of none
  <dbaron> +1 to what AmeliaBR (IRC) just said
  TabAtkins: Agree. If animation is active we should preserve that
             there is a transform b/c none has a lack of side effects
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/3290#issuecomment-539719709
  TabAtkins: Further issue is ^
  TabAtkins: There's an example where one endpoint has non-normalize
             rotation, but during animation we do axis normalization.
             If it's active do we return normalized or specified
             non-normalized? Fine with consistent where when animation
             is running we report the animation's value.

  smfr: Does WebAnimations have something to say?
  TabAtkins: Yes, it has to report if there is an active animation.
             Not sure if it has details about this issue. It knows if
             an animation is running
  smfr: May be a case where we just want consistency
  TabAtkins: Agree, everything except none case is consistency. I
             think that leans us to take value animation is working
             on, not the endpoint value
  smfr: Sounds fine to me
  astearns: Proposal is we return the values the animation is working
            on while the animation is going and that includes the
            endpoints per the definition in web animations
  astearns: Any concerns with this change?
  astearns: Objections?

  RESOLVED: We return the values the animation is working on while the
            animation is going and that includes the endpoints per the
            definition in web animations

Let 'transform-origin' and 'transform' take comma-separated lists
  github: https://github.com/w3c/csswg-drafts/issues/589

  smfr: Old proposal to allow transform property to take a comma sep
        list where each has its own transform-origin. Additionally a
        proposal for shorthand to allow origins
  smfr: Seems a bit too late to add this, big change to transform. Not
        in favor, but welcome other input
  <dbaron> Seems like a bunch of complexity (e.g., with animations),
           so I'm fine with rejecting the proposal.
  TabAtkins: Reasonable. To address use case might be interesting to
             explore transform-origin function that takes the list.
             But that would be convenience feature.
  TabAtkins: I was in favor back in the day, but I agree it's minor
             and not worth the churn
  AmeliaBR: Agree with TabAtkins. If we do this it has to apply to
            transform-box as well as transform-origin
  astearns: Is what the proposal requests possible but in a different
  TabAtkins: Yeah, translate-origin is a translate function before and
             after your transform list. You can simulate it on your
             own. You have to know how to do that and perhaps an
             example would be good. Nothing to prevent you from
             representing on your own
  astearns: Proposal is to reject this proposal
  astearns: Concerns?

  RESOLVED: Reject this proposal

CSS Text 3

Bidi and pre-wrap end of line spaces
  github: https://github.com/w3c/csswg-drafts/issues/4422#issuecomment-543054050

  florian: Spoke about similar and resolved. This is a new one.
  florian: We have provisions as to what happens to spaces at end of
           line. Number of cases where supposed to hang. When you do
           bidi on line and spaces end up in the middle of the line is
           unclear and not interop. Screenshot in the issue of what
           everyone does and a second of what I should should be done
  florian: Complication of screenshot is spec allows 2 things, spaces
           to hang or spaces to collapse. Not discussing changing that.
  florian: There's a number of variants, so easier to look at. If
           people have looked would appreciate feedback on if you
           agree or not.

  TabAtkins: In your example are the colored spaces logically in
             rainbow order?
  florian: No, just different colors. No order. whitespace-pre example
           show order when they are bidi reordered. Source order is in
           link above
  TabAtkins: Looking for easy way to know logical order of spaces, but
             answer is look at source
  AmeliaBR: Example is spaces between every letter and some of the
            letters are naturally right to left and some are left to

  florian: Look at comment at bottom where I explain every case where
           I think they should change and why they're wrong. If you
           think there's something incorrect in that claim it would be
           good to know
  fantasai: Intention is correct, want to re-work PR
  astearns: People should look, fantasai rework the PR before next
            week, then we'll resolve

  astearns: Thanks everyone and we'll talk next week

Received on Wednesday, 23 October 2019 23:21:31 UTC