W3C home > Mailing lists > Public > www-style@w3.org > February 2020

[CSSWG] Minutes A Coruña F2F 2020-01-23 Part II: CSS Values, CSS Transforms, CSS Overflow & CSS Scollbars, Web Animations & CSS UI [css-values] [css-transforms] [css-overflow] [css-scrollbars] [web-animations] [css-ui]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 18 Feb 2020 19:19:55 -0500
Message-ID: <CADhPm3uXX8AfMJMVWXAZ6dXJTViaB5aZdb-qJOtWRxtsX86z2g@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.

CSS Values

  - TabAtkins' polls for how to handle mod() in issue #2513 (Add
      round()/floor()/ceil() functions) got different answers
      depending on how the question was asked so there is no clear
      conclusion on the best approach.
      - Polls: https://twitter.com/tabatkins/status/1219936010961915905
        | https://twitter.com/tabatkins/status/1219939184682717184

CSS Transforms

  - RESOLVED: No change to the behavior, add a note to the spec
  - RESOLVED: Move the box keyword definitions on css-box and publish
              a new working draft
  - RESOLVED: Rebase the rest of the specs referring to these
              definitions to point to css-box
  - RESOLVED: Move margin-trim to css-box-4 before republishing

CSS Overflow & CSS Scollbars

  - RESOLVED: Move scrollbar-gutter to the scrollbars spec, add
              florian as an editor (Issue #4674: scrollbar-gutter is
              too complex)
      - Due to the discussion about what properties below on
          scrollbar-gutter (below) it was suggested that the move
          shouldn't occur until after the final property set is
          decided and therefore it can be certain that this property
          is a better fit for Scrollbars.
  - There are not documented use cases for all the scrollbar-gutter
      properties so several implementors expressed concern about
      implementing properties that may not be needed. Florian will go
      back through and add in the use cases for the properties for the
      group to use and then finalize the property set during a future

Web Animations & CSS UI

  - RESOLVED: Mark user-select as discretely animatable, not
              non-animatable. (Issue #3153: Animating user interaction


Agenda: https://wiki.csswg.org/planning/galicia-2020

Scribe: emilio

CSS Values

Update on mod() function
  github: https://github.com/w3c/csswg-drafts/issues/2513

  <TabAtkins> https://twitter.com/tabatkins/status/1219936010961915905
  <TabAtkins> https://twitter.com/tabatkins/status/1219939184682717184
  TabAtkins: So the poll I started yesterday about mod has ended
  TabAtkins: had some fair results, and the contradictory results I
  TabAtkins: So 3/2 in favor of JS semantics if you ask directly, 9/1
             in favor of math if you ask them about expected results
             of a basic computation. So depends on how you ask.
  TabAtkins: So the conclusion is that most people just write buggy
             code and they think / want math semantics
  TabAtkins: There's also a lot of discussion in the replies about
  TabAtkins: and it seems math is a better suit to fix those use cases
  jfkthame: Would people be better off with explicit is-odd / even
  TabAtkins: They sometimes use it as a proxy for odd / even, but it's
             not general of course
  TabAtkins: So no decision for now yet unless the room is convinced,
             but worth thinking about it and we can pick this up at a
             later call

  TabAtkins: How does the room feel? Did anyone change their mind?
  myles: I guess there's a third option which is not defining what
         negatives does
  TabAtkins: That's what C++ does and that's evil
  myles: I didn't mean to return unicorns but just explicitly return 0
         or something
  TabAtkins: It seems negatives could be common, I wouldn't want that
  Rossen: Seems not many opinions have changed so let's move on

CSS Transforms

'view-box' definition doesn't make sense
  github: https://github.com/w3c/csswg-drafts/issues/4662

  TabAtkins: The definition seems to not make sense
  TabAtkins: The origin and size of the box are not related
  TabAtkins: says that the origin of the coordinate space is the
             viewbox start
  TabAtkins: and the size is the size of the viewbox
  TabAtkins: So for example if you have a viewbox="20 20 100 100"
  TabAtkins: the origin of the coordinate space is outside of the
             viewport, such as the origin is at (-20, -20)
  TabAtkins: so that the viewbox is based off a rectangle outside of
             the svg's viewport

  heycam: So before CSS transforms, in svg you couldn't use percents
          inside transform so this was a non-issue
  heycam: I wonder if the issue is the way we're defining this
  heycam: Maybe it doesn't make sense to define that rect
  emilio: For percents in transforms you just need a basis so you
          don't need any origin right?
  fantasai: Yeah but other stuff references the view-box
  TabAtkins: And the origin matters for rotations and scales
  emilio: Fair
  myles: Pretend you use transform-box: view-box and rotate by 3deg or
         something, what would you expect?
  TabAtkins: Multiple acceptable answers, but the issue is that the
             size and the origin are not related, unlike other boxes

  fantasai: The issue is that this is how transforms have been defined
            in SVG
  fantasai: [reads AmeliaBR's comment in the issue:
  TabAtkins: Ok if it's what SVG uses by default then sure, whatever
  TabAtkins: but I'd like it to be called out explicitly
  faceless2: The way we see the viewbox is just a translate transform
  faceless2: I'm not sure it's as confusing as it sounds

  TabAtkins: My issue is that if you choose transform-origin: 100%
             100% the point you get makes no sense
  TabAtkins: but sure if it's legacy then fine, I thought it was
             invented recently as it was added after other changes
  TabAtkins: so I'm ok with the behavior but I want to clarify that
             this is legacy svg behavior

Consolidating Box Definitions

  fantasai: There are other specs that reference these values somewhat
  fantasai: we copied them all out into the box model module
  fantasai: I want to update the definition of viewbox to account for
            this and then change all specs to reference those
  fantasai: Any objections to doing that?
  <TabAtkins> https://drafts.csswg.org/css-box/#keywords

  RossenF2F: It seems something we should do, and seems we should
             close 4662 with no change
  RossenF2F: with the note added to the spec explaining why
  TabAtkins: I guess we'll add it to the box spec
  RossenF2F: Sure
  fantasai: Do we need another keyword to reference the box tab was
            talking about? (size of viewbox at the position of
  RossenF2F: Probably not
  RossenF2F: Objections to the proposed resolution?

  RESOLVED: No change to the behavior, add a note to the spec
  RESOLVED: Move the box keyword definitions on css-box and publish a
            new working draft
  RESOLVED: Rebase the rest of the specs referring to these
            definitions to point to css-box

  fantasai: I propose to move the only non-css2 feature in css-box
            (margin-trim) to level 4 and move this to CR and co. fast
            so that other specs can depend on it
  RossenF2F: Sounds reasonable, objections?

  RESOLVED: Move margin-trim to css-box-4 before republishing

CSS Overflow

scrollbar-gutter is too complex
  github: https://github.com/w3c/csswg-drafts/issues/4674

  cbiesinger: We're interested in implementing this: there's a lot of
              values for this property, but a lot of values didn't
              seem that useful to me
  cbiesinger: florian came with some use cases but I'm not sure
              they're useful enough?
  iank: We probably only want to implement stable
  florian: The other values were solving issues raised by Google
  florian: we should explain them better in the spec
  florian: but I'd be sad if we removed it
  cbiesinger: I think your explanation makes sense

  fantasai: Seems to me this feature belongs on css-scrollbars, not
  florian: I don't care, though I'm not an editor of css-scrollbars,
           so if you want me to keep editing the feature I should
           become an editor
  RossenF2F: Objections to move from css-ui to css-scrollbars and
             adding florian as an editor?

  RESOLVED: Move scrollbar-gutter to the scrollbars spec, add florian
            as an editor

  myles: We did a review with some people that know more about design
         than me
  myles: This feature fundamentally breaks overlay scrollbars
  myles: but we also understand that there's a real problem here
  myles: and you don't want the scrollbar to cover things
  myles: There's also another issue (#4691) which proposes adding an
         environment variable with the width of the native scrollbars
  myles: It seems that'd allow authors to peek
  <tantek> myles++ has a very good point
  florian: I don't think the stable value changes anything with
           overlay scrollbars, it's the force value what's problematic
           for you right?
  myles: Any property that says "all elements should not be covered by
         overlay scrollbars" is problematic
  hober: We like the idea of moving active elements but we don't want
         to encourage authors to try to inset everything

  cbiesinger: The env variable seems a better solution for the google
              use case
  florian: I don't think it would because an env variable is for the
           entire page, so it doesn't depend on whether there actually
           are scrollbars
  cbiesinger: I meant the combination of the env variable with the
              stable value
  fantasai: But florian's point means that scrollbar width may change
  fantasai: and you don't know the scrollbar width
  myles: The wide value is not really that wide, so probably just the
         wide one would be enough
  myles: I think the value should be zero for non-overlay scrollbars

  <tantek> we deliberately removed explicit numeric width from
           scrollbar-width. there's also no "wide" value
  <tantek> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
  <tantek> just: auto | thin | none

  fantasai: We need both to align non-scrollable elements to scrollbars
  myles: Isn't that a problem now?
  florian: Yes, but that's something that `scrollbar-gutter` solves
  florian: The `always` toggle let you get the scrollbar gutter on
           elements that are not scrollable
  florian: which lets you fix that
  <fantasai> The example is is a toolbar which is not scrollable over
             a scrollable box. The author wants the rightmost item in
             the toolbar to align with the rightmost item in the
             scrollable box.
  hober: In a world with that value and overlay scrollbars then that'd
         be zero

  myles: [[discussing with florian on the whiteboard]]
  <fantasai> The discussion is about how to know how thick to make the
             padding on the toolbar if the scroller has a
             'scrollbar-width: thin' declaration - the solution
             currently is to say 'scrollbar-width: thin;
             scrollbar-gutter: always force' on the toolbar
  myles: So you mean that we need two environment variables, one per
         scrollbar-width value?
  <tantek> there is no "thick"
  <tantek> scrollbar-width: auto
  <tantek> is what I think people are trying to say?
  <tantek> examples?
  * tantek agreed with myles

  florian: The thing that would fix this is `always`, people are
           already moving stuff away from the scrollbars, just
           guessing how wide they are
  hober: So a variable that tells you how wide it is?
  florian: As long as you can do that then I'm fine
  myles: There are too many values
  TabAtkins: Some of them could be named better
  <TabAtkins> Okay, so I remember why we did "always" - "stable" means
              that authors still have to ensure their designs work on
              both widths. "always" was meant to be a "let authors
              safely be a little lazier" value.
  <TabAtkins> I feel strongly that if we do stable, we *need* force;
              that's the use-case Florian illustrated and it's very
              valuable I think.
  <TabAtkins> We can maybe drop "both" - it had use-cases that I think
              were mostly based on "always".
  <TabAtkins> So perhaps an `auto | [ stable && force? ]` grammar

  <tantek> re: https://github.com/w3c/csswg-drafts/issues/4674 "Blink
           is interested in implementing/shipping scrollbar-gutter"
  tantek: I'd like to ask Google which other values besides stable is
          Blink interested in implementing, and is blink interested in
          implementing scrollbar-{width,color}?
  cbiesinger: Definitely interested in stable and the env variable,
              not so much in others

  tantek: Makes sense, and I tend to agree with myles that there's if
          there's no implementor interest and no use case maybe should
          be dropped
  cbiesinger: scrollbar-{width,color} is not on the roadmap
  iank: Not meaning we won't implement, but not on the roadmap
  tantek: Then I'd probably advocate for undoing the move to the
          scrollbars spec
  tantek: we'd have to do a lot of gymnastics
  hober: Why not put them in different levels of the same spec?
  fantasai: I think there's a benefit to readers to have related
            features in the same spec
  fantasai: keeping it in overflow doesn't make much sense
  tantek: I don't think there's any benefit of moving it
  RossenF2F: I don't think we should do busywork just for the sake of
             doing it, but I do think that we should have
             scrollbar-related properties together to move them for
             the REC track, and for readers
  RossenF2F: This is why we have modules and levels
  RossenF2F: so we probably can still make a level of scrollbars be on
             the REC track with color/width

  <bkardell> what about what hober said?
  <fantasai> hober, scrollbar-color and scrollbar-width already have
             one implementation
  <fantasai> hober, scrollbar-gutter has an intent from Chrome
  <fantasai> hober, it's not clear which is further ahead in that
  <fantasai> hober, and we're not even in CR, so there's no reason to
             drop anything atm

  tantek: Given the fact that there's disagreement on what
          implementors are interested in I think that trumps the
          cosmetic use case
  tantek: That practical divergence should override the cosmetic thing
  <bkardell> "interest" and "priority" aren't the same though
  fantasai: But it's a WD
  tantek: Right that's why I think busywork is not warranted
  tantek: hearing from WebKit that they're interested in all three,
          otherwise just leave it alone?
  RossenF2F: Let's try to avoid discussing process too much... Do you
             want to undo the previous resolution?
  tantek: Yes, because the lack of interest from blink in
          scrollbar-width/color means we shouldn't do it
  iank: That's a misrepresentation
  jensimmons: interest is not the same as saying not on the roadmap
  iank: It just meant not in the roadmap at the moment
  iank: that may change in the future
  cbiesinger: I'm more skeptical about the scrollbar-width use case,
              we just don't plan to implement it soon
  RossenF2F: There are other implementors other than google :-)
  TabAtkins: Yeah we try to be extremely clear when objecting because
             we understand it's a powerful statement

  <fantasai> I want to point out that overflow-4 is otherwise
             completely experimental stuff and is not an appropriate
             place for a feature that is being imminently implemented
  <tantek> fantasai then move the experimental stuff in overflow-4 to
  <tantek> don't make extra busy work for multiple specs
  <fantasai> tantek, it's not an overflow feature, it's a scrollbar
  <fantasai> tantek, it doesn't belong in that module
  <tantek> overflow and scrolling are tightly related
  <TabAtkins> tantek, stop objecting to other people volunteering to
              do work
  <tantek> fantasai quit making an aesthetic argument
  <fantasai> tantek, it's a usability argument. I want our specs to
             not be GCPM-style hodgepodges
  <tantek> I'm saying postpone until we get positive signals from
           implementers for all three properties
  <tantek> I'm arguing for more modularity not less
  <tantek> anyway my objection to the previous resolution is recorded
  <TabAtkins> tantek, one property per spec?
  <tantek> TabAtkins: no I'm not interested in strawman like that or
           fantasai's "GCPM-style hodgepodgs"
  <tantek> seriously, not good faith arguments
  <tantek> starting by removing things that lack a reason is the right
           thing to do

  florian: I heard calls for dropping values and I'd like to push
           back. We designed this for years in response to use cases.
           I'm happy to document what the use cases were and maybe
           rename values so they're better names
  florian: but until that's done I don't think we should drop values
  hober: That's some work in order to chop things, I'd rather spare
         you the work and chop them now
  <tantek> hober++
  <tantek> I'm really not sympathetic to features without examples/
           explanations up front
  florian: It's just some examples, and I'm sure we won't chop it off
  dbaron: I'd say that's a reason why specs should have explainers
          with what they're trying to solve
  myles: I don't think that actually conflicts with the env variable
  <tantek> if you can't link to the examples / explanations, consider
           them non-existent
  florian: I recall people saying there are no use cases but there
           were, and I'll spend some time cleaning up this and
           investigate dropping these after we remember what they're
  <tantek> florian: if you want to postpone dropping, then why not
           postpone merging also? why is that kind of tentative
           reasoning good for one postponement and not another?
  <tantek> feels pretty inconsistent

  TabAtkins: I think we agree that stable or something that implements
             that is good, and that env doesn't solve it
  TabAtkins: I think `force stable` seems reasonable too
  TabAtkins: as that is what you can use to align
  TabAtkins: non-scrollable things to scrollable things
  cbiesinger: You can use that with the env variable right?
  TabAtkins: Yes
  florian: Don't you need a media query for overlay scrollbars?
  emilio: env variable would be zero in that case
  TabAtkins: Always is the one you were more skeptical about
  TabAtkins: it's done so that you can consistently design stuff
             across systems
  TabAtkins: I could see us dropping always for now
  TabAtkins: `both` is intended for always and it seems to be a lot
             less valuable with stable
  TabAtkins: and I think we can drop it for now too
  TabAtkins: So we can probably drop them and use `stable` with the
             `force` keyword, or with the `env()` variable
  myles: Sounds reasonable
  * fantasai thinks we should take this offline, have Florian and Tab
             come to a conclusion and come back with it
  <emilio> fantasai++

  florian: My proposal is to revisit this in a week or three
  florian: once we have the cases described and alternatives clear
  <tantek> if you're postponing dropping, then postpone merging
  <tantek> why is postponing ok for one and not the other?

  hober: I wanted to reply to tab
  hober: You said that you're ok dropping always and both, and then
         between stable + force, or stable + env() you're indifferent
  hober: I prefer the env variable
  hober: I think it should be an exceptional thing done with
         particular descendants, and the env variable encourages this
         a bit more
  TabAtkins: Are you ok with adding more than two values for different
  hober: We can get to that once it comes up

  cbiesinger: I agree with hober though for different reasons. I think
              env() is more understandable for authors than `stable
  RossenF2F: So next steps florian brings the use cases for the
             current design
  hober: I think we have multi-engine agreement here, which seems
         worth noting
  <tantek> I agree with cbiesinger, so don't bother with moving a dead
           property into a different spec
  <cbiesinger> well the property isn't dead, just maybe some values of

  RossenF2F: Re: merging, scrollbar-width/color just styles
             controls... scrollbar-gutter is more about the box model
  RossenF2F: so let's not move everything to scrollbars yet until we
             know what will remain there
  RossenF2F: next call we'll see whether we stick to that resolution
  <tantek> Thanks Rossen for clarifying purpose of scrollbars spec.
           You're right we should have started there
  <tantek> Rossen++ for upleveling the conversation
  <tantek> That sounds like I need to better document scope in the
           Scrollbars spec
  <tantek> TabAtkins: I've grown very intolerant of time-wasting

  Scribe: TabAtkins

safe-area-insets-* for embedded document by iframe
  github: https://github.com/w3c/csswg-drafts/issues/4670

  emilio: There's no explicit area in env() spec about how
          safe-area-inset behaves in iframes
  emilio: Implementations disagree. We're doing some related work,
          would like it clarified.
  emilio: If iframes are nested, they may not care about safe areas,
  TabAtkins: Who's responsible for this spec?
  heycam: dino and you
  TabAtkins: I'm there for processing model, not values. ^_^
  hober: I'm happy to bug dino about this.
  TabAtkins: Can you (emilio) tag dino into the thread?
  emilio: Yes

Web Animations & CSS UI

Animating user interaction controls
  github: https://github.com/w3c/csswg-drafts/issues/3153

  fantasai: I thought we resolved this topic last year. I think we
            should be marking these properties as discretely
            animatable? (nav-up, user-select, etc)
  fantasai: Stuff in the UI spec.
  dbaron: I think we've only marked things as non-animatable when
          there are technical problems, like animation-* or display.
  fantasai: That's my understanding, so I think we just close this
  <tantek> is that really the right default?

  florian: I agree we only make things impossible when it's
           technically hard, and I don't that the css-ui things are
           that. I think they should be switched to discrete
  florian: So if anything in CSS UI is still marked as non-animatable,
           we should fix that to say "discrete"

  tantek: Something dbaron said about non-animatable.
  tantek: I agree that's been our historical default, but I'm
          wondering if that's actually desirable.
  tantek: At minimum, every time we mark something animatable, that
          implies we need tests for that, that the animation works.
  tantek: So those are all costs. So is that rule a sufficient
          default? In this particular case, it feels kinda weird to
          animate these particular properties.
  tantek: I want to know florian's opinion on this. But my intuition
          is that there's no use-case for these particular properties.
  dbaron: As far as use-cases, people use animations in contexts where
          they animate some UI in from not being there, then "turn it
  dbaron: I could imagine setting nav-up as part of turning it on.
          Maybe it could have been there all the time, but it seems
          plausible to do.
  tantek: That's the kind of reasoning I'm happy to have on the record.
  tantek: If you're animating layout, you might need to animate the
          nav-* props; seems weird but I've seen weirder.

  TabAtkins: And Lea has brought up examples in the past of
             odd-seeming animations; I think there's probably an
             example for everything.
  heycam: I think there's value in having the blanket rule of
          "animatable unless impossible" vs lots of use-case analysis.
  heycam: And if something's not animatable we have to write tests for
          that anyway, so same amount of work.
  * emilio was going to make the same point as heycam :)
  <tantek> good point heycam
  <heycam> great minds :)
  florian: Agree on testing.

  florian: And note it's also about transitions. "animate or not"
           tells you whether the transition happens at the middle or
           at the beginning (or end? don't remember). So it has to
           switch anyway.
  florian: display, animation, etc can't be switched at all for
           technical reasons, but everything else we're just deciding
           where in the animation it switches, and there's no good
           reason to ban it from choosing where to switch.
  florian: I agree that user-select doesn't appear to have a use-case,
           but for afore-stated reasons having an exception here
           doesn't seem to be useful; we still have to pick one way or
           the other.
  <tantek> is there a use-case for user-select animating?
  <tantek> what are we making user-select consistent with?
  <fantasai> all other properties in CSS that use keyword values
  <heycam> tantek, perhaps for similar reasons as dbaron mentioned
           about some UI animating in. maybe you want it not to
           respond to user interaction until the animation is done, or
           at a certain point
  <tantek> ok heycam. good enough for now.
  <TabAtkins> tantek, more importantly to florian's point,
              transitioning the property makes it swap at some point
              regardless, its just about whether it's possible to
              choose where it transitions or not.
  <tantek> TabAtkins, ok that's the consistency I was looking for.

  RossenF2F: So close as accepted? Any objections?

  RESOLVED: Mark user-select as discretely animatable, not
Received on Wednesday, 19 February 2020 00:20:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:15 UTC