W3C home > Mailing lists > Public > www-style@w3.org > August 2021

[CSSWG] Virtual F2F 2021-07-27 Part III: CSS Cascade, CSS Fonts, Animations/Transitions/Gradients, CSS Nesting [css-cascade] [css-fonts] [css-animations] [css-transitions] [css-images] [css-nesting]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 16 Aug 2021 18:11:07 -0400
Message-ID: <CADhPm3snjoKTpczBm_bznFbWVtfRW+wXPJ8+PUbSh-aSSS6Nrg@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 Cascade

  - RESOLVED: Close no change, until there's a stronger use case (Issue
              #6461: Any needs to avoid other layers overriding
              name-defining @-rules?)
  - RESOLVED: Reserve the CSS wide-keywords (making the whole layer
              block invalid at parse time) for now and details TBD when
              we have better use cases (Issue #6323: Allow authors to
              explicitly place unlayered styles in the cascade layer

CSS Fonts

  - RESOLVED: No change, should work with already-in-the-spec calc()
              improvements (Issue #5635: Need method to interpolate
              variable font settings)


  - RESOLVED: This is something we want to work on, exact details TBD
              (Issue #5617: Higher level CSS interpolation module)

CSS Nesting

  - RESOLVED: Publish FPWD of nesting


Agenda: https://github.com/w3c/csswg-drafts/projects/19

Scribe: emilio

CSS Grid

Replaced elements with percentage sizes in auto-min grid areas
  github: https://github.com/w3c/csswg-drafts/issues/6278

  TabAtkins: iank asked us not to resolve on this, but we can probably
  Rossen: should we move on to other issues?
  TabAtkins: let's move on

CSS Cascade

Any needs to avoid other layers overriding name-defining @-rules?
  github: https://github.com/w3c/csswg-drafts/issues/6461

  miriam: So it's possible to give importance to e.g. using an
          animation (like using !important on animation-name)
  miriam: but there's no way to do the same for the animation
          definition itself
  miriam: We discussed how name-defining constructs should behave for
          layers, but there's no way to make them difficult to override
  miriam: That seems fine to me but OP wondered about whether there's a
          use case for it
  TabAtkins: Without a strong use case I'd rather avoid adding another
             level of layering given they interact with tree scopes
  miriam: Agreed

  fantasai: How many of these things we have? We haven't needed one so
  fantasai: Layers end up reordering these name-defining constructs,
            and the question is whether it's needed to make them
  fantasai: important is really about needing something to be overridden
  fantasai: I don't think we need to add an importance mechanism to
            these name-defining constructs

  <TabAtkins> The fact that nobody's request the ability to put
              !important on these constructs so far (which is today's
              poor-man version of layers) suggests it's not needed
  * emilio agrees with TabAtkins

  Rossen: Seems like we should move on until there's a stronger use case

  RESOLVED: Close no change, until there's a stronger use case

Allow to explicitly place unlayered styles in the cascade layer order
  github: https://github.com/w3c/csswg-drafts/issues/6323

  miriam: This one is another coming from an earlier resolution
  miriam: We resolved that unlayered styles are lower priority
  miriam: jensimmons asked about whether it'd be useful to tweak the
          unlayered styles priority
  miriam: There's some syntax proposals in the issue
  miriam: and I'd expect it to work at each level of layering
  miriam: Are we happy with an empty layer rule syntax? Does this
          become too complex?

  florian: I could see use cases for top/bottom, has any
           non-theoretical use case come up for in the middle?
  miriam: Yeah, you want components at the top and resets on the
          bottom, so you might want most of your styles between them
  TabAtkins: Like florian I see the use case but I'm not sure we need
             to solve it right now
  TabAtkins: We could reserve the CSS wide keywords as layer names in
             case we want to solve them
  miriam: Does that become a problem if additional wide-keywords are
  TabAtkins: Theoretically? But we haven't added many over the years
  fantasai: We could also do something that isn't a keyword, like an

  fantasai: I don't have strong opinion on having to solve this now,
            and I'd be ok reserving the wide-keywords

  florian: Maybe I need to re-read the minutes for when we decided to
           switch top/bottom, I wasn't there and it seems !important
           could take care of jumping to the top
  miriam: Main reason for that was that putting them at the bottom
          allows progressive enhancement
  miriam: Sort of like when not all browsers had media queries you'd
          write the specific styles in there
  miriam: but lots of people think of layers as a way to hide their
  florian: I guess I see it more like the latter but that also doesn't
           give me a strong use case for having unlayered styles in the
  florian: I'd be fine reserving the wide keywords though

  fantasai: So there's the question of whether we add it now, if we
            don't we might want to just reserve the keywords
  miriam: If we're not sure if it's needed I'd be ok with reserving the
          keywords and delaying
  miriam: since it adds a fair amount of complexity
  florian: What do we need by reserving the keyword? Just making them
           syntactically invalid?
  fantasai: Yeah, if you define @layer with that keyword the whole
            block is in invalid
  florian: Is that progressively-enhanceable? If you add a layer that
           doesn't work and then it starts working...
  fantasai: Why would you type it in if it doesn't work?
  florian: Would it be wholly invalid or just ignored?
  TabAtkins: Could we bring that detail back to the thread?
  Emilio: fwiw it seems simpler to make the whole block invalid at
          parse time

  RESOLVED: Reserve the CSS wide-keywords (making the whole layer block
            invalid at parse time) for now and details TBD when we have
            better use cases

CSS Fonts

Need method to interpolate variable font settings
  github: https://github.com/w3c/csswg-drafts/issues/5635

  <astearns> https://typetura.com/
  astearns: This was raised by Scott a while back along with other
  astearns: He works on typetura which does a lot of fancy things with
            responsive typography
  astearns: and he'd like to do fancier things and helpfully filed a
            bunch of issues
  astearns: but they didn't get a lot of attention
  astearns: so I raised them to get some attention from the group
  astearns: He wants to interpolate variable font settings that are
            numbers with e.g. viewport lengths
  astearns: Can't use calc() because incompatible units

  TabAtkins: It's perfectly fine to use calc(), you just need to divide
             the unit away
  TabAtkins: unless there's something more subtle going on we should be
             fine on this issue
  astearns: There are some other subtleties, calc() might be limiting,
            but let's do this on the next issue
  <chris> calc(19px/1px)
  <fantasai> chris, wouldn't you just write 19 at that point?
  <chris> if you have some length and it happens to have px, you can
          convert it to number by dividing out the unit
  <chris> but what I put was a handy test
  emilio: Tracking multiple units doesn't work, but dividing the same
          units and getting an integer possibly works already?

  RESOLVED: No change, should work with already-in-the-spec calc()


Higher level CSS interpolation module
  github: https://github.com/w3c/csswg-drafts/issues/5617

  astearns: This also might be covered in-spec but not impls
  astearns: In addition to using calc() across various types, they want
            to use easing functions for ~all properties
  astearns: Haven't looked at it in a while, but perhaps we can use
            easing functions in all properties or is it more limited
            than that?
  chris: When we added animations and before with SMIL we got some
         feedback from animators saying that it only worked on two
  chris: so this is a thing we want any time we transition, animate or
  astearns: And I don't think we have any of the easing editors on the
  astearns: It seems they are meant to be used anywhere where a value
            could be set
  fantasai: What did you mean with that?
  <fantasai> https://www.w3.org/TR/css-easing-1/#easing-functions
  fantasai: They are meant to be used where an easing function is
            asked for
  fantasai: it's a function, not a value
  astearns: I believe Scott's ask is for things like optical sizing to
            be able to use easing functions as values
  astearns: to be able to have more subtle transition across values
  <chris> seems like a reasonable ask
  fantasai: You need a range of values for that as well, not just the
            easing function

  lea: If I'm reading this correctly, easing functions is just a minor
       piece of that issue
  lea: There are other important issues like mixing relative units
  lea: Gradient stops can automatically be evenly spaced, whereas it
       needs to be done manually in keyframes
  lea: I didn't open this issue and Scott isn't here, but I think the
       idea is to unify all these interpolation mechanisms
  lea: so that the same features are available everywhere

  miriam: When interpolating between breakpoints wrt media/container
          queries, part of the complexity is that you have to set those
          breakpoints and then somehow attach an animation to those
  miriam: I've thought a bit to scrolling animations and animation
          timelines linked to container / media queries
  miriam: Not sure if something like that would help

  <argyle> https://shadows.brumm.af/
  argyle: I use a lot of online tools that would generate things for me
          like shadows (^)
  argyle: What I'd like to do instead of something like this is letting
          CSS do this with a clamp-like function
  argyle: so that I can get an easing shadow with a natural curve
  argyle: It'd be really cool to pass curves to shadows / gradients /
          etc rather than a bunch of percentages
  argyle: Almost anywhere where we accept multiple values we could
          shorten the entire stack into one or two by specifying the
          range and a curve
  argyle: If you're looking for use cases for stuff like this I can help
  astearns: I think this is very relevant, there are lots of use cases
            to express stuff in terms of curves of values. Not quite
            sure where to start though

  Rossen: Where do we go from here? Is this the most appropriate issue
          to capture this?
  astearns: birtles suggests this as an expansion to web-animations-2
  emilio: Use cases Adam mentions aren't particularly animation-like
  Rossen: Shouldn't but it's where most that stuff is defined

  Rossen: Sounds like enough motivation was heard. There are some
          overlapping efforts in the interpolation space with
          animations-2, and if that's not enough we need to figure out
          what else is needed
  Rossen: Is there anything else we can do with this issue?
  <lea> +1 to work on it

  RESOLVED: This is something we want to work on, details TBD

FPWD for Nesting

  <TabAtkins> https://drafts.csswg.org/css-nesting-1/
  TabAtkins: We have agreement that this is a good idea, I'd like to
             request FPWD
  TabAtkins: We've discussed nesting a bunch of time, has matured a
             lot. There's the OM bits, etc. Gotta do some work on syntax
  <chris> +1 to FPWD, LGTM
  <lea> +1 to FPWD
  <astearns> +1 to FPWD
  <miriam> +1
  <rachelandrew> +1

  RESOLVED: Publish FPWD of nesting

  <lea> This is possibly the main reason authors still use
        preprocessors, if I could +100 I would
  <TabAtkins> Agreed, lea


  Rossen: What's the status of logical? We have min-block-size defined
          but not on TR
  Rossen: Not published since 2018
  Rossen: It's the only thing implemented everywhere but not on a WD
  <fantasai> https://www.w3.org/TR/css-logical-1/#propdef-min-inline-size
  fantasai: It is on TR (^)
  fantasai: We should update it, there's lots of specs we should update
  Rossen: There's stuff in the ED which is not in a public WD
  Rossen: We should revisit this
  Rossen: That's everything for today, let's end here
  <fantasai> https://www.w3.org/TR/css-logical-1/#property-index
Received on Monday, 16 August 2021 22:12:46 UTC

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