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
              order)

CSS Fonts
---------

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

Animations/Transitions/Gradients
--------------------------------

  - 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

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

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
             discuss
  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
             already
  miriam: Agreed

  fantasai: How many of these things we have? We haven't needed one so
            far
  fantasai: Layers end up reordering these name-defining constructs,
            and the question is whether it's needed to make them
            important
  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
          added?
  TabAtkins: Theoretically? But we haven't added many over the years
  fantasai: We could also do something that isn't a keyword, like an
            asterisk

  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
          resets
  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
           middle
  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
            issues
  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()
            improvements

Animations/Transitions/Gradients
================================

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
         values
  chris: so this is a thing we want any time we transition, animate or
         interpolate
  astearns: And I don't think we have any of the easing editors on the
            call
  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
          breakpoints
  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

Publishing
==========

  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 : Monday, 16 August 2021 22:12:47 UTC