– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<astearns> github-bot, take up w3c/csswg-drafts#10675

[css-inline-3] Naming text-box-trim et al.

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10675.

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/csswg-drafts#10675

[css-inline-3] Naming text-box-trim et al.

<github-bot> OK, I'll post this discussion to 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 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://drafts.csswg.org/css-inline-3/#changes

fantasai: I will republish the working draft

RESOLUTION: Republish as WD

TabAtkins: don't have anything ready for republication

github-bot: take up w3c/csswg-drafts#10363

[css-text-3][css-text-4] Japanese small kana and `line-break: normal`

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10363.

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/csswg-drafts#10418

Position of the text-overflow ellipsis

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10418.

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/csswg-drafts#8431

<github-bot> matthieud, ignoring request to take up w3c/csswg-drafts#8431 which is already the current github URL

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()"

end