Meeting minutes
Misc
Rossen3: Any changes to the agenda?
Rossen3: gonna skip the first issue
Rossen3: the reading flow one. got request to skip bc some ppl not ready
Rossen3: one was removed, the other one will be skipped
Rossen3: any other changes?
astearns: future agenda things
<astearns> w3c/
astearns: next week starting off with overall issue from ChrisL about font privacy
… people from Brave will be joining
… talking about how are going to solve font fingerprinting
<TabAtkins> uhhhhh who request skipping the reading flow items
astearns: have a good problem about the problems for privacy and lack of access for local fonts and bunch of differnet issues about possible solutions but have not gotten people volunteering to work on implementing and trying out these
… would like to get to this next week: some commitment to working on these things to get past the formal objection
<astearns> https://
astearns: second thing is we have this project (link) that has a numbe rof issues in flight for scope
… and scope is part of this years interop, so we should proably finish up
… ptal a the items in the inteh progress section
… most likely will have a breakout session
chrishtr: want to come back to the agenda
… who requested to remove the reading flow issues?
Rossen3: a member, doesnt matter
TabAtkins: we were discussing these already last week, werid that it gets pushed out
Rossen3: we respect the request of any member of the wg if they want to move bv they need more time
TabAtkins: bizarre that this is secret
Rossen3: if the person wanted to request this publicly then they would have done so
TabAtkins: in general, we are not comfortable with things getting pushed away for secret reasons
astearns: the reason is not secret, they needed more time
TabAtkins: but nobody knows who it was, which is bizarre
Rossen3: this has happened before
astearns: one thing we can do to make this better to post to the private list about it
… instead of sharing it on top of the meeting
TabAtkins: yes, please
<rachelandrew> +1 to that suggestion
chrishtr: that’d be great, thank you.
github-bot, take up w3c/
Interpolate values between breakpoints
<github-bot> OK, I'll post this discussion to https://
TabAtkins: elika and i were looking over this and there is a generic request to interpolate values based on some othe rprogeress value
… can be done by hand with calc, but does not work for all values
… or there are complex ways to interpolate
… seem slike a reasonable thing, that if you can do atransition, you can get the value for it too
… upon review of the use-case, what we were tyring in the spec was not good enough
… currently not implemented, so can start over
… new proposal
… two notions of interpolation
<scribeAssistant> Writeup is at w3c/
TabAtkins: 1. mixing of two values
… 2. interpolate values in series, more like linear() for timing or gradients
<weinig> are the existing spec'd functions the progress() functions?
TabAtkins: both are nearly identical, but when you reach 3 values they differ a lot
… can model either with the other, but frustrating and weird
… prop to introduce mix and map
<scribeAssistant> weinig: https://
TabAtkins: mix = …
… syntax proposal in the issue
… thoughts, ideas, …?
<lea> w3c/
lea: posted my thoughts on this link here
… when i started writing that i was not too crazy about introducing mor efunctions
… wanted to overload the exsting mixing functions
… but while writing my feedback it would make sens to have a new function (if it has a good name)
… maps typically help you transform 1 value into another
… (example)
… several requests had to add mapping to css
… even though sth like calc-map() or whater-map() it overloads the concept and now mapping is 2 diff things
… also confusing to be using an established concept in a diffefernt way
… interpolate is long and technical
… brainstormed a bit (see table in comment)
… leaning towards the name scale which gives a nice color-scale
… and calc-scale
… not ideal for images
… also huge +1 for solving this use case
… is major in design systems and tokens
… so yeah
TabAtkins: not attached to the name, we chose map bc interpolate was bad for your reasons and its also short like mix
<fantasai> +1
TabAtkins: scale seems appropriate
… having a hwole family of related fns the worry
<fantasai> We weren't particular about the name, just needed one.
<astearns> a little worried about our existing scale property
weinig: which of the css-values=5 fns is this replacing?
TabAtkins: the mix functions, not the pgoress ones which are inputs to these
weinig: got it
… other suggestion: blend
… bc that is often the result
… proble with scale is that we already have scale()
TabAtkins: only obj to blend is that it is a close synonym to mix
<lea> +1 to TabAtkins . Also `blend` sounds related to blend modes
TabAtkins: the better we can help authors remember which is which is good
lea: +1
… and also bend sound related to blending modes
TabAtkins: prolly cant avoid some semantic overlap
Rossen3: sounds like we are converging?
fantasai: yes, want to go over what it is
… the fn takes a bunch of top level params and what th eprogrsss is within the scale and a list of stops similar to linear-gradient(0 with an interpolation option between the stops (easing fn for example)
… and then the top level options are a source for the progress, also giving you an option of transofmring that source thorugh an easing function, and an option saying each step gets its own easing
… that is the top level
… and then the stops have a syntax where it is `stop: value` and you interpolate between th stops
<fantasai> color: color-map(media-progress(width, 0px, 2000px),
<fantasai> 0%: red,
<fantasai> 100%: blue);
<fantasai> color: color-map(media(width),
<fantasai> 0px: red,
<fantasai> 2000px: blue);
fantasai: also introducing new fns
… percentages, pull the value out directly
… pull out the start and end values, package them up together and put m in a variable
… so the progress functions are worth keeping for that reason
… Qs?
lea: dont quite understand by vs each
… its a good design goal to be compatible with gradients
… it could even b ea design goal that everyting in side color-scale is a valid gradient
… good for rease and debugging
… the syntax with colons of positions adn values. not sure the reduction with the rest of CSS is warranted by the usability adv
… seems small
… breaking compat is a good thing if it gives you a significant advantage, not sure that is the case here
… suggestion to stick to existing syntax
… we would need to make it mandatory that the stop position comes after the value in the calc version, as otherwise there would be disambiguation problems
… where you can percentages
<TabAtkins> animating-timing-function vs animation-easing
fantasai: diff between by and each is wehther you are applying easing between two stops or to the entiry of the progress value. Animations have this distinction. Can ease the entire timilne or in between keyframes.
… have the ability to put easing between any two stops, or the whole thing upfront
… that is the difference
… about the colon in the stop syntax: that is bc of the parsing ambiguity
… cant know the reeturn value upfront
… other optino is to align with if() and use semicolons
… not sure though
TabAtkins: there are certain value types make it ambigious to read or actually ambiguious
… e.g. calcs() sometimes hard to read
… not obvious to a human sometimes
… more problematic is the generic map() that can do entire property values
… no way to know where the value ends
… so have to either put the percentages in a distinguished place (like now) or only require 1
… would not allow us to do 1 or 2 stops
… bc those fns have parsing difficulties if you try to mix things in, we decided to carry that through the whole family of functions
… making most of map fns look similar to mix functions but hten some not , looks worse
<Zakim> lea, you wanted to ask about multiple positions, also use cases for each
lea: agree that constiency with eachother is more imporatnt than consistency with the rest of CSS
<TabAtkins> 1 + 2px +3px
lea: not sure about the color … hard to read or disambiguation issue?
… for the generic no amount of syntax would work other than putting it first
fantasai: (missed) progress values. can have a stripe
lea: is the generic fn actually ahppening? remember we had one for mix but then had to drop it
TabAtkins: multiway interpolation is trickier but if its just for map you are only interpolating two values at a time – we already know how to do that
lea: this wont solve issue with generic, but at least fo rothers we coul dintroduce an at-keyword
… like red at 50%
… very readable
TabAtkins: but unfrotunately does not extend
… not the best, happy to discuss precise syntax more
… looking for objections about the general approach
Rossen3: so now are gonna stick with the map?
<lea> fantasai: no, I meant `at 50%`
<fantasai> @ 50% might be kinda nice though :)
<fantasai> It avoids any parsing issues since @ is not otherwise valid
<lea> can we have a proposed resolution?
TabAtkins: lets switch over to scale and continue discussing
lea: do we have a proposed resolution? take on work?
TabAtkins: yes: accept the approach we have outlined in the issue changing the map naming for scale and continue iterating on the design in the spec
<lea> PROPOSED RESOLUTION: Accept the general approach, change map naming to scale for now, iterate on syntax later
Rossen3: sounds reasonable
weinig: will the keyframes part remain as well?
TabAtkins: that is the plan, but also up for discussion
weinig: I think you should keep them
fantasai: Qs for syntax were about the separator keywords by vs each and the name of the function
<lea> Huge +1000 to solving this problem, this is huge. Some doubts about each (do we have use cases for it?) but we can sort out later
lea: +1, like I said in IRC
… its low level, but lack of being able to do this keeps cropping up all the time
fantasai: yes, need to thank scott for filing this and following up on it
Rossen3: Objections?
… none, so we are resolved.
RESOLUTION: Accept the general approach, change map naming to scale for now, iterate on syntax later
github-bot, take up w3c/
… first you layout the table without collapse, and then remove th ecollapsed tracks
… this is about collapsing of rows and cols
… typically it is ht eparent formatting context that decides th esize of a box, but here it is like the table and this can confus the parent FC
… was investigating what browsers do
… only checked gecko and blink
… there is a table in this comment I linked to
… some shrink or do not shrink
… ?? they dont collapse which I think is right. would otherwise be bad if table is inside an inline-block
… when actually deciding final size of the table ther eare diferences
… gecko has wrapper table box and ?? box, and blink only has single box.
… in the inline axis gecko does not shrink the table wrapper box, only the table grid box
… this has nice properties lik avoiding conflicts with PFC
… some slightlly surprinsg things like cnetering with auto margins it only cneters the wrapper so could be off center
… blink has a single box and tries to shrink “both” things
… but it does not shrink in a flex row bc it could conflict with flex sizing algo I think
… what does it mean if the table is suddenly shrinking?
… does not shrhink for tables that have flex items in a row or if the table is abspos
… otherwise it behaves a if table wrapper shrinks
… for table grid gecko ??? it shrinks except for flex rows and abspos boxes
… things that are more itneresting in the block axis: both try to shrink as much as possible
… but in flex columns no browsers shrinks the intrinsic block contributions
… for final size of the tbl wrapper blocks gecko ???, blink doe snot shirnk the wrapper but doe shrink the grid
… not sure whatis going on.
… I like gecko’s inline-axis behavior
… not sure about the block
… like that a box can decide to if inline size conficts with PFC it can shrink
… there are several things to discuss here
[css2][css-tables] Do collapsed tracks also shrink the table wrapper box or only the table grid box?
<github-bot> OK, I'll post this discussion to https://
<oriol> w3c/
iank_: 1 thing I dislike is that when we set a height 100px on a table it will shrink both ??? seems like a ?? on the wrapper box side
… if we end up with resolution that keeps the wrapper box at 100px tha twould b egood
… some complexity … if all ?? size up to the inner grid box
… not sure what to do there
fantasai: for the margin case I wonder we could prolly compensate for that by either having the auto margins also do sth to the tabl egrid box or just saying authors can use the alignment properties to align both boxes
<Zakim> fantasai, you wanted to comment on alignment
iank_: oriol, can you say why you don tlike affecting th eintrinsic contributions?
<oriol> w3c/
oriol: see this link
… if you have a table that is inside an inline-block and the table has 2 cols, one of which is collapsed, and each coll has a cell with min-content size of 50 and max content of 100
… if you dont take collpased tracks into account the of the tbl is 200px
… if we decided to change this, it could be 200 but removing 1 col, so 100px
… problem is that when we lay out table for real, we only have 100px of avialbe space to give both cols
… so each would be 50px instead of 100px
… what will happen is that we end up with 1 col of 50px and its not the ideal size
iank_: makes sense
… making intrinsic block contributions match inline contributions would be the right way to go there for consistency
… and we likely are not constrained too much bc webkit doe snot have this feature yeat
… might need to think a bit more about the wrapper and grid box sizes
… the way that they work could be funky
Rossen3: Oriol, where do you want to take this?
… the issue or try for a resolution?
oriol: if Ian wants to think more about it, we can bring back to the issue
… this even belongs to CSS2, so a bit weird that we have this
… but can bring back to the issue
iank_: if you (oriol) write down possible solutions, that would be helpful
… what you think is the best
… I can also propose something
Rossen3: So let’s take it back to the issue
… perhaps we can have a proposed resolution by the next time
github-bot, take up w3c/
[css2][css-tables] Does `overflow` apply to table-wrapper or table-grid? css-tables contradicts CSSWG resolution
<github-bot> OK, I'll post this discussion to https://
oriol: this is conflict regarding what box overflow applies to
… spec says that by default properties that you set on a table element apply to the grid not the wrapper
… and then for overflow it originally was not defined in CSS2 but then it was added in an errate that the overflow applies to the box not the wrapper
… thatwas a resolution but only part of it got in CSS2
… but then in CSS3 that became the opposite
… so we should decide if it applies to the box or the wrapper
… elika is of the opinion that is more useful on the grid
… I tested if you use contain: paint it applies to the wrapper
… so would be Ok to apply to the grid
… reason tables-3 says it applies to the wrapper it is bc of overflow … which that applies to the wrapper
… so need to decide if it applies to the grid, affects transform style sof the grid or the wrapper, should it apply to the same box?
… not that familiar with transforms
Rossen3: Comments?
dholbert: we got a bug filed on this a while back in firefox
… spec maybe aligns with what gecko is doing
… i did file bugs in chromium and webkit, but dont know the progress of those
… this is about the overflow applying
… IIRC the spec says wrapper
iank_: preference to apply to the wrapper making all of the ?? and transform style props to aply to the wrapper
… like clip and clip-path
… just for consistency
… suspect it is like … debatable which is most useful
… if someone wants to clip inthe wrapper, then we allow clipping on the sectino elements which make that possible
… so I would like to keep everything on the wrapper
emilio: main diff here is wehter caption and so on get clippped
… as an author I expec thte ?? behavior that what scrolls decides the content of the table
… otherwise bottom captions become useless in scrollable tables
… would be odd to push ??? to the bottom of the scrollable table
iank_: you cant scroll right?
oriol: values other than visible or hidden
iank_: overflow: scroll on a table does not do anything right now
… like overflow hidden is treated as clip
… so therefore preference to keep everything on the wrapper
emilio: other thing we could do is apply to both, but could have observable difference
… in that case no strong preference though
… the caption thing still applies though right?
… I guess not, bc you clip outside of the captions vs inside
iank_: yes
fantasai: same thought as emilio: if we could make it scrollable obvs thing would be to scroll the table itself.
<iank_> i don't think we'll be able to make scrolling work from a compat point of view.
bramus: people want that, along with sticky headers
fantasai: if we want to do that eventually, would taking a decision to do it on the wrapper cause a problem?
iank_: tables and overflow:scroll have been around for long enough
… they cant really be made scrollable bc of style constraints
… if you set `height` it does not add … intrinsic block sizes override that
fantasai: there is the ?? algo to make that work
iank_: not an easy path to make tables scrollable
<fantasai> s/there is the ??in that case we'd need a new table-layout algo/
iank_: substantial rework to how they work
iank_: what was your point about sticky headers?
… we have sticky top rows, but stikcy cols is a different problem
Rossen3: we are at time
… not sure we can resolve right now, I think?
… table scrolling will take up more time
… seems like an interop nightmare
iank_: dont think we need to make tables scrollable int he near term
… could back ourselves in a corner
… if we ever make them scrollable, then we can change things
… sticking on the wrapper
fantasai: as you note, we'd need an opt into a different algorithm, so we could use that as a switch for overflow as well
iank_: putting us on the wrapper does not paint it into a corner
Rossen3: So can we decide on that?
iank_: if no-one objects, then yes
PROPOSED RESOLUTION: overflow applies to the wrapper box
<fantasai> PROPOSED: overflow applies to wrapper box
Rossen3: objections?
RESOLUTION: overflow applies to the wrapper box
none
Rossen3: next weeek we’ll start with the overflow issues
<jcraig> w3c/
<jcraig> astearns: Will send an update on ChrisL's fingerprinting summary later this week
<jcraig> weinig: for w3c/
<astearns> github-bot, take up w3c/
[css-color-hdr] How should checking for percentages summing to 0 work in dynamic-range-limit-mix() when calc() is used?
<github-bot> OK, I'll post this discussion to https://
<jcraig> weinig: issue is that the spec for dynamic color mix has rules applied at parse time that check if value is zero
<jcraig> if all percentages add up to zero, they are invalid, but calc() may not know if it's invalid yet
<jcraig> options: either define at calc time what do in that scenario, mark as invalid at computed style time, or have it behave as if all percentages are the same; evenly divided
<jcraig> someone brought up the a concern with 50 high 50 low example, nothing constrained, you'd get 33/33/33 (not sure if I scribed that correctly)
<jcraig> currently we even split it, but worth considering when animating the ramps to zero
<jcraig> ChrisL: people will ramp it for animation so we should ensure it's not jarring
<jcraig> weinig: no current test for that.... but yes, should fix that
<jcraig> propose if all zero, treat as all at 33%
<jcraig> ChrisL: sounds reasonable
<jcraig> proposal: remove the sentence in spec that says if sum is zero, treat as invalid; possibly add new prose about splitting the percentage, and update tests
<jcraig> weining: i can take on an item to work up the correct prose for that change to splitting the percentage
<jcraig> astearns: no objections resolved...
RESOLUTION: remove the sentence in spec that says if sum is zero, treat as invalid; possibly add new prose about splitting the percentage, and update tests
<astearns> github-bot, take up w3c/
[css-color-hdr] How should multiple layered elements with different `dynamic-range-limit` values behave?
<github-bot> OK, I'll post this discussion to https://
<jcraig> weinig: for multiple layered elements, need more added to clarifying the model underlying what this property actually does
<jcraig> uses tone map compositing example to explain compositor controlling whether this is additional headroom
<jcraig> ChrisL: we have a brief section on compositing... would be good to get better text
<jcraig> weinig: understanding what implementors would like to apply here would be useful
<jcraig> and the constraints of existing compositors
<jcraig> Said: the dynamic range limit is cascading, correct?
<jcraig> weinig: inherited but overridden by an explicit defining on higher specificity
<jcraig> smfr: yes, agreed at F2F that these are not multipliers
<jcraig> ChrisL: should be documented, possibly in an appendix...
<jcraig> easy to write something that looks great from a color theory perspective but may not be implementable
<jcraig> PROPOSAL: modify spec text as discussed, to try and flesh out if there are blocking compositor issues in implementations; possibly add an appendix of test cases and blocking issues with platform limitations
<jcraig> weinig: WPT is lacking here because the color space can be modified
<jcraig> ChrisL: and WPT is limited to sRGB
RESOLUTION: modify spec text as discussed, to try and flesh out if there are blocking compositor issues in implementations; possibly add an appendix of test cases and blocking issues with platform limitations
<jcraig> weinig: I will take that issue
<astearns> github-bot, take up w3c/
[css-color-hdr] Add permission policy (or other mechanism) to irreversibly limit EDR
<github-bot> OK, I'll post this discussion to https://
smfr: issues is ads in cross origin frames showing hdr
… one way to got is not allowing HDR cross origin
… or we could use the property
… or do we want to add to the iframe attribute that grants permissions
… Is the definition of the css property on an iframe even specified?
… does it apply to all the contents?
astearns: , do we have any cases where things don't propagate down into an iframe?
smfr: , I think HDR is a little special, and we should we say something
ChrisL: , this is a about stoping ads doing bad things
smfr: , yes, but it is also about explicitly letting some cross origin iframes
… this is partially a HTML issue, since the attribute would be in HTML
astearns: the permission policy would be an attribute?
smfr: yes
ChrisL: is this being discussed in HTML?
smfr: I don't think so
pal: this is complex, but someone who made an HDR video would be upset if they got squashed when embedded
smfr: yeah, we currently always allow HDR on video
… so we may want to allow it to always work cross origin
pal: codepen is an extreme example, because it wants the iframe to be perfect
… would be good to hear from website authors
… the default of showing in HDR is better than not, but can be jarring
astearns: not sure who filed the issue, but the person who filed the issue seemed to want to be able to limit things
smfr: actually, it was filed by a webkit engineer
… but others have mentioned a concern of ads
pal: isn't the only thing you would ever want to do is make it all sdr?
smfr: not sure, might have HDR but not want flashy ads to be HDR
pal: I think the website should probably have control
smfr: I think both the website author and user
… defaults we choose are important
astearns: and giving authors the tools
… no way to currently allow a hosting page to say it only wants sdr
smfr: this is a sleeping problem, since we only just started shipping HDR now
weinig: I am not sure the issue of an embedded YouTube not being HDR is that big a deal
… you can always put a tinted div over a video
… letting the hosting site make things SDR seems fine
jcraig: we had a similar issue internally with a feature that dims things automatically when things are flashy, and there was a question of whether it was ok to change the artists intent
… but ultimately, allowing the user to have the control was the way to go
pal: movies are mastered under the idea they will be the only thing displayed
ChrisL: yeah, but we can't do that on the web, we have to allow mixed content
pal: yeah, when a movie is watched on the web, it is already compromised
… image gallery much more complicated
astearns: ok, good talk, lets take this back to the issue