Meeting minutes
<astearns> github-bot, take up w3c/
[css-inline-3] Naming text-box-trim et al.
<github-bot> OK, I'll post this discussion to https://
none
publication
Rossen: publication thing that are almost ready : Chris, Tab ?
Rossen: anything need to be published ?
ChrisL: already done an async discussion, dont need to talk now
github-bot: take up w3c/
[css-inline-3] Naming text-box-trim et al.
<github-bot> OK, I'll post this discussion to https://
fantasai: we took resolution to split text-box-edge
fantasai: one for line box sizing, one for triming 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 ?
no resolved name for line-fit-edge, no resolved on the new keyword, no discussion for the shorthand text-box syntax
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
Rossen4: we can resolve on the names ?
<ntim> I think these are already resolved on
RESOLUTION: 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
Rossen4: 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 doesnt 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, pesonally
<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
RESOLUTION: Use trim-start and trim-end instead of start and end
<fantasai> POLL: text-box: trim; or text-box: trim-both;
<ntim> B
<astearns> b
<kbabbitt> B
<florian> 0 (ok either way)
<TabAtkins> b
<schenney> B
<fantasai> (clear property is clear: none | left | right | both)
<Rossen4> B
<fantasai> 0
<miriam> 0
<ChrisL> abstain
0
<fantasai> kojiishii: A
<ntim> We should resolve on the fact the `text-box` exists as a shorthand fwiw
RESOLUTION: 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
RESOLUTION: "text-box" shorthand with value "normal" set the longhands default
<fantasai> https://
fantasai: I will republish the working draft
RESOLUTION: Republish as WD
TabAtkins: don't have anything ready for republication
github-bot: take up w3c/
[css-text-3][css-text-4] Japanese small kana and `line-break: normal`
<github-bot> OK, I'll post this discussion to https://
fantasai: small value for line-break currently specifiy that you can break between regular kana and normal kana
fantasai: it's unsual 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
RESOLUTION: "normal" value for "line-break" must not break between regular kana and small kana
github-bot: take up w3c/
Position of the text-overflow ellipsis
<github-bot> OK, I'll post this discussion to https://
florian: there are differencies between browsers for text-overflow ellipsis
florian: spec says that you should remove enough text to place the ellipsis and that position is immediatly 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 reveral 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
<Zakim> ChrisL, you wanted to say we should not insist on jitter
ChrisL: the jitter in current implementation is not good
florian: in theory the spec says that all implementaiton should reveal text when you scroll, but only firefox does it
florian: but other browser don't so no jitter because they dont reveal text
<ChrisL> but they would
iank_: jitter doesnt happen currently
miriam: i like the behavior to allow scrolling
miriam: but what is the point of repositionning 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 ian 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
<fantasai> Options: A) Allow repositioning. B) Allow fading. C) Allow repositioning or fading.
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> D) Allow neither
fantasai: choices would be repositioning or fading or both or neither
RESOLUTION: Allow (but don't require) repositioning or fading
[css-color-6] add color functions for some (or all) compositing/blending operations
github-bot: take up w3c/
<github-bot> matthieud, ignoring request to take up w3c/
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 read weirds 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-*
<ChrisL> ntim++
ntim: consistency with color-mix()
<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
D
<ntim> A or B (no strong opinion)
<Rossen4> D B
<schenney> B
<ChrisL> D
<TabAtkins> d
<miriam> A C or D
<kbabbitt> A > D > B> C
<schenney> Change: D
<ethanjv> D > A
<masonf> someone needs to write some code to see which option won.
<nicole> haha
Rossen4: based on first choice color-layers() win
<ChrisL> 0/
RESOLUTION: color-layers([<blend-mode>, ]? <color>#)
RESOLUTION: function name is "color-layers()"