[CSSWG] Minutes Telecon 2023-08-30 [css-text] [css-color] [css-inline] [css-borders] [css-images]

  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

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)


Agenda: https://lists.w3.org/Archives/Public/www-style/2023Aug/0016.html

  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

  Miriam Suzanne

Scribe: emeyer

Chair: astearns


  <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?

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?

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

  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
  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
  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
  <fantasai> +1 to TabAtkins
  fserb: The syntax currently defines the image as proportional to
  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
  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
  TabAtkins: In some ways, it's just incompatible, as with repeating
  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,
  <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
  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

  RESOLVED: We go with option 2 and worry about composability in the

Received on Wednesday, 30 August 2023 23:28:52 UTC