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

[CSSWG] Minutes Telecon 2021-03-03 [css-fonts-4] [css-color]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 4 Mar 2021 18:42:15 -0500
Message-ID: <CADhPm3uXqQ3yg6qg8zWWPW5vZpCQE1P1r9=aP9JAV7gPbDAGmw@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 Fonts 5
-----------

  - When adding a definition for advance-override (Issue #5983:
      advance-override details) there's a need to consider where the
      adjustment should occur. There wasn't clear consensus on where
      spacing should be added. It was suggested that this be
      considered at the same time as issue #6075 (Add glyph scaling
      override descriptor to @font-face)

CSS Color
---------

  - RESOLVED: Add back commas (Issue #6066: Commas in color-mix())
  - A separate issue will be opened to consider removing the "in"
      keyword from color-mix.
  - RESOLVED: color-mix(<metadata>, <color-option>#{2}), where
              <color-option> = <color> && <percentage>? (Issue #6064:
              More clarity around the percentage in color-mix())
  - RESOLVED: Negative percentages are invalid in color-mix() (Issue
              #6047: How should negative percentages behave in
              color-mix()?)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2021Mar/0000.html

Present:
  Adam Argyle
  Rossen Atanassov
  Tab Atkins-Bittner
  Tantek Çelik
  Elika Etemad
  Simon Fraser
  Daniel Holbert
  Sanket Joshi
  Jonathan Kew
  Una Kravets
  Daniel Libby
  Chris Lilley
  Ting-Yu Lin
  Peter Linss
  Alison Maher
  Myles Maxfield
  Cameron McCormick
  Morgan Reschenberg
  Alan Steanrs
  Miriam Suzanne
  Lea Verou

Regrets:
  Christian Biesinger
  Mike Bremford
  Megan Gardner
  Dael Jackson
  Jen Simmons
  Greg Whitworth

Scribe: fantasai
Scribe's scribe: myles & TabAtkins

CSS Fonts 5
===========

advance-override details
------------------------
  github: https://github.com/w3c/csswg-drafts/issues/5983

  fantasai: We decided we wanted to add an advance-override descriptor
            to the @font-face rule, but we didn't define what it
            actually does other than to say it takes a percentage
            that's resolved against the advance itself
  fantasai: A couple of points that would need to be resolved: 1. How
            are we increasing or decreasing the advance width? The
            size of the glyph in both axes together? Just x axis?
            Space around each glyph? left side? right side, start end,
            end end?
  fantasai: There's been some discussion in the issue about what it
            should apply to and how it should apply, but no
            conclusions.
  fantasai: I think the first thing we'd have to decide is how we
            increase the size of the glyphs
  fantasai: to do text layout
  myles: Shouldn't distort the outlines

  chris: We're changing the advance, not the bounding box of the
         glyph. Not changing the outline
  chris: just changing the amount you need to move forward
  chris: Very clearly not changing any glyph geometry
  chris: There is a proposal to have a scale factor, but that's
         separate
  myles: I think that the exact way that space is added, I think
         that's not a super important decision, so doing whatever
         makes sense is easiest. For us that would be applying to the
         right side always
  Rossen: Is that affected by directionality?
  myles: No, always on the right side
  chris: Why?
  myles: It's just easier to implement. Base-level API renders text LTR
  chris: So you're saying you do bidi reordering in the backing store
         and then apply space after that?
  Rossen: So proposal is to keep it uniform on one side

  jfkthame: I would not like to specify that space is only applied on
            one side
  jfkthame: if that's easiest to apply, maybe allow it
  jfkthame: but I don't think that's the best behavior
  jfkthame: Browser should be able to apply equally across both sides
            of glyph
  jfkthame: which is superior

  <chris> I'm a bit concerned about margins not lining up, with space
          at the margins
  chris: Could add space not at margins
  myles: Bleeds into my point. Naive implementation is to just
         multiply the number in the font file
  myles: but that applies before shaping
  myles: When you apply shaping, have to match what's in the font file.
  myles: Correct implementation of this needs to apply this after
         shaping
  myles: which is a more complicated implementation
  myles: Doing something like what chris said is not hard, because
         you're already at the level of knowing that information

  Rossen: So sounds like we're aligning on adding space on both sides?
  Rossen: Any other opinions? or resolve?
  myles: If you do it on both sides, then alignment won't look good on
         either side
  jfkthame: We're putting the space equally makes for a less-bad
            result than you will get than if it's all on one side
  jfkthame: In practice, I don't think this is a feature that should
            be used for a large adjustment
  jfkthame: It's for fine-tuning the metrics of a fallback font to
            match another font
  jfkthame: so the adjustment is going to be a small fraction of a
            glyph width. Not too bad.
  <chris> we should put that wording from jfkthame into the spec -
          fine adjustments, not major ones. fine tuning
  myles: I suggest leaving it undefined
  myles: Major point is that it makes text more/less compact
  myles: Might be worth getting impl experience
  jfkthame: Wrt trimming space at line boundaries, I'd be opposed.
  jfkthame: This is effectively about modifying the metrics of the font
  jfkthame: if you modify metrics of a glyph, should be everywhere
            that glyph occurs, not different based on position in the
            line
  <astearns> AFAIK this feature is NOT about making things look good,
             it’s merely about reducing layout shift once a font loads

  fantasai: Slight tangent, but
  fantasai: This feature has a lot of badness to it
  fantasai: First, as we've been discussing, it distorts alignment
  fantasai: Second, it breaks complex and cursive writing systems
  fantasai: Third, because it introduces uneven amounts of spacing
            between pairs of characters, it distorts the rhythm of the
            text and hence impacts readability in a negative way
  fantasai: None of these problems apply if the font is scaled in both
            axes instead of adding space between characters
  fantasai: And I think it would be harmful if we ship this feature
            without also shipping a scaling-factor descriptor that
            could be used in any cases where that would be usable in
            place of advance-override
  jfkthame: Strongly agree with that.

  TabAtkins: Keep in mind, the goal is not to define a new typographic
             feature for text. It's to replace existing hacks that
             people use to reduce layout shift when fonts load
  TabAtkins: if we can reduce layout shift, even if it looks bad,
             still successful
  TabAtkins: Want it to look good and make it work across writing
             systems
  TabAtkins: but if not ideal, that's fine, because that's not the
             point
  TabAtkins: Should be for fonts that not there for very long, will be
             replaced by the real font later
  TabAtkins: Want a solution that works across scripts and works OK,
             better than current hacks

  xiaochengh: Regarding scaling / font-size override
  xiaochengh: we have prototyped in Chrome, and found it tricky to
              nicely specify
  xiaochengh: This might affect ascent-override etc.
  xiaochengh: they have a %, which font-size do these resolve against?
              resolve against the font-size property value of the
              element or used font size?
  xiaochengh: Either way going to surprise some users
  xiaochengh: since our main focus is to reduce layout shift, wouldn't
              want to introduce a blocking issue on top of advance
              override

  fantasai: To reply to TabAtkins, I understand this is for reducing
            layout shift
  fantasai: But there's different way to do that, and I think in many
            cases scaling outlines without affecting resolution of
            length units would also have that affect
  fantasai: wrt using it as a fallback, what happens if the other font
            doesn't load
  fantasai: This isn't "only applies in a fallback font"
  fantasai: People on slow connections, etc are stuck with a font
            that's not just non-ideal but also has weird spacing
  fantasai: And this doesn't work for complex or cursive script as
            specified today.
  fantasai: You can handle those scripts if you scale, not if you
            intro space.
  TabAtkins: If your fallback font plus scaling advance looks
             terrible, you chose a bad fallback font
  TabAtkins: We don't need to protect author from that. They should
             tweak it to be closer.
  TabAtkins: If it is, it's a bad page.

  <jfkthame> instead of `font-size-override`, suggest something like
             `glyph-scale-factor`, then it's clearer that it doesn't
             affect anything else

  myles: What is the exit for this discussion? We've talked about
         several issues here.
  TabAtkins: Trying to figure out how to fix this for awhile
  TabAtkins: keep getting objections that it's not ideal
  TabAtkins: but nobody is helping making a better solution
  TabAtkins: We did exploration with scaling, it doesn't look good
  TabAtkins: maybe we need to scale on some scripts
  TabAtkins: but essentially just letter-spacing works well
  fantasai: letter-spacing applies evenly
  fantasai: and if it's supposed to apply for temporary font, should
            shut off if you're not loading another font and sticking
            with this one
  TabAtkins: But then you have a layout shift
  fantasai: If downloading is turned off, then no layout shift
  myles: Rogue character with accent in the middle of a paragraph
         causes ...
  <TabAtkins> summary of myles: also useful if you have a fallback
              used for certain characters, which has an oddly
              different character size - this lets you adjust the
              fallback characters to feel better

  Rossen: Proposed path forward... not hearing a clear consensus
          around a) where the adjustment should take place or b)
          should we even have that
  Rossen: I think we resolve in backwards order
  Rossen: First question, should we still pursue this?
  <chris> OK so close this discussion with "needs proposal"?
  fantasai: I can live with having this plus a scaling factor, but not
            having just this one, because if only have a broken option
            that's not good enough
  myles: I think we should have both, changing scaling factor makes a
         lot of sense
  TabAtkins: Not hearing any objections to what we're doing here,
             other than fantasai's point.
  Rossen: So no objection to continuing on this
  Rossen: So specific proposal here, fantasai mentioned adding scaling
          factor and then we have to decide where space is added
  Rossen: My proposal is to take back to the issue and iron it out
          there
  fantasai: Suggest to take a resolution on a) adding a scale-factor
            descriptor that only affects the glyph outline b) add
            space on both sides, maybe *allow* (MAY) UAs to do one
            side only if it's an implementation problem c) apply it to
            all glyphs in all writing systems, d) warn about how that
            can break things in certain writing systems / if too much
            space is added

CSS Color
=========

Consider clarifying Highlight system color, and maybe adding a new
    system color for control background
------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6008

  chris: emilio raised it
  chris: I'm reluctant to add a new system color

Commas in color-mix()
---------------------
  github: https://github.com/w3c/csswg-drafts/issues/6066

  leaverou: Since we have rule that ? repetition should use commas but
            not other things
  leaverou: we removed commas from color-mix because not a list
  leaverou: but it doesn't read very nicely, and not clear which color
            the percentage belongs to
  leaverou: so thinking to add the commas back
  leaverou: Since we can't keep going back and forth about it, UAs are
            implementing
  leaverou: Wanted to resolve this once and for all
  leaverou: I also agree it's more readable with commas
  leaverou: I think it should have a comma to separate metadata from
            list of colors
  leaverou: Clarify whether about the first color or the function as a
            whole
  leaverou: Seem to have consensus on adding them back
  leaverou: Also, do we still have 'in' for color space?
  leaverou: Seems like only have color space in the beginning

  TabAtkins: Agree with leaverou
  TabAtkins: We're not attached to using commas everywhere like JS is
  TabAtkins: only use it in some places
  TabAtkins: It works reasonably here
  TabAtkins: and helps with readability
  TabAtkins: and we should also have the metadata in a single thought
             at the beginning, separated by comma
  TabAtkins: Consistent with gradients and shapes
  TabAtkins: so +1 to what leaverou suggested

  una: I agree that commas are needed here
  una: much like gradients
  <miriam> +1 need commas
  una: I also want to add, I don't think we need 'in' keyword if we
       have this syntax
  una: I think we are reaching consensus in the issue, and +1 to
       proposal
  <aja> fwiw, emilio landed on nightly, used commas, & % applied to
        2nd color, "in srgb" at start or end. willing to change
  leaverou: I would argue for 'in' keyword
  leaverou: It reads better, and also lets us expand the syntax later
            to add more options
  leaverou: So, makes it more readable and makes syntax less
            ambiguous, so argue to keep it
  Rossen: Seems like we have consensus around adding commas, any
          objections?

  RESOLVED: Add back commas

  Rossen: Next one is do we want to have the 'in' keyword
  una: I would like to object to it
  una: Reasoning, I don't think it's necessary and we don't have a
       construct of 'in' elsewhere in CSS, so introduces new concept
       not seen anywhere else and I don't think it adds clarity
  una: Don't want to add new syntax to CSS
  <TabAtkins> Also object, we don't use these sorts of intro keywords
              except absolutely necessary for disambiguation.
  <astearns> we have 'at' elsewhere
  <TabAtkins> Colorspace keywords are plenty clear and won't block our
              extensibility in the future.
  <TabAtkins> astearns, yeah, that's for disambiguation
  <TabAtkins> because there are two positions

  Rossen: OK, I suggest we open a separate issue for this
  leaverou: Using prepositions for metadata in functions is common in
            gradients as well, which is where I got the inspiration.
            But agree with separate issue.
  TabAtkins: I'm happy to argue that gradients are special
  <TabAtkins> gradients use "to" because it disambiguates whether the
              gradient comes *from* that direction or goes *to* that
              direction (and we flipped back and forth during dev, so
              there's no obvious answer).
  <TabAtkins> gradients use "at" to separate the <position> from the
              possibly-preceding <length>{1,2}

More clarity around the percentage in color-mix()
-------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6064

  miriam: In the middle space, single percentage value, and spec was
          conflicted on what that refers to
  miriam: is it percentage color, or distance to second color
  miriam: or percentage of second color
  miriam: Spec disagreed with itself
  <leaverou> note: the spec has since been fixed and does not disagree
             with itself anymore :)
  miriam: With commas, would be nice to do percentage in either color
  miriam: so if you put in first color refers to weight of that color,
          second is weight of second color
  miriam: Would have to decide what to do if 2 percentages are
          specified
  miriam: SASS functions confusing as well, never clear to me which
          the percent refers to

  chris: My understanding was % is % of that color, and all examples
         (there were more examples before)
  chris: there was just one sentence that was off, and Adam fixed it
  chris: Seems clear it's a % of that color, not along a blend between
         the two colors
  chris: the color that it's next to
  leaverou: mixing paints, makes sense % of first color
  chris: ... that's confusing
  chris: if % don't add up, scale to add to 100%
  chris: Does that make sense?
  miriam: So % goes with a color between the commas, that makes sense
          to me
  miriam: So % can be applied to either color, and can put it in one
          or both
  leaverou: Should allow for ...
  leaverou: and scale accordingly
  chris: Have that in HWB, if too high scale it back

  TabAtkins: I think whichever syntax we go with, should be consistent
             between color-mix() and cross-fade()
  <fantasai> +1
  TabAtkins: cross-fade() matches up with what miriam suggests
  TabAtkins: Can add % with any of the images
  TabAtkins: whichever one, if omitted, it's just 100% - [sum]
  TabAtkins: If don't add up to 100%, we fill in the remainder with a
             transparent image
  TabAtkins: idk if we want to do with colors
  leaverou: 3-way mixes are confusing, too many ways to do it
  TabAtkins: I agree with reasoning for not doing 3-color mixes, but
             adding in transparency doesn't suffer from same confusion
             issues
  TabAtkins: not strong on either, but greater consistency with
             cross-fade() would be good
  <chris> prefer a rebalance like HWB
  <TabAtkins> chris, note that HWB does *not* rebalance for <100% sum
  <TabAtkins> there it takes the remainder from the pure hue
  <TabAtkins> >100% causing rescaling is uncontroversial and common
              between all the functions, yes

  Rossen: Can someone summarize the proposed resolution?
  leaverou: Before we summarize, one last point
  <TabAtkins> Proposed new grammar: color-mix(<metadata>,
              <color-option>#{2}), where <color-option> = <color> &&
              <percentage>?
  leaverou: If we handle percentages < 100% by mixing with
            transparent, it has special interpolation handling so we
            don't want to do that
  TabAtkins: Ignoring the < 100% sum and take it to the issue, think
             we can resolve on the rest
  <argyle> `color-mix(in lch red 80%, blue)` also `color-mix(in lch,
           red, blue 80%)`
  <argyle> `color-mix(in lch, red 80%, blue)` also `color-mix(in lch,
           red, blue 80%)`
  TabAtkins: Proposal above
  TabAtkins: If above 100%, rescale to add to 100%
  <TabAtkins> if below 100%, figure out in issue
  Rossen: Any objections?

  RESOLVED: color-mix(<metadata>, <color-option>#{2}), where
            <color-option> = <color> && <percentage>?

How should negative percentages behave in color-mix()?
------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/6047

  chris: Sam Weinig who is implementing pointed out that can't do
         negative percentages
  chris: una said why don't we clip it 0-100%
  chris: nobody wants this
  chris: I can define it
  fantasai: Can you make it invalid?
  TabAtkins: Invalid matches behavior in other mixing functions
  TabAtkins: We intend for it to be meaningless, so should be invalid

  RESOLVED: negative percentages are invalid in color-mix()
Received on Thursday, 4 March 2021 23:42:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 4 March 2021 23:42:56 UTC