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

Text Breakout

[css-overflow-4] Ellipsizing of text in middle of string

astearns: are we going to do this, or punt it?

SebastianZ: Longstanding thing I proposed 10 years ago, a way to crop content of an element in the middle instead of at the beginning or end
… proposal went through some iterations
… current idea is to make text-overflow a shorthand and introduce text-overflow-handling and text-overflow-position

<SebastianZ> w3c/csswg-drafts#3937 (comment)

text-overflow = <'text-overflow-handling'> || <'text-overflow-position'>

text-overflow-handling = auto | [ clip | ellipsis | <string> | fade | <fade()> ]{1,2}

text-overflow-position = [ start || end ] | middle

SebastianZ: we cover the current behaviors, plus cropping

SebastianZ: also outlined rudimentary algorithm later on

SebastianZ: anyone on the call have comments?

florian_irc: my main concern here is the handling of bidi

florian_irc: in general, just like in start/end of line, should do visual cropping not logical
… logical questions is going to be having some strange cropping
… in generalized case, including bidi, makes me worry
… because when you chop start/end, clear what happens, but if you crop middle you have to move the other parts
… suspect it's more complex than we wish

kizu: I don't have any opinion on bidi, but ellipsing in the middle is something I've wanted for more than 10 years

kizu: Last time, there was concern about not allowing clipping in the middle

kizu: but still good way to do it, if it's exactly in the middle then author can position something interesting there

kizu: but this will require browser to know

kizu: other than that, lots of people want this

kizu: idk if in this issue or other, if we need an ellipsis in multiline

kizu: in our product we need this, but should discuss separately

kizu: but for single-line, a lot of use cases

jfkthame: I still disagree with Florian that visual ellipsizing in the middle is the right approach for bidi

jfkthame: in most cases, the most important content will be the beginning of the text and/or the end of the text logically speaking

jfkthame: so those pieces should be preserved

jfkthame: I wonder if, given the complexity/uncertainty, is define middle as a feature but leave the behavior of bidi cases for browsers to experiment with initially

jfkthame: until we see what works in real-world use case

<SebastianZ> +1 to what Jonathan said.

fantasai: I think this makes sense -- the question is whether there's implementor interest. If so, we should spec it.

astearns: do you want to gate specifying on implementor interest? Or should we start it, mark it at risk, and work on spec in parallel?

astearns: should we gate spec on implementer interest?

florian_irc: in this case, I think yes

florian_irc: we agree that this is hard, and we don't know enough to spec it

florian_irc: so even if we did spec it, we wouldn't be able to get interop-level detail

astearns: even if there's open questions, the majority of use cases aren't bidi

astearns: it's something devs need and have a use for

andreubotella: Chromium has an implementation of ellipsis in the middle that they use for file selection

andreubotella: I don't know what it does wrt bidi, but they have an implementation

florian_irc: even if not bidi, there's still ambiguity wrt visual or logical middle

florian_irc: if non-monospace font, where is the middle?

florian_irc: effect of disagreeing will be less dramatic, but still will have disagreement

florian_irc: but maybe useful enough to spec

florian_irc: would prefer to wait until interest, but not an objection

SebastianZ: There was at some point an implementation in XUL

SebastianZ: but they removed it at some point

dholbert: we replaced it with another hack based on HTML+CSS

dholbert: we have something, but idk how good it is. Similar to Chromium

astearns: given that there does appear to be something implemented, is that enough?

fantasai: can't speak for Apple, but doubt we'd object

jfkthame: unsure when we'd get to it, but some interest

jfkthame: we know that what we've got doesn't handle i18n well

jfkthame: and partly lack of a spec has discouraged us from being more thorough about integrating with CSS

astearns: I'm inclined to resolve that we start the spec of this, knowing it will be complicated, and it may take awhile

florian_irc: Do we start with SebastianZ's proposal of two longhands?

astearns: seems like a good place to start

fantasai: probably need to bikeshed -handling at some point

astearns: proposed to start?

RESOLUTION: Start work on middle ellipsis in css-overflow-4

[css-text-4] text-autospace: what gets copied?

florian_irc: Current recommendation from i18n is to just copy the source

florian_irc: Elika does point out there might be more nuance, because in CJK it adds spacing but doesn't add space characters (but can remove them)

florian_irc: whereas in other cases, it can insert actual characters

florian_irc: unsure if this was considered well enough

florian_irc: maybe we should chat with i18n for that last point first, and come back

[css-text] Should text-wrap-style:balance be allowed to affect the block height?

jfkthame: Came up as I was fixing a bug

jfkthame: Spec requires that text-wrap: balance doesn't change the number of lines

jfkthame: thought an author might expect it doesn't affect the overall size of the block

jfkthame: I wondered if that was a correct expectation, or whether it's OK for it to alter the block height

jfkthame: currently that's a constraint in Firefox

florian_irc: In Firefox, is that constraint generally observed or always? Complicated wrt floats etc.

jfkthame: always

fantasai: when we wrote the spec it wasn't about wanting to restrict the height -- it was about the general case of not wanting the 2 line heading to become a 3 line heading because you turned on text-wrap:balance

fantasai: since then it's been brought up about balancing a larger number of lines, e.g., 20-30 or more. At that point you might not care if a line is added/removed if you balance the text.

astearns: we have a current limit at 10, implementations may be more restrictive

fantasai: not required to do more than 10, but can

fantasai: I don't think we should restrict effects on the block height. Changing the way text wraps can change the height of the lines. Maintaining a stable height wasn't particularly the goal of the feature.

fantasai: Instead, we should say for a small number of lines (e.g., < 8) then the restriction should stay, but for more than that (betwen 6 and 10) the number of lines can change.

fantasai: Trying not to change it but might shift by 1 or 2 lines. Enables some faster algorithms which might make larger numbers of lines more possible.

florian_irc: agree with fantasai, also curious about firefox

florian_irc: did you implement this way for a specific reason?

jfkthame: it was fallout from fixing a different bug

jfkthame: that ended up with ensuring that the height doesn't change, that wasn't a specific demand

florian_irc: in that case, the current definition is maybe too specific about precisely how much balancing is the right amount

florian_irc: maybe we shouldn't require the the Firefox behavior, but allow some amount of discretion

florian_irc: might want to balance other considerations

astearns: the method to evaluate whether to evaluate whether something is more balanced

astearns: it's not "you must achieve this", but if you hadn't done this then the line breaks you're considering are not more balanced

astearns: seems we could resolve on loosening the requirement on changing number of lines if number of lines balancing is a larger number

astearns: maybe other things fall out from that

(and is it clear that the requirement is about "number of lines" rather than about "height")

florian_irc: if we don't require FF behavior, should make that clear

fantasai: if we change it so the # of lines is possible to change that will be more obvious

astearns: might still be worth clarifying

astearns: proposed that we relax the restriction on changing the number of lines, and clarify it's only about number of line breaks not resulting height

[discussing what's the limit]

PROPOSED: Number of lines can change if it's more than 6-ish lines being balanced

RESOLUTION: Number of lines can change if it's 6+ lines being balanced, and note that this is about line breaks not content height shifts

[css-text-4 / css-overflow-4] Interaction of `text-wrap: balance` and `(-webkit-)line-clamp`

florian_irc: do we clamp first and then balance, or balance first and then clamp?

florian_irc: dominant view in the issue is clamp first, then balance

florian_irc: but jfkthame points out that if you animate the height, this could be a lot of rebalancing

florian_irc: which is weird

jfkthame: the current safari tech preview seems to do balance and then clamp behavior

jfkthame: opposite of Blink

fantasai: if we want both behaviors, we could change based on 'will-change'

fantasai: could clamp-then-balance if it doesn't have 'will-change', and vice-versa

florian_irc: the fewer additional corner cases we add for fragmentation etc the better it is for later

astearns: I'm convinced that people want both. In case where you're not animating, if you do it one way it looks like balance doesn't do anything

astearns: and in other case, animating is bad

florian_irc: animatable way seems complicated in general case. With simple version of line-clamp probably alright

florian_irc: assume part after laid out same as before

florian_irc: but if we have `continue: fragment`, the next fragment might be a different width

florian_irc: I'm not even sure if you move the clamping point between containers of different widhts before you clamp, what does that mean?

[balancing independently before/after line breaks or page breaks]

fantasai: It's a little bit not what 'will-change' was designed for.

[in response to astearns asking why fantasai was laughing when suggesting the switch]

kizu: this seems like a rare enough use case... for authors if the animation is fast enough you won't notice
… and can otherwise work around it

kizu: will-change suggestion is kinda weird, maybe better to use a dedicated switch

florian_irc: agree this is a rare case. not that revealing progressivly is not rare, but on something that has balance seems rare. For headlines etc.

florian_irc: so my inclination is to start by clamp then balance, and if we need an opt in later we worry how it works then

astearns: given that jfkthame's test results consider this a change in WebKit, is that Ok with WebKit?

I agree with Florian that it's a rare case and we should pick something and not add switches.

fantasai: Seems reasonable to try, since it seems that would be desired by authors.

RESOLUTION: Clamp, then balance

[css-ruby-1] Breaks within implicit bases is not Web-compatible

fantasai: In suggested UA style sheet, we had rb { white-space: nowrap}. Most ruby bases don't have an rb element for reasons that I disapprove of, but it's where we're at.

fantasai: We wanted to allow bases to wrap... so we don't want to forbid wrapping within bases entirely with no way to change it.

fantasai: There are different approaches we could take to solve this.

fantasai: One is to have the UA apply text-wrap-mode to anonymous... but if we did that author wouldn't be able to allow wrapping.

fantasai: We could say anonymous ruby bases have text-wrap-mode: nowrap on them, and if author wants to wrap the base they could use an rb or a span.

fantasai: ANother option is to have a pseudo-element for anonymous ruby bases.

florian_irc: if a pseudo, then all ruby bases whether anonymous or not

fantasai: or that

fantasai: Third option, have white-space: normal compute to nowrap on ruby bases and magically inherit that way. So unless you explicitly set it to something else it will be nowrap.

florian_irc: I think a pseudo-element would be overkill

florian_irc: if just for this use case

florian_irc: so first option would make sense

florian_irc: but there are other use cases for a ruby base pseudo-element

florian_irc: so maybe we get one later; but that's complicated so wouldn't start there

1. apply `text-wrap-mode: nowrap` to anonymous bases

2. add a ::ruby-base pseudo-element and apply it that way

3. make `white-space: normal` compute to `nowrap` on ruby bases

<emilio> I think that's the simplest approach

dbaron: I also lean towards the first proposal

dbaron: the one other thought is, I'm concerned about making pseudo-element apply to all ruby bases whether anonymous or not

dbaron: as of right now we don't have a pseudo-element that also matches real elements

dbaron: there are some proposals that might take us down this path, but it's got some interesting issues and wouldn't want to go down this path without thinking about it carefully first

florian_irc: fair enough

astearns: sounds like we're converging on 1st option

astearns: personally concerned about that, because we're dictating styling that you can only change by changing your markup

astearns: which seems like the wrong path

astearns: should have a way to override the thing we're applying to the anonymous bases

astearns: but if ppl want that, we could add the pseudo element

florian_irc: that said, you're not changng your markup to something unrelated, if you elide markup you have fewer things to style

fantasai: two points:

fantasai: one, the suggestion about computing text-wrap-mode differently... we'd make text-wrap-mode: normal | wrap | no-wrap

fantasai: normal would be the initial value and mean wrap except for a ruby base

fantasai: so if you wanted to style it differently you could set text-wrap-mode: wrap on the ruby element

fantasai: second, we wouldn't have this problem if html parsers injected rb tags into ruby, which they should have done, and I'm still annoyed about that.

florian_irc: is that still fixable?

fantasai: I don't know. We'd have to analyze existing content to see what kinds of selectors are being used.

fantasai: if people are using child selectors in combination with ruby, those could break

fantasai: I don't expect people to do that unless they're doing something fancy with rp

dbaron: It feels less costly to do a pseudo-element than to do the extra value of text-wrap-mode

dbaron: so given choice between those two, I would lean towards pseudo-element

fantasai: implementation cost aside, agree it's a lower cost to authors, since they only encounter the complication if they're working in ruby (which is highly specialized)

emilio: analogy with table parts is good, if you wanted you can just write it

fantasai: tables inject tbody even if you don't write it

emilio: I mean, if you set 'display: table-cell' on a random element no way to style the table

emilio: I agree with styling the anonymous boxes, it's consistent

florian_irc: and also it's compatible with extending to introduce a pseudo-element

florian_irc: and it's also compatible with fixing the HTML parsing, if we're ever able to do that

PROPOSED: Adopt `text-wrap-mode: nowrap` styling to anonymous ruby bases

ruby > :not(rb, rbc, rtc, ruby) { text-wrap-mode: nowrap; }

fantasai: we'd have to add this rule also, because real elements can't inherit from anonymous

dbaron: a bit concerned about that selector because it looks expensive from perf perspective ... unsure for current engines

dbaron: idk if will require parent of every element

emilio: that rule is not great

RESOLUTION: Style anonymous bases with text-wrap-mode: nowrap as described in w3c/csswg-drafts#10073 (comment)

(I'm a little worried the 2 things are tied together and we may need to reconsider.)

emilio: regarding performance, it's probably not as terrible as it used to be, but only probablistic filtering

emilio: overall I don't think it's great

emilio: can we set nowrap on the ruby element itself?

fantasai: ruby itself needs to be able to wrap

emilio: can we explicitly list stuff?

florian_irc: all possible inline elements?

astearns: can it be magic?

emilio: not really great...

astearns: ok, out of time. Can either leave open or resolve to add it and then work through the perf concerns.

astearns: what's the preference?

dbaron: lean towards leaving it open

RESOLUTION: unresolve previous resolution

Administrivia

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

Alternate masonry path forward

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

fantasai: topics: can masonry replace grid, track info, interaction of masonry-grid. For authors? For spec?

w3c/csswg-drafts#9041 (comment)

fantasai: Q? Use case for variable track sizes. It not neceaary, all sorts of objections due to complexity. Jen SImmons has demos to present and talk through.

->

jensimmons: We're hoping to make real progress on this question, it's been 4 years since this question first came up

<bts> Link to demo: https://webkit.org/demos/grid3/photos/

jensimmons: the demos are online

https://webkit.org/demos/grid3/photos/

jensimmons: Photos demo is a good start. If we show numbers you can see multicol layout, where the images go down the first column, then second, etc.

jensimmons: for this content it's ok, other content it's not great; but also it doesn't allow loading additional content to the bottom

jensimmons: if you use grid L1, it lines up in both row and column. If aspect ratio isn't uniform, doesn't look great

jensimmons: masonry gives a chance to lay things out going across the top of the columns, and then keep going across filling the shortest colun

jensimmons: it builds into grid easily, can specify any set of columns you want and then set rows to 'masonry'

jensimmons: basically turns the rows off

jensimmons: There are other things you can do with grid, because full power of grid-template-columns

jensimmons: in this demo, first and last cols are fixed sizes, and the iddle columns 1fr, and number of columns scales with width of window

jensimmons: next demo, all columns are flexible but we have narrow and wide columns

jensimmons: and always starts and ends with a narrow column

jensimmons: the basic masonry layout is popular because JS can only do so much, but building into CSS can do a lot more

jensimmons: spanning in grid allows some interesting possibilities, e.g. every 5th item is wider here. Gives more graphic design interest.

jensimmons: in this version made the landscape photos wider

jensimmons: [shows horizontal masonry demo]

jensimmons: Mega menus are another use case

jensimmons: multicol would go down the columns, but masonry allows to lay out the first items across

jensimmons: Text becomes more interesting also.

jensimmons: a lot of websites lay out teaser content by fitting the content to the regular boxes

jensimmons: often by trucating it

jensimmons: keep everything the same aspect ratio, creates a very modernist grid

jensimmons: this is why graphic design can feel boring on the web

jensimmons: classic masonry allows more flow of content, but still somewhat rigid

jensimmons: start applying different widths and spans, create very interesting layouts

https://webkit.org/demos/grid3/photos/

jensimmons: this last demo is classic masonry, but grid allows some extra possibilities

jensimmons: the header/sidebar can be shifted to the other side using explicit placement

jensimmons: or use subgrid to align metadata across cards

<lea> +1 for letting Jen finish. This is important, we can spend 5 more minutes on it. Also, talking about timeboxing came close to taking more time than the actual presentation.

jensimmons: subgrid is powerful here

jensimmons: questions?

jensimmons: As I wrote in the article, this is about saying "hey, we've got grid -- but what if we let go of the idea that it's only modular grids?"

jensimmons: columnar grids are grid systems, historically in graphic design

jensimmons: this just lets us turn off rows (or turn off columns)

jensimmons: and contents pack together

?: is this display: block grid?

<Rossen__> qKeith

jensimmons: no inlines, this is just 'display: grid'

TabAtkins: I posted a long comment to the issue about an hour ago. Long because I went into our reasoning, but can read tldr and proposal

TabAtkins: summary of our position, we the Chrome+Edge engineers find the current spec unshippable given the algorithm in it

<dbaron> w3c/csswg-drafts#9041 (comment)

TabAtkins: it can trigger quadratic or exponential behavior, which could brick the page

TabAtkins: we acknowledge they are edge cases

TabAtkins: The restrictions we need are not ones that Jen's demos hit

TabAtkins: We just need to restrict to either a) fixed or flexible tracks OR b) intrinsic tracks

TabAtkins: every demo presented works in those constraints

TabAtkins: problem only happens when you can mix intrinsic track with other types of track sizing

TabAtkins: because that's when spanners start to contribute differently in different racks

<Zakim> TabAtkins, you wanted to discuss after the demos

TabAtkins: On a more conceptual level, we thing there's a number of friction points where the syntax is suboptimal because designed for 2D grid

TabAtkins: or concepts don't directly translate and need to default values instead of rejecting at parse time

TabAtkins: e.g. auto-fit is treated as auto-fill

TabAtkins: However, we thing there's also significant conceptual similarity to grid. It has tracks, lines, etc.

TabAtkins: so should do as much connection between the two

TabAtkins: e.g. have subgrid take lines from a parent, assuming we have fixed sizing bits

TabAtkins: Similarly submasonry value, taking lines from parent

TabAtkins: Everywhere they interact, make it easy to translate knowledge. But they're still not the same thing, and enough pain points that they should be done in different display types

<lea> Lea: These demos are impressive, and this is solving real author pain points.

<lea> Lea: I did have some reservations about how this combines with multicol from an author point of view, but I think I'm now convinced this makes sense as a part of grid.

<dholbert> TabAtkins' github comment with more details: w3c/csswg-drafts#9041 (comment)

Lea: One thing is that the `masonry` keyword seems a little magical. How can authors set constraints on the min and max size of these generated rows/columns? How does it interact with `grid-auto-flow`?

Lea: e.g. what about 'dense' keyword?

miriam: Agree quite a bit with Lea. Agree we like this as part of grid. Syntax feels right.

miriam: would like to add a few more constrainst

miriam: get that there's some constraints on implementation

miriam: Looking at separate masonry proposal, seems like new terms for similar things

miriam: why do I need to learn new terms for the same thing?

miriam: I also might want to switch between grid and masonry at different break points

miriam: keeping them together makes it a lot easier to do

+1 to miriam great point about switching to/from masonry

miriam: I like the grid syntax if we can make it work

<Zakim> fantasai, you wanted to respond to Lea's questions

fantasai: Reponse to Lea. I don't iunderstand min/max rows columns. Maybe explain later.

fantasai: Dense, autoflow maybe mergable from ? and ?

jensimmons: We put this out to designers and developers to see what kind of feedback we would get

jensimmons: Get it to developers. See what feedback.

jensimmons: overwhelmingly people want to see this as part of grid. It's not 100%, but on issue in CSSWG it's roughly 80/20 in favor of building into grid.

jensimmons: authors prefer making it part of what they're already familiar with, already learning, as part of CSS Grid

ydaniv: +1 to what miriam said before

ydaniv: thinking about interpolation, animating to/from masonry and grid

ydaniv: could be easier inside grid than between display types

<TabAtkins> wrt the author feedback, note that the blog post argued exclusively against an overly simplistic model (only fixed-size, identical tracks, a la multicol). Every demo was showing how we need more than that. As I said, tho, every demo is perfectly fine; the actual restrictions we need are much more subtle. We can't take support for "what the blog post displayed" as arguments for "build it into Grid".

florian_irc: Thanks Jen & team for the demos, and also for presentation. I had skimmed the blog but realized more things during presentation

florian_irc: more compelling, and really makes the case for needing these capabilities

florian_irc: wrt Google proposal posted recently, seems it's fuller than what was originally discussed

florian_irc: I think we need more time on this topic soon, and discuss the differences between the two

rachelandrew: WebKit team presented to developers saying the only way is to have grid implementation, and I don't think that's the case as Tab outlined

rachelandrew: but when I first started showing people Flexbox and Grid, people would say "it's inconsistent", because it was different from block layout

rachelandrew: at this point we have good understanding of formatting contexts

rachelandrew: my worry as someone who teaches this is, if we put masonry in grid we have to say "these properties only work in grid that's not masonry" or "these properties only work in grid that is masonry"

rachelandrew: if we build into a separate display type, can still have a lot of cool stuff, but not dancing around the differences

dholbert: we have a prototype implementation of masonry in grid

dholbert: I'm sympathetic to the performance considerations of every item in every track

dholbert: agree with sharing a lot of the same behavior with grid

dholbert: using a restricted form of track syntax but compatible for masonry, that's only possible to do by using a different set of property names

<Zakim> lea, you wanted to ask how does this work with explicit col/row placement?

lea: How does masonry work with explicit grid placement?

fantasai: If you specify specific track, maonsry item goes there.

fantasai: Just like grid etc, move to that position and keep placing.

florian_irc: Do you ignore a dimension?

fantasai: Yes.

<TabAtkins> + there's a switch in masonry-auto-flow about whether to place all the explicit items first (like Grid does) or in the normal order.

Rossen__: Good discussion, let's review comments and come back to it later.

big +1 for integrating masonry-auto-flow with grid-auto-flow if this becomes part of grid

<astearns> let’s keep posting and conversing in the issue - please do not wait until we can schedule more call time

[css-color-4][Editorial?] Clarify that `none` is preserved in calculations

lea: Awhile back we invented 'none' value for color components to represent achromatic colors (that don't have a particular hue)

lea: when converting gray to a polar format, which hue do you use? none are relevant

lea: then we expanded to chroma and saturation for same reason

lea: eventually it turns out once it was deployed, very useful in many more use cases

lea: lets you represent colors that are parameterizable, that get meaning based on where you use them

lea: e.g. color with nones and lightness, and mix with it to get tints

lea: with relative color syntax becomes even more useful

lea: when we wrote the spec, what do you output a color that has 'none'?

lea: so we decided to make it convert to zero

lea: when you're converting from one color space to another, e.g. rgb to lch
… you don't want to expose color space conversion math
… this conversion to zero is like a last ditch effort. last thing you do if there's nothing else reasonable to do
… the way this was interpreted by impls, you also convert to zero when you can't do a computation, e.g. calc(h)
… this is against author intent; h and calc(h) should really be the same
… you could imagine having a color in relative color syntax and using calc or calc-mix to ?
… all of these would be solved if we resolved that 'none' was preserved during calculations. don't convert nones to anything, nones remain nones
… I've written details about how this might work in the issue
… interpolation operations have the behavior of the current value of none, only have this behavior if the other value is not "none-containing"
… if you're interpolating between a value with none to some other value, you get the non-none-containing value
… [missed some]
… this reduces magic/discontinuities.
… Also need to sort out how to handle this for a syntax that allows 'none', e.g. clamp's 1st or 3rd argument. Is it the 'none' that means no bound, or 'none' that means the color meaning of 'none'?
… we just need to define precedence. I'd argue for using the color meaning of 'none', but I don't care too much
… main thing I care about is that 'none' values are not dropped
… ChrisL suggests that this is just an editorial change, but Romain said it's editorial; hence, running by the group

<Zakim> ChrisL, you wanted to agree that coercing none to 0 should be deferred as much as possible, ie used value time

ChrisL: I no longer thing this is editorial. main thing is preserving author intent. Coercing none to zero is an option of last resort if you're literally trying to draw 'none'

ChrisL: other cases, hue of 'none', does that mean they really want a bright magenta red? no

ChrisL: we're seeing people comment on this in implementations, people complaining about why-are-they-getting-a-red-arbitrarily

<TabAtkins> +1 to preserving none. I think it's probably fine to treat `clamp()`'s none as the color none in RCS.

<TabAtkins> (Because, as noted, you can always write `clamp(-infinity, val, infinity)` instead.)

ChrisL: regardless of the mechanics, the general thing of "we need to preserve this value unless we can get rid of it" is the main thing. we can talk about ways to achieve it separately if needed

Romain: I was wondering if this is implementable. I assume browsers have an internal representation of color that's channel values, but with this proposal you need to preserve much more information about how the color was specified

<Romain> calc(none + 0.2)

Romain: I think this would be very surprising when you move this across color spaces. When you write: [...]

Romain: if you write this^ in LCH or oklch, the 0.2 has a different scale in both. But if you switch color spaces, it gets preserved and not converted, and that can be surprising

Romain: not an absolute blocker, but does have sharp edges

lea: RE implementability, browsers have to do this with variable references already

emilio: that's not how variable reference works; they're substituted before parsing

emilio: you don't have a concept of a calc with variable references; you have a string with variable references substituted

lea: my point is that not every component actually resolves. Even in rel color syntax, you keep the values of the base color [??]

<ChrisL> right but you don't have an immediately displayable color

lea: let's not conflate preserving none in color space conversions & in calculations

lea: converting btwn color spaces is a whole different beast; that's one of the reasons resolving to 0 was invented

lea: don't want to convert none in a way that exposes color space conversion math

<Zakim> lea, you wanted to react to Romain to reply to romain

<ChrisL> https://drafts.csswg.org/css-color-4/#analogous-components

lea: the spec also has a part where if you're converting between two color spaces, where one component of first color space is largely orthogonal to the rest and related to a component in color space b, then swap the none out for zero, and then replace the none in that component [??]

<chrishtr> again+

lea: let's discuss the color space conversion separately; it's hairy

emilio: I agree that preserving 'none' in some way makes sense

emilio: I was going to say something similar to Romain

emilio: when you mix 'none' in more complex calculations... have you given thought to making 'none' more similar to how NaN works? as soon as you mix something with 'none', it remains 'none' instead of being an expression involving 'None'?

<ChrisL> We invented none because the spec said NaN and tab told us not to :)

emilio: that would be less complex to implement. Interpolating without having to [...] transforms have such a thing, where you have to keep them as a mix that isn't simplified

emilio: that seems like a less confusing model, where doing math with 'None' gives you 'None'

ChrisL: That's what the spec used to say; it used NaN explicitly

ChrisL: Tab suggested we use a special value, which is where None came from

TabAtkins: My argument against NaN was for other reasons, unrelated to infectiousness

<Zakim> ChrisL, you wanted to react to emilio

Lea: infectious none is actually worse than converting it to 0. E.g. clamp(50, none, 60) is conceptually very different than none, you're basically saying "I want the component of the other color, but it needs to be within this range. Converting the whole component to none in that case could even harm accessibility, if the constraint was there to e.g. ensure sufficient contrast.

<Zakim> lea, you wanted to say let's not conflate preserving none in calculations with preserve none during color space conversions and to

lea: infections 'none' is worse than converting it to zero

lea: if you have an expression clamping 'none' to 50 or 60, the author wants it to be in this range

<ChrisL> w3c/csswg-drafts#6107

lea: if you convert the whole thing to none, then that can harm a11y

Romain: this is still related to color space conversion because the spec says you have to convert to the same color space when doing interpolation

ChrisL: that's correct, because of missing components

<TabAtkins> (We shouldn't use NaN to indicate "no channel value" because NaN *also* comes from simple math errors. We didn't want "author made a math error" to accidentally also trigger "this channel is powerless and should be taken from the opposing color". The infectiousness wasn't a part of this.)

chris-harrelson: what does calc(none + 20) resolve to?

lea: that's well-defined in the issue. calc(none+20) -- the none would become the value of that component in another color, and then you add 20

lea: get the lightness of the other color, and then subtract 20 from it

lea: e.g. if you're trying to interpolate from a certain color to a darker version of it, regardless of what color you're starting with

chris-harrelson: so that means zero is not the right number, in those use-cases

<ChrisL> So setting hue to calc(none+180) gives you the complement of the other color, when interpolating for example

lea: correct, zero is almost never the right number

ChrisL: I've got a suggested resolution for what we want to achieve, it sounds like we have consensus on that?

ChrisL: "don't get rid of none and replace it with zero unless you absolutely have to, e.g. if you're forced to use it as a used value"

lea: that might be all we need?

emilio: I agree

I wonder if implementations could even internally rewrite to RCS, in some ways it's like a late-resolving RCS

emilio: I sort of want to review the proposed changes with more detail; the details of how you do that might be a bit tricky

lea: proposed: None is preserved in calculations involving css math functions

lea: ...and also when interpolating between values containing 'none' and values not-containing-none

<ChrisL> +1

RESOLUTION: None is preserved in calculations involving css math functions

<lea> s/None is preserved in calculations involved in css math functions/`none` is preserved in calculations involving CSS math functions

When interpolating between two none-containing values, the result is a calc-mix() expression preserving the `none` values in both values

PROPOSED: ^

<ChrisL> +1

PROPOSED: When interpolating between two none-containing values, the result is a calc-mix() expression preserving the `none` keywords in both values

dholbert: do we need to cover interpolating between none/not-none?

lea: that's already defined

flackr: I see in the issue description that there's also a proposal that 'none' resolves to the other component, if the other component is not none-containing

lea: that's already how none works / what none does

Romain: that's not true; it's not a placeholder for the other channel. It makes a channel missing

Romain: it's not like the nesting selector where it's a placeholder for the parent

Romain: this would be a new mechanic. I'm fine with it being a new mechanic, but we should call it that

ChrisL: that's already in the spec?

Romain: that's related to color components

flackr: I'd like to know what's used in the other end of the interpolation. pulling the color from the other end isn't what authors would expect

<TabAtkins> That is actually intended behavior, yes

flackr: if you're pulling from 2 color values and a none in the middle, pulling from two color values at the ends isn't what authors would expect

lea: that's an orthogonal issue and what happens today

Rossen__: objections?

RESOLUTION: When interpolating between two none-containing values, the result is a calc-mix() expression preserving the `none` keywords in both values

[end of meeting]

end