IRC log of css on 2023-12-20
Timestamps are in UTC.
- 16:57:17 [RRSAgent]
- RRSAgent has joined #css
- 16:57:21 [RRSAgent]
- logging to https://www.w3.org/2023/12/20-css-irc
- 16:57:21 [Zakim]
- RRSAgent, make logs Public
- 16:57:22 [Zakim]
- Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
- 16:58:39 [PaulG]
- present+
- 16:59:13 [ydaniv]
- ydaniv has joined #css
- 16:59:39 [gtalbot]
- gtalbot has joined #css
- 17:00:50 [dholbert]
- present+
- 17:00:51 [dbaron]
- Present+
- 17:00:54 [Rossen_]
- present+
- 17:01:14 [chrishtr]
- present+
- 17:01:39 [jfkthame]
- jfkthame has joined #css
- 17:01:41 [flackr]
- present+
- 17:01:46 [jfkthame]
- present+
- 17:01:48 [rachelandrew]
- present+
- 17:01:59 [miriam]
- present+
- 17:02:19 [chris]
- chris has joined #css
- 17:02:24 [chris]
- present+
- 17:02:35 [changseok]
- changseok has joined #css
- 17:02:46 [bramus]
- present+
- 17:03:15 [YehonatanDaniv]
- present+
- 17:03:56 [TabAtkins]
- present+
- 17:04:09 [schenney]
- schenney has joined #css
- 17:04:17 [florian]
- present+
- 17:04:40 [github-bot]
- Topic: [css-color-hdr] Add mechanism to query HDR headroom
- 17:04:41 [astearns]
- github-bot: take up https://github.com/w3c/csswg-drafts/issues/9306
- 17:04:41 [github-bot]
- astearns, ignoring request to take up https://github.com/w3c/csswg-drafts/issues/9306 which is already the current github URL
- 17:04:46 [bts]
- bts has joined #css
- 17:04:59 [vitorroriz]
- vitorroriz has joined #css
- 17:05:40 [changseok]
- present+
- 17:07:39 [lea]
- lea has joined #css
- 17:07:48 [bradk]
- bradk has joined #css
- 17:08:23 [pal]
- pal has joined #css
- 17:08:24 [frances__]
- frances__ has joined #css
- 17:08:36 [frances__]
- <@frances_> rossen: let's start with the first few issues [11:03] <@frances_> pierre: present background behind issues and areas to collaborate [11:03] <@frances_> rossen: I will try and help you [11:04] <@frances_> pierre: sounds great, might not solve in 10 minutes, maybe solve later [11:05] <@frances_> pierre: presentation on adding HDR imagery to html canvas for css requirements [11:05] <@frances_> pierre: highlight some work on color on web[CUT]
- 17:08:36 [chris]
- scribenick: frances
- 17:08:51 [dholbert]
- scribenick: frances__
- 17:08:54 [keithamus]
- keithamus has joined #css
- 17:08:55 [plinss]
- present+
- 17:09:04 [keithamus]
- present+
- 17:09:07 [bradk]
- present+
- 17:09:22 [bts]
- present+
- 17:09:48 [frances__]
- pierre: so far the web has standard images. effort to bring to both tv and movies, pcs, higher dynamic range images, much broader range of lumniscence, darker and brighter than png images used to
- 17:10:20 [frances__]
- pierre: in order to enable this, higher pixel beyond 8 bits beyond power law gamma transfer function, much effort done in the past decade
- 17:10:27 [fantasai]
- [pal expains SDR - standard images, whose ranges 0-100 nits, the range of luminance in a standard laptop]
- 17:10:35 [frances__]
- on streaming services, blue ray, and cinema, want to bring to pcs
- 17:11:11 [frances__]
- pal: web community group has been bringing high range images on html canvas. web gpu and so forth
- 17:11:26 [frances__]
- pal: straw man proposed to add HDR imagery through a series of steps
- 17:11:31 [lea]
- present+
- 17:11:35 [dbaron]
- s/web community group/color on the web community group/
- 17:12:00 [frances__]
- pal: add series of 8 bit color per pixel, assist with mapping to displace that might not be high dynamic range, add api
- 17:12:17 [fantasai]
- [Slide: add HDR colorspaces to Canvas; add higher bit depth to Canvas etc. ; add image color volumne info to Canvas ; add display color volumn info query ; recommendations for mapping to/from HDR ]
- 17:12:25 [vmpstr]
- present+
- 17:12:55 [frances__]
- pal: render on displays that might not have required/narrow and render HDR images, welcome feedback
- 17:13:03 [frances__]
- pal: pause for questions
- 17:13:14 [frances__]
- rossen: suggests to keep going
- 17:13:25 [chrishtr]
- q+
- 17:13:39 [frances__]
- pal: HDR colorspaces fulfill two objectives: mapping between pixel values and emitted light
- 17:14:03 [gtalbot]
- gtalbot has left #css
- 17:14:09 [frances__]
- pal: also reference viewing environment (ambient light and reference display)
- 17:14:21 [chrishtr]
- q-
- 17:14:46 [frances__]
- pal: ITU-R standard recommendation bt.2100 built on and recommends three colorspaces
- 17:15:15 [chrishtr]
- q+
- 17:15:27 [frances__]
- pal: uses hlg transfer function, uses pq transfer function, and linear light where rib corresponds to reference white (1,1,1)
- 17:15:30 [chris]
- q+
- 17:15:45 [emeyer]
- emeyer has joined #css
- 17:15:52 [bkardell_]
- bkardell_ has joined #css
- 17:15:57 [frances__]
- pal: same color primaries and reference viewing environment, add support to the three areas
- 17:16:03 [bkardell_]
- present+
- 17:16:06 [chrishtr]
- q-
- 17:16:09 [emeyer]
- present+
- 17:16:25 [frances__]
- pal: issue is high dynamic range image for narrow range image display
- 17:16:38 [bradk]
- bradk has joined #css
- 17:16:55 [frances__]
- pal: should a single algorithm be mandated or recommended?
- 17:17:00 [fantasai]
- i/pal: issue is/pal: Request is for CSS to add these three color spaces, as we are planning to add also to Canvas
- 17:17:05 [frances__]
- pal: how should a single algorithm be selected?
- 17:17:20 [frances__]
- pal: the cg has been considering a call for proposals
- 17:17:47 [frances__]
- pal: what is the capabilities of the display for minimum and maximum display luminance and of reference white?
- 17:18:13 [frances__]
- pal: possiblility to increase fingerprinting surfs and introduces privacy concerns
- 17:18:32 [frances__]
- rossen: focus the conversation
- 17:18:51 [frances__]
- rossen: what is the path forward?
- 17:18:57 [PaulG]
- q+
- 17:18:57 [Rossen_]
- ack chrishtr
- 17:19:00 [bradk]
- bradk has joined #css
- 17:19:11 [fantasai]
- i/pal: what is/pal: Also some applications might want to provide their own mapping, so would need some information from the UA
- 17:19:11 [frances__]
- chris: what are the colorspaces suggesting for canvas, are they all available in css ideally?
- 17:19:20 [frances__]
- rossen: confirms, yes would be ideal
- 17:19:42 [dbaron]
- I'm curious what "add a color space to CSS" means -- add it as part of mechanism for specifying colors, add the ability to use it as a working color space for compositing, other things?
- 17:19:50 [frances__]
- chris: on other issue, there is already an unofficial draft created. waiting for interest shown
- 17:20:26 [frances__]
- chris: brought down to simple high level proposed resolution, and propose to work on the draft together
- 17:20:36 [schenney]
- The trick is figuring out a HDR->SDR mapping that works when color information is spread across lots of elements (as opposed to a single image)
- 17:20:59 [Rossen_]
- ack chrishtr
- 17:21:01 [Rossen_]
- ack chris
- 17:21:03 [Rossen_]
- ack PaulG
- 17:21:05 [dbaron]
- https://drafts.csswg.org/css-color-hdr/
- 17:21:34 [chris]
- Paul, please have a look at https://drafts.csswg.org/css-color-hdr/#a11y
- 17:21:41 [frances__]
- paulg : has question and concern on samsung browser full canvas interface. would be excited. Is there a lag time between canvas and web implementation?
- 17:21:43 [chris]
- q+
- 17:21:59 [frances__]
- paulg: a hack with no script and can leave alot of people out on accessibility
- 17:22:24 [frances__]
- paulg: what coordination to do with color coordinations to accommodate for higher luminance?
- 17:22:29 [Rossen_]
- ack chris
- 17:22:41 [fantasai]
- s/a hack with no script and/if these are only available for Canvas, devs might use Canvas rather than Web in the interim, which/
- 17:22:44 [pal]
- q+
- 17:22:45 [frances__]
- chris lilley: already have accessibility considerations on the draft
- 17:22:53 [florian]
- q+ to ask if these 3 color spaces achieve different things, or if they are different ways to achieve the same thing
- 17:23:29 [frances__]
- rossen: let's answer high level bit to continue working on in csswg, and move onto other issues
- 17:23:34 [Rossen_]
- ack pal
- 17:23:56 [Rossen_]
- Zakim, close queue
- 17:23:56 [Zakim]
- ok, Rossen_, the speaker queue is closed
- 17:24:02 [frances__]
- pal: thank group for opportunity, focus on the colors
- 17:24:05 [Rossen_]
- ack florian
- 17:24:05 [Zakim]
- florian, you wanted to ask if these 3 color spaces achieve different things, or if they are different ways to achieve the same thing
- 17:24:10 [chris]
- Proposed Resolution: CSS WG adopts the CSS Color HDR draft as a work item
- 17:24:43 [frances__]
- florian: question: out of 3 color spaces, bigger range?
- 17:24:57 [frances__]
- chris lilley: yes, better use cases
- 17:25:08 [chrishtr]
- sgtm
- 17:25:16 [frances__]
- rossen: objections?
- 17:25:30 [fantasai]
- s/bigger range/are they different ways of achieving the same thing that we expect one to win, or do we need all three/
- 17:25:45 [fantasai]
- s/yes, better use cases/we need all three, they have different use cases/
- 17:25:49 [emilio]
- present+
- 17:26:06 [chris]
- Resolution: CSS WG adopts the CSS Color HDR draft as a work item
- 17:26:26 [frances__]
- RESOLUTION adopt the CSS Color HDR draft as a work item
- 17:26:29 [vitorroriz]
- present+
- 17:26:42 [fantasai]
- RESOLVED: CSS WG adopts the CSS Color HDR draft as a work item
- 17:26:42 [bradk]
- Rossen_: is that Hawai’i?
- 17:26:49 [frances__]
- rossen: archive is in the IRC
- 17:27:30 [frances__]
- rossen: next-issue #9511
- 17:27:39 [Rossen_]
- github-bot: take up https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1839208142
- 17:27:39 [github-bot]
- Topic: [css-text][text-spacing] Visual regressions of line-start at portals and news sites
- 17:27:39 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9511.
- 17:28:04 [Rossen_]
- Zakim, open queue
- 17:28:04 [Zakim]
- ok, Rossen_, the speaker queue is open
- 17:28:15 [frances__]
- chris harrelson: css property is text-spacing trim
- 17:28:28 [fantasai]
- spec -> https://www.w3.org/TR/css-text-4/#text-spacing-trim-property
- 17:28:28 [duga]
- duga has joined #css
- 17:28:33 [frances__]
- christ: current spec causes compatibility issues in japanese sites
- 17:28:51 [florian]
- q+
- 17:29:13 [frances__]
- chris h: existing behavior has use cases, make the default what is currently case, add keywords, current comment is out of date, add normal
- 17:29:37 [frances__]
- chris h: second discussion for additional keywords to add, propose to segment, discuss, and resolve
- 17:29:46 [Rossen_]
- ack florian
- 17:30:26 [frances__]
- florian: thinks there's a shortcut, different from written, identical to current behavior and adjacent would be better than current with no combat problems of current draft, and would support
- 17:31:13 [frances__]
- florian: keep space in start, and trim adjacent, cohesive investigation
- 17:31:32 [bradk]
- Rossen_: nice. I recognized the bird sounds from when I was in Maui last month. 👍
- 17:31:36 [frances__]
- chris h: thank you for clarifying
- 17:31:38 [fantasai]
- florian: Current behavior is space-all, we're trying to choose an initial value that's the intersection of what's better and what's Web-compatible
- 17:31:41 [vitorroriz]
- q+ (can be by text): so "normal" would be space-all ?
- 17:31:46 [frances__]
- rossen: request for other feedback
- 17:31:49 [emilio]
- looks sensible to me at a glance
- 17:32:07 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1853187016
- 17:32:12 [astearns]
- q+ vitorroriz
- 17:32:24 [frances__]
- fantasai: proposal to add new value normal to represent initial value with space start trim adjacent and allow end, table of what happens at start edge, end edge, and between
- 17:33:20 [frances__]
- fantasai: current spec says that we would use space first as start and trim adjacent edge, not web compatible. Proposal to introduce normal keyword, remember initial value and possibly tweak it.
- 17:33:43 [Rossen_]
- ack vitorroriz
- 17:33:50 [frances__]
- vitor: normal value wouldn't be equivalent to space? fantasai: no
- 17:34:28 [frances__]
- fantasai: would be safest option, and possibly improve. from investigation main issues are on the start edges have not come up with problems of trim adjacent behavior at the end
- 17:34:33 [fantasai]
- s/space/space-all/
- 17:34:34 [astearns]
- s/Rossen_: nice. I recognized the bird sounds from when I was in Maui last month. 👍//
- 17:34:47 [frances__]
- rossen: sibling property of auto-space possibly something equivalent
- 17:34:55 [astearns]
- s/Rossen_: is that Hawai’i?//
- 17:35:12 [frances__]
- florian: with each issue on GitHub, everyone feels pretty aligned
- 17:35:22 [fantasai]
- PROPOSED: Initial value of text-spacing is 'normal' representing the 'space-start trim-adjacent allow-end' behavior
- 17:35:25 [frances__]
- rossen: summarize ask for proposed path forward?
- 17:35:41 [florian]
- s/with each issue/within issue
- 17:35:45 [frances__]
- florian: has the proposed resolution
- 17:36:00 [frances__]
- rossen: any additional comments to proposed resolution?
- 17:36:30 [fantasai]
- https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1862787959
- 17:36:45 [fantasai]
- Value syntax would be: normal | trim-start | space-first | trim-auto | space-all | trim-all | auto
- 17:36:53 [frances__]
- florian: what do we do with other values? auto is already in spec, would be how to rebalance rest set of values
- 17:37:06 [fantasai]
- Current syntax is: space-all | trim-auto | [ allow-end || space-first ] | trim-all | auto
- 17:37:54 [frances__]
- florian: removes ability to combine space first with the name of the value at the start end, trim adjacent in the middle, removes trim end variant of space first
- 17:38:06 [frances__]
- florian: most were not useful in implementation in browsers
- 17:38:20 [frances__]
- rossen: ask for opinions?
- 17:38:23 [vitorroriz]
- q+
- 17:38:27 [frances__]
- fantasai: supports change
- 17:38:38 [Rossen_]
- ack vitorroriz
- 17:38:42 [frances__]
- vitor: auto value will be there?
- 17:38:51 [frances__]
- fantasai: yes
- 17:39:18 [frances__]
- florian: auto matches operating systems native behavior. default would be normal
- 17:39:47 [frances__]
- fantasai: proposal to rename auto to match-platform to be more obvious
- 17:39:57 [frances__]
- rossen: objections? none, resolved
- 17:39:59 [fantasai]
- s/proposal to/we could also/
- 17:40:18 [fantasai]
- RESOLVED: Accept Murakami's proposal to simplify to text-spacing: normal | trim-start | space-first | trim-auto | space-all | trim-all | auto
- 17:40:34 [bradk]
- bradk has joined #css
- 17:40:35 [frances__]
- RESOLVED: remap property value space for text-spacing
- 17:41:31 [astearns]
- github-bot: take up https://github.com/w3c/csswg-drafts/issues/9639
- 17:41:32 [github-bot]
- Topic: [css-view-transitions-1] Disallow the name `auto` as `view-transition-name`
- 17:41:32 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/9639.
- 17:41:37 [noamr]
- noamr has joined #css
- 17:43:19 [frances__]
- bramus: right now the property transition view name accepts custom in #8319, might be feasible to add alternate shorthand name, use value of auto in that case
- 17:43:39 [fantasai]
- bramus: this would create a conflict with view-transition-name, so propose to disallow auto
- 17:43:45 [bramus]
- s/custom/custom-ident
- 17:43:47 [frances__]
- RESOLUTION: disallow auto for view transitions
- 17:43:54 [fantasai]
- s/RESOLUTION/RESOLVED/
- 17:44:06 [fantasai]
- s/view transitions/view-transition-name/
- 17:44:14 [frances__]
- RESOLUTION: disallow auto for view-transitions-name/view-transitions
- 17:44:37 [frances__]
- rossen: keep going to next issue
- 17:44:42 [github-bot]
- Topic: [css-scoping] Always serialise the implicit `:scope` ?
- 17:44:51 [frances__]
- rossen: always serialize implicit scope?
- 17:45:06 [bramus]
- s/accepts custom/accepts auto.
- 17:45:16 [TabAtkins]
- q+
- 17:45:32 [frances__]
- matthieu d: in css copying spec all rules in the spec have a : scot selector, nesting serialize implicit selector, value context related to selector
- 17:45:42 [Rossen_]
- ack TabAtkins
- 17:46:01 [emilio]
- q+
- 17:46:07 [Rossen_]
- ack emilio
- 17:46:09 [frances__]
- tabatkins: more transportable to other spots for javascript copying and pasting
- 17:46:38 [miriam]
- q+
- 17:46:39 [frances__]
- emilio: consistent for @ scope or nested inside, still seems fine
- 17:46:52 [Rossen_]
- ack miriam
- 17:47:07 [frances__]
- miriam: question, what implications does this have for the behavior or just internal?
- 17:47:28 [frances__]
- matthieu d: no implication, only for serialization, one value for specificity, already counted
- 17:47:59 [frances__]
- miriam: some questions from roman about nesting and scope and how the implicit scope works in nested context
- 17:48:35 [frances__]
- matthieu d: serializing when there is an implicit scope
- 17:48:45 [frances__]
- rossen: any other questions/concerns?
- 17:48:55 [frances__]
- rossen: any objections?
- 17:49:25 [frances__]
- PROPOSAL: serialize implicit scope pseudoclass in rule selectors
- 17:49:47 [frances__]
- RESOLUTION: serialize implicit scope pseudoclass in rule selectors
- 17:49:59 [Rossen_]
- github-bot: take up https://github.com/w3c/csswg-drafts/issues/626#issuecomment-1800254442
- 17:49:59 [github-bot]
- Topic: [css-transitions] Transition to height (or width) "auto"
- 17:49:59 [github-bot]
- OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/626.
- 17:51:37 [fantasai]
- scribe+
- 17:52:14 [fantasai]
- TabAtkins: People have been asking for transition height 0 - auto since beginning of transitions
- 17:52:19 [fantasai]
- TabAtkins: also have use cases for other definite heights
- 17:52:36 [fantasai]
- TabAtkins: Other one is, not just transitioning from auto, but any of the intrisinc keywords
- 17:52:47 [fantasai]
- TabAtkins: to/from zero to any other value is commonly desired, for good shuttering animations
- 17:52:57 [fantasai]
- TabAtkins: the most obvious solution is to let people use intrinsic sizing keywords in calc()
- 17:53:03 [fantasai]
- TabAtkins: this isn't great, I explain why in issue, short version is
- 17:53:16 [fantasai]
- TabAtkins: several layout algorithms branch based on exactly which intrinsic sizing behavior being invoked
- 17:53:25 [fantasai]
- TabAtkins: What's min-content/2 vs fit-content/2
- 17:53:35 [fantasai]
- TabAtkins: could affect element and/or its neighbors different
- 17:53:49 [fantasai]
- TabAtkins: We also have other behavior, e.g. cyclic percentages, which can have intrinsic behavior
- 17:54:11 [bts]
- bts has left #css
- 17:54:14 [fantasai]
- TabAtkins: You can interpolate among percentages, but if you interpolate 100% to 0 at 50% you'd still have auto to 0
- 17:54:19 [fantasai]
- TabAtkins: creates a jump
- 17:54:23 [fantasai]
- TabAtkins: Propose to introduce a new function
- 17:54:32 [fantasai]
- TabAtkins: first arg is an intrinsic size calculation
- 17:54:40 [fantasai]
- TabAtkins: second arg is a calculation
- 17:54:43 [fantasai]
- TabAtkins: it can accept a size keyword
- 17:54:56 [fantasai]
- TabAtkins: this forces relying on a single intrinsic size
- 17:55:03 [fantasai]
- TabAtkins: and also means you can transition cyclic percentages
- 17:55:14 [duga]
- duga has joined #css
- 17:55:18 [fantasai]
- TabAtkins: Also, by having as a separate function, this gives us a hook for activating better transition behavior automaticall
- 17:55:26 [fantasai]
- TabAtkins: right now, min-content to 100px, it is discrete transition behavior
- 17:55:38 [fantasai]
- TabAtkins: having a new function on one end allows us to automatically upgrade both sides to the function
- 17:55:50 [fantasai]
- TabAtkins: Can go over more details if ppl have questions, but in general I think this is the right way to go
- 17:55:58 [fantasai]
- TabAtkins: would like to introduce to values-5
- 17:55:58 [lea]
- q+
- 17:56:03 [fantasai]
- TabAtkins: dbaron wants to Intent to Experiment
- 17:56:13 [Rossen_]
- ack lea
- 17:56:14 [dbaron]
- Intent to Prototype, not intent to Experiment :-)
- 17:56:20 [fantasai]
- lea: To make sure I understand, reason of new function is so that there's only one intrinsic sizing keyword and not multiple?
- 17:56:24 [fantasai]
- TabAtkins: that's the main one, a few other reasons
- 17:56:39 [fantasai]
- lea: would it be possible to use regular calc() and just apply that restriction?
- 17:56:47 [fantasai]
- TabAtkins: You have non-keyword intrinsic size things, like cyclic percentage
- 17:56:50 [fantasai]
- TabAtkins: you couldn't d othose
- 17:56:53 [fantasai]
- TabAtkins: but if we ignore that case
- 17:56:58 [fantasai]
- TabAtkins: we could, but it makes for more difficult debugging
- 17:57:03 [fantasai]
- TabAtkins: you have to know that the restriction exists
- 17:57:15 [fantasai]
- TabAtkins: it's possible to learn, just seems a step further than I would usually want to require for authors
- 17:57:31 [fantasai]
- lea: If we use calc(), there's a clear path to relaxing restrictions over time
- 17:57:56 [fantasai]
- TabAtkins: I doubt the problems I mention are solveable. The branching on layout algorithms is important
- 17:57:59 [fantasai]
- TabAtkins: not likely to change
- 17:58:06 [fantasai]
- TabAtkins: so don't think there's a path to mixing in calc() ever
- 17:58:20 [fantasai]
- lea: evolution is only one reason, and often group does the impossible later down the line
- 17:58:38 [fantasai]
- lea: authors might not hit the restriction, not common in use cases
- 17:58:44 [fantasai]
- lea: have to learn a new function
- 17:58:48 [fantasai]
- TabAtkins: have to pay a learnability tax
- 17:58:55 [bradk]
- bradk has joined #css
- 17:58:57 [fantasai]
- TabAtkins: calc-size() solving other problems better seems worth it to me
- 17:59:07 [Rossen_]
- ack dbaron
- 17:59:12 [fantasai]
- TabAtkins: folding it into calc() has those problems, and also a different type of learnability hit
- 17:59:30 [fantasai]
- dbaron: anotehr case is opt-in to new behavior, the function provides this. If we use calc, we need a separate switch.
- 17:59:59 [TabAtkins]
- fantasai: My first impression is that it does make sense to do this as a separate fucntion, for the reasons metnioned
- 18:00:09 [TabAtkins]
- fantasai: Like to and from 0, if you're just 0 you'll lose the branching behavior
- 18:00:34 [TabAtkins]
- fantasai: This provides a way where even if the calc evaluates to zeor, you're still hanging onto the fact that this is trying to do the intrinsic sizing thing and layout algos will be consistent
- 18:00:53 [fantasai]
- Rossen_: any other comments?
- 18:01:16 [fantasai]
- TabAtkins: proposed resolution is add calc-size() to css-values-5 and work out details there
- 18:01:24 [fantasai]
- Rossen_: objections?
- 18:01:33 [fantasai]
- RESOLVED: Add calc-size() to css-values-5 and work out details there
- 18:01:45 [fantasai]
- Topic: End
- 18:01:59 [fantasai]
- Rossen_: reminder to add yourself to F2F wiki
- 18:02:08 [bradk]
- bradk has joined #css
- 18:02:15 [fantasai]
- -> https://wiki.csswg.org/planning/mountain-view-2024
- 18:02:22 [fantasai]
- Rossen_: That's it for 2023! See you in 2024
- 18:02:34 [emeyer]
- emeyer has left #css
- 18:02:53 [Rossen_]
- Zakim, end meeting
- 18:02:53 [Zakim]
- As of this point the attendees have been PaulG, dholbert, dbaron, Rossen_, chrishtr, flackr, jfkthame, rachelandrew, miriam, chris, bramus, YehonatanDaniv, TabAtkins, florian,
- 18:02:57 [Zakim]
- ... changseok, plinss, keithamus, bradk, bts, lea, vmpstr, bkardell_, emeyer, emilio, vitorroriz
- 18:02:57 [Zakim]
- RRSAgent, please draft minutes v2
- 18:02:58 [RRSAgent]
- I have made the request to generate https://www.w3.org/2023/12/20-css-minutes.html Zakim
- 18:03:05 [Zakim]
- I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye
- 18:03:05 [Zakim]
- Zakim has left #css
- 19:05:19 [duga]
- duga has joined #css
- 19:56:04 [duga]
- duga has joined #css
- 20:58:47 [duga]
- duga has joined #css
- 23:41:54 [dholbert_]
- dholbert_ has joined #css