- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 16 Aug 2021 18:11:07 -0400
- 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