- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 4 Mar 2021 18:42:15 -0500
- 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