Meeting minutes
New meeting link sent to private list.
<dbaron> Oh, so one reason the "project" wasn't updating for me was that... the URL changed to https://
Shared Element Transitions
<fantasai> Rossen_: welcome to Day 2
<dbaron> github: https://
<vmpstr> vmpstr
<fantasai> vmpstr: About Shared Element Transitions, a new set of APIs we're working on for animations and transitions between pages
<fantasai> vmpstr: single page and hopefully multipage as well
<fantasai> vmpstr: Was presented in breakout session
<fantasai> vmpstr: since then worked on spec text and prototype in Chromium as well
<vmpstr> https://
<fantasai> vmpstr: I sent this spec draft to the list awhile back
<fantasai> vmpstr: hoping that ppl interested would have read through the draft
<fantasai> vmpstr: ultimate goal for us is adopting this into the CSSWG
<fantasai> vmpstr: so we wanted to use this opportunity to surface issues ppl may have
<fantasai> vmpstr: and of course we're happy to answer any questions
<fantasai> khush: Other goal that I'm hoping is, there are a few open issues in the spec and things came up while prototyping
<fantasai> khush: and wanted to go over those as well
<fantasai> khush: hoping we can file issues within CSSWG and go from there
<fantasai> Rossen_: We've had the overview in the past, there's also an open aggregate for this feature, which we haven't gotten to
<fantasai> Rossen_: questions or comments or feedback to vlad and khushal?
<fantasai> Rossen_: what do they need to move forward and adopt this as part of the CSS charter?
<fantasai> Rossen_: do we need any additional overview, refresher of the APIs?
<fantasai> TabAtkins: Happy to discuss any concerns, but also if OK with making ED can discuss later as wel
<fantasai> fremy: I like the idea, just note that there is no images or diagram or anything in the draft
<fantasai> fremy: so maybe in a future version, have a diagram of the different pseudo elements
<Rossen_> https://
<fantasai> fremy: and what order they're in the page
<fantasai> fremy: it's in Ch4, but a diagram would be nice
<fantasai> fremy: not a blocking thing
<fantasai> Rossen_: I posted also a link to the explainer, a bunch of really well-illustrated examples there
<JakeA> Updated developer-facing article https://
<fantasai> fremy: exactly what I was hoping for
<fantasai> Rossen_: anything else, fremy ?
<fantasai> fremy: nope
<fantasai> JakeA: I posted a link to the developer-facing content for this, which includes a lot of videos and examples
<fantasai> JakeA: can put it in the spec if wanted
<fantasai> JakeA: I've never seen a video in a spec before!
<fantasai> TabAtkins: of all this specs, this is probably the one that would most benefit!
<fantasai> Rossen_: Any objections to adopting this work?
<fantasai> fantasai: Are we adopting an ED, or are we also publishing FPWD
<fantasai> TabAtkins: still have some tweaks to make, so happy to wait until we get those down and then doing FPWD
<fantasai> fantasai: If you have planned edits, let's do ED now and FPWD later then.
RESOLUTION: Add Shared Element Transitions as ED, with JakeA, khush, and TabAtkins as editors
<fantasai> Rossen_: anything else on this topic?
<bramus> Nice!
<vmpstr> o/
Agenda-Bashing
Sizing
[css-sizing] How does 0x0 size affect last remembered size?
<emilio> github: https://
<JakeA> Thanks all. I'm going to finish some spec edits for SET. Ping me if you need me and I'll rejoin.
<emilio> oriol: Not sure if I should do a quick intro about contain-intrinsic-size: auto
<emilio> ... which is a feature that remembers the last size of an element
<emilio> ... and then uses that instead of collapsing the contribution of the contents
<emilio> ... when you have size containment
<emilio> ... this specific issue is about 0x0 size. The spec seems to assume that using ResizeObserver is the way to track this size
<emilio> ... since it mentions that the size is updated at ResizeObserver time
<emilio> ... when implementing this I found a problem when the size is 0x0
<emilio> ... if you start observing an element with ResizeObserver and the element doesn't have a 0x0 size then you get an observation with the current size
<dbaron> This sounds like a spec bug, and the spec should handle 0x0 sizes just like other sizes.
<emilio> ... but you don't get it without it
<emilio> ... so the question is should we still store this size as the last remembered size?
<emilio> ... seems like Chromium wasn't doing it
<emilio> ... so I don't see a reason about why special-casing it
emilio: now that you've explained this, this is only observable in some cases, right?
emilio: if there's not stored size, you use 0x0
emilio: e.g. in one axis
<emilio> oriol: when you have c-i-s: auto you need to provide a fallback value
<emilio> ... so if you get the fallback you can detect it's not stored
<emilio> TabAtkins: this appears to be a corner case falling from the implementation details
<emilio> ... so I don't mind either way
<emilio> dbaron: I think this is just a spec bug that was copied to the spec because it was written based on impl
<emilio> ... I think 0x0 should be handled like any other size
<emilio> TabAtkins: the spec doesn't special-case this
<emilio> ... so it's an impl bug
<emilio> oriol: yeah, this is because the ResizeObserver inits its size to 0x0
<emilio> TabAtkins: we only reuse the RO timing
<emilio> dbaron: it might be a bug in ResizeObserver
<emilio> flackr: should we remember 0x0 only if the element was visible? This is intended for content-visibility
<emilio> oriol: there are some issues with storing the size
<emilio> oriol: you need to be size-contained at the time, which c-v provides in some cases
<emilio> ... so if you lay out the content normally without size-containment etc it gets saved
<emilio> flackr: if the element has never been on screen we shouldn't be remembering 0x0 for its size
<emilio> ... we'd lay out 0x0 with c-v: hidden
<emilio> oriol: if it has c-v from the beginning you don't store the size
<emilio> flackr: but c-v: auto changes dynamically when you scroll
<emilio> oriol: if you have c-v: auto initially outside of the screen we won't store the last remembered size because it has size containment, we'll store it once you enter the screen
<emilio> flackr: so we won't save the size if it has size containment, so my concern is addressed
<emilio> ... resizeobserver will still fire
<emilio> oriol: yeah, but you won't store the last remembered size
emilio: I think I agree with dbaron , that it feels like a bug in ResizeObserver
emilio: IntersectionObserver does fire an observation immediately, regardless of whether on the screen
emilio: so it feels to me like a bug that ResizeObserver doesn't fire on zero
<flackr> +1
emilio: and that would fix this by extension
emilio: so I suspect we just move this to the ResizeObserver spec
emilio: idk who's the editor of that?
emilio: but given the precedent of IntersectionObserver always firing as well, it doesn't seem to me that this would be objectionable
emilio: It seems the editors are no longer working on CSS specs
emilio: so we need new editors for this spec?
Rossen_: Let's figure out what we want to fix and then figure out who is going to do it
oriol: Proposed resolution would be that 0x0 size is not special, is just like any other size
emilio: that's the current spec behavior
Rossen_: that doesn't require any change to the spec, simply requires implementations to fix their bugs
emilio: but then we need to file a ResizeObserver bug
Rossen_: yeah, but we're here to fix specs
Rossen_: seems we don't need a spec change, if hte bugs are not filed, please go and file them
Rossen_: Anything else on this topic?
Rossen_: objections to resolving on 0x0 is not a special size?
RESOLUTION: 0x0 is not special wrt ResizeObserver or c-i-s
emilio: This means we need ResizeObserver spec changes
[discussion of possible editors]
RESOLUTION: Replace ResizeObserver editors with Oriol and Emilio
Last Rememberd Size unclear when auto
github: https://
oriol: spec says that when we store last remembered size, this survives box destruction, e.g. if you add 'display: none', the element will keep storing this last remembered size
oriol: my question here is if the element is removed from the tree
oriol: and then later re-inserted
oriol: will it still have its last remembered size from the previous position in the tree?
oriol: should we remove the last remembered size?
TabAtkins: I suggest whatever is easiest to implement
<emilio> https://
<emilio> github: https://
TabAtkins:
TabAtkins: Rossen made the point that moving the element is done by removing the item ...
TabAtkins: but if you're e.g. re-ordering a list, you might want to keep that info
<iank_> yeah there are lots of cases for moving things around, and it should keep the same last size.
TabAtkins: The common case for removing from document and re-inserting is moving it around
TabAtkins: and the common case of that is re-ordering within a list of similar items
TabAtkins: so my suggestion is to keep the last remembered size until normal things remove it
emilio: You can move things around, given how specced right now
<ydaniv> Is removing from layout tree much different from being removed completely from the DOM?
emilio: that means that if you move it, by the time you ??, it will already have a box
emilio: when we fire ResizeObserver calllback, if you move an element, it will have a new box and a new position in the tree
emilio: do we want to clear it if it's not in the document or doesn't have a box, i.e. when you fire the ResizeObserver event
emilio: [missed]
emilio: Deciding at the time of ResizeObserver doesn't prevent the moving case from working
TabAtkins: if you remove it from the tree, hold onto it a bit, ResizeObserver fires, and then you don't have a remembered size at that point
TabAtkins: when the ResizeObserver timing happens (well-defined), if the element is outside the document, we clear the last remember size
TabAtkins: because we forget the size in some cases at ResizeObserver timing
Rossen_: what do we do for animations?
TabAtkins: they're tied to the box
TabAtkins: but these are tied specifically to the element itself
TabAtkins: is there an implementation concern?
emilio: no
TabAtkins: I could lean either way
Rossen_: Oriol, do you have an opinion
oriol: No strong opinion, just wondering about it
oriol: I suppose we can leave it to not do anything special
oriol: Styles might change if you move it, or the old size might be strange in the new position
oriol: but can also be fine
oriol: so no strong opinion
iank_: The reason not to tie it to the box is that we have a lot of features that will switch out of the box
iank_: e.g. like when using CQ, it will be very common fro an element to have potentially different boxes associated
ydaniv: c-i-s is only interesteding if you have content-visibility and still out of view, right?
ydaniv: so by the time that the element is in view, it doesn't really play any part, right?
oriol: it can play a part if you first lay out the element normally and it can store its size, and then you add content-visilbity: hidden, the it can be in the screen and keep its contents, and it will use its last remembered size
oriol: we resovled this last week
TabAtkins: that's the exact weirdo case this is designed for
Rossen_: Ok, regardless if it's weird or not, we need to make it more predictable
Rossen_: if we specify that it fires, the previous size
Rossen_: would there be any objections?
TabAtkins: I think I lean very slightly towards it forgetting its size
TabAtkins: if you're stashing away, not just doing a move
<flackr> q_
TabAtkins: it's much less clear that the new context you're putting it into would be similar
TabAtkins: so I lean towards forgetting if it's out of document
Rossen_: when you last checked this, did you check what implementations did?
oriol: Chromium never seems to remove last remembered size
oriol: and in Gecko haven't landed implementation
flackr: For virtual scroller recycling element, I think we'd see this happen, and you'd want to forget the size, because you're changing the content before re-inserting
Rossen_: so then the proposed resolution is that the element will forget its last size
TabAtkins: at normal ResizeObserver timing
vmpstr: then if removed and then re-aded, then it's keeps its size if it happened before the resize observer timing
TabAtkins: At ResizeObserver time, you also check if it is in the document
TabAtkins: if not, forget the size
RESOLUTION: At ResizeObserver time, forget an element's last remembered size if it is currently out of the document
Is last-remembered size recorded if size containment in single axis?
github: https://
oriol: we are only storing last remembered size if there's not size containment
oriol: however, in newer specs of css-contain, we may have size containment in a single axis
oriol: what happens?
oriol: Are we still storing both width and height of last remembered size?
oriol: do we not update last remembered size in the uncontained axis?
oriol: shoudl we check at least one of the axes has size containment and then store both?
oriol: how should this work exactly?
TabAtkins: this is a very good question
Rossen_: do you have a proposal, Oriol?
oriol: maybe would feel more natural to me to do independently rather than together
oriol: right now Chromium stores together
oriol: I don't have a strong opinion
TabAtkins: I think I lean toward tracking them together, just because say you have a set width and you have a contained block size
TabAtkins: whatever block size you want to remember, that depends on your width
TabAtkins: if you end up with a different width, your height is not going to be very meaningful
TabAtkins: it's weird to expect a different width also
TabAtkins: but I feel either record both or record neither
TabAtkins: and you need to have containment to get sizing to trigger
flackr: I was going to suggest the opposite
flackr: reason beign that the only way that you have containment in one axis by it being an explicit style, whereas containment in both axes is because of content-visiblity and being off-screen
flackr: if the developer, while on screen, has containment in one axis
flackr: then it should store the last remembered size when it goes off screen
Rossen_: that's a compelling argument
TabAtkins: that seems reasonable
Rossen_: sounds like we're approaching a resolution
Rossen_: proposed resolution is that we'll keep them separate, and store them separate
Rossen_: any objections?
RESOLUTION: "last remembered size" is tracked for the two axises independently (in case of containment in one axis), and can be invoked independently (with c-i-s:auto in one axis)
Break
<br end=??:20>
Last remembered size unclear under auto
github: https://
github: none
Clarify contain-intrinsic-size with multicol/grid
github: https://
oriol: spec defines c-i-s as setting the intrinsic inner size
oriol: then it says that this causes the box to size as if its in-flow contents ...
oriol: but what exactly are its in-flow contents?
oriol: multicol container or grid container
oriol: in a multicol container, the size, it sets the width of the box
oriol: but if you have columns or tracks, the total width of the column/container will be bigger than that
oriol: in grid it's the opposite,
oriol: but here, c-i-s, was setting the content size of the grid
oriol: ...
oriol: I don't think it's completely clear, and I want to have a resolution on this
<iank_> our multi-col intrinsic sizing isn't particularly good in this respect.
TabAtkins: the Grid behavior is correct. Multicol is wrong
TabAtkins: we didn't think about multicol when writing this, but thought about grid, and ignoring the grid stuff is the intended behavior
TabAtkins: multicol should be fixed, and get a clarification in the spec to make extra clear
oriol: if you specify c-i-s: none and then in grid it may become greater than zero
oriol: if you have .e.g. fixed tracks
oriol: but if you specify c-i-s: zero
oriol: then it will override grid template properties?
TabAtkins: correct
TabAtkins: If no setting the size, you pretend no children, but grid is still there
TabAtkins: but if set a size, you get that size
fantasai: what's the behavior with multicol?
TabAtkins: if you set c-i-s to a length, you get that size, not size of columns
fantasai: columns are usually less fixed-size than fixed-size columns anyway
Rossen_: is that the only clarification we need?
TabAtkins: this isn't a clarification for multicol specification, just make clear that things such as multicol or grid don't do anything special, size just gets overridden
Rossen_: what's the proposed resolution?
TabAtkins: clarify spec that layout systems that can have sizing effects even with empty children don't matter, c-i-s overrides all of that and sets a particular content size
RESOLUTION: Clarify that setting c-i-s to a size overrides the content size, even if there is other sizing info such as grid column widths
Clarify how c-i-s affects size containment algo
github: https://
oriol: There's a bunch of sentences in the spec, mostly editorial, but the interaction of how the algo in containment spec is altered to take c-i-s into account
oriol: mostly editorial, might not worth it to discuss now, just one thing I wanted to discuss is
oriol: what about replaced elements?
oriol: The contain spec sais that when you have a replaced element with size containment, it behaves as if it had no natural aspect ratio
oriol: and the natural size was zero
oriol: what happens if you have c-i-s?
oriol: what Chromium does is that the replaced element still doesn't have a natural aspect ratio
oriol: but the natural width and height are the ones specified in c-i-s
oriol: does this make sense, or do we want some other behavior?
TabAtkins: having natural width/height take from c-i-s makes sense
TabAtkins: you asked, why do first layout if going to relayout
TabAtkins: answer is, we want to make sure that under normal circumstances, width calculates before height
TabAtkins: depending on contents, can have different effets
TabAtkins: once have width, then calculate height
oriol: so can we have an example of these cases in the spec?
ACTION TabAtkins add an example
ACTION: TabAtkins add an example
Rossen_: does that mean we don't need to change anything?
TabAtkins: Oriol's second example, needs fixing in the spec
<emilio> fantasai: we want to clarify that it doesn't set the a-r right?
Proposed: contain-intrinsic-size size is used as the natural sizes of replaced elements (but does not set the aspect ratio)
<iank_> some SVGs have this behaviour.
<emilio> TabAtkins: yeah
<emilio> fantasai: I wanna suggest that if the aspect-ratio...
<emilio> TabAtkins: we wanna say that it doesn't have an intrinsic aspect-ratio, the property can affect
<emilio> fantasai: wonder if there's utility in being able to set the a-r from those sizes
<emilio> ... guess it has to be opt-in, we don't know if the element is supposed to have an aspect-ratio
<iank_> if you want to opt-in to an aspect-ratio you can just set the aspect-ratio as well?
<emilio> ... we might want to have that ability
<emilio> ... yeah, you can do that explicitly, but it'd be easier to have it computed from c-i-s
<emilio> ... that's something to think about but can be addressed later
<emilio> Rossen_: objections?
RESOLUTION: contain-intrinsic-size size is used as the natural sizes of replaced elements (but does not set the aspect ratio)
last remembered size if no principal box
github: https://
oriol: In a note, when the element gets display:none, then the last remembered size is supposed to be preserved
oriol: if the elmeent doesn't have 0x0, and the box is distroyed when you apply 'display:none', then the last remembere size will be zero
oriol: if c-i-s is auto, then need to remember this last size
oriol: so we override the last size with 0x0
oriol: and then I guess we should ad the condition that the element at that point is not generating a principal box, shouldn't record the size
TabAtkins: correct, if it doesn't have a principal box shouldn't record the size
TabAtkins: agree we should fix that
oriol: if there's no box, shouldn't we be able to remove this last remembered size?
oriol: we resolved that if it's removed from the tree, we clear the size
oriol: I guess if it doesn't have a box, the size doesn't change, but my understanding is even if the size doesn't change, if you remove c-i-s: auto you remove last remembere size
TabAtkins: lacking a principal box shouldn't remove the remembered size
TabAtkins: as long as you still have c-i-s: auto
oriol: Consider a case where we have a box, but let's say that we have c-i-s: auto and we remmeber the size
oriol: and then we remove c-i-s: auto
oriol: but box size doesn't change
oriol: should we remove the last remembered size?
TabAtkins: yes
TabAtkins: this is not tied to ResizeObserver, it's tied to ResizeObserver timing
oriol: if you lose c-i-s: auto, but this doesn't trigger a size change, then we still remove the last remembered size
fantasai: okay
oriol: in this case, we wouldn't get an observation because the size didn't chnage
oriol: but if we can remove the size when c-i-s: auto is lost, what if we first add display:none
oriol: and then remove c-i-s: auto
oriol: by consistency, we need to remove the last remembmered size as well
oriol: but most browsers don't recompute style during 'display: none'
TabAtkins: so that's an implementation difficulty with matching the spec
<vmpstr> fantasai: suppose if it's display: none you can flip things on and off
fantasai: and when you remove 'display: none', you check if cis:auto is there and either clear the last remembered size or not/
emilio: but you need to do that not at ResizeObserver time, but as soon as you get a box that is not cis:auto
emilio: so you go display:none, at ResizeObserver time we dont' know what to do because don't have a box
emilio: if when you come back, you need to check cis:auto
TabAtkins: that seems fine to me
emilio: It's weird to update this in different places
TabAtkins: I also think it's weird to do that, but it's apparently problematic to do it while display is none
TabAtkins: So we check for cis:auto when the element begins generating a principal box again
TabAtkins: if it doesn't ahve cis:auto at that point, forget its last remembered size
emilio: yeah, ok
TabAtkins: if you're doing anything weird switching cis while you're display:none it's your fault
emilio: consider CQ, might flip things dpeneding on container
emilio: if you're already compute CQ, you may need to create a box for asize that isn't your final one
emilio: you may clear the remembere dsize,
emilio: ...
TabAtkins: why would you clear it at that point
emilio: imagine without CQ matching, you don't have cis:auto
emilio: and once you know that you have a container of a given size, the box gets cis:auto
TabAtkins: easiest solution is to put cis:auto less conditionally
emilio: yes, I agree, but its a sketchy case
emilio: because it depends on how precisely you implement queries
TabAtkins: I think it's okay
TabAtkins: it seems ok for it to be less certain
TabAtkins: there's an easy solution: don't make it conditional in your styles
TabAtkins: so proposed resolution is that we add new condition to forget last remembered size
TabAtkins: which is if an element goes from not generating a principal box to generating one, we check cis and if it's not auto we forget the size
oriol: and for storing the size the element should have a box
Rossen_: any objections to first one?
<TabAtkins> s/???/and only storing the size if it has a principal box/
RESOLUTION: If, when an element goes from not generating a principal box to generating one, it does not have cis:auto, forget any last remembered size
TabAtkins: if an element doesn't have a principal box, we do not record a principal size
RESOLUTION: If an element doesn't have a principal box, we do not record a last remembered size
Rossen_: anything else on this issue?
oriol: nope
Agenda Bashing
github: https://
github: none
Color Contrast
<Rossen_> https://
<emilio> oh! I was looking at https://
premultiplication and undefined values
github: https://
chris: we have some stuff abou thow to convert colors
chris: first, nones get replaced by zero, bc you need a number to convert
chris: we also have text to interpolate, which says if one has none it takes the value from the other
chris: This avoids interpolating an achromatic to chromatic where it starts from an essentially random color
chris: These assume the space you're specified and interpolated in are the same
chris: If they're not, the conversion happens and you lose the info
chris: There's also the issue taht if you're using two different color spaces, what to do?
chris: If you have one in lch and one in hsl, do you copy the hue angle even if it's a different color?
chris: it starts not making sense unless the values you're comparing nones for are in the same color space
chris: then the question was, do we want this anyway?
chris: We started with saying tha tsometimes the channel was NaN
chris: and i was convinced to change it to none
chris: for consistency we added it everywhere, including in places no one asked for it
chris: that's extra testing, what's the point, etc
chris: it does help i nsome cases - if you have two in the same polor color space, it helps
lea: for none to resolve, you clearly need to convert to the same color sapce
lea: no question
lea: but there's a question of how to convert if both colors can have none
lea: i don't think having none everywhere created new problems, they exist even if it's only present in hues
lea: we need to figure it out regardless of if it's allowed in rgb, etc
chris: i don't think that transporting nones from one color to another when they're in another color space is *useful*, it's just the only thing to do from the spec text
chris: but it doesn't make a lot of sense
florian: do you have an idea of the solution
<fantasai> TabAtkins: I disagree that it doesn't make sense when they're in different color spaces
<fantasai> TabAtkins: if you take achromatic hsl into chromatic lch
<fantasai> TabAtkins: it's ...
<fantasai> TabAtkins: if you wanted to maintain intent of none behavior, I think answer is convert using the same rules, and remember the noneness and apply it on the other side of the conversion
<fantasai> miriam: that only seems possible with hue, though, right?
<fantasai> TabAtkins: powerlessness extends across conversions, right?
<fantasai> TabAtkins: if your hue is none and you convert to RGB ...
<fantasai> miriam: if your R, G, or B is none and you convert to hue, how do you do the conversion?
<fantasai> chris: to restate, you take which component names have none, then you do the conversion, and if that component name exists in the result ...
<fantasai> chris: if you convert hsl to lch, they both have hues
<fantasai> chris: but if you convert to profoto rgb, then no place to put it
<fantasai> TabAtkins: if you have zero chroma, should be same as ???
<fantasai> TabAtkins: so need to some manual mapping of what coverts to what as nones
<fantasai> TabAtkins: but e.g. polar to rectangular or vice versa wipes out the info
<fantasai> lea: even if going from hsl to lch, ...
<fantasai> lea: do we really want none^2/2?
<fantasai> TabAtkins: treat none as zero, convert it over, remember that the hue was zero, and then none it
<fantasai> lea: so would need to rmeember that hue in hsl and lch relate
<fantasai> TabAtkins: chroma and saturation should also map
<fantasai> TabAtkins: lightness should map
<fantasai> TabAtkins: if we want to maximize author friendliness of original intent, we need to set up a map of which channels can carry noneness into other profiles
<fantasai> lea: how would that work with custom profiles?
<fantasai> TabAtkins: probably can't do it with custom profiles
<fantasai> lea: another suggestion is to ditch none altogether and handle achromatic colors specially, same as how we handle transparent colors specially
<fantasai> lea: it's not as elegan
<fantasai> TabAtkins: only objection there is one of the uses for none is to handle things without chroma that do have a definite hue
<fantasai> TabAtkins: e.g. things like white and black, they have undefined chroma as well
<fantasai> TabAtkins: so they don't go from zero chroma into bright chroma red
<fantasai> dbaron: It would probably be useful to look the mapping from basically a table that shows what components in this color influence what components in ths other color
<fantasai> dbaron: for example, when convering hsl to lch, which components of hsl influence l in lch, etc.
<fantasai> dbaron: that might be useful
<fantasai> dbaron: it sounds like you want to transfer noneness in some cases beyond where it's strictly ok?
<fantasai> TabAtkins: less probably
<fantasai> dbaron: my intuitino is it would strictly be okay only where the inputs to the value were the ????
<fantasai> dbaron: I think
<fantasai> TabAtkins: might be, not 100% certain
<fantasai> dbaron: do more than that, but look at these tables and see what you want to do
<fantasai> dbaron: assuming you want to go down that path
<fantasai> chris: in genera, prefer ...
<fantasai> chris: but if I have a none alpha, and I convert to zero, and then I get transparent black, then ...
<fantasai> TabAtkins: we only premultiply during transitions right?
<fantasai> TabAtkins: idk if we've specifyed more clearly
<fantasai> chris: we have
<fantasai> TabAtkins: srgb is stored premultiplied?
<fantasai> chris: no, but when you interpolate you premultiply
<fantasai> miriam: but at that point you've already done the replacement
<fantasai> dbaron: is it possible you want the math for none to be different for different plcaes where you can put a none?
<fantasai> chris: I think good thing about Tab's proposal is you don't have to handle none through the entire calculation chain
<fantasai> chris: just put it back at the end
<fantasai> dbaron: was suggesting for alpha cases, but maybe you want to treat it as 1 rather than zero
<fantasai> TabAtkins: yes, when you do conversoin you turn it into a number, and that's already in the spec
<fantasai> dbaron: ah, I thought someone said it's always zero
<fantasai> chris: it is
<fantasai> TabAtkins: even for alpha?
<fantasai> lea: maybe alpha should be 1
<fantasai> TabAtkins: alpha isn't involved in color space conversions
<Zakim> lea, you wanted to answer dbaron
<fantasai> lea: for HSL and LCH, for example, I think basically all components influence all components, it's jus thtat some components influence some other components more
<fantasai> lea: hue and lightness still influence every component, because not 1-1 mapping
<fantasai> dbaron: that was my intuition, especially once you're converting between d50 and d65 then you're definitely
<fantasai> TabAtkins: my intention was to put a table of what components map across, only a handful to worry about
<fantasai> TabAtkins: all the hue-ish things, all the red-green-blue-ish things'
<fantasai> Rossen_: that's the action out of this issue?
<fantasai> TabAtkins: proposed resolution is we specify how none is carried across color space converstion to a related component on the other side
<fantasai> Rossen_: objections?
RESOLUTION: Specify how none is carried across color space conversion to a related component on the other side
<dbaron> (I do wonder how the stability of this relates to stability of other features in color 4.)
end
[agenda-wrangling[
]]
color-contrast()
specifying the contrast algo for color-contrast()
lea: since there are problems with every contrast algo known right now
lea: wcag2 is well known but with big problems
lea: theres' a study linked in the issue that shows it has something like 40% false results
lea: we suspect the reason in practice people don't realize how bad it is is because the colors you feed in aren't random, they're already "probably readable", so this is a second line of defense
lea: but once it's baked into a css algo it'll be used to generate color pairs without author intervention
lea: so if it's this bad, we can't use it
lea: otoh, APCA is positioned as a successor, but has issues
lea: Patent filed for it, unclear if it's usable
lea: weird note about licensing for web-based usages
lea: and the author has been rather difficult to work with, got a temp ban from w3c
lea: there are some other algos, chris probably knows more, they also generally don't produce great results
lea: So a) it should be possible to specify the algo specifically, rather than picking a default
lea: but even if we make it mandatory, that's not a solution, authors will learn an invocation and we won't bea ble to shift away
fantasai: So not shipping yet, but we stil lneed to add keywords
lea: not keywords, some kinda function since the levels are different fro each algo
<Zakim> chris, you wanted to react to lea
chris: re the patent situation
chris: At a certain maturity level you can lodge an exclusion
chris: In this case the patent was disclosed but not excluded
chris: the actual disclosure has some wording about license restrictions
chris: the patent policy does not allow such restrictions
chris: it needs RAND as well as free
chris: w3c patent people say it's unenforcable
chris: so currently it seems to be royalty-free
florian: the patent disclosure period has elapsed, and there was no exclusion
una: agree its 'important to speciy the algo
una: Wanna be able to use new algos in the future
una: Yesterday we also talked about letting the browser decide the auto algo
<dbaron> +1 to "should be able to specify the algorithm" (pending the details, which are in other issues!)
una: If wcag2 is the current default, we want the browser to be able to update to new ones
una: I think this can be done if there's no keyword (or auto?)
una: and a keyword means the user always wants a specific algo
una: seems like best of both worlds for usability and ability to be specific for contrast algo
una: tldr, should be able to specify contrast algo but also should be able to say auto
flackr: if the user has told the browser they have a color deficiency, can the UA take that into account and select a contrasting color based on it?
chris: people with atypical color vision don't ahve reduced contrast sensitivity
chris: with exception of red-on-black
chris: where they're actually better
<Zakim> chris, you wanted to talk about levels per algorithm
chris: re the "function instead of keyword", it's because the different algos use different numeric ranges
dbaron: responding to una
dbaron: maybe pushing a little outside this issue
dbaron: i am skeptical of anything where we ship something and later change what color is produced
dbaron: people will evaluate whether they've succeeded in their design not just by writing a contrast(), but also by looking at it and making sure they like it
<florian> +1
dbaron: if we go and change the colors later, people will probably be unhappy and pages will be broken
una: this is why i think it should be an option
una: but authors should generally be using a specific algo
una: but an option could be to let the browser decide, if they don't care as much about a particular combo
dbaron: i think once we ship the feature it'll be hard to change
color-contrast(unstable-algo-don't-use(1.0) ...)
florian: agree, we'll be dealing with less fuly-informed authors and teams, who will show the result to someone in approval who won't be caring about code, just result, and even if it's well-intended it might look wrong alter
florian: even if you told them it could be different that wouldn't matter
una: i'm afraid if we ship the current contrast algo people wont' update their code, adn pages will be stuck on bad results
miriam: I agree that's a useful use-case and what I'd expect
miriam: I think it would be useful to recommend to authors to put the algo into a custom prop so it's easy to update later
fantasai: given how broken wcag2 is, we're asking a lot of people to bake wcag2 into their page, and they won't update their code ever
fantasai: if wcag2 is the only thing we have to offer and we don't have the ability to auto-upgrade it
fantasai: then even 5 years from now people will be teaching that you use the wcag2 algo
fantasai: seems harmful to the web and we shouldn't be shipping it as a solution
fantasai: if we wanted to go down the auto-updating path and ship now, we could ship a more limited version that only gives white or black
fantasai: that's basic, but it solves a useful problem
fantasai: text is readable
fantasai: but for this issue, i think we do need the ability to choose an algorithm
fantasai: not just because we want authors to change what they use over time, but they also might actually want a specific algo, frmo design or legal perspective
fantasai: in the future we might have an excellent algo, but the laws in XYZ might require contrast that conforms to wcag2, I want to be able to say I want the color that conforms to awesome-algo and wcag2.
fantasai: So not just one algo, but 2+
fantasai: In the case of "most contrasty one", you can only ahve one, but in "reach at least this level" we can offer multiple
fantasai: I agree that using a function makes most sense so we can put appropriate scale info in
fantasai: so for this issue proposal is to add one or more algo functions to color-contrast() arg
fantasai: that accept the numeric level
fantasai: and this should be one of the prelude args
castastrophe: so much +1 to that
<lea> needless to say, +1 to everything fantasai just said
castastrophe: from design system perspective, people aren't likely to update this code frequently
castastrophe: so having generic name function with a default algo that we can update as we go along...
castastrophe: i don't know if we've changed defaults under the feet
castastrophe: we've done that a lot in design components, using the bad default for now until we figure it out
fantasai: i agree with that, but that's a different issue about the default
fantasai: for the purpose of this discussion it's assumed specified
castastrophe: was thinking about generic name
fantasai: name is color-contrast(), and you'd say like color-contrast(wcag2(...), black, white)
una: so this issue is about always requiring a specific color-contrast algo
fantasai: for now, we can discuss optionality later
una: def +1 on making it possible
una: i would like a world where it's not required
<fantasai> default algorithm
una: we'll discuss that later
chris: we can always relax it later if it's required now
fantasai: so proposal is we add to color-contrast() a number of specific-algo functions accepted as one of its arguments
dbaron: clarifying - saying the level is optional. does that mean if you don't give a level you get th emost contrasty choice, and if you do you get the first color that meets the level?
chris: yes, that's already what the spec says
Rossen_: objections
lea: what's the reason to get the most contrasty pair? why not just default to a reasonable level?
RESOLUTION: Allow color-contrast() to specify the algo and level, by taking an algo function as an arg
Rossen_: that's another issue, we'll discuss that later
una: what if none of the color values work?
chris: If you give a target and you run off the end of the lsit, you'll get either white or black, whichever is better
<dbaron> (what happens if algorithms disagree on whether white or black is higher contrast? :-P)
end
dbaron, they we use middle gray
color-contrast should distinguish fg from bg
github: https://
chris: Most of the algos, you give two colors, and they generally denote one of them is lighter and the other is darker
<dbaron> (when skimming the list of algorithms you referenced... I only saw APCA that cared which was fg/bg)
chris: At least APCA, and som eothers, requires you to say which is the text and which is bg, and if you swap you don't get the same number
chris: wcg doesn't care
fantasai: two proposals in the issue
fantasai: both of them are suggesting an over/under keyword
fantasai: one of them puts it as first arg color-contrast(over white, ...) meaning white is bg
fantasai: this follows same pattern as gradients
fantasai: downside is because arg is a color, it looks like part of the color list
fantasai: other suggestion was to use keyword as divider color-contrast(white under ...)
<fantasai> https://
fantasai: argument against was it felt a little backwards about which keyword you used
lea: the way the comma works, it tends to have higher precedence than just words
lea: so using a word to separate from a comma-seaprated list, it looks like you have one big first entry in the list
lea: But that's a problem with the current syntax
<dbaron> +1 to lea about comma versus space precedence
una: have we considered a slash rather than comma? like `red over / <color-list>`
una: seems to make it easier to separate
castastrophe: i love that solution
castastrophe: like the natural language read of "color over"
castastrophe: +1 to slash
<Zakim> dbaron, you wanted to suggest []
dbaron: suggest bracketed list
dbaron: grid tracks do this
<chris> +1 to a slash or some other way of grouping the list
una: my first thought was bracket list
<astearns> so `red over [<color-list>]`
una: just think it's more of a convention to use the slash
lea: issue with nested function...
TabAtkins: not function, just brackets around the color list
lea: oh, that's different
lea: we have a precedent of using slashes to separate parts within comma list, in backgrounds, so using it here with opposite precedence
<fantasai> TabAtkins: That was going to be my objection as well
<chris> looks like an array: white over [red, blue, violet]
fantasai: suggest we bikeshed over lunch
<bkardell_> 👉 red, black 👈
<br dur="1h 10m">
end
SVG Parameters spec
<astearns> github: https://
<una> dholbert: proposed feature to allow SVG images to be customized using CSS
dholbert: suppose you have a btn with an SVG image as its bg, and you want to be able to dynamically make it look different when its hovered/disabled/etc. or theme style
dholbert: the only way to do that now is to have several different copies of the SVG image
dholbert: theres no way to restyle an SVG image based on state
dholbert: Tab has a proposed spec via letting you specify CSS variables in-url as a part of the fragment identifier as a part of the SVG image's URL
<bramus> Spec URL: https://
dholbert: basic idea is in the fragment identifier you can specify the name of a CSS variable that will be exposed inside the SVG image
dholbert: you can set the initial value inside the SVG image
dholbert: normally css variables have no initial value, this changes that
dholbert: so the embedding document sets the initial value and embedding file can observe or change it
dholbert: if you're looking at the SVG file directly there is default
dholbert: use case = icons in Firefox toolbar
dholbert: we would like to be able to use it for icons of Firefox add-ons (to be able to hover them and have them respond to themes)
dholbert: right now our proprietary version we have for our own iconography is turned off bc we dont want add-ons to create icons
dholbert: we want to advance Tab's spec or something else if there are concerns
TabAtkins: In favor of adopting, but discussed interaction with @property's initial value, this will probably override
smfr: sounds similar to related discussion around allowing dark and light mode popping into SVG
smfr: sounds like this will work in SVG for both image and iframe
smfr: in iframes, SVG can exfiltrate this data that's pased in, but may be ok bc its uner c ontrol of parent frame
dholbert: one concern about cross-origin iframes
dholbert: worried about scenario where you have content that uses background property, expecting a color to be passed in, and the surrounding content passes an attacker control image (?)
dholbert: for that reason, i think we should avoid cross-origin iframe usage
smfr: agree - slightly concerning that an SVG could be made to load an external resource that could be part of a security exploit
<fantasai> smfr: so I agree with limiting to same-origin
dholbert: if you're using it in an iframe, there's already ways to do the same thing - if we spec this for images you would also expect it to work similarly in an iframe
emilio: not sure about whether it should override @property initial value
emilio: that has sensible behavior, using CSS-wide keywords
emilio: I'm not sure I'm a fan of passing stuff via the URL
emilio: i.e. if you have a bunch of icons, you can have a single place where you define the props you're passing down to them
emilio: you can put all your values in a CSS variable and pass those down, but I would have preference to having it be a CSS prop on the embedder element instead of as a part of the URL
TabAtkins: objection to that is it works fine on an image or iframe element, but its less likely to work well if you're specifying CSS background-images that expect property names to be passed
emilio: you cant use it in different URL values (cant pass different params to different URL values in the same element)
emilio: may not have come across that use case but I do believe its important
TabAtkins: I'd be fine with both if thats okay
emilio: feels like a bit of an abuse of the URL to stash things in the URL
fremy: I actually liked the oposing argument initially (im not sure why we want to restrict this to SVGs)
<fantasai> +1 fremy
fremy: I think people use variables assuming they are controlled by the page - if we are changing the opt-in, we're changing it from something author controls to something URL controls
fremy: initial value if you specify a keyword from a param or a URL, if that is specified, that would enabel the mechanism to use the externally supplied value - 1st benefit is that its an opt in
fremy: you explicity say this property is a color (for example) and you only get a color as a result
fremy: you can protect yourself against invalid syntax
TabAtkins: the premise that this opens you up for attack bc this changes your expectations for what syntax of a variable value will be is invalid usage and will screw up your property
TabAtkins: in that case, it would make something valid that you would rely on being invalid, but not int he normal case
fremy: you might be relying on the initial or fallback value and assume that itll never cause an issue
fremy: so thats a problem
TabAtkins: i suppose thats true, i was trying to avoid a double handshake bc its more work, but i'm not opposed to it if it makes the cross-origins concerns less
<fantasai> fremy++
<dbaron> (I think fremy was talking about var() functions that provide a fallback value.)
emeyer: as an author, i've run into the situation more than once that I've had to inline SVGs to do this same thing
emeyer: makes sense for performance reaons if you want to refer to an SVG only once
<fremy> (what @dbaron clarified is correct, I was mentioning authors using var(--non-existent, default) and hitting default right now)
emeyer: have mashed my teeth before about wanting to adjust the fill, as an author i would be very interested in having a CSS property way of saying "this is what I want to pass into this resource"
emeyer: i.e. im only transitioning <color> or <opacity> for this SVG -- these are the properties I want to pass in
emeyer: would be super useful for that
emeyer: however doesnt help with background SVGs and there needs to b e a way to address that as well
emeyer: very useful to be able to say what properties i want to pass (ie. `pass-property: all`)
TabAtkins: I propose we address emilio's and other concerns by saying we add a property that takes custom element names and potentially values to pass to the resource and any images used by the resource but also use the existing syntax in the spec
TabAtkins: you wouldn't be able to flag non-custom properties
TabAtkins: the values of arbitrary properties aren't sufficiently defined
TabAtkins: i.e. if you wanted to pass stroke value you have to define it
emeyer: as an author, that's a bummer but i understand the limitations
emilio: do you mean completely override?
TabAtkins: same name override
emilio: when fremy was talking about typing things, nothing stops you from doing that
emilio: just bc they get validated at computed value time, doesn't mean you cant type it
miriam: not understanding cross-origin security concerns
miriam: it seems to me custom properties are already considered insecure bc as a user i can change them
miriam: already dont allow custom props to be used in a way that can be a security issue
<Zakim> fantasai, you wanted to react to miriam
fantasai: the example that was given is: youre expecting to get a background color, someone passes a URL to an image they control, now its loading in your context with your permissions
dholbert: the part thats not possible is suppose this is embedded content from a secure site, they specify a bg thats different if you're logged in or not, have a css property if you're logged in, an attacker can identify if you're logged in if updating the property sends them a ping
astearns: i seem to remember we have extensions to the URL function and things we want to add to it in the future - do these play well ?
TabAtkins: yes, it does
astearns: would we need to add keywords?
TabAtkins: if we're doing a different type of parameter we can add keyword to express that
emilio: depending on whether we make this handshake or not, you can already pass a lot of data in the URL hash in the iframe
emilio: you could already right now use a custom property that isn't defined as such
emilio: I don't think its the most concerning of risks
emilio: on an iframe you can already script read the hash out and polyfill this for iframes right now
emilio: we'd need to evaluate the risk, how many cross-origin pages use custom props in a way that could be dangerous
emilio: if we double handshake it should be fair
emilio: still on the fence passing it in the URL hash vs. CSS function
emilio: URL hashes have meaning right now
TabAtkins: SVG syntax defines other things i.e. viewbox and media fragments in SVG hash
emilio: if there is precedent, it makes me more comfortable with it
TabAtkins: for it to be a problem you'd have to have a property with param
<dholbert> emilio: see https://
ydaniv: still trying to understand usecase of loading an image: the concern is if you specify the URL for an image it will be loaded by that image instead of an expected color
<fantasai> dholbert: in an iframe, not a problem for svg image
fremy: if you assume there's a security bug in the browser triggered by running a resource you'll still manage to trigger it
dholbert: any time providing external data into a document you have this potential issue
lea: 2 things - if we end up requiring a double handshake, can we jsut require it on cross-origin images and not everywhere?
lea: i think its important to find use cases of cross-origin images
<fremy> +1 on lea's point, CDNs are popular
lea: also - we need to make sure different uses of hash can be combined
<flackr> Just have to establish that it's uncredentialed right?
lea: hash is used for many things today
lea: need to preserve these capabilities, and in the future we might be using hash for even more different things - something to consier
chris: we already use viewbox and you can combine it with other hashes
TabAtkins: potentially only requiring double handshake for cross-origin is what i wanted to aim for as well
TabAtkins: your other point about cross-origin images - i definitely agree we should be able to adress cross origin svgs in some way
TabAtkins: uncredentialed
emilio: cross-origin SVGs arent the issue bc they can't do a lot of things, its cross-origin iframes
emilio: the problem is loading an SVG iframe not an SVG image bc its a different security model
fantasai: if its loaded as an SVG image its not a security issue -- if its loaded as an SVG iframe the security model is more relaxed and we'd have to have some cross-origin security
fantasai: emilio made a point that passing all this via URLs isnt great bc you have to repeat it every time for each image
fantasai: you arent able to have shared information across the multiple images
fantasai: the other bit of feedback was fremy - if we're doing this in a URL mechanism why are we restricting it to SVGs, why not expand it?
fantasai: do we want to design a syntax that can we used i other formats as well
fantasai: i.e. non-CSS resources
TabAtkins: this is a CSS feature, don't care about other resources
<ydaniv> <object> also problematic
fantasai: suppose word documents want to be able to interpret URLs and support media fragment syntax
fantasai: discussed limiting passing of parameters in cross-origin context when loaded as an iframe but not worrying about that if loaded as an SVG image
<dholbert> ydaniv: <object> is effectively a synonym for <iframe> from a capabilities/security-model perspective, IIUC
fantasai: emilio brought up issue if you're passing the parameter and setting the param vs. changing the inital value of the property in that document which are very different
yeah when we say "iframe" we generally mean "any of the elements that can load an active document"
fantasai: fremy brought up issue that the image should be recieving this info and be able to or required to type the incoming prop data
<lea> it's important that it sets the initial value, not just setting the property, so SVG can provide fallback values via var(--prop, fallback)
fantasai: so if you're trying to pass an image to a var thats expecting a color itll fail
astearns: you want us to adopt this as an editors draft?
dholbert: yes
dholbert: at a high-level, it seems nobody is objecting to the overall idea but we should add property syntax to more concisely address list of passed in custom properties
astearns: anyone have concerns and wants to address why we shouldnt adopt this?
<silence>
astearns: Proposed Resolution: Adopt this as an editors draft and start working on these issues
<fantasai> lea, I don't think that's an issue with setting initial value vs setting the value
TabAtkins: i'm happy to do it
TabAtkins: would like co-editor, dholbert volunteered as co-editor
<fantasai> lea, if the author defined the property with an initial value, they should get that value when the parameter is not set
fremy: last thought i had was we have to consider use case of single-origin: What happens if you also use the address in the address bar?
fremy: you could also introduce your variables in a website hyou don't control the origin
<fantasai> lea, the question is if the parameter overrides that initial value (and is represented by 'initial' keyword) or if it is just setting the property to a different value (like declaring it on root); I think the second is more appropriate
TabAtkins: you could just load an SVG directly, we dont know if its single or cross origin
TabAtkins: would consider that cross-origin for safety
TabAtkins: if its an SVG we don't care as much, if its an iframe, choose safety
https://
RESOLUTION: Adopt SVG params spec as ED
<dholbert> o/
color-contrast()
syntax
<fantasai> github: https://
<fantasai> Suggestion is color-contrast([over|under] <color> <contrast-algo>#, <color>#)
<fantasai> Suggestion is color-contrast([over|under] <color> <contrast-algo>+, <color>#)
<emilio> emilio: why a +
<emilio> fantasai: because they're space-separated
<emilio> una: example w/ colors?
<fantasai> color-contrast(over white wcag2(AA), blue, red, green)
<emilio> astearns: which of blue, red, green looks best over white
<emilio> una: I read white as foreground
<emilio> TabAtkins: proposition first because of gradients
<emilio> una: here I expect location + color value
<emilio> fantasai: we intended to read not as a param but a proposition
<emilio> bramus: why not background/foreground rather than over/under?
<emilio> astearns: that also has the same issue
<emilio> fantasai: we could do that
<emilio> una: I can see where it's coming from but I don't know...
<emilio> chris: not sure it has the same ambiguity
<dbaron> this is why I like color-contrast(white over [blue red green], wcag2(AA))
<emilio> lea: can be icons too right?
<emilio> chris: the algorithm is only about text
<emilio> +1 to dbaron
<smfr> i suggest color-contrast(blue, red, green over white using wcag2(AA))
<lea> +1 to fantasai
<emilio> fantasai: we generally put arbitrary long lists at the end
<emilio> una: I'd make contrast algorithm first
<emilio> ... so wcag2, white over blue, green, red
<emilio> TabAtkins: the algorithm could be typed first
<emilio> fantasai: everything before the first comma can be reordered
so you could write: `color-contrast(wcag2(AA) white over, red, blue, green)`
<emilio> chris: algo can specified against the target, what if you don't have a target contrast?
<lea> Could we maybe use a keyword before <contrast-algo>+ ? E.g. using <contrast-algo>+? color-contrast(using wcag2(aa) ...)
<fantasai> color-contrast(over white wcag2(), red, blue green)
<fantasai> color-contrast(over white wcag2(), red, blue, green)
<fantasai> or
<fantasai> color-contrast(over white wcag2(max), red, blue, green)
not `white over`, that would be invalid
specifically because the order you put it in reverses the meaning
<emilio> una: over before the value is hard to read
<emilio> dbaron: I think the bracketed list
(`over white` and `white over` read as exactly opposite things)
<dbaron> (because they are opposite things!)
<emilio> dbaron: I think the bracketed list was nice but some people don't like that
<emilio> fantasai: I think it should parallel gradients
<emilio> lea: also color-mix()
<fantasai> emilio: given confusion about ordering of stuff, can we choose some fixed order?
<fantasai> emilio: if you can reorder this stuff, we are getting confused
<fantasai> TabAtkins: preposition and color have a fixed order
<fantasai> TabAtkins: but algorithms can be moved around
<fantasai> emilio: why do we want to specify multiple algorithms?
<fantasai> T
<fantasai> TabAtkins: example was, if tomorrow someone comes up with the best contrast algo that works perfectly
<fantasai> TabAtkins: but you also need to satisfy WCAG2 for legal reasons
<fantasai> TabAtkins: you will need to specify two algorithms
<fantasai> chris: 2 algos or multiple?
<fantasai> TabAtkins: 1 or more
<fantasai> TabAtkins: you have to pass all the thresholds
<fantasai> TabAtkins: if they disagree on white or black, we prioritize the first specified algo
<fantasai> una: Wouldn't that give us the same problem with color list last?
<fantasai> fantasai: they're not comma-separated, and you will likely only have one or two
<fantasai> una: could space-separate color list
<fantasai> TabAtkins: that would prevent us from adding any parameters to the list, which I don't think we want to do
<astearns> I think I’d prefer `white background` and `white foreground` meaning the color is in that slot
<emilio> astearns: I'm not happy with the proposition, I'd rather have a noun phrase
<emilio> ... because it's not misinterpretable
<emilio> fantasai: do we want to go for the full word of just fg/bg?
<bramus> had same concern as astearns
<emilio> una: don't mind that
<lea> not abbreviations please!
<emilio> ... I think it's more readable because color is first
<emilio> bramus: background / foreground is clear
<emilio> clearer to me*
<bkardell_> color-contrast(black foreground wcag(), red, blue, yellow) ?
<emilio> una: if we're having foreground/background what about if you have a border or so?
<bkardell_> is that the suggestion?
<emilio> fantasai: I think you pick your contrast algorithm and pick something
<emilio> fantasai: usually it's not equal amounts of colors
<emilio> fantasai: so that's what you'd use as background
<emilio> lea: given most contrast algos don't distinguish bg/fg, could we have a default?
<emilio> ... so that we don't need to specify?
<emilio> chris: so the first one can be one of them?
<emilio> TabAtkins: what about the algo that does care?
<emilio> ... why not make it gramatically required? Some algos don't care numerically but
<chris> wht nt uz abrvnz
<emilio> lea: also can we not do bg/fg (abbreviations)?
<dbaron> dbaron: why not make it grammatically required (just for the algorithms that require it)?
<emilio> ... also can we have a keyword before the algorithm so it's easier to read?
<emilio> TabAtkins: we usually don't do that unless needed for disambiguation
<emilio> fantasai: as long as it doesn't prevent reordering
<emilio> TabAtkins: proposal is a keyword to separate the algos from the rest of the stuff, like put the keyword "using" in front or so
<emilio> fantasai: we don't need it so I don't think we should add it
<emilio> TabAtkins: agreed
<bramus> `color-contrast(<color> [background|foreground] using <contrast-algo>+, <color>#)` then?
+1
<emilio> dbaron: what I was suggesting is to require foreground / background only when using an algorithm that needs it, otherwise optional
<emilio> lea: that's what I meant
<emilio> TabAtkins: so it'd be grammatically invalid to not provide it?
<emilio> dbaron: yes
color-contrast([ [ <color> [background|foreground] ] && <contrast-algo>+ ], <color>#)`
<emilio> una: related to the following question, auto would always require it
<emilio> florian: some algos require foreground/background, are there other things?
<emilio> chris: not so far
<emilio> ... there's a proposal to add a third color which is the surround
<emilio> florian: e.g. to get a numerical value of wcag you don't need font-size, but AA/AAA does
<emilio> ... does that become an input?
<emilio> chris: that's a good question and I think background/foreground is reasonably special
<emilio> florian: I suspect font-size is quite special too?
<emilio> TabAtkins: you can specify the level as well
<emilio> florian: if you know the font-size
<emilio> fantasai: since the algorithm takes params we could communicate there
<emilio> lea: that'd make the grammar harder to define that conditional-requirement
<emilio> TabAtkins: we'd define it in prose
<emilio> TabAtkins: a bit annoying
<emilio> lea: if we use a default we don't have that problem
<emilio> TabAtkins: yeah but that means that people will forget and get confusing answers
<emilio> lea: maybe mandatory everywhere?
<emilio> TabAtkins: yeah
<emilio> fantasai: I think that'd be fine
<Zakim> dbaron, you wanted to disagree about mandatory everywhere
<emilio> dbaron: I think right now there's only one algo that needs it and is still in flux
<lea> +1 to TabAtkins
<emilio> TabAtkins: I think intuitively, the fact that a lot of algos don't use it is clear that they are garbage, because changing fg and bg significantly changes the perception of contrast
<dbaron> ok, makes sense
<emilio> lea: can we resolve about making bg/fg mandatory?
<emilio> bkardell_: lots of the examples colors are just color names
<emilio> ... part of the reason we're doing it at runtime is that you might not have known inputs
<emilio> ... I think the complex case is when you don't have a single color background
<emilio> ... e.g. if you look at the screen what the color name should be?
<emilio> TabAtkins: nobody has put down an algorithm to do that easily
<emilio> bkardell_: I think I disagree
real example, say a button: `color-contrast(lightblue background using wcag2(AA), royalblue, navy, darkblue)`
<Zakim> fantasai, you wanted to say I'm less happy about typing "background" every time
<emilio> TabAtkins: in any case it's a much more complex problem
<lea> una: `using` was rejected
<emilio> fantasai: I'm happy to make things mandatory, but I'm against adding more boilerplate
<emilio> TabAtkins: that's why I was going for fg/bg
<emilio> lea: over/under aren't that much timing
<emilio> typing*
<emilio> TabAtkins: less clear
<emilio> florian: front/back?
<emilio> fantasai: that'd work for me
<emilio> una: issue isn't the naming, was the position
<emilio> astearns: proposed resolution is that the first part of the syntax is color with front/back, applying to that color
`color-contrast(lightblue back wcag2(AA), royalblue, navy, darkblue)`
<dbaron> do we want to consider fore/back rather than front/back?
<emilio> fantasai: as long as they're reorderable?
color-contrast( [ <color> && [front | back]? && <algo>? ], <color># )
<lea> TabAtkins: <algo>+, not ?
dbaron -- I think that `fore` might be more confusing
<emilio> smfr: I think having the fore/back not applying to the chosen colors
yes, right, typo on my part
<emilio> ... logically I'd think "the color I wanna choose is the front color"
<emilio> astearns: so you'd like the modifier in the color list?
<emilio> florian: we had the same problem with gradient direction, to top left, or from top left?
<emilio> smfr: I kinda prefer under/over but we rejected that so...
<dbaron> I told you smfr wanted prepositions :-)
<emilio> TabAtkins: curious about why you think over/under apply to a different thing than front/back
<lea> yeah, I also liked that over/under read more like natural language :/
<emilio> smfr: because it's like writing an english sentence, over <foo> I can remember
<emilio> una: that's why I preferred using too
<fantasai> 1. over/under
color-contrast{start: <color>, position:[front|back], choices: <color>+ }
<fantasai> 2. front/back
<dbaron> IMO, "white front" is natural language but "front white" is not.
<fantasai> 3. something else
<florian> 2
<emilio> lea: what were arguments against over under again?
<emilio> chris: confusing order
<emilio> una: you could reorder the first three values
<emilio> fantasai: we wouldn't allow to reorder that
<smfr> i like ‘over|under <color>’
<emilio> +1 smfr
<emilio> fantasai: in gradients we do the same
<lea> +1 smfr
2
<lea> 1
<bramus> 2
2
<emilio> 1
<fantasai> 1
<astearns> 2
<chris> 2
<miriam> 1
<smfr> 1
<dbaron> abstain
<bkardell_> abstain
<emeyer> abstain
<dholbert> abstain
<emilio> una: core issue is do we want to make sure it's required?
<dbaron> (BTW, with my [] suggestion there's an only-over option where you could write "green over [red white blue]" or "[red white blue] over green".)
<emilio> lea: we concluded it should be required
<emilio> astearns: no consensus
<emilio> TabAtkins: proposal to keep keywords undefined
<emilio> ... poll authors then come back
<dbaron> (6 votes for #2, 5 votes for #1, 4 abstain... since some people voted with /me and weren't logged)
RESOLUTION: Keywords undefined
RESOLUTION: Whatever keywords for foreground/background whatever they are are required
RESOLUTION: No keyword ahead of algorithm list
<emilio> lol
<emilio> TabAtkins: next is comma separation between color list and the rest
<emilio> chris: if I have `over white, green, red, blue` it looks confusing
<emilio> chris: I don't think it makes sense
<bkardell_> fantasai: I had some lag, but yes - what smfr said :)
<emilio> chris: that'd look awful
<emilio> TabAtkins: it'd have the keyword before
<emilio> fantasai: agree it's a problem
<emilio> dbaron: same
<emilio> florian: not sure what's better
precedence for / is that it's weaker than commas when mixed
we have several properties using that
<emilio> lea: right, alternatives are not better
<emilio> astearns: proposal to punt
<emilio> ... (until keywords are decided)
<smfr> +1 to lea
<emilio> lea: right now color-contrast sounds like it returns a contrast, not a color
<dbaron> I like contrasting-color()
<fantasai> contrast-color()
<emilio> ... can we change the name? color-contrasting / contrasting-color?
<emilio> fantasai: I don't like adding ing
<emilio> lea: I think contrast-color works fine
<emilio> una: I like it
<miriam> +1
<emilio> astearns: objections?
<ydaniv> +1
<emilio> chris: I think we had them and then we harmonized with color-*
<emilio> ... but agree it's better the other way
contrast function name
https://github.com/w3c/csswg-drafts/issues/7557
<emilio> github: https://
<lea> github: https://
RESOLUTION: Rename to contrast-color() (discussion in #7359)
default algorithm
<fantasai> github: https://
<emilio> fantasai: (1) use UA default that can change over time, (2) wcag2 forever, (3) always required
<emilio> (4) mandatory for now, default later
<emilio> (5) changing default, but only without candidates, so either white or black
<emilio> fantasai: so you don't have these more subtle color distinctions
<lea> so it will basically be only contrast-color(over var(--color))?
yes
<emilio> ... we can use wcag2 by default now and change it, without more subtle changes
<emilio> chris: I disagree with lots, first that white / black are not much change
<emilio> florian: it won't chose between brand color and something else
<emilio> chris: wcag2 default is problematic. we already have a formal objection'd formally object to that
<dbaron> s/I'd formally object/We already have a formal objection/
<emilio> TabAtkins: to get around that we can leave the algo undefined to UA determination
<lea> if we can also provide the algorithm, we've just resolved #7345
<emilio> florian: It's probably good to not say it's WCAG, which means people wouldn't rely on it for legal reasons
I love the usefulness of `contrast-color(over var(--color))`
<emilio> astearns: so with option five you it's invalid if you provide candidates?
<emilio> fantasai: yes
<emilio> astearns: if we go for (5) we also go for (4) when we have candidates?
<emilio> fantasai: yes
<emilio> lea: wanna point out since we are about to resolve in the simplified form, if we can also provide an algo, can we resolve #7345 first that allows us to avoid candidates?
candidates optional in contrast-color()
<fantasai> github: https://
<emilio> fantasai: proposed resolution is that candidates are optional and default to white and black
<emilio> una: sounds good, it simplifies the function. We've talked about future-proofing and verbosity I think this is perfect, and I think "I just want good contrast" will be a large use case
emilio: wht happens if you have one candidate?
TabAtkins: you just get white/black if you fall off the list
<lea> emilio: if that passes, it's returned, otherwise you get white or black
RESOLUTION: Make candidates optional, use white / black if there's no available options that pass the contrast test
default algo
<fantasai> github: https://
<emilio> una: I really like having no algo specified, just the value you want contrast against
<fantasai> emilio: if you fall off the list, do you implicitly end up with white and black and if white passes contrast testing...?
TabAtkins: No, you take the one that's more contrasting
<fantasai> chris: They're not tried in order, just either give me white or black
<fantasai> TabAtkins: if you want to specify the order, give a list
<lea> emilio: this is why it's not unfortunate that we're maximizing: color: color-mix(contrast-color(over var(--color), var(--color) 20%);
<emilio> dbaron: open to default in the future right?
<emilio> TabAtkins: yes
<dbaron> (I was responding to a statement of the proposed resolution that wasn't minuted.)
<emilio> florian: so options are either contrast-color(over ...), or contrast-color(over foo <algo>, a, b, c..) right?
<emilio> astearns: objections with going with (4) + (5)
<emilio> Proposed: We have an unspecified default, the best available to the UA, which gets updated, only when there aren't any candidates. If you include any candidates, algorithm is mandatory
<fantasai> contrast algorithm is optional, and defaults to the best available to the UA (which gets updated over time), if no candidate colors are specified
<fantasai> yes
RESOLUTION: We have an unspecified default, the best available to the UA, which gets updated, only when there aren't any candidates. If you include any candidates, algorithm is mandatory
end
<emilio> <br size=20min>
color-contrast()
transparency
<fantasai> github: https://
<emilio> lea: current draft doesn't mention transparency
<emilio> ... most contrast arguments ignore it
<emilio> ... if fg is semi-transparent some algorithms make it work, otherwise ignore it
<emilio> ... when you have a range of contrasts there's no answer
<emilio> ... one option would be using the minimum contrast
<emilio> ... for wcag there's work to compute min/max contrast
<emilio> ... if foreground is transparent but bg is opaque you can alphablend but in the bg case it's not so clear cut...
<emilio> florian: for fg there's an answer, For background, what authors should be supplying is not the possibly semi-transparent background color of the element, but rather the composited background against which the foreground will be seen. It's not necessarily easy for authors to figure
<emilio> dbaron: first intuition is that having a bg that's not opaque should be a syntax error
<emilio> ... wrt contrast ranges, maybe alpha-compositing bg with alpha over foreground with no alpha might give you the minimum contrast, but might vary per algo
<emilio> fantasai: was gonna suggest the same, composite semi-transparent bg over foreground color would give you the worst case scenario
<emilio> ... if both semi-transparent it gets extra-exciting, maybe composite against black?
<emilio> lea: not sure how we'd specify this so that semi-transparent is invalid
<fantasai> TabAtkins: in prose
<emilio> lea: compositing on black might give you the max contrast
<Zakim> chris, you wanted to wonder about mixed domain backgrounds
<emilio> chris: if you have stuff like iframes that are transparent, does that allow you to find the background behind the iframe
<emilio> TabAtkins: not doing that, there's no way to know what the color will be used on
<fantasai> emilio: Making it invalid at syntax time sounds nice, but not possible in the presence of currentColor
<fantasai> emilio: Offhand, I don't expect this to be a super common thing to hapen
<florian_irc> what that is, but that's the only thing that makes sense. The color-mix function might help./
<fantasai> emilio: doing what fantasai and dbaron suggested seems a reasonable compromise to me
<emilio> dbaron: what I was suggesting if they are both not opaque was to take the foreground, modify alpha to be 1, then composite the bg on top
<florian> s_what that is, but that's the only thing that makes sense. The color-mix function might help./__
<emilio> ... then compare fg composited against that
<emilio> ... that was my intuition for the worst case
<emilio> fantasai: [sanity-checks that]
<florian> s_to figure_to figure what that is, but that's the only thing that makes sense. The color-mix function might help._
composite fg over bg over (fg with alpha set to 1)
<lea> no need for color-mix(), relative color syntax can do that: lab(from foreground l a b / 1)
<emilio> dbaron: new_bg = alpha(fg, 1.0); bg = composite(bg, new_bg);
<fantasai> emilio: the goal is to make both opaque
<fantasai> emilio: so you need to composit on top of the new background that's opaque
<emilio> dbaron: this is sort of speculative, we should work it out in an issue
<emilio> astearns: well this would be the issue
<emilio> dbaron: underlying question is "does this give you the worst case?"
<emilio> lea: intuitively it seems like it might
<emilio> fantasai: so generically, we have a canvas that is the foreground with alpha 1, then we draw the background, then the foreground
fg compared against (bg on top of opaque fg)
<emilio> ... if everything is opaque then it all works out
<fantasai> s/works out works out easily, otherwise you need to do some compositing/
<emilio> florian: sounds like it gives a , not sure it's a great answer
<emilio> TabAtkins: how can you get a less contrasting color with the foreground than the foreground itself
<dbaron> It's probably not the absolute minimum for all algorithms, but it's probably close.
<fantasai> emilio: I'm not sure it'll be the least contrasting color
<fantasai> emilio: the least contrasting option would be the compositing the background with the foreground maxed out
<fantasai> TabAtkins: that's the suggestion
<fantasai> emilio: but that's not quite the same
<fantasai> emilio: the least conrasting option with the foreground is the foreground itself
<fantasai> emilio: okay, yeah
<fantasai> emilio: if you apply the background, then, yes, that should give you the worst. Nevermind
<emilio> dbaron: I'm not sure it's the least contrasting. if you state it like fantasai where you have three layers
<lea> FWIW this was the research I had done 10+ years ago on min/max WCAG contrast: https://
<lea> I can't at a glance tell if the formula for min contrast is what dbaron is proposing
<emilio> dbaron: the contrast aren't uniform with blending
<emilio> ... so I think there's variations where this might not work
<lea> +1 fantasai
<emilio> florian: other concern is that if we manage to find the least contrasting situation, we might fall back to black / white unnecessarily, as what's behind the semi-transparent background might not at all be that worse case scenario
<emilio> fantasai: I think dbaron's proposal is the best option, I propose to spec it and let people tell us why we're wrong
<fantasai> emilio: I think what I was thinking is along the lines of what dbaron thought earlier
<fantasai> emilio: the worst contrast is when the blend of the background color and the color below it is exactly the foreground
<fantasai> emilio: using the foreground color itself doesn't give you the worst one
<fantasai> emilio: suppose you have a red foreground, opaque red
<fantasai> emilio: and you have semitransparent white bg
<fantasai> emilio: can you get a way such that compositing semitransparent white will end up red?
RESOLUTION: When calculating color contrast between pairs of semi transparent colors, if the background is opaque, UAs should alpha blend the foreground on the background and use that as the foreground color. If the background is also semi-transparent, it would be alpha blended first with an opaque version of the foreground
<fantasai> TabAtkins: a medium gray foreground, half-transparent black background, clearly the worst contrast is putting it over white
<fantasai> TabAtkins: putting over medium gray is not as bad
<fantasai> emilio: it's probably good enough
<fantasai> florian: could also just put white or black as the backdrop, depending on color scheme
<fantasai> emilio: [missed]
<fantasai> emilio: Gecko does have some contrast checks for selection
<fantasai> emilio: what we do in the case of semintransparent backgrounds is using the default background
Notably the worst case here is 50% transparent bg. as it gets more or less transparent, the answer becomes easier
<fantasai> emilio: basically composit with canvas, can guarantee it's opaque
<fantasai> emilio: simpler answer, maybe more correct
<fantasai> TabAtkins: how about we resolve for now that we'll adopt this approach with a color TBD
<fantasai> TabAtkins: could still use examples and thought
RESOLUTION: Amend previous resolution, the canvas color in previous resolution is TBD
<dbaron> (rather than opaque version of foreground)
RESOLUTION: (rather than opaque version of foreground)
[css-color-6] Behavior of color-contrast() when no level is specified
<emilio> github: https://
<emilio> lea: r/n per spec if no level is specified (wcag()), behavior is to get the most contrasting color, vs if you provide a level (wcag(aa)) you get the first that passes
<emilio> ... I think that's a bit inconsistent, ignores preference order
<emilio> ... not sure what use cases it covers
<emilio> ... and is inconsistent with general use of functional notations where if you omit something it defaults to something
<emilio> ... so basically magic
<emilio> fantasai: no magic
<emilio> lea: it's magic in the sense that there's no way to pass an argument to do the same
<fantasai> emilio: I think I agree, either choosing a reasonable default or making the level mandatory are both reasonable options
<fantasai> astearns: ...
<emilio> astearns: are the levels fixed?
<fantasai> emilio: they depend on the algorithm
<emilio> astearns: seems slightly better in the sense that if we add a level behavior doesn't change?
<emilio> TabAtkins: not really, if we're choosing a default. I prefer making it mandatory because the level depends on your use case. People might not understand them but at least it's affirmative action, not "I wrote the shortest thing"
<emilio> chris: You increase contrast so that legibility improves and reading speed improves, up to a point, so there's an argument to be made that there's an optimal contrast
<emilio> fantasai: but optimal isn't gonna be any of the minimums that we have here
<emilio> ... I think the behavior of picking the max is reasonable, and if we want a keyword we can add it
<emilio> ... and there are use cases for having a bunch of colors and picking the best, and define what an optimum contrast is not feasible
<emilio> ... so I'd rather stick with the max behavior, and if we want a max keyword I won't object
<emilio> chris: I don't think you really responded to my point
<emilio> fantasai: if you have infinite colors to choose from I agree with you, but we're choosing between two or maybe three colors from the author
<emilio> miriam: does this mean that on this case we won't ever fall back to white / black/
<emilio> *?
<emilio> fantasai: yes
<emilio> emilio: if you don't specify any color you pick between white / black right?
<emilio> fantasai: yes, if there's any color you choose between them
<emilio> dbaron: I think we're discussing two things
<emilio> ... one is that the syntax is confusing because it switches between modes
<emilio> ... the other is that the other mode is not useful
<emilio> ... one way to fix the former might be to have two different functions
<emilio> fantasai: I'm not sure they're sufficiently different to warrant 2 different functions
<Zakim> lea, you wanted to say that people with dyslexia actually find very high contrasting text *harder* to read
<emilio> ... I'm fine adding a max keyword
<emilio> lea: people with dyslexia actually find very high contrasting text harder to read, so more contrast might not be better
<emilio> ... but as una has mentioned already, authors not always want the highest contrast
<emilio> ... they have preferences
<emilio> ... also I don't think authors will provide only a couple colors, but will choose a span of colors
<emilio> ... also it was pointed out that this mode is a bit inconsistent when where you specify a level you can always fall back to white and back
<emilio> ... like if you have blue and dark blue
<emilio> fantasai: that might be what you want if your color is not for text
<emilio> lea: but I think that default is not reasonable
<emilio> fantasai: if the author doesn't want maximal contrast they should not pass white/black to the list, this default always chooses one of the provided colors, is easy to understand
<emilio> ... you might not want the maximum contrast, but wanting the maximum inside a set is reasonable
<emilio> ... and getting the first that passes the bar might not always be what you want
<emilio> astearns: if we go with what's specced now that's a lot easier to understand than picking a level and find a reference, and see why you're getting a particular color
<fantasai> emilio: I think we're in agreement that the mode that fantasai describes is reasonable
<fantasai> emilio: there are use cases for that, nobody's disagreeing right?
<fantasai> emilio: the question is whether it should be the default
<lea> wcag2(max) sounds like it gets you the maximum wcag contrast (21). Perhaps it should be a preamble modifier
<fantasai> emilio: It's a bit weird that you pass an argument and it changes, maybe we pass the algorithm as a keyword rather than a function? But I guess some algos want parameters...
<emilio> florian: agree with fantasai that it's a useful behavior. I think either this is the default mode when there's no threshold, or there's no default and you must specify a threshold or invoke the mode with a keyword
<emilio> ... having something else be the default feels very arbitrary and possibly wrong
<fantasai> +1
<emilio> emilio: agree
<emilio> lea: one thing I pointed out in irc is that if we make it a max argument looks like it gives you a maximum contrast (21) which you can always get with white and black
<emilio> ... should it make a different modifier?
RESOLUTION: no change
<emilio> fantasai: I propose we keep it the default and if we find a good syntax for that we do that
Ranges of Candidate Colors
<lea> github: https://
<emilio> lea: there's a discontinuity between how designers design UI and how the contrast-color() function works
<emilio> ... they often have a base color and adjust coordinates (usually lightness) to get sufficient contrast
<emilio> ... right now it's possible but you'd need to provide a bunch of colors to simulate a range
<emilio> ... it'd be nice if you could simplify that usage
<emilio> ... not sure if it would need special syntax, or even if we want to do this
<emilio> ... we might want to punt on it and do it only if people actually do this
<emilio> dbaron: when you suggested syntax, before you said gradient my initial reaction was to use the interpolation syntax
<emilio> ... I think you could reuse the interpolation syntax without specifying the end
<emilio> ... it's basically gradient without direction / radial stuff
<emilio> ... other thought is that this is difficult to explain with multiple contrast functions
<emilio> ... if you specify something that's a range of color we specify the order in which you process them in
<emilio> lea: I think before we dive down into details we should decide if we want to pursue this
<emilio> ... what that syntax would look like is secondary
<fantasai> emilio: I think I'd rather punt on it for now
<fantasai> emilio: there are a bunch of things to figure out, e.g. what are the steps you use for lightness?
<fantasai> emilio: what's the resolution of all the colors you try?
<fantasai> emilio: you may try 1000s of colors to find somehting
<fantasai> emilio: seems a bit unpredictable, perf-wise
<fantasai> emilio: I guess you can binary search, maybe?
<astearns> evaluating all the colors for multiple algorithms seems expensive
<fantasai> emilio: assuming contrast is alwasy increasing or decreasing
<fantasai> emilio: so unless we find ppl actually doing this,
<dbaron> yeah, I think you can't assume that contrast is always increasing/decreasing
<fantasai> emilio: if you pass 1000 colors, then worst case you evaluate 1000 colors
<fantasai> emilio: For now I'd rather defer this
<fantasai> emilio: I'd rather get the bits we know we want right, and then if we want to extend, we can always do it
<emilio> TabAtkins: you can't assume contrast is monotonic if you interpolate hue
<emilio> ... so sampling frequency becomes important
<lea> I actually agree
<emilio> ... so I say we punt for now
RESOLUTION: punt for now, revisit later
<lea> github: https://
<emilio> github: https://
color-contrast() with automatic continuous lightness adjustment
<emilio> github: https://
<emilio> lea: so this is similar to the previous problem we discussed where you have a given color and you want to lighten or darken it enough so that you get decent contrast
<emilio> ... I think in this case the contrast does tend to be monotonic
<emilio> ... so you might be able to binary search
<emilio> ... we could punt as well for now
<emilio> TabAtkins: I don't think this one is problematic but might be worth punting for the moment
<emilio> miriam: I think this is useful, it's something that a preprocessor can do in a bunch of cases, but it's ok if we delay it
<emilio> astearns: people want to ship contrast-color() so the simpler the better for now
<fantasai> emilio: was going to mention, what we use internally for a lot of these use case
<fantasai> emilio: it's not lightness, luminance more generally
<fantasai> emilio: in order to replicate a default color palette with an arbitrary accent color
<fantasai> emilio: we have a function to adjust the function to a given luminance
<fantasai> TabAtkins: that's just relative color syntax
<fantasai> emilio: I think unless we have any pressing issue, I vote to punt
<fantasai> emilio: this seems extremely similar to what we discussed
<fantasai> emilio: so maybe punt
RESOLUTION: Defer for now
end of contrast issues
Allow <input> and <select> to be sized by contents
<emilio> github: https://
<emilio> lea: so this is related to the <textarea> issue
<emilio> ... this is about sizing the width of <input> and <select> of form controls to match the contents
<emilio> ... it's insanely difficult to do right today
<emilio> ... you need to use a span to measure, or measure scrollHeight if you have overflow, etc
<emilio> ... you don't know how big the icons in date / time / number inputs
<emilio> ... it'd be nice to size these based on their contents
<emilio> ... it'd be elegant if you could just say "width: fit-content" or so
<emilio> ... not sure if that's web-compatible
<emilio> ... a lot of the issues re. <textarea> are not present
<emilio> iank_: not strictly true
<fantasai> emilio: It's not hard to implement
<fantasai> emilio: but there's a lot of different considerations
<fantasai> emilio: for example, the most obvious one after going through this code, is if you odn't want to size it to the size of, for example, autofill suggestions
<fantasai> emilio: if you multiple options to choose from, right now when you hover over the option we preview it
<fantasai> emilio: but we dont' expose that to the page until you actually interact with it
<fantasai> lea: I think it's fine to ignore autofill
<fantasai> lea: never seen a use case that involved passwords
<emilio> dbaron: few thoughts, one of them is "what counts as contents": does placeholder count?
<emilio> ... one of the other things you might run into is that for text inputs and you wanna resize as people type you might find the performance of it to be suboptimal
<emilio> ... and that's gonna be a little unpleasant
<emilio> ... but I guess people will deal with it if that's what they want
<emilio> iank_: this has the same issue as textarea
<emilio> ... where min/max-content are used directly within the flexbox algorithm
<emilio> ... I don't think we can ship anything that changes min-content in these
<emilio> iank_: sounds like what emilio implemented yesterday would've changed all of those
<emilio> fantasai: you mean the automatic minimum size?
<Zakim> fantasai, you wanted to ask if it's min-content or the automatic minimum size
<emilio> iank_: also the content size if you use flex-basis: content
<emilio> ... also somewhere else
<emilio> fantasai: I think we could say that the automatic minimum size is whatever size we currently get from html attributes
<emilio> ... but if you use min-width: 0 then you won't be using ams
<emilio> ... and then width: max-content to remove the influence of automatic preferred sizes
<emilio> ... and these are both things that you need to do and shouldn't cause a compat issue
<emilio> fantasai: I'm proposing changing the meaning of max-content
<emilio> ... so there's a preferred size
<emilio> ... currently entering flexbox via ams and automatic preferred size
<emilio> ... these are tied to keywords, `min-width: auto`, etc
<fantasai> emilio: but in terms of actual behavior changes
<fantasai> emilio: basically, how do you change the min- or max-content
<fantasai> emilio: what I'm imagining you're saying is, make this change to the max-content size
<fantasai> emilio: so max-content on an input follows the content
<fantasai> emilio: but in flexbox either special case and not call it max-content for inputs
<emilio> fantasai: flexbox doesn't use max-content, it works in terms of contributions
<emilio> iank_: it does work in terms of max-content
<emilio> fantasai: it only does if width is auto, right?
<emilio> iank_: so to opt into this you'd need to change min-width and flex size
<emilio> fantasai: because of ams is tied to this you need to remove it in min-width and so
<emilio> iank_: I agree it'd work but I don't think that'd be a great solution, we already have compat issues with <input> using min-content and stuff like that
<fantasai> emilio: so you're proposing for auto size to be as-is
<fantasai> emilio: and split max-content from preferred size
<fantasai> emilio: which right now are the same
<fantasai> emilio: I'm not a huge fan of adding more intrinsic width types, but maybe it's not too much of a pain
<emilio> iank_: when we were changing the min-width/height: auto behavior, we found that lots of people that set min/max-width: 0
<emilio> ... also common to use flex: 1 1 0 and so
<dholbert> s#min/max-width:0#min-width/min-height#
<emilio> ... and there you'd change a lot of stuff, seems scary
<Zakim> lea, you wanted to react to placeholders
<emilio> lea: Wanted to say that placeholders should be considered for calculating the width
<emilio> ... it's implemented as shadow dom descendant
<emilio> ... but also what if we say that this only works if min-width is >0
Also very hesitant to override any of the existing content size keywords for this, but am happy to have a new keyword (or two?)
<emilio> ... in most cases you do need to specify min-width of zero
<emilio> ... it's user-hostile to not have that
<emilio> fantasai: it's user-hostile to do that ~everywhere
<emilio> ... but we can't do that because it'd be discontiguous
<emilio> nous*
<emilio> fantasai: we could introduce a new max-content-no-i-really-mean-it
<emilio> ... but I'd rather avoid that
<bkardell_> this-is-my-final-answer-max-content
<emilio> TabAtkins: I'd rather do that, I share iank_'s concerns
<fantasai> emilio: for select in particular, I don't think it's so problematic
<fantasai> emilio: because it's almost never empty by default
<fantasai> emilio: but for input it seems very sketchy
<dholbert> `max-form-content` or `max-field-content`?
<fantasai> emilio: I also recall Firefox, in terms of select intrinsic sizing
oooh yeah i like dholbert's ideas
<fantasai> emilio: because we actually consider the option styles
<fantasai> emilio: I fixed that
since these keywords won't mean anything for non-form controls
<fantasai> emilio: it was not an easy change
(we'll just define them to resolve to min-content or something)
<emilio> iank_: re. placeholder I'm not convinced that it's feasible because we remove the placeholder from the dom when the field is focused
<emilio> ... so you don't want the input to shrink down
<emilio> ... when looking into textarea, people let the placeholder overflow sometimes etc
<emilio> ... there's something to consider
<emilio> ... for <select> I think the real usecase it's a different min/max-content algorithm
<emilio> ... all browsers match the current behavior of longest option
<emilio> ... so you really want a different intrinsic sizing algorithm
<emilio> lea: you say that you remove the placeholder from the dom when you focus
<emilio> ... but it's still visible
<emilio> iank_: when you actually enter content
<emilio> lea: yeah but then you want the input to be sized to the content
<emilio> iank_: I don't think that's what users would expect
<emilio> bramus: I think I agree
<emilio> ... if you have a placeholder with your name then it'd snap
<emilio> lea: in such a form then you wouldn't use this feature
<emilio> ... also you'd define the placeholders with that in mind
<emilio> bramus: but if you have a long place-holder then...
<emilio> lea: that's what min-width is for
<astearns> this is a much different use of an input that I was considering
<emilio> iank_: I think then people wouldn't consider the placeholder and it might get cropped
<emilio> lea: they can always use min-width
<emilio> ... for other use cases it's weird to have so much space around your control
<fantasai> emilio: I agree that you should be able to use something like input:not(:placeholder-shown) { min-width: .. } and it will be discontinuous when you start hiding it
<fantasai> emilio: in FF we don't remove the placeholder from the DOM, we just hide it with visibility:hidden
<fantasai> emilio: so the min-width of the input is the width of the placeholder
<fantasai> emilio: it is implementable, but ...
<fantasai> iank_: we might have some of ours out-of-flow so they don't contribute to baselines or something like that
<fantasai> emilio: it woudl be great to be interoperable on how we impleemtnt these as well
<fantasai> iank_: this is why I wanted to focus on textarea
<fantasai> iank_: developer need is very clear
<fantasai> iank_: Ideally, we'd standardize on internal structures so we can get exact correct thing
<fantasai> emilio: regarding select, agree that it's effectively a different intrinsic sizing algorithm
<fantasai> emilio: the current one, max-content and new one can be min-content
<fantasai> emilio: it's not amazing, it can be useful
<fantasai> emilio: I was a bit skeptical about this until Lea showed me some slides
<fantasai> emilio: I agree that just changing the meaning of min- or max-content might not be great
<fantasai> emilio: maybe a new property like form-intrinsic-size: legacy ?
<fantasai> emilio: and a new keyword?
<fantasai> emilio: that could work
<fantasai> emilio: and could also work for textarea sizing
<fantasai> emilio: change it so it makes sense
<fantasai> iank_: I agree that would be a nice thing
<fantasai> iank_: my only concern then is, doesn't allow us to ???
<fantasai> iank_: it doesn't allow us to do this in a piecemeal fashion, we have to get everything correct at once
<fantasai> iank_: which is a big undertaking
<fantasai> emilio: on the flip side, you end up adding one property instead of one per element
<fantasai> emilio: and it has a name that may make more sense
<fantasai> emilio: and not specific for this particular kind of element
<fantasai> emilio: but I agree
<fantasai> iank_: that's why with textarea one I really focused on changing how you multiply lh unit nternally
<fantasai> iank_: but I see what you're saying
<emilio> fantasai: we have an intrinsic-sizing property
<emilio> ... which was intended to fix some of the problems with the way we calculate intrinsic sizing
<emilio> ... so we have a place to put it
<fantasai> https://
<emilio> min-intrinsic-sizing
<emilio> ... names are not amazing, suggestions welcome
<emilio> ... this was about the compressible stuff
<emilio> ... so the reason why everybody puts min-width: 0 on everything is because of this
<emilio> dholbert: two thoughts: first one is that if we have a unified keyword / property for input and textarea
<emilio> ... you might end up with a textarea sizing the line greedily
<emilio> ... sort of the fit-content for textarea vs. max-content with single-line input
<emilio> ... we might need to be a bit careful there
<emilio> ... the first screenshot shows a <select>-like input, but less convinced about <input>
<emilio> ... would be good to collect the use cases for these
<emilio> ... willing to believe there are good use cases though the one on the issue seemed a bit abstract
<emilio> iank_: if I had to rank what devs would use
<emilio> ... auto-expanding textarea is the most common I've seen. I agree <select> is probably common as well, but I haven't seen many auto-growing <input>
<emilio> bramus: I've seen those in settings-like pages, like newsletter subscription, with a paragraph with two or three text-fields inside
<emilio> astearns: should we go back to the issue, add examples, possible ways of specifying this
<emilio> *?