Meeting minutes
[css-color-hdr] Add mechanism to query HDR headroom
<astearns> github-bot: take up w3c/
<github-bot> astearns, ignoring request to take up w3c/
<@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]
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
pierre: in order to enable this, higher pixel beyond 8 bits beyond power law gamma transfer function, much effort done in the past decade
<fantasai> [pal expains SDR - standard images, whose ranges 0-100 nits, the range of luminance in a standard laptop]
on streaming services, blue ray, and cinema, want to bring to pcs
pal: color on the web community group has been bringing high range images on html canvas. web gpu and so forth
pal: straw man proposed to add HDR imagery through a series of steps
pal: add series of 8 bit color per pixel, assist with mapping to displace that might not be high dynamic range, add api
<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 ]
pal: render on displays that might not have required/narrow and render HDR images, welcome feedback
pal: pause for questions
rossen: suggests to keep going
pal: HDR colorspaces fulfill two objectives: mapping between pixel values and emitted light
pal: also reference viewing environment (ambient light and reference display)
pal: ITU-R standard recommendation bt.2100 built on and recommends three colorspaces
pal: uses hlg transfer function, uses pq transfer function, and linear light where rib corresponds to reference white (1,1,1)
pal: same color primaries and reference viewing environment, add support to the three areas
<fantasai> pal: Request is for CSS to add these three color spaces, as we are planning to add also to Canvas
pal: issue is high dynamic range image for narrow range image display
pal: should a single algorithm be mandated or recommended?
pal: how should a single algorithm be selected?
pal: the cg has been considering a call for proposals
<fantasai> pal: Also some applications might want to provide their own mapping, so would need some information from the UA
pal: what is the capabilities of the display for minimum and maximum display luminance and of reference white?
pal: possiblility to increase fingerprinting surfs and introduces privacy concerns
rossen: focus the conversation
rossen: what is the path forward?
chris: what are the colorspaces suggesting for canvas, are they all available in css ideally?
rossen: confirms, yes would be ideal
<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?
chris: on other issue, there is already an unofficial draft created. waiting for interest shown
chris: brought down to simple high level proposed resolution, and propose to work on the draft together
<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)
<dbaron> https://
<chris> Paul, please have a look at https://
paulg: has question and concern on samsung browser full canvas interface. would be excited. Is there a lag time between canvas and web implementation?
paulg: if these are only available for Canvas, devs might use Canvas rather than Web in the interim, which can leave alot of people out on accessibility
paulg: what coordination to do with color coordinations to accommodate for higher luminance?
chris lilley: already have accessibility considerations on the draft
rossen: let's answer high level bit to continue working on in csswg, and move onto other issues
pal: thank group for opportunity, focus on the colors
<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
<chris> Proposed Resolution: CSS WG adopts the CSS Color HDR draft as a work item
florian: question: out of 3 color spaces, are they different ways of achieving the same thing that we expect one to win, or do we need all three?
chris lilley: we need all three, they have different use cases
<chrishtr> sgtm
rossen: objections?
RESOLUTION: CSS WG adopts the CSS Color HDR draft as a work item
RESOLUTION adopt the CSS Color HDR draft as a work item
RESOLUTION: CSS WG adopts the CSS Color HDR draft as a work item
rossen: archive is in the IRC
rossen: next-issue #9511
<Rossen_> github-bot: take up w3c/
[css-text][text-spacing] Visual regressions of line-start at portals and news sites
<github-bot> OK, I'll post this discussion to https://
chris harrelson: css property is text-spacing trim
<fantasai> spec
christ: current spec causes compatibility issues in japanese sites
chris h: existing behavior has use cases, make the default what is currently case, add keywords, current comment is out of date, add normal
chris h: second discussion for additional keywords to add, propose to segment, discuss, and resolve
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
florian: keep space in start, and trim adjacent, cohesive investigation
chris h: thank you for clarifying
<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
rossen: request for other feedback
<emilio> looks sensible to me at a glance
<fantasai> w3c/
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
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.
vitor: normal value wouldn't be equivalent to space-all? fantasai: no
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
rossen: sibling property of auto-space possibly something equivalent
florian: within issue on GitHub, everyone feels pretty aligned
<fantasai> PROPOSED: Initial value of text-spacing is 'normal' representing the 'space-start trim-adjacent allow-end' behavior
rossen: summarize ask for proposed path forward?
florian: has the proposed resolution
rossen: any additional comments to proposed resolution?
<fantasai> w3c/
<fantasai> Value syntax would be: normal | trim-start | space-first | trim-auto | space-all | trim-all | auto
florian: what do we do with other values? auto is already in spec, would be how to rebalance rest set of values
<fantasai> Current syntax is: space-all | trim-auto | [ allow-end || space-first ] | trim-all | auto
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
florian: most were not useful in implementation in browsers
rossen: ask for opinions?
fantasai: supports change
vitor: auto value will be there?
fantasai: yes
florian: auto matches operating systems native behavior. default would be normal
fantasai: we could also rename auto to match-platform to be more obvious
rossen: objections? none, resolved
RESOLUTION: Accept Murakami's proposal to simplify to text-spacing: normal | trim-start | space-first | trim-auto | space-all | trim-all | auto
RESOLUTION: remap property value space for text-spacing
<astearns> github-bot: take up w3c/
[css-view-transitions-1] Disallow the name `auto` as `view-transition-name`
<github-bot> OK, I'll post this discussion to https://
bramus: right now the property transition view name accepts auto.-ident in #8319, might be feasible to add alternate shorthand name, use value of auto in that case
<fantasai> bramus: this would create a conflict with view-transition-name, so propose to disallow auto
RESOLUTION: disallow auto for view-transition-name
RESOLUTION: disallow auto for view-transitions-name/view-transitions
rossen: keep going to next issue
[css-scoping] Always serialise the implicit `:scope` ?
rossen: always serialize implicit scope?
matthieu d: in css copying spec all rules in the spec have a : scot selector, nesting serialize implicit selector, value context related to selector
tabatkins: more transportable to other spots for javascript copying and pasting
emilio: consistent for @ scope or nested inside, still seems fine
miriam: question, what implications does this have for the behavior or just internal?
matthieu d: no implication, only for serialization, one value for specificity, already counted
miriam: some questions from roman about nesting and scope and how the implicit scope works in nested context
matthieu d: serializing when there is an implicit scope
rossen: any other questions/concerns?
rossen: any objections?
PROPOSAL: serialize implicit scope pseudoclass in rule selectors
RESOLUTION: serialize implicit scope pseudoclass in rule selectors
<Rossen_> github-bot: take up w3c/
[css-transitions] Transition to height (or width) "auto"
<github-bot> OK, I'll post this discussion to https://
TabAtkins: People have been asking for transition height 0 - auto since beginning of transitions
TabAtkins: also have use cases for other definite heights
TabAtkins: Other one is, not just transitioning from auto, but any of the intrisinc keywords
TabAtkins: to/from zero to any other value is commonly desired, for good shuttering animations
TabAtkins: the most obvious solution is to let people use intrinsic sizing keywords in calc()
TabAtkins: this isn't great, I explain why in issue, short version is
TabAtkins: several layout algorithms branch based on exactly which intrinsic sizing behavior being invoked
TabAtkins: What's min-content/2 vs fit-content/2
TabAtkins: could affect element and/or its neighbors different
TabAtkins: We also have other behavior, e.g. cyclic percentages, which can have intrinsic behavior
TabAtkins: You can interpolate among percentages, but if you interpolate 100% to 0 at 50% you'd still have auto to 0
TabAtkins: creates a jump
TabAtkins: Propose to introduce a new function
TabAtkins: first arg is an intrinsic size calculation
TabAtkins: second arg is a calculation
TabAtkins: it can accept a size keyword
TabAtkins: this forces relying on a single intrinsic size
TabAtkins: and also means you can transition cyclic percentages
TabAtkins: Also, by having as a separate function, this gives us a hook for activating better transition behavior automaticall
TabAtkins: right now, min-content to 100px, it is discrete transition behavior
TabAtkins: having a new function on one end allows us to automatically upgrade both sides to the function
TabAtkins: Can go over more details if ppl have questions, but in general I think this is the right way to go
TabAtkins: would like to introduce to values-5
TabAtkins: dbaron wants to Intent to Experiment
<dbaron> Intent to Prototype, not intent to Experiment :-)
lea: To make sure I understand, reason of new function is so that there's only one intrinsic sizing keyword and not multiple?
TabAtkins: that's the main one, a few other reasons
lea: would it be possible to use regular calc() and just apply that restriction?
TabAtkins: You have non-keyword intrinsic size things, like cyclic percentage
TabAtkins: you couldn't d othose
TabAtkins: but if we ignore that case
TabAtkins: we could, but it makes for more difficult debugging
TabAtkins: you have to know that the restriction exists
TabAtkins: it's possible to learn, just seems a step further than I would usually want to require for authors
lea: If we use calc(), there's a clear path to relaxing restrictions over time
TabAtkins: I doubt the problems I mention are solveable. The branching on layout algorithms is important
TabAtkins: not likely to change
TabAtkins: so don't think there's a path to mixing in calc() ever
lea: evolution is only one reason, and often group does the impossible later down the line
lea: authors might not hit the restriction, not common in use cases
lea: have to learn a new function
TabAtkins: have to pay a learnability tax
TabAtkins: calc-size() solving other problems better seems worth it to me
TabAtkins: folding it into calc() has those problems, and also a different type of learnability hit
dbaron: anotehr case is opt-in to new behavior, the function provides this. If we use calc, we need a separate switch.
<TabAtkins> fantasai: My first impression is that it does make sense to do this as a separate fucntion, for the reasons metnioned
<TabAtkins> fantasai: Like to and from 0, if you're just 0 you'll lose the branching behavior
<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
Rossen_: any other comments?
TabAtkins: proposed resolution is add calc-size() to css-values-5 and work out details there
Rossen_: objections?
RESOLUTION: Add calc-size() to css-values-5 and work out details there
End
Rossen_: reminder to add yourself to F2F wiki
https://
Rossen_: That's it for 2023! See you in 2024