- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 21 Dec 2023 10:45:15 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Color HDR
-------------
- RESOLVED: CSS WG adopts the CSS Color HDR draft as a work item
(Issue #9306: Add mechanism to query HDR headroom)
CSS Text
--------
- RESOLVED: Remap property value space for text-spacing (Issue #9511:
Visual regressions of line-start at portals and news
sites)
- RESOLVED: Accept Murakami's proposal to simplify to text-spacing:
normal | trim-start | space-first | trim-auto | space-all
| trim-all | auto (Issue #9511)
View Transitions
----------------
- RESOLVED: Disallow auto for view-transitions-name/view-transitions
(Issue #9639: Disallow the name `auto` as
`view-transition-name`)
CSS Scoping
-----------
- RESOLVED: Serialize implicit scope pseudoclass in rule selectors
(Issue #9621: Always serialize the implicit `:scope` ?)
CSS Transitions
---------------
- RESOLVED: Add calc-size() to css-values-5 and work out details
there (Issue #626: Transition to height (or width) "auto")
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2023Dec/0008.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins-Bittner
David Baron
Keith Cirkel
Emilio Cobos Álvarez
Yehonatan Daniv
Elika Etemad
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Pierre-Anthony Lemieux
Vladimir Levin
Chris Lilley
Peter Linss
Eric Meyer
ChangSeok Oh
Florian Rivoal
Vitor Roriz
Brandon Stewart
Miriam Suzanne
Bramus Van Damme
Lea Verou
Regrets:
Sebastian Zartner
Chair: Rossen
Scribe: frances
CSS Color HDR
=============
Add mechanism to query HDR headroom
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9306
Rossen: Let's start with the first few issues
pal: Present background behind issues and areas to collaborate
Rossen: I will try and help you
pal: Sounds great, might not solve in 10 minutes, maybe solve later
[archived presentation:
https://lists.w3.org/Archives/Public/www-archive/2023Dec/0006.html ]
pal: Presentation on adding HDR imagery to html canvas for css
requirements
pal: highlight some work on color on web
pal: So far the web has standard images. Effort to bring to both tv
and movies, pcs, higher dynamic range images, much broader range
of luminescence, darker and brighter than png images used to
pal: In order to enable this, higher pixel beyond 8 bits beyond power
law gamma transfer function, much effort done in the past decade
[pal explains SDR - standard images, whose ranges 0-100 nits, the
range of luminance in a standard laptop]
pal: 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
[Slide: add HDR colorspaces to Canvas; add higher bit depth to Canvas
etc.; add image color volume info to Canvas ; add display color
volume 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: Should I pause for questions
Rossen: Suggest 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
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 community group has been considering a call for proposals
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: Possibility to increase fingerprinting surfs and introduces
privacy concerns
Rossen: Let's focus the conversation
Rossen: What is the path forward?
<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: What are the colorspaces suggesting for canvas, are they all
available in css ideally?
Rossen: Confirm; yes would be ideal
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://drafts.csswg.org/css-color-hdr/
PaulG: I have a 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 a lot of
people out on accessibility
PaulG: What coordination to do with color coordination to accommodate
for higher luminance?
<chris> Paul, please have a look at
https://drafts.csswg.org/css-color-hdr/#a11y
chris: 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: Thanks to the group for opportunity, focus on the colors
<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: We need all three, they have different use cases
<chrishtr> sgtm
Rossen: Objections?
RESOLVED: CSS WG adopts the CSS Color HDR draft as a work item
CSS Text
========
Visual regressions of line-start at portals and news sites
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1839208142
chrishtr: CSS property is text-spacing trim
<fantasai> spec ->
https://www.w3.org/TR/css-text-4/#text-spacing-trim-property
chrishtr: Current spec causes compatibility issues in japanese sites
chrishtr: Existing behavior has use cases, make the default what is
currently case, add keywords, current comment is out of
date, add normal
chrishtr: Second discussion for additional keywords to add, propose
to segment, discuss, and resolve
florian: I think 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
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
chrishtr: Thank you for clarifying
Rossen: request for other feedback
<emilio> looks sensible to me at a glance
<fantasai> https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1853187016
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-all 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?
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 the issue on GitHub, everyone feels pretty aligned
Rossen: Summarize ask for proposed path forward?
<fantasai> PROPOSED: Initial value of text-spacing is 'normal'
representing the 'space-start trim-adjacent allow-end'
behavior
florian: Issue has the proposed resolution
Rossen: Any additional comments to proposed resolution?
<fantasai> https://github.com/w3c/csswg-drafts/issues/9511#issuecomment-1862787959
<fantasai> Value syntax would be: normal | trim-start | space-first |
trim-auto | space-all | trim-all | auto
<fantasai> Current syntax is: space-all | trim-auto | [ allow-end ||
space-first ] | 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
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: I support the change
vitorroriz: 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
RESOLVED: Accept Murakami's proposal to simplify to text-spacing:
normal | trim-start | space-first | trim-auto | space-all |
trim-all | auto
RESOLVED: Remap property value space for text-spacing
<florian> thanks to the Koji / Chrome team for doing the detailed
compat investigation
<fantasai> +1
View Transitions
================
Disallow the name `auto` as `view-transition-name`
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9639
bramus: right now the property transition view name accepts
custom-ident in #8319, might be feasible to add alternate
shorthand name, use value of auto in that case
bramus: this would create a conflict with view-transition-name, so
propose to disallow auto
RESOLVED: disallow auto for view transitions
RESOLVED: disallow auto for view-transitions-name/view-transitions
Rossen: Keep going to next issue
CSS Scoping
===========
Always serialize the implicit `:scope` ?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9621
Rossen: Always serialize implicit scope?
matthieu: In css scoping spec all rules in the spec have a :scope
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: 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: Serializing when there is an implicit scope
Rossen: Any other questions/concerns?
Rossen: Any objections?
PROPOSAL: serialize implicit scope pseudoclass in rule selectors
RESOLVED: Serialize implicit scope pseudoclass in rule selectors
CSS Transitions
===============
scribe: fantasai
Transition to height (or width) "auto"
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/626#issuecomment-1800254442
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 intrinsic 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
automatically
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 people 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 do those
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: Another case is opt-in to new behavior, the function provides
this. If we use calc, we need a separate switch.
fantasai: My first impression is that it does make sense to do this
as a separate function, for the reasons mentioned
fantasai: Like to and from 0, if you're just 0 you'll lose the
branching behavior
fantasai: This provides a way where even if the calc evaluates to
zero, 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?
RESOLVED: Add calc-size() to css-values-5 and work out details there
Rossen: Reminder to add yourself to F2F wiki
<fantasai> -> https://wiki.csswg.org/planning/mountain-view-2024
Rossen: That's it for 2023! See you in 2024
Received on Thursday, 21 December 2023 15:45:49 UTC