- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 8 Aug 2024 19:07:20 -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 Inline
----------
- RESOLVED: Name of properties are text-box-edge and text-box-trim
(Issue #10675: Naming text-box-trim et al.)
- RESOLVED: Use trim-start and trim-end instead of start and end
(Issue #10675)
- RESOLVED: The value "trim-both" for property "text-box-trim" (Issue
#10675)
- RESOLVED: "text-box" shorthand with value "normal" set the
longhands default (Issue #10675)
- RESOLVED: Republish as WD
CSS Text
--------
- RESOLVED: "normal" value for "line-break" must not break between
regular kana and small kana (Issue #10363: Japanese small
kana and `line-break: normal`)
CSS Overflow
------------
- RESOLVED: Allow (but don't require) repositioning or fading (Issue
#10418: Position of the text-overflow ellipsis)
CSS Color
---------
- RESOLVED: color-layers([<blend-mode>, ]? <color>#) (Issue #8431:
Add color functions for some (or all) compositing/
blending operations)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Aug/0005.html
Present:
Rossen Atanassov
Tab Atkins-Bittner
Kevin Babbitt
Matthieu Dubet
Elika Etemad
Mason Freed
Chris Harrelson
Chris Lilley
Alison Maher
Tim Nguyen
Florian Rivoal
Alan Stearns
Miriam Suzanne
Regrets:
Robert Flack
Daniel Holbert
Jonathan Kew
Noam Rosenthal
Khushal Sagar
Sebastian Zartner
Chair: Rossen
Scribe: matthieud
Rossen: publication- anything that are almost ready: Chris, Tab?
Rossen: anything need to be published?
ChrisL: Already done an async discussion, don't need to talk now
CSS Inline
==========
Naming text-box-trim et al.
---------------------------
github: https://github.com/w3c/csswg-drafts/issues/10675
fantasai: We took resolution to split text-box-edge
fantasai: one for line box sizing, one for trimming block container
fantasai: We need to discuss some details about the syntax, the names
of the properties, names of the values
fantasai: There is a new property line-fit-edge which inherits
fantasai: and also text-box-edge not inherited initial value auto
which compute to the value of the line-fit-edge
fantasai: and shorthands for them together
fantasai: with a "normal" keyword for the shorthand which compute to
"none" and "auto"
<astearns> seems OK to me, no better idea for line-fit-edge
florian: Which part is resolved and which part is your invention?
fantasai: No resolved name for line-fit-edge, no resolved on the new
keyword, no discussion for the shorthand text-box syntax
<chrishtr> Koji from my team reviewed and thought it was fine, so
good from Chrome's POV
<ntim> lgtm for the whole proposal
chrishtr: names of properties are fine
chrishtr: line-fit-edge details might need more discussion about
behavior
Rossen: We can resolve on the names?
RESOLVED: name of properties are text-box-edge and text-box-trim
fantasai: The shorthand is text-box but for the values there is a new
normal keyword but the rest is weird like text-box-start
... etc
fantasai: maybe we should rename some values to add trim-start
trim-end trim-both
fantasai: would be consistent with text-spacing
fantasai: or maybe trim instead of trim-both
florian: Seems a bit hard to understand how they relate, so in favor
of those changes
<fantasai> text-box: normal | <'text-box-trim'> || <'text-box-edge'>
<fantasai> but text-box: start (e.g.) is pretty weird, so suggest
text-box: trim-start
<fantasai> Precedent: text-spacing: space-all | normal | space-first
| trim-start | trim-both | trim-all
<ntim> trim is ambiguous whether it's trim-both or trim-all
Rossen: What is the difference between trim-both and trim-all
fantasai: trim-all trim all characters, trim-both only trim only the
start edge and end edge
florian: the important is that stuff that trim is prefixed by trim-*
florian: in the text-box case the difference between both and all
doesn't exist so they have the same behavior
florian: so "trim" makes sense in the text-box case
fantasai: trim and trim-both both make sense, do we want to make the
keyword shorter or compatible with text-spacing
<TabAtkins> I think the `trim-*` names sound reasonable, personally
<fantasai> sure, but between `trim` and `trim-both`?
<TabAtkins> Ah, trim-both, if it's less than trim-all
<fantasai> OK. But for text-box there's no trim-all in this case,
just in text-spacing
<TabAtkins> Sure, but consistency is good across the props
RESOLVED: Use trim-start and trim-end instead of start and end
<fantasai> POLL: text-box: trim; or text-box: trim-both;
<fantasai> (clear property is clear: none | left | right | both)
<ntim> B
<astearns> b
<kbabbitt> B
<florian> 0 (ok either way)
<TabAtkins> b
<schenney> B
<Rossen> B
<ChrisL> abstain
<fantasai> kojiishii: A
<ntim> We should resolve on the fact the `text-box` exists as a
shorthand fwiw
RESOLVED: The value "trim-both" for property "text-box-trim"
fantasai: The initial value of text-box-edge is auto, but
text-box-trim is none. That leaves 'text-box: none' or
'text-box: auto' for setting the initial value, and both of
these read very weirdly, so I added a normal keyword to the
shorthand
<florian> +1 to the name and to the normal keyword
<astearns> +1 to what florian +1ed
PROPOSED RESOLUTION: "text-box" shorthand with value "normal" set the
longhands default
<ntim> +1
RESOLVED: "text-box" shorthand with value "normal" set the longhands
default
Publication
-----------
<fantasai> https://drafts.csswg.org/css-inline-3/#changes
fantasai: I will republish the working draft
RESOLVED: Republish as WD
<florian> yay! That's one I had been eagerly waiting for
<florian> thank you Elika for pushing it forward
CSS Text
========
Japanese small kana and `line-break: normal`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10363
fantasai: Normal value for line-break currently specify that you can
break between regular kana and small kana
fantasai: It's unusual to break there in japanese
fantasai: Proposal would be to not break before the small kana (you
can break with line-break: loose)
florian: The i18n group supports this
<ChrisL> +1 to not breaking
PROPOSED RESOLUTION: "normal" value for "line-break" should not break
between regular kana and small kana
RESOLVED: "normal" value for "line-break" must not break between
regular kana and small kana
CSS Overflow
============
Position of the text-overflow ellipsis
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10418
florian: There are differences between browsers for text-overflow
ellipsis
florian: Spec says that you should remove enough text to place the
ellipsis and that position is immediately next to the
remaining text
florian: Firefox is inconsistent, sometimes it does something
different but useful
florian: It places the ellipsis at the very end of the line box
florian: It's nice because if you scroll, you reveal some of the
elided away text
florian: It avoid the ellipsis to jump back and forth during scrolling
<ChrisL> That does seem to be a better behavior, avoiding jitter
florian: but the spec says something else
florian: Another behavior would be while you scroll you hide the
ellipsis, compute and re-show the ellipsis to avoid jitter
florian: if we want ellipsis to be always visible, firefox behavior
is nice
ChrisL: The jitter in current implementation is not good
florian: In theory the spec says that all implementation should
reveal text when you scroll, but only Firefox does it
florian: but other browser don't so no jitter because they don't
reveal text
<ChrisL> but they would
iank: jitter doesn't happen currently
miriam: I like the behavior to allow scrolling
miriam: but what is the point of repositioning the ellipsis at the
end?
miriam: So it looks like current spec is good
florian: If you scroll using the scrollbar or touchpad, the ellipsis
disappear
florian: however by selecting the text not visible or scroll by
script, the ellipsis remain visible
florian: maybe it should disappear all the time (but how does it
would work with script?)
florian: For iank's point, should we disallow reveal as you scroll ?
florian: Current discussion might be moot for Chrome
iank: I agree with miriam that if you are going to hide ellipsis
while scrolling, the jittering point disappear as well
florian: 2 options here : either allow the repositioning of the
ellipsis like firefox is doing, or keep the spec as is which
requires the ellipsis right next to the text and we should
probably in/out to avoid jitter
<fantasai> Options: A) Allow repositioning. B) Allow fading. C) Allow
repositioning or fading.
<fantasai> D) Allow neither
fantasai: Choices would be repositioning or fading or both or neither
RESOLVED: Allow (but don't require) repositioning or fading
CSS Color
=========
Add color functions for some (or all) compositing/blending operations
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8431
ChrisL: You want to composite color1 on color2
ntim: Currently web devs need background gradient to composite one
color on top of the other.
<TabAtkins> +1 to the functionality too, seems easy and moderately
useful
ChrisL: Proposition is using color-layer
<fantasai> color-layer([<blend-mode>, ]? <color>#)
<astearns> slight preference for color-over, as I associate *-layer
with stacks of things
ntim: Either color-over() or color-layer() and inside the function
you have a comma separated list of colors and optional
blend-mode
<miriam> layer-colors() reads better to me
ChrisL: Optional blend-mode preference, if not specified you get the
default
fantasai: We agree on the arguments of the function [<blend-mode>, ]?
<color>#
miriam: color-layer reads weird because it's not a single layer
miriam: Proposal for layer-colors() or color-over()
<fantasai> color-layers?
ChrisL: all color functions start with color-*
ntim: consistency with color-mix()
<ChrisL> ntim++
<miriam> color-stack(), color-over()…
ChrisL: color-stack() sounds like stacking context, weird
<fantasai> POLL: A) color-over B) color-layer C) color-stack
<fantasai> D) color-layers
<nicole> D
<fantasai> not A
<astearns> A
<matthieud> D
<ntim> A or B (no strong opinion)
<Rossen> D B
<schenney> B
<ChrisL> D
<TabAtkins> d
<miriam> A C or D
<kbabbitt> A > D > B> C
<schenney> Change: D
<ethanjv> D > A
Rossen: Based on first choice color-layers() win
RESOLVED: color-layers([<blend-mode>, ]? <color>#)
Received on Thursday, 8 August 2024 23:07:52 UTC