- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 Aug 2023 19:28:17 -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 Text
--------
- RESOLVED: Publish CSS Text 3 as a CRD
CSS Color
---------
- RESOLVED: Accept the proposed resolution with the examples included
(Issue #8318: Specified value for color when calc() is
used)
CSS Inline
----------
- RESOLVED: Three longhand properties as proposed with two linked by
a shorthand, names to be bikeshed, one issue for each to
work them out (Issue #8829: It's impossible to use
`text-box-trim` without changing line progression within
the paragraph)
CSS Borders
-----------
- RESOLVED: Allow a single value for box-shadow-offset for that
longhand property only (Issue #8568: Allow declaring
`box-shadow-offset` with a single value)
CSS Images
----------
- RESOLVED: We go with option 2 [add a stripe function family] and
worry about composability in the future (Issue #7244:
Allow stripes to be used as gradients)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Aug/0016.html
Present:
Tab Atkins
David Baron
Oriol Brufau
Emilio Cobos Álvarez
Matthieu Dubet
Elika Etemad
Robert Flack
Paul Grenier
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
David Leininger
Chris Lilley
Peter Linss
Eric Meyer
ChangSeok Oh
Florian Rivoal
Fernando Serboncini
Jen Simmons
Alan Stearns
Bramus Van Damme
Lea Verou
Sebastian Zartner
Regrets:
Miriam Suzanne
Scribe: emeyer
Chair: astearns
TPAC
====
<astearns> https://wiki.csswg.org/planning/tpac-2023
astearns: Elika put together a Wiki planning page for TPAC
astearns: Please add your availability, particularly if you're
joining remotely
astearns: Rossen unfortunately cannot make it to TPAC, so Elika and
Miriam have volunteered to help with chairing duties
astearns: Any changes to today's agenda?
(silence)
CSS Text 3 CRD
==============
github: https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-1693967377
<chris> +1 to transition to CRD
florian: The question is, should we publish as a CR draft
florian: Spec is up to date, tests exist for every change
<chris> changes look good, few open issues
florian: There are a couple of open issues, but they're coordination
problems with other specs or browser releases
florian: We should compile comments and wider review, and if those go
well we're probably ready for a full CR
astearns: Thank you for making sure all the changes have tests
florian: Thank Elika as well
chris: Everything looks good after a quick look
astearns: Any objections?
RESOLVED: Publish CSS Text 3 as a CRD
CSS Color
=========
Specified value for color when calc() is used
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8318
chris: I have a proposed resolution in the issue
chris: Go with what's implemented
chris: If calc() resolves to a single value, you get that value
without the calc() wrapped
chris: clamp() resolves to the clamped value
emilio: Want to clarify that I think the second example is wrong
chris: Yes, you're right; oops
emilio: Otherwise seems fine to me
<dbaron> I think 1/0 should be +inf, no?
<TabAtkins> 1/0 is definitely inf
<emilio> nvm
<TabAtkins> https://drafts.csswg.org/css-values-4/#css-infinity
TabAtkins: This is fine with me
astearns: Comments or objections?
(silence)
RESOLVED: Accept the proposed resolution with the examples included
`contrast-color()` MVP in Level 5
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9166#issuecomment-1688124086
astearns: We discussed this last week but I'm wondering if we should
postpone
TabAtkins: Yes, we'd like to postpone to next week
astearns: Should we discuss the next topics without Myles?
fantasai: I can go over this but not sure if we should resolve on it
fantasai: There are some open questions to consider
CSS Inline
==========
It's impossible to use `text-box-trim` without changing line
progression within the paragraph
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8829
fantasai: Two issues are open on the fact that the current way we've
set up this trimming feature depends on a property that has
two different effects
fantasai: I'll call one the leading-trim effect
fantasai: This is the effect of taking the first line box and
trimming down to some metric rather than the full ascent of
the font and half-leading and so on
fantasai: Same thing on the bottom edge
fantasai: The second, the line-box-contain effect
fantasai: Line boxes can grow, but this effect allows us to say for
an inline box, rather than using ascent metrics, use
another metric like the cap-height
fantasai: That way an accent on top of a character can leak outside
the line box and that's okay
fantasai: The issues say it would b e useful to separate these two
fantasai: An author might want to use one over the other
[some things missed]
fantasai: Proposal is to split text-box-edge into text-box-edge and
text-line-edge (names subject to bikeshed)
fantasai: Does this make sense or do we need more description?
astearns: It makes sense to have separate properties; the names
should give an idea of the connection between them
astearns: Not sure ‘box' and ‘line'
astearns: do that
jensimmons: Use case: I might be an author who wants my paragraph box
to line up with a floated image, so I need to chop off
the paragraph's top whitespace
jensimmons: So I use text-box-edge and chop it to the cap height or
x-height or whatever
jensimmons: Separate, there are accent marks or super/subscripts and
I get weirdness where extra line box height happens
jensimmons: I want the spacing to be regular throughout the text so
the vertical rhythm is consistent
jensimmons: I need to be able to say I want to use this different
font metric than is used to line up block edges with
floats or whatever
dbaron: It wasn't clear to me which property you were proposing to
split
fantasai: Right now, leading-trim works at the intersection
text-box-trim (which looks up text-box-edge)
fantasai: text-box-edge says what metric you care about: ascent,
cap-height, something else
dbaron: And that only applies to inlines?
fantasai: Right
dbaron: You want to let people set inline and block trimming
differently
fantasai: Yes
jensimmons: I think it will become best practice for authors to put
into resets a thing to change how box models work for
lines and line boxes
jensimmons: Separately, you might need to do something different in
certain places
dbaron: The one that interacts with text-box-trim needs to be
narrowed?
jensimmons: I think so, yeah
dbaron: Okay, this makes sense
florian: Even if you're not looking at different font metrics, in the
old model you had to turn on line re-jiggling to be able to
access the box trimming
florian: With this you can say this is what I do to boxes, leave the
lines alone
jensimmons: I do think authors think of these things differently
jensimmons: Having them tied together doesn't quite make sense
fantasai: Going into the re-jiggling of the properties, we end up
with three longhands
fantasai: text-line-edge to measure line edges
fantasai: text-box-edge
fantasai: text-box-trim, which sets the side you trim
fantasai: From there, we can create a shorthand which sets side and
trim in one shot
fantasai: So an author who want to affect line sizing would set
text-line-edge, which inherits
fantasai: An author could set text-box-edge to say which boxes are
trimmed
fantasai: We can also eliminate the longhand of text-box and have a
property that just sets the sides with the trim
fantasai: The advantage of longhand is that you can set these things
separately without needing variables
fantasai: That's an open question of whether to have the longhands,
or just have the shorthand
fantasai: Another open question is whether the initial value of
text-box-edge should be an auto that looks up text-line-edge
florian: I think we do want the longhands
florian: One seems to be linguistically dependent, the other not
florian: Not sure what we should call the shorthands, but we can
figure that out
astearns: Should we resolve on having three longhand properties and
have one issue for each?
fantasai: Seems fine; I would also add the shorthand to encompass two
of them
astearns: I would really like to see examples, particularly of the
reset things Jen was talking about
astearns: Showing the motivation for having a separate property
astearns: Then another example showing how you would use the
properties together
<florian> do it
RESOLVED: Three longhand properties as proposed with two linked by a
shorthand, names to be bikeshed, one issue for each to work
them out
CSS Borders
===========
Allow declaring `box-shadow-offset` with a single value
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8568
SebastianZ: Proposal is to set a single value for the box shadow
offset instead of having two values
SebastianZ: Setting one value would automatically set the other, so
the same distance for both axes
SebastianZ: Furthermore I suggest changing the syntax to avoid any
conflicts that arise regarding a single value instead of
two values
SebastianZ: We also have the values for blur and spread, which are
length-percentage
SebastianZ: If we want to introduce a way to define offset by a
single value, we have to think about how it can be done
without conflicts
TabAtkins: As noted in the issue, the shorthand already has a bunch
of numbers, so we'd have to do something new to separate
them
TabAtkins: The only author benefit would be to set 45 degree offsets
a little more easily
<smfr> agree with Tab
<emilio> +1
TabAtkins: I suggest we reject as DONTCHANGE
fantasai: I agree with regard to the shorthand
fantasai: I don't care if we make this possible on the longhand
or not
<Zakin> lea, you wanted to say I don and to also agree that I don't
think the complexity of this change is worth the use cases
addressed, I'm not even convinced 45deg is that common
lea: I agree that the complexity of the change isn't worth it
SebastianZ: I want to note we have different issues that suggest to
extend the other values as well, so at some point if we
want to extend the shorthand, we'll have to introduce a
new syntax
SebastianZ: On the other hand, I'd be fine for now that we just allow
it on longhands and then we can separately discuss the
shorthand syntax
lea: I don't see harm with allowing a single length in the longhand,
consistent with other properties in CSS; but not worth the
complexity of allowing in the shorthand
SebastianZ: Maybe we can agree to add it to the longhand for now?
<lea> +1
<fantasai> +1
<TabAtkins> no opinion on the longhand
astearns: Agreed it's a small use case, but the change to the
longhand is also small
<fantasai> I'm in favor because it's how we handle other two-value
properties. Even if the use case is small, the consistency
is good.
RESOLVED: Allow a single value for box-shadow-offset for that
longhand property only
SebastianZ: I'll file a new issue about the shorthand syntax
astearns: I think there's a fair consensus here that we not do that
SebastianZ: There are several use cases to extend the other longhands
and have other features there
astearns: I'm happy for you to open the shorthand issue if it refers
to all those other use cases, not just this one
CSS Images
==========
Allow stripes to be used as gradients
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7244
SebastianZ: We had several discussion of how to bring stripes()
syntax into gradients
SebastianZ: There were three proposals initially, but the third was
ruled out
SebastianZ: So we now have two choices
SebastianZ: Add the stripes() function to existing gradient functions
SebastianZ: Or add new functions just for stripes
SebastianZ: Both have pros and cons
SebastianZ: Tab suggested option 2, Lea said option 1, I think we
should go with option 2 for now but keep discussing
option 1
TabAtkins: My big question is whether we have a reasonable argument
for making this easier to do
TabAtkins: You can already do stripes in gradients, with a different
syntax and with some more author work
TabAtkins: The question is whether stripe images like this are common
and complex enough that writing them in gradients as they
are now is an impediment to authors
TabAtkins: I just don't feel like it's been established that there's
a big need for this in the authoring community
<fantasai> +1 to everything TabAtkins said
lea: The whole point of defining stripes as a 1D image was that we
intended to use them in other places in CSS
lea: Defining how 1D images can be used in place of gradient colors
stops can be much more useful down the line
lea: Defining ad-hoc gradient functions sets us up for having to
define a lot of specific functions
lea: Combining two concepts they already know is something they might
do accidentally
lea: We could say that the stripes() function has to be in place of
the color stops at first, and relax that later
lea: I want to be able to talk about how 1D images should work
lea: If we want to do something like this, there could be value in
renaming stripes() to something more broad
lea: Even in the border use case that started this, it's weird to set
a border to stripes()
lea: maybe bands would be a better term
<bradk> 'radial-gradient(stripes,' doesn't seem better than
'radial-stripes('
bramus: I always have to look up how to do this in existing
gradients, and there are a lot of tools out there to do this
properly
bramus: I'm leaning toward option 1, which seems nice to me
TabAtkins: The point of defining of defining 1D images was to have a
concept for 1D images which are only useful for borders
TabAtkins: The ability to re-use this for certain 2D cases was
discussed but was not the reason we did it
fserb: First, I agree with when Bramus said about people trying to do
stripes on gradients
fserb: Independent of what Tab said, I think option 1 looks better
fserb: What does the 100px in that option mean?
SebastianZ: In my proposal it was the width of the stripes
<astearns> example: background-image: linear-gradient(45deg, black,
stripes(red, yellow, lime, blue) 100px, white);
SebastianZ: So that would be a 100px-wide areas for the stripes, so
each stripe would be 25px wide
SebastianZ: This is different to the color-stop syntax we currently
have
SebastianZ: My point was to make it easier to express a width for all
the stripes
SebastianZ: We could use color-stop syntax as Oriol pointed out
<TabAtkins> I am indeed finding a bunch of "gradient stripe
generators" from a quick search, so I wouldn't object to
linear-stripes()/etc
<fantasai> +1 to TabAtkins
fserb: The syntax currently defines the image as proportional to
whatever?
SebastianZ: The current use cases are just for borders and outlines
SebastianZ: There, it takes the border width into account
SebastianZ: So in this case, I wanted to say “let's define a width
for this”
fserb: This seems like a generic problem of stripes
fserb: Maybe the linear gradient syntax is more consistent
<lea> thought experiment: how would we do the opposite? How would we
produce a <1d-image> that is a gradient? I'm not saying let's
do it, but it's not entirely unthinkable, especially once <
1d-image>s start being used all around (e.g. strokes, paths
etc) We'd need to be consistent.
<argyle> https://shorturl.at/or689
argyle: I've been making lots and lots of stripes and it's hard to
find online the syntax easiest to manage
argyle: In the link I shared, I provided multiple stripe examples
<lea> argyle: I created the whole technique of using CSS gradients
for patterns back in 2010, so you are not alone here! :)
argyle: Would this proposal fix some of the hard stop problems,
allowing aliasing
argyle: Sometimes stripes aren't even; sometimes the syntax is used
to do easing
argyle: If we're going for stripe convenience, I'd like to see
aliasing as an option
fantasai: Want to support everything Tab said
fantasai: If we're going to add this, we should use option 2
<bradk> +1 to #2
fantasai: If we want to do a composable thing, then I think we should
add linear-pattern and radial-pattern that are dedicated to
composing 1D patters, including 1D stripes() and gradient()
fantasai: Trying to shoehorn stripes() into gradient functions is
awkward
fantasai: I don't think it's a good plan
<smfr> +1
<TabAtkins> (note, for example, that a repeating stripes, which would
be great, isn't currently compatible with putting
stripes() directly into repeating-linear-gradient() - the
way that flex is defined is incompatible with the way
that the repeating width is found)
lea: Want to point out the proposal says we'll define linear and
radial stripes, but there's more than that: conics, repeating
gradients, maybe mesh gradients later on
<argyle> conic stripes https://shorturl.at/itzDR
TabAtkins: To Adam, stripes() is not just about evenly-sized stripes
TabAtkins: So long as they are solid-color stripes of some size,
you're good to go
TabAtkins: The transition between color areas is not defined
TabAtkins: I presume stripes would work similarly to linear gradients
TabAtkins: That should be fine to allow, but it would be good to
raise as an issue that we should say so in the spec
TabAtkins: The idea of just using stripes() directly in gradient
functions
TabAtkins: In some ways, it's just incompatible, as with repeating
gradients
TabAtkins: You could not use a repeating-linear-gradient with a
flex-defined stripe
TabAtkins: The concepts are just different enough that they need
special handling
TabAtkins: That's why I don't think this is do-able in a generic way
TabAtkins: Google shows there are a lot of stripe generators, so the
need does seem to exist
<argyle> +1 to dedicated functions
<bramus> +1 to that
<fserb> I wonder if we are going to end up defining a 1d-image
gradient, to do linear-gradient(45deg, gradient(red,
white)...)
<fantasai> fserb, that's why I don't think we should shove this into
the gradient functions. If we want composing the
functions, we should add a composition function that's
better suited to composing.
<fserb> fantasai, yeah, it makes sense.
fserb: You mentioned a bunch of functions, but that's different than
what Elika said, right?
fantasai: I was suggesting both; I think it's convenient to have
dedicated functions in parallel with gradient functions
fantasai: If we want composable things, we need to define those
<SebastianZ> +1
<lea> a composition function is more complex and confusing than
either option, and we're just hoping it will save us complexity
down the line…
<florian> +1
lea: To Tab, who said stripes wouldn't work with repeating gradient
syntax, wouldn't that depend on the syntax we choose??
TabAtkins: Yes, that would work, but that would be the most complex
and least justified of the syntax options
<fantasai> +1
<TabAtkins> the *-stripes() function family, paralleling gradients
<TabAtkins> (these are basically just sugar for a gradient)
<fserb> I like composition functions more than stripe specific
functions, but I agree that adding stripe support to gradient
is not great.
SebastianZ: I think fantasai's suggestion is a good path forward
SebastianZ: Let's introduce new stripe-gradient functions and later
on, pursue a way to mix both stripes and gradients
SebastianZ: At some point we could have in the image-1D data type
some gradient function as well that could be used inside
other patterns
SebastianZ: You could use both, having both gradients and stripes
SebastianZ: So, option 2 for now
<TabAtkins> Yeah, I'd prefer waiting on for a third example before we
try to generalize.
<fserb> that's fair too
astearns: I think that's about all we could resolve on today, absent
any objection
<bradk> Straw poll?
astearns: I'm not sure there's sufficient enthusiasm to start that
work
astearns: Are there any objections to adding the stripe function
family, as in option 2?
<TabAtkins> +1 to adding *-stripe() functions
<bramus> Would be great for authors already
(silence)
RESOLVED: We go with option 2 and worry about composability in the
future
Received on Wednesday, 30 August 2023 23:28:52 UTC