23:02:07 <RRSAgent> RRSAgent has joined #css
23:02:11 <RRSAgent> logging to https://www.w3.org/2024/08/07-css-irc
23:02:11 <Zakim> RRSAgent, make logs Public
23:02:12 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
23:02:27 <astearns> astearns has changed the topic to: aug 7 agenda: https://lists.w3.org/Archives/Public/www-style/2024Aug/0005.html
23:02:44 <schenney> schenney has joined #css
23:03:37 <andreubotella> andreubotella has joined #css
23:03:39 <ChrisL> present+
23:04:58 <matthieud> matthieud has joined #css
23:05:28 <miriam> present+
23:07:13 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10675
23:07:13 <github-bot> Topic: [css-inline-3] Naming text-box-trim et al.
23:07:13 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10675.
23:07:48 <Rossen4> Rossen4 has joined #css
23:08:48 <astearns> topic: none
23:08:51 <matthieud> topic: publication
23:09:28 <matthieud> Rossen:  publication thing that are almost ready : Chris, Tab ?
23:09:38 <matthieud> Rossen: anything need to be published ?
23:09:46 <alisonmaher> alisonmaher has joined #css
23:09:51 <alisonmaher> present+
23:10:00 <matthieud> ChrisL:  already done an async discussion, dont need to talk now
23:10:07 <Rossen4> present+
23:10:30 <matthieud> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10675
23:10:30 <github-bot> Topic: [css-inline-3] Naming text-box-trim et al.
23:10:30 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10675.
23:10:56 <matthieud> fantasai:  we took resolution to split text-box-edge
23:11:09 <matthieud> fantasai:  one for line box sizing, one for triming block container
23:11:48 <matthieud> fantasai:  we need to discuss some details about the syntax, the names of the properties, names of the values
23:12:04 <matthieud> fantasai:  there is a new property line-fit-edge which inherits
23:12:30 <matthieud> fantasai:  and also text-box-edge not inherited initial value auto which compute to the value of the line-fit-edge
23:12:39 <matthieud> fantasai: and shorthands for them together
23:13:08 <matthieud> fantasai:  with a "normal" keyword for the shorthand which compute to "none" and "auto"
23:13:54 <astearns> seems OK to me, no better idea for line-fit-edge
23:13:56 <matthieud> florian: which part is resolved and which part is your invention ?
23:14:21 <matthieud> no resolved name for line-fit-edge, no resolved on the new keyword, no discussion for the shorthand text-box syntax
23:14:31 <matthieud> fantasai: no resolved name for line-fit-edge, no resolved on the new keyword, no discussion for the shorthand text-box syntax
23:14:57 <chrishtr> Koji from my team reviewed and thought it was fine, so good from Chrome's POV
23:15:13 <ntim> lgtm for the whole proposal
23:16:11 <matthieud> chrishtr: names of properties are fine
23:16:21 <matthieud> chrishtr: line-fit-edge details might need more discussion about behavior
23:16:51 <matthieud> Rossen4:  we can resolve on the names ?
23:17:14 <ntim> I think these are already resolved on
23:17:36 <matthieud> RESOLVED: name of properties are text-box-edge and text-box-trim
23:18:24 <matthieud> 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
23:18:37 <matthieud> fantasai: maybe we should rename some values to add trim-start trim-end trim-both
23:18:44 <matthieud> fantasai: would be consistent with text-spacing
23:18:54 <matthieud> fantasai: or maybe trim instead of trim-both
23:19:42 <matthieud> florian: seems a bit hard to understand how they relate, so in favor of those changes
23:19:45 <fantasai> text-box: normal | <'text-box-trim'> || <'text-box-edge'>
23:19:59 <fantasai> but text-box: start (e.g.) is pretty weird, so suggest text-box: trim-start
23:20:06 <fantasai> Precedent: text-spacing: space-all | normal | space-first | trim-start | trim-both | trim-all
23:21:13 <ntim> trim is ambiguous whether it's trim-both or trim-all
23:21:32 <matthieud> Rossen4: what is the difference between trim-both and trim-all
23:22:03 <chrishtr> present+
23:22:19 <matthieud> fantasai:  trim-all trim all characters, trim-both only trim only the start edge and end edge
23:22:47 <matthieud> florian: the important is that stuff that trim is prefixed by trim-*
23:22:52 <ethanjv> ethanjv has joined #css
23:23:45 <matthieud> florian: in the text-box case the difference between both and all doesnt exist so they have the same behavior
23:24:07 <matthieud> florian: so "trim" makes sense in the text-box case
23:24:47 <matthieud> fantasai: trim and trim-both makes sense, do we want to make the keyword shorter or not
23:24:56 <fantasai> s/makes sense/both make sense/
23:25:07 <fantasai> s/or not/or compatible with text-spacing/
23:25:10 <TabAtkins> I think the `trim-*` names sound reasonable, pesonally
23:25:24 <fantasai> sure, but between `trim` and `trim-both`?
23:25:33 <TabAtkins> Ah, trim-both, if it's less than trim-all
23:25:50 <fantasai> OK. But for text-box there's no trim-all in this case, just in text-spacing
23:26:03 <TabAtkins> Sure, but consistency is good across the props
23:26:44 <fantasai> RESOLVED: Use trim-start and trim-end instead of start and end
23:27:11 <fantasai> POLL: text-box: trim; or text-box: trim-both;
23:27:47 <ntim> B
23:27:48 <astearns> b
23:27:53 <kbabbitt> B
23:27:55 <florian> 0 (ok either way)
23:28:00 <TabAtkins> b
23:28:03 <schenney> B
23:28:04 <fantasai> (clear property is clear: none | left | right | both)
23:28:05 <Rossen4> B
23:28:08 <fantasai> 0
23:28:15 <miriam> 0
23:28:40 <ChrisL> abstain
23:28:40 <matthieud> 0
23:28:50 <fantasai> kojiishii: A
23:29:36 <ntim> We should resolve on the fact the `text-box` exists as a shorthand fwiw
23:29:47 <matthieud> RESOLVED: the value "trim-both" for property "text-box"
23:29:56 <fantasai> s/text-box/text-box-trim/
23:30:40 <matthieud> fantasai:  the initial value of text-box-edge is auto, but text-box-trim is none. What would be the one for text-box ?
23:30:43 <florian> +1 to the name and to the normal keyword
23:31:02 <astearns> +1 to what florian +1ed
23:31:11 <matthieud> PROPOSED RESOLUTION:  "text-box" shorthand with value "normal" set the longhands default
23:31:13 <ntim> +1
23:31:14 <fantasai> s/What would be the one for text-box ?/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/
23:31:34 <matthieud> RESOLVED: "text-box" shorthand with value "normal" set the longhands default
23:31:42 <fantasai> https://drafts.csswg.org/css-inline-3/#changes
23:31:48 <matthieud> fantasai:  I will republish the working draft
23:32:00 <fantasai> RESOLVED: Republish as WD
23:32:36 <matthieud> TabAtkins: don't have anything ready for republication
23:33:13 <matthieud> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10363
23:33:13 <github-bot> Topic: [css-text-3][css-text-4] Japanese small kana and `line-break: normal`
23:33:13 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10363.
23:33:51 <matthieud> fantasai:  normal value for line-break currently specifiy that you can break between regular kana and normal kana
23:34:18 <matthieud> s/normal/small
23:34:34 <matthieud> fantasai:  it's unsual to break there in japanese
23:34:57 <matthieud> fantasai: proposal would be to not break before the small kana (you can break with line-break: loose)
23:35:23 <matthieud> florian: the i18n group supports this
23:36:15 <ChrisL> +1 to not breaking
23:36:23 <matthieud> PROPOSED RESOLUTION: "normal" value for "line-break" should not break between regular kana and small kana
23:36:51 <matthieud> RESOLVED:  "normal" value for "line-break" must not break between regular kana and small kana
23:37:57 <matthieud> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10418
23:37:57 <github-bot> Topic: Position of the text-overflow ellipsis
23:37:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10418.
23:38:27 <matthieud> florian:  there are differencies between browsers for text-overflow ellipsis
23:38:56 <matthieud> florian:  spec says that you should remove enough text to place the ellipsis and that position is immediatly next to the remaining text
23:39:11 <matthieud> florian:  firefox is inconsistent, sometimes it does something different but useful
23:39:23 <matthieud> florian: it places the ellipsis at the very end of the line box
23:39:42 <matthieud> florian: it's nice because if you scroll, you reveral some of the elided away text
23:40:20 <matthieud> florian: it avoid the ellipsis to jump back and forth during scrolling
23:40:24 <ChrisL> That does seem to be a better behavior, avoiding jitter
23:40:33 <matthieud> florian: but the spec says something else
23:41:04 <matthieud> florian: another behavior would be while you scroll you hide the ellipsis, compute and re-show the ellipsis to avoid jitter
23:41:04 <ChrisL> q+ to say we should not insist on jitter
23:41:16 <matthieud> florian:  if we want ellipsis to be always visible, firefox behavior is nice
23:41:18 <iank_> q+
23:41:25 <Rossen4> ack ChrisL
23:41:25 <Zakim> ChrisL, you wanted to say we should not insist on jitter
23:41:29 <matthieud> ChrisL:  the jitter in current implementation is not good
23:41:41 <miriam> q+
23:41:57 <matthieud> florian:  in theory the spec says that all implementaiton should reveal text when you scroll, but only firefox does it
23:42:31 <matthieud> florian: but other browser don't so no jitter because they dont reveal text
23:42:32 <ChrisL> but they would
23:42:50 <Rossen4> ack iank_
23:42:55 <matthieud> iank_: jitter doesnt happen currently
23:43:22 <florian> q+
23:43:31 <matthieud> miriam:  i like the behavior to allow scrolling
23:43:42 <matthieud> miriam: but what is the point of repositionning the ellipsis at the end ?
23:44:01 <matthieud> miriam:  so it looks like current spec is good
23:44:10 <Rossen4> ack miriam
23:44:12 <Rossen4> ack florian
23:44:22 <matthieud> florian:  if you scroll using the scrollbar or touchpad, the ellipsis disappear
23:44:38 <matthieud> florian: however by selecting the text not visible or scroll by script, the ellipsis remain visible
23:44:54 <matthieud> florian: maybe it should disappear all the time (but how does it would work with script?)
23:45:51 <matthieud> florian: for ian point, should we disallow reveal as you scroll ?
23:46:28 <matthieud> florian: current discussion might be moot for Chrome
23:47:04 <matthieud> iank_:  I agree with miriam that if you are going to hide ellipsis while scrolling, the jittering point disappear as well
23:48:48 <fantasai> Options: A) Allow repositioning. B) Allow fading. C) Allow repositioning or fading.
23:49:02 <matthieud> 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
23:49:27 <fantasai> D) Allow neither
23:50:48 <matthieud> fantasai: choices would be repositioning or fading or both or neither
23:51:36 <fantasai> RESOLVED: Allow (but don't require) repositioning or fading
23:51:47 <github-bot> Topic: [css-color-6] add color functions for some (or all) compositing/blending operations
23:51:49 <ChrisL> q+
23:52:03 <matthieud> github-bot: take up https://github.com/w3c/csswg-drafts/issues/8431
23:52:03 <github-bot> matthieud, ignoring request to take up https://github.com/w3c/csswg-drafts/issues/8431 which is already the current github URL
23:52:21 <Rossen4> ack ChrisL
23:52:26 <nicole> nicole has joined #css
23:52:38 <matthieud> ChrisL:  you want to composite color1 on color2
23:53:48 <matthieud> ntim: currently web devs need background gradient to composite one color on top of the other.
23:53:57 <TabAtkins> +1 to the functionality too, seems easy and moderately useful
23:54:16 <matthieud> ChrisL: proposition is using color-layer
23:54:50 <fantasai> color-layer([<blend-mode>, ]? <color>#)
23:54:59 <astearns> slight preference for color-over, as I associate *-layer with stacks of things
23:55:01 <matthieud> ntim:  either color-over() or color-layer() and inside the function you have a comma separated list of colors and optional blend-mode
23:55:10 <miriam> layer-colors() reads better to me
23:55:38 <matthieud> ChrisL: optional blend-mode preference, if not specified you get the default
23:56:16 <matthieud> fantasai: we agree on the arguments of the function [<blend-mode>, ]? <color>#
23:56:24 <Rossen4> ack miriam
23:56:35 <ChrisL> q+
23:56:40 <ntim> q+
23:56:41 <matthieud> miriam: color-layer read weirds because it's not a single layer
23:56:55 <matthieud> miriam: proposal for layer-colors() or color-over()
23:57:02 <fantasai> color-layers?
23:57:14 <Rossen4> ack ChrisL
23:57:23 <Rossen4> ack ntim
23:57:29 <matthieud> ChrisL:  all color functions start with color-*
23:57:35 <ChrisL> ntim++
23:57:43 <matthieud> ntim:  consistency with color-mix()
23:57:45 <miriam> color-stack(), color-over()…
23:58:33 <matthieud> ChrisL: color-stack() sounds like stacking context, weird
23:58:43 <fantasai> POLL: A) color-over B) color-layer C) color-stack
23:58:48 <fantasai> D) color-layers
23:58:51 <nicole> D
23:59:05 <fantasai> not A
23:59:05 <astearns> A
23:59:06 <matthieud> D
23:59:09 <ntim> A or B (no strong opinion)
23:59:12 <Rossen4> D B
23:59:14 <schenney> B
23:59:16 <ChrisL> D
23:59:21 <TabAtkins> d
23:59:25 <miriam> A C or D
23:59:27 <kbabbitt> A > D > B> C
23:59:29 <schenney> Change: D
23:59:37 <ethanjv> D > A
23:59:40 <masonf> someone needs to write some code to see which option won.
23:59:55 <nicole> haha
00:00:38 <matthieud> Rossen4:  based on first choice color-layers() win
00:00:39 <ChrisL> \0/
00:00:53 <fantasai> RESOLVED: color-layers([<blend-mode>, ]? <color>#)
00:00:54 <matthieud> RESOLVED: function name is "color-layers()"
00:01:44 <astearns> topic: end
00:01:56 <astearns> zakim, end meeting
00:01:56 <Zakim> As of this point the attendees have been ChrisL, miriam, alisonmaher, Rossen, chrishtr
00:01:56 <Zakim> RRSAgent, please draft minutes v2
00:01:57 <RRSAgent> I have made the request to generate https://www.w3.org/2024/08/07-css-minutes.html Zakim
00:02:04 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
00:02:04 <Zakim> Zakim has left #css
01:44:30 <projecto-> projecto- has joined #css
01:45:01 <leaverou_> leaverou_ has joined #css
01:46:02 <Rossen-> Rossen- has joined #css
01:46:32 <shans_> shans_ has joined #css
01:47:02 <sylvaing_> sylvaing_ has joined #css
01:48:44 <nucliweb> nucliweb has joined #css
02:06:44 <Linux_Kerio> Linux_Kerio has joined #css