- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Jan 2024 18:47:41 -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.
=========================================
Text-Focused Extra Meeting
==========================
CSS Text
--------
- RESOLVED: Define that hanging punctuation is set to none for pre
elements in the user agent style sheet (Issue #9689:
Prevent `pre` from inheriting hanging-punctuation by
default with a user-agent style rule)
- RESOLVED: Forced break resets the balancing algorithm for
text-wrap:balance (Issue #9112: Should `text-wrap:
balance` apply separate logic before and after forced
breaks?)
- Folks requested more time to think about issue #9310 (Interaction
of `text-wrap: balance` and `(-webkit-)line-clamp`), especially
for creating stability when there's a display more text option
after a one line block
- RESOLVED: The definition of space-first uses allow-end on the end
side (Issue #9736: Line-end behavior of
text-spacing-trim: space-first)
- RESOLVED: Use HALT when available and need a half-width glyph
(Issue #8293: `text-spacing` and OpenType halt/vhal/chws/
vchw features)
CSS Fonts
---------
- RESOLVED: Add font-width property and descriptor and make
font-stretch a legacy alias (Issue #551: font-stretch is
unfortunately named)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jan/0004.html
Present:
David Baron
Andreu Botella
Yehonatan Daniv
Elika Etemad
Brian Kardell
Jonathan Kew
Ian Kilpatrick
Eric Meyer
Florian Rivoal
Vitor Roriz
Jen Simmons
Alan Stearns
Miriam Suzanne
Sebastian Zartner
Chair: astearns
Scribe: frances
Text-Focused Extra Meeting
++++++++++++++++++++++++++
CSS Text
========
Prevent `pre` from inheriting hanging-punctuation by default with a
user-agent style rule
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9689
astearns: Comment about prevent inheriting by default for hanging
punctuation in code
<fantasai> +1
<jfkthame> +1
Florian: No strong opinion, raised by Amelia, she recommends none in
user style sheet or have no effect in a preserved space
context, not sure to have having punctuation by default,
might be nonsensical
fantasai, Amelia, and astearns: agreed
astearns: Is there anything else that doesn't make sense in a
preformatting context?
emeyer: Thinking table cells, less clear than the precase, would it
hang over the edge in the table cell
astearns: Depends on margins and padding, not as clear cut
PROPOSAL: Define that hanging punctuation is set to none for pre
elements in the user agent style sheet
astearns: Any objections?
fantasai: Spec it first, make an HTML pr, has a default set of styles
<fantasai> https://www.w3.org/TR/css-text-3/#default-stylesheet
astearns: Might be easier for html people to take things one by one
RESOLVED: Define that hanging punctuation is set to none for pre
elements in the user agent style sheet
Should `text-wrap: balance` apply separate logic before and after
forced breaks?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9112
<fantasai> proposal:
https://github.com/w3c/csswg-drafts/issues/9112#issuecomment-1649890262
astearns: Next issue is on text-wrap: balance, what happens before
and after they break?
fantasai: Johnathan proposed, applies to before and after the lines
the lines independently
astearns: Discussed it before, should the balancing algorithm stop or
continue? Does it continue and try to balance before or
after the break? One or more balancing sections?
Florian: Proposal is good, separate sets for performance is be good,
and no downside identified
astearns: Any other opinions?
emeyer: Can think of possibility where to balance and center and
force break at a certain point, maybe one word that is
centered in the middle of it all. Feel like as an author,
wrapping spans anyway
astearns: Because of the way we are measuring better balance, we are
already accounting for different line lengths for
fragmentation and line breaks, hard pressed to find result
that is substantially different. Balance better to improve
according to the spec.
dbaron: The other thing is that if we want to group across breaks, it
would be good for blocking across elements, if there were
such a thing, it make sense to be a separate mechanism for
both
Miriam: Might be misunderstanding this as being fragmentation breaks
possibly
fantasai: Still line breaking across the fragmentation breaks, if not
after the fragmentation and two long lines from wrapping,
need to balance across both
Miriam: More about hard breaks
dbaron: Where you break the lines can influence where you fragment
astearns: I was correct. Should be only forced breaks
astearns: Any other comments?
PROPOSAL: Forced break resets the balancing algorithm for
text-wrap:balance
RESOLVED: Forced break resets the balancing algorithm for
text-wrap:balance
Interaction of `text-wrap: balance` and `(-webkit-)line-clamp`
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9310
astearns: What do we do with line-clamp in next issue?
jfkthame: If line-clamp is in effect with only some blocks being
displayed, should balance apply to the entire block and
entire block being displayed? Approaches can give two
different results
jfkthame: Not clear of the difference
Florian: Complicated, line-clamp adds ellipses at the end of the line
when being displayed, add before or after balancing?
Generalization about whether same answer applies to
text-wrap: pretty or not? Take into account all of the
lines? One that uses fragmentation and one that doesn't.
Florian: Doing clamping first then adding the ellipsis then balancing
probably makes the most sense, might not stay true with
other variants
<fantasai> ->
https://github.com/w3c/csswg-drafts/issues/9310#issuecomment-1708989604
fantasai: Ian posted the issue that applied line clamp after breaking
the line, developers weren't happy and changed the
balancing, no negative feedback since
andreubotella: One issue would be for animating height to continue
the clamp, not something that is being currently done,
this is a use case that is not currently possible, I
don't see it being very widely used, but it might see
some usage. Might not become easily possible. Does
that change things? Do we want that to continuously
change the line breaks when the number of lines
changes?
Florian: In case of balance not in case of pretty, two face
definition of how balance, would be strange to balance,
maybe ...ellipsis is not bad, might have arbitrary strings,
if balancing not taking it into account, need to know where
to insert
iank: Should be balancing less visible, if balancing the entire
paragraph, lines might be less visible, less sure about
balancing with ellipsis or not. Sometimes goes in with the
content, sometimes a hanging thing where not considered part of
the block
astearns: Any more opinions?
jfkthame: Still conflicted, what Ian is proposing in issue. Looks
well for the static case, if we find height of the element
and vary line clamp as line height varies, line height
might be disconcerting
astearns: Would we consider having different behavior on the static
versus dynamic case?
jfkthame: Don't want to implement two ways of doing it
astearns: See point of shifting the different line breaks, not sure
what to do with discrepancy
Florian: Syntax wise we could choose between the two behavior through
"balance stable" as we already have that second keyword, but
that's only if we're actually interested in having both,
which we might not be
jfkthame: I'd like to consider it a bit further particularly with the
use case in mind of a block with one line and option to
display more with the text staying stable
astearns: Once in view, the line breaks should not change, expanding
might shift the lines.
astearns: Not resolved today. Will be on a later agenda to discuss
more.
CSS Fonts
=========
font-stretch is unfortunately named
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/551
astearns: Next issue is on the agenda is the name of font-stretch
jfkthame: font-stretch should be font-width, would be a better name.
Has been this way for a long time, possibly alias the
property and use something they understand better.
astearns: You mention font-synthesis-width?
jfkthame: Would be different to synthesize, might need to control the
behavior. Something suggested to change, but need to alias
because would not be backwards compatible
Florian: There are different ways to do aliasing, and the relevant
one here is "legacy name aliasing", as defined in
css-cascade.
<fantasai> https://www.w3.org/TR/css-cascade/#aliasing
jensimmons: I also support this, not something we typically do, can't
keep making different changes. Words are meaningful and
in adjoining industries, it should just be font-width
astearns: Add font-width, and make font-stretch a legacy alias for
the font description. Issue of expecting what font-stretch
should do for another issue
fantasai: Pretty close to what you are supposed to do for properties
per spec.
PROPOSAL: Add font-width property and descriptor and make
font-stretch a legacy alias of those
astearns: Any objections?
RESOLVED: Add font-width property and descriptor and make
font-stretch a legacy alias
CSS Text (con't)
================
Line-end behavior of text-spacing-trim: space-first
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9736
astearns: Then we have text-spacing-trim
Florian: Implied in this included in the resolution, what should be
the line ending behavior of text-space first? Choice between
force trimming and allow trimming
Florian: If we always allow trimming at the end, could be a little
strange about left edge and slightly moved right edge. If
inline block and force trim the end, with a single line
space first, trim and then inline might look weird, possibly
floats
Florian: Special case for inline and special case for floats. Could
be improved by force-trimming on the end, will be a
compromise. We had resolve to change, need to be deliberate.
fantasai: Awkward lack of symmetry trimming with forced trimming on
any text that's a single line, e.g. abspos, floats, etc. If
space first, allow trimming on the other side.
astearns: Happy to defer, is this something that we can define and
change in the future?
fantasai: Possibly shouldn't define it, already making some choice to
the initial value, some tweaking that can be done, decide
today what can be done.
Florian: If exceptional handling for floats and inline blocks, might
be cases where it is better for force-end, this is safer.
astearns: The definition of space-first is to allow the style on the
end side.
florian: An alternative would be to trim on the end side,.
<fantasai> https://drafts.csswg.org/css-text-4/#text-spacing-trim-property
astearns: Have not read everything in the issue, should we do
anything for the last line?
<astearns> Proposed: The definition of space-first uses allow-end on
the end side.
astearns: Did not raise it in GitHub, should we have a separate issue?
Florian: Could have issues in compat, should we only do it for last
line or all of the lines?
astearns: Any objections?
RESOLVED: The definition of space-first uses allow-end on the end side
`text-spacing` and OpenType halt/vhal/chws/vchw features
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8293
fantasai: HALT provides the same glyph with half-width metrics; HWID
provides half-width versions of the glyph, potentially
substituting the glyph shape as well; CHWS does half-width,
but contextually, tries to provide the text-spacing-trim
smarts itself, but that only works if their logic matches
ours (which it won't in many cases)
jfkthame: Not an expert, not sure.
fantasai: text-spaced-trim specify to trim the blank space, and trim
properly without changing the shape of the glyph. HWID
could substitute the glyph.
fantasai: If HALT is missing, we could "synthesize" by, check the
HWID feature and check the glyph substitution for the same
shape and size, assume that HWID did not replace the glyph
and apply if it behaves the same, but we don't want to use
HWID if it is substituting the glyph, better to synthesize
the HALT metrics
astearns: Resolve today or discuss more?
Florian: There is a disagreement on using HALT, what can you do when
you can't use it?
fantasai: Use when it is available
PROPOSAL: Use HALT whenever you need a half-width glyph and HALT is
available
fantasai: Designed to use both, there are closing parentheses, need
to change the spacing around it, why we don't want to use
HWID. Might be a reasonable proxy. If using glyph
substitution, don't want to do it and better to substitute.
jfkthame: Can be used to substitute and replace. If it changes the
shape, and affects the half-width of the glyph.
Florian: Remove the white-space. If half remove half. If not half,
then remove. Get rid of the blank part if it does not fit.
Florian: Not sure on the rest
astearns: Can resolve on using HALT
PROPOSAL: Use HALT when available and need a half-width glyph
RESOLVED: Use HALT when available and need a half-width glyph
Received on Wednesday, 10 January 2024 23:48:17 UTC