17:02:41 <RRSAgent> RRSAgent has joined #css
17:02:45 <RRSAgent> logging to https://www.w3.org/2025/02/12-css-irc
17:02:45 <kbabbitt> kbabbitt has joined #css
17:02:45 <Zakim> RRSAgent, make logs Public
17:02:46 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
17:02:50 <noamr> present+
17:02:56 <kbabbitt> present+
17:03:02 <gfaujdar> gfaujdar has joined #css
17:03:15 <emilio> present+
17:03:23 <smfr> smfr has joined #css
17:03:24 <jfkthame> present+
17:03:25 <kizu> kizu has joined #css
17:03:25 <miriam> present+
17:03:29 <joshtumath> present+
17:03:29 <kizu> present+
17:03:31 <smfr> present+
17:03:31 <gfaujdar> present+
17:05:02 <alisonmaher> https://wiki.csswg.org/planning/newyork-2025#new-york-f2f-april-2025
17:05:15 <argyle> argyle has joined #css
17:05:15 <astearns> thanks, alisonmaher!
17:05:22 <argyle> present+
17:06:06 <noamr> Meeting is going to be held at the MS office in NYC, April, see wiki link
17:06:09 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/6323
17:06:09 <github-bot> Topic: [css-cascade-5] Allow authors to explicitly place unlayered styles in the cascade layer order
17:06:09 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6323.
17:06:17 <vmpstr> present+
17:06:42 <bkardell_> bkardell_ has joined #css
17:07:08 <schenney> schenney has joined #css
17:07:11 <noamr> miriam: we discussed this at the f2f. we seem to have a solution in the thread. the goal is being able to name layers that are stronger than unlayered styles
17:07:27 <chrishtr> present+
17:07:38 <noamr> miriam: the proposal is to have a character before the name that marks that a layer is stronger rather than weaker than unlayered style
17:08:13 <noamr> miriam: we suggested the caret, a concern was raised that the character should not be part of the name. this sent us back. in that thread we've agreed on a path forward, if we're ok going with this
17:08:41 <kizu> kizu has joined #css
17:08:51 <noamr> miriam: 1. resolving that we're taking on the caret approach at the beginning of the layer name. 2. The caret is syntax rather than a layer name.
17:09:11 <noamr> miriam: this allows one issue to discuss, whether we allow name conflicts between strong and weak layers of the same name
17:09:12 <TabAtkins> q+
17:09:24 <noamr> miriam: sounds OK?
17:09:30 <Rossen6> ack TabAtkins
17:09:50 <noamr> TabAtkins: seems fine. It would have been ok in the name but this is acceptable. for name conflicts, everything gets more complex if we try to prevent conflicts
17:10:15 <noamr> TabAtkins: it's reasonable if weak/strong names are different in the CSSOM, works similar to important
17:10:18 <kizu> +1
17:10:21 <bramus> +1
17:10:26 <noamr> miriam: seems right
17:10:45 <kbabbitt> +1 to the proposal, I had someone ask about this feature the other day
17:10:57 <noamr> rossen: anyone wants to add? challenge?
17:11:27 <noamr> PROPOSED RESOLUTION: we use a caret approach. It's part of the syntax and not part of the name. Weak/strong with the same name is ok
17:11:58 <noamr> bramus: also something about CSSOM?
17:12:09 <noamr> miriam: we expose strength in CSSOM
17:12:31 <TabAtkins> names come in "strong" and "weak" versions, in the CSSOM there's a bool that reflects this; in the @layer rule a ^ prefix indicates it's strong
17:12:38 <noamr> RESOLVED: we use a caret approach. It's part of the syntax and not part of the name. Weak/strong with the same name is ok
17:12:49 <noamr> PROPOSED RESOLUTION: strength is exposed in CSSOM, detailxz TBD
17:13:13 <noamr> rossen: objections?
17:13:16 <noamr> RESOLVED: strength is exposed in CSSOM, details tbd.
17:13:31 <noamr> rossen: miriam, you're going to follow up?
17:13:32 <noamr> miriam: sure
17:14:00 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11408
17:14:00 <github-bot> Topic: [css2][css-tables] Do collapsed tracks also shrink the table wrapper box or only the table grid box?
17:14:00 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11408.
17:15:00 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/3720
17:15:00 <github-bot> Topic: [css-borders] Add a 'hairline' border-width value
17:15:00 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/3720.
17:16:17 <noamr> noamr has joined #css
17:16:39 <noamr> TabAtkins: people look for a hairline border-width, usually "as thinner as visible", something like device pixels
17:17:10 <noamr> TabAtkins: we saw that it's not something that we want to expose because it varies across devices. Authors don't anticipate this change
17:17:18 <noamr> TabAtkins: we'd like to avoid this
17:17:27 <noamr> TabAtkins: device pixels is not always well defined
17:17:38 <noamr> TabAtkins: also it's not clear what happens if it's zoomed
17:17:47 <noamr> TabAtkins: this can become very small
17:18:20 <sgill> sgill has joined #css
17:18:29 <noamr> TabAtkins: kbabbitt suggested to declare that hairline is exposed as 1px, but rendered in an implementation-defined way, probably something like device pixel aligned
17:18:42 <smfr> q+
17:18:46 <Rossen6> q+
17:18:48 <joshtumath> q+
17:19:03 <noamr> TabAtkins: we can define how hairline works for each CSS property, e.g. border/column etc
17:19:24 <noamr> TabAtkins: this would allow accessibility options for users who need to scale the hairline, and this won't mess up design
17:19:42 <flackr> q+
17:19:54 <noamr> TabAtkins: I suggest we take Kevin's proposal and add it to the border-spec and columns spec for multicol rule, perhaps to other specs that need this
17:19:57 <emilio> q+
17:20:09 <Rossen6> ack smfr
17:20:25 <noamr> smfr: I'm concerned that the painted width is different from the background. it means that the background is going to leak out of the hairline
17:20:31 <flackr> q- same q as smfr
17:20:35 <flackr> q-
17:20:44 <noamr> smfr: we can apply the same heuristic, but it seems weird that the geometry doesn't match
17:20:59 <Rossen6> q-
17:21:01 <noamr> TabAtkins: we should define that background area extends, but doesn't paint
17:21:11 <noamr> smfr: it doesn't work with box-shadow, adjacent boxes
17:21:21 <bkardell_> present+
17:21:23 <noamr> TabAtkins: I think it's a good thing, but probably usually fine
17:21:30 <kbabbitt> q+
17:21:47 <dholbert> RE the gap, you'd *only* get a gap on a HiDPI screen, which is weird
17:21:49 <noamr> smfr: my suggestion would be that the border-width would be some fractional implementation defined value rather than being different
17:21:50 <gill> gill has joined #css
17:22:36 <noamr> Rossen: I can see how this would work if it takes the outermost part of the pixel, e.g. there should never be background that extends out, same for shadows etc. Anywhere else, you're asking for all of the trouble smfr pointed out
17:22:55 <noamr> TabAtkins: I was describing it wrong. The details in the thread are to have it on the outside, exactly for these issues
17:23:05 <noamr> TabAtkins: let's go with that
17:23:16 <emilio> It reveals the underlying background unless it uses `padding-box` or so right?
17:23:25 <TabAtkins> yes
17:23:30 <noamr> Rossen: it's going to break things that align, like snapping/abs position etc
17:24:01 <noamr> joshthumath: similar note, the stripes function (not implemented yet). what would happen when we want multiple hairline-width stripes?
17:24:17 <sgill> sgill has joined #css
17:24:23 <sgill> present+
17:24:25 <noamr> TabAtkins: I think hairline wouldn't be a generic width value, it's a value for specific properties like border-width
17:24:35 <kizu> Fun fact: Chrome paints `2px double` border as 2 hairline lines with a gap
17:24:56 <noamr> TabAtkins: we'd probably won't paint stripes in a hairline-widdth border
17:25:04 <Rossen6> ack emilio
17:25:10 <Rossen6> ack joshtumath
17:25:27 <joshtumath> s/joshthumath/joshtumath/
17:25:37 <noamr> emilio: I was going to raise a lot of smfr's concerns. I don't object to hariline value, but I think we can change the border bounding algorithm we have to bound towards the nearest hairline
17:26:10 <noamr> emilio: the UA already aligns pixels e.g. 0.01 border-width to something that's hairline-like
17:26:42 <noamr> emilio: I would prefer to tweak the current border-width rounding to a hairline
17:27:10 <noamr> emilio: for shadows, it's not a huge issue. maybe it's just a matter of implementing stripes
17:27:35 <noamr> emilio: I much rather expose the current border-width rounding and allowing the UA to tweak it, or expose a round-ish function
17:27:44 <smfr> Blink and WebKit round a 0.0001px border up to a hairline; Gecko doesn't draw it
17:28:14 <noamr> Rossen6: also what does this mean for two hairline borders to collapse
17:28:30 <emilio> smfr: Probably pixel precision issue, `0.01px` does get rounded up
17:28:54 <noamr> kbabbitt: I heard that in border the hariline would be painted on the outermost hairline, and the background would fill under that
17:29:13 <noamr> TabAtkins: it's not that the background fills in, it's that the background is drawn under the border area
17:29:42 <noamr> kbabbitt: I want to avoid something where when a designer defines something on a high DPI device it breaks on a different device with lower DPI
17:30:22 <noamr> Rossen6: I'm not sure where this was going. There are still some questions
17:30:38 <noamr> Rossen6: this sounds like a great proposal and something that people are trying to do today
17:30:53 <noamr> Rossen6: is that something we want to pursue? Do we have a good starting point?
17:31:01 <noamr> TabAtkins: we don't have all the details yet
17:31:11 <noamr> TabAtkins: I propose we take this back to the issue
17:31:18 <emilio> TabAtkins: wdyt of `border-snap(<length>)` which just snaps that length as a border or so?
17:31:58 <TabAtkins> emilio, that's part of why I don't *want* to rely on border rounding. "if you want a hairline, put in a value that is *probably* too small to actually paint, but not *too* small, and you have to guess what "too small" means"
17:32:01 <emilio> I think it's not incompatible with `hairline`, if we make hairline resolve to pixels and affect geometry...
17:32:07 <emilio> fair
17:32:07 <noamr> leaverou/leaverou_: join the call?
17:32:14 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10647
17:32:16 <github-bot> Topic: [css-shapes] Overload `path()` for CSS-y SVG path syntax instead of taking up `shape()`
17:32:16 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10647.
17:32:18 <lea> on it
17:32:32 <noamr> yay
17:33:26 <TabAtkins> lea: there's been dsicussion around making paths easier in CSS
17:33:38 <TabAtkins> lea: so far it's still very closely mapped to SVG paths
17:34:03 <TabAtkins> lea: taking the design of paths, with its concepts, segments, commands, args, and supporting a CSS syntax for them
17:34:11 <TabAtkins> lea: that's what we've done with the other shapes already too
17:34:19 <TabAtkins> lea: polygon(), circle(), etc
17:34:20 <noamr> q+
17:34:29 <kbabbitt> q-
17:34:30 <Rossen6> ack kbabbitt
17:34:38 <TabAtkins> lea: so it seems weird that we leave path() as this weird function that just takes a string of SVG, and make a different shape() function for the cssy one
17:34:43 <TabAtkins> lea: less discoverable and inconsistent
17:34:57 <TabAtkins> lea: when i filed this issue, thought we might leave shape() for another feature
17:35:08 <TabAtkins> lea: but now I think overloading path() is better even disregarding that
17:35:21 <Rossen6> ack noamr
17:35:37 <TabAtkins> noamr: shape() does already ahve a few features that SVG doesn't, or does it differently
17:35:48 <TabAtkins> noamr: order of control points, you can combine rel/abs in the same shape
17:36:00 <TabAtkins> noamr: now adding corner shapes, that'll probably get added to shape()
17:36:15 <lea> q+ You can combine relative and absolute in the same shape in `<path>` too? Also, the idea was that we'd eventually backport corner rounding  to `<path>` too
17:36:17 <TabAtkins> noamr: but also, I think path() can still be extended to make it actually usable, by giving it viewbox and fit
17:36:21 <lea> q_
17:36:22 <lea> q+
17:36:29 <TabAtkins> (lea, he meant combining in one command)
17:36:47 <TabAtkins> noamr: i don't have a strong opposition to calling this path(), but I do think they're a bit different
17:36:52 <TabAtkins> noamr: shape() is a recipe to create a shape
17:37:14 <TabAtkins> noamr: once you combine the shape with a reference box, the path you get can be vastly different from what svg coudl make
17:37:30 <TabAtkins> noamr: so i think keeping shape() separate makes sense as it's a recipe to create paths rather than the path itself
17:37:37 <stepheckles> stepheckles has joined #css
17:37:47 <TabAtkins> noamr: also the mental model fo path() is closely related to SVG, and if it's extended as I propose it'll stay close to SVG
17:38:00 <TabAtkins> lea: you mention rounding
17:38:01 <Rossen6> ack lea
17:38:15 <TabAtkins> lea: i think we eventually want to backport some of these improvement to path, at least those that are feasible
17:38:31 <TabAtkins> lea: but in general i think a better shape function is useful, it just worries me that we're leaving this gap
17:38:59 <TabAtkins> lea: authors will expect a CSS syntax for <path> like the other functions/elements have, and they'll find path() and shape() is a different thing
17:39:04 <noamr> q+
17:39:26 <Rossen6> ack noamr
17:39:34 <TabAtkins> noamr: we dont' have proposals to backport the new stuff to SVG, or filling in gaps
17:39:37 <smfr> +1
17:40:02 <TabAtkins> noamr: so right now, is this better to give a new name with the intention that it'll continue growing, or should we name it path() and say it's a CSS-ified <path> but with extensions
17:40:03 <lea> q+
17:40:14 <TabAtkins> noamr: I think it ends up just being a name thing
17:40:25 <TabAtkins> noamr: No strong opinion, but weak pref for shape()
17:40:49 <lea> q?
17:40:58 <smfr> q+
17:41:14 <Rossen6> acl lea
17:41:18 <TabAtkins> lea: replying to "no proposals for backport"
17:41:23 <Rossen6> ack lea
17:41:32 <TabAtkins> lea: when designing syntax, it's not just about what proposals exist now, bute what future direciton the language might go to
17:41:37 <TabAtkins> lea: that's the challenge with standards
17:41:51 <TabAtkins> lea: things like backporting rounding to <path> is a low-hanging fruit I think we could end up with
17:41:57 <TabAtkins> lea: so we shoudl plan around it
17:42:00 <TabAtkins> q+
17:42:10 <TabAtkins> smfr: I feel more strongly than Noam that shape() is right
17:42:19 <TabAtkins> smfr: it's more discoverable, search for "css shape function" you'll find it
17:42:31 <TabAtkins> smfr: I see it being used a lot with future border-shape, so shape() seems natural
17:42:47 <TabAtkins> smfr: i sympathize with lea that we shoudl design for the future, but we can choose a different name in the feuture if needed
17:42:53 <Rossen6> ack smfr
17:42:57 <lea> present+
17:42:57 <Rossen6> ack TabAtkins
17:43:28 <noamr> TabAtkins: re any backporting/future extensions of path(), to the extent we want to backport anything into SVG, we'll still be spelling it in the SVG way and would probably want to maintain this in-string capability
17:43:29 <lea> q+
17:44:08 <noamr> TabAtkins: if we don't backport to SVG, but just add to the string that SVG defines, it would look quite different from what shape is doing, because you can't drop things as easily into a command because of the parsing
17:44:24 <noamr> TabAtkins: anything we add to SVG would probably not make it into the path itsself. I'm not hopeful
17:44:44 <noamr> lea: another benefit is that it's convertable
17:45:11 <noamr> lea: I'm convinced that the current design is good enough. I wonder how much can be backported to path?
17:45:32 <noamr> TabAtkins: what kind of improvements?
17:45:55 <noamr> lea: same segments with CSSified names, length-percentage etc
17:46:05 <Rossen6> ack lea
17:46:10 <noamr> smfr: a more restricted grammar of this
17:46:15 <noamr> lea: sounds perfect
17:46:36 <TabAtkins> noamr: i'm also okay with taht possibility, think it's doable to take the subset of shape() be ported back to path()
17:46:52 <lea> PROPOSED RESOLUTION: shape() remains as-is, spec subset that is more tightly tied to SVG <path> for a path() overload
17:47:06 <TabAtkins> Rossen6: so I'm hearing keep shape() as is... [basically restates lea's proposed resolution]
17:47:22 <noamr> +1
17:47:24 <TabAtkins> +1
17:47:25 <smfr> +1
17:47:53 <chrishtr> +1
17:48:46 <TabAtkins> RESOLVED: shape() remains as-is, spec subset that is more tightly tied to SVG <path> for a path() overload
17:49:23 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10773
17:49:23 <github-bot> Topic: [css-view-transitions-2] Elements with content-visibility in new Document
17:49:23 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10773.
17:50:27 <TabAtkins> noamr: issue with how cross-document VTs, the order that things are discovered for an incoming VT
17:50:46 <TabAtkins> noamr: We check for the names, and only after check if the element is visible (based on content-visibility:auto)
17:51:15 <TabAtkins> vmpstr: for initial c-v:auto determination, it happens during "update the rendering" in html
17:51:32 <TabAtkins> vmpstr: if we ahve an incoming VT, we need to determine which elements are matched to the old doc *prior* to running "update the rendering"
17:51:54 <TabAtkins> vmpstr: so we have an issue, all the c-v:auto things aren't matched even if they're in the viewport, because we haven't determined their visibiility yet
17:52:10 <TabAtkins> vmpstr: so proposal is, if we ahve an incoming VT, we run the c-v:auto determination first
17:52:30 <TabAtkins> vmpstr: this might also apply to same-doc transitions if you've added an element to the DOM with c-v:auto
17:52:47 <Rossen6> q
17:52:48 <emilio> q+
17:52:49 <TabAtkins> vmpstr: but it's less clear that's needed, since the same-doc steps happen in a different spot. but we do want the same ability
17:53:13 <TabAtkins> emilio: are you proposing to run the determination steps again/first, or *move* them?
17:53:22 <TabAtkins> vmpstr: the initial determination has to just run before the VT matching steps
17:53:38 <TabAtkins> vmpstr: so i'm proposing that we do it *again* if there's an incoming VT
17:53:38 <Rossen6> ack emilio
17:54:05 <TabAtkins> vmpstr: doesn't duplicate work because the second time it's not the initial determination, it's a subsequent
17:54:12 <TabAtkins> emilio: I thought VT operations already happened after this, maybe I was wrong
17:54:22 <TabAtkins> vmpstr: for the cross-doc case, it happens before
17:54:32 <TabAtkins> vmpstr: it needs to happen before frames are drawn in the new doc
17:54:38 <TabAtkins> vmpstr: so "udpate the rendering" hasn't run yet
17:55:03 <TabAtkins> emilio: okay, so cross-doc VT runs the c-v:auto determination explictly, outside the rendering loop
17:55:06 <TabAtkins> vmpstr: yeah
17:55:16 <TabAtkins> emilio: it's a little sad, might expect intersection observers to also work...
17:55:29 <TabAtkins> emilio: maybe it's better to run the whole rendering loop but not point, that seems tricky to define tho
17:55:38 <TabAtkins> emilio: maybe that's fine, but wondering if we've consdiered larger changes like that
17:55:41 <TabAtkins> vmpstr: we haven't
17:55:50 <TabAtkins> vmpstr: the c-v case was a bug report
17:55:56 <TabAtkins> vmpstr: haven't seen other cases reported yet
17:56:08 <TabAtkins> vmpstr: don't thi8nk we want to run the rAF handlers without them producing paint
17:56:25 <TabAtkins> emilio: maybe not, but also it might not be too bad?
17:56:36 <TabAtkins> emilio: but if you did a c-v:auto-like thing with IO you might want that to run
17:56:38 <bramus> q+
17:56:47 <TabAtkins> emilio: seems a bit whack-a-mole if we need to keep adding things for the VT step
17:57:09 <TabAtkins> vmpstr: if there's script involved, yeah, that won't trigger. but c-v is a CSS thing, so as long as things are declarative they should all "work"
17:57:14 <TabAtkins> vmpstr: but script is tricky
17:57:27 <smfr> +1 to emilio
17:57:38 <TabAtkins> emilio: i think my pref would be to try running one frame without painting, that might work, but that's a bit awkward. dont' want to block if you're certain on this approach, just feels a bit special-casey for my taste
17:58:08 <TabAtkins> bramus: wanted to underline the c-v part affects whether the element is captured or not, authors have reported that
17:58:15 <Rossen6> ack bramus
17:58:20 <TabAtkins> bramus: maybe we can resolve on just the c-v part and then experiment with the frame render?
17:58:26 <emilio> q+
17:58:35 <TabAtkins> bramus: some people are blocked on this right now, they can't add the c-v perf improvement to their website due to VTs
17:58:37 <Rossen6> ack emilio
17:59:09 <TabAtkins> emilio: there are two approaches, right? a third is to make c-v:auto not behave as hidden for VT. i think scrollIntoView() already acts like you're visible
17:59:13 <TabAtkins> emilio: so it's not unheard of
17:59:33 <TabAtkins> vmpstr: with find-in-page there's no difference, but this would defeat the style optimation for c-v:auto on navigations that have an incoming VT
17:59:53 <TabAtkins> vmpstr: there's no user action besides the navigation, and we need to run style on the whole document to find names then
18:00:19 <TabAtkins> vmpstr: we've previously decided that in same-doc, if a c-v auto is off-screen then a sub-element won't be available for VT
18:00:31 <TabAtkins> emilio: right, point is that you don't have to paint it, you just check for names
18:00:55 <TabAtkins> Rossen6: out of time on the call, don't feel like we're ready to resolve.
18:01:00 <TabAtkins> Rossen6: continue discussion in the issue
18:01:16 <TabAtkins> github-bot, end topic
18:01:28 <TabAtkins> Rossen6: reminder, breakout on HDR taking place in two hours (noon pacific)
18:01:47 <TabAtkins> TabAtkins: HDR using this zoom?
18:01:55 <TabAtkins> astearns: no, different zoom, link in private list
18:03:07 <flackr> present+
18:03:32 <astearns> HDR zoom link in https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0094.html
18:09:38 <astearns> zakim, end meeting
18:09:38 <Zakim> As of this point the attendees have been alisonmaher, bramus, flackr, ydaniv, noamr, kbabbitt, emilio, jfkthame, miriam, joshtumath, kizu, smfr, gfaujdar, argyle, vmpstr, chrishtr,
18:09:41 <Zakim> ... bkardell_, sgill, lea
18:09:41 <Zakim> RRSAgent, please draft minutes v2
18:09:42 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/12-css-minutes.html Zakim
18:09:49 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
18:09:49 <Zakim> Zakim has left #css
18:52:51 <dholbert_> dholbert_ has joined #css
19:51:34 <astearns> astearns has changed the topic to: HDR breakout agenda: https://lists.w3.org/Archives/Public/www-style/2025Feb/0003.html
19:58:06 <astearns> zoom link at https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0094.html (or message me directly)
19:58:46 <joshtumath> joshtumath has joined #css
19:59:49 <ChrisL> present+
19:59:58 <astearns> zakim, start meeting
20:00:47 <joshtumath> present+
20:01:53 <cpn> cpn has joined #css
20:02:48 <joshtumath> ScribeNick+
20:02:53 <cpn> present+ Chris_Needham
20:02:54 <smfr> present+
20:02:57 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11616
20:02:57 <github-bot> Topic: [css-color-hdr] CSS syntax for HDR colors parameterized by headroom
20:02:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11616.
20:03:01 <ChrisL> present+
20:03:40 <pal> pal has joined #css
20:03:52 <ccameron> ccameron has joined #css
20:04:05 <heycam> heycam has joined #css
20:04:05 <weinig> present+
20:04:16 <ccameron> hello!
20:04:16 <heycam> present+
20:04:44 <joshtumath> ccameron: Taking some ideas in ICC, and also colour matching with 8 map images in ISO
20:04:51 <joshtumath> ... A good way to deal with HDR colours
20:04:59 <joshtumath> ... We're not going to expose headroom directly
20:05:09 <joshtumath> ... recomputing every time there are changes is painful
20:05:16 <ChrisL> q+
20:05:24 <joshtumath> ... want to say headroom for this and that, and interoplate between the two in UA
20:05:45 <joshtumath> ... the UA and device can limit it
20:05:54 <smfr> q+
20:06:00 <joshtumath> ... wanted to present the idea. not the definitive way to do it
20:06:08 <joshtumath> ... good to wait until ICC stuff is in a good place
20:06:17 <joshtumath> ... but that's the idea. wanted to see if anyone has thoughts
20:06:19 <astearns> ack ChrisL
20:06:25 <joshtumath> ChrisL: I really like the idea
20:06:37 <weinig> q+
20:06:41 <joshtumath> ... for SDR, everything relative to medium white
20:06:46 <cpn> s/8 map/gain map/
20:06:48 <Zakim> Zakim has joined #css
20:06:52 <joshtumath> ... but HDR there is no single value to use but we can't expose the headroom
20:07:07 <joshtumath> ... in the original proposal, you can say what the headroom is for two colours
20:07:12 <joshtumath> ... but when would it not be 0?
20:07:29 <joshtumath> ... it's only defined in between. what if headroom is 2 and 4 on an SDR display?
20:07:37 <joshtumath> ccameron: it needs to be defined down to 0
20:07:54 <joshtumath> ... I'm still working on proposal for what to do with different headroom values
20:07:59 <joshtumath> ... maybe we should build that into the syntax
20:08:14 <joshtumath> ... for images, you can say-- Oh. There is a reason why not to have 0
20:08:29 <joshtumath> ... suppose you had content that you don't want to become HDR
20:08:45 <joshtumath> ... is that the most useful thing, I don't know
20:08:58 <joshtumath> ChrisL: we have to define what happens when headroom is 0
20:09:23 <joshtumath> ... could make the headroom 0 the default value. removes verbosity
20:09:30 <joshtumath> ... could have n values
20:09:41 <joshtumath> ... I don't want to make this too complicated. I want it to be good enough
20:09:44 <ChrisL> q?
20:10:12 <joshtumath> ccameron: I like that idea. I also think that if we workshop this, having an initial version with only two values, one headroom 0 sounds good
20:10:24 <joshtumath> ... maybe we do want the whole p?? wise thing
20:10:38 <joshtumath> ... it adds complexity, but I'd be happy to leave that out for v1
20:10:46 <joshtumath> ... make sure the common case is super simple
20:11:26 <joshtumath> smfr: The colour that you render, the comutation of that colour takes into account screen brightness?
20:11:33 <joshtumath> ccameron: yes
20:11:44 <joshtumath> smfr: need to treat it like accent colour and not paint it into canvas?
20:12:09 <joshtumath> ccameron: I think canvas right now, it's a snapshot at a fixed headroom. not possible to realise values at rendering
20:12:12 <pal> q+
20:12:28 <joshtumath> ... so I haven't written this up. but 2d canvas has a headroom that's 0 SDR
20:12:45 <joshtumath> ... so maybe render canvas by 2, but you need to tell canvas what the effective headroom is
20:13:01 <joshtumath> smfr: so there's no way of using the colour painted as a proxy for screen brightness?
20:13:09 <joshtumath> ccameron: there better not be!
20:13:21 <joshtumath> ... the goal is to make it so you can't exfoltrate that
20:13:40 <joshtumath> ... you have to re-render your entire page when the headroom changes, so we're aligned on that
20:13:48 <joshtumath> smfr: the screen brightness things are ramped
20:14:01 <joshtumath> ... I really want to avoid re-rendering on brightness change
20:14:08 <joshtumath> ChrisL: what is the alternative?
20:14:26 <joshtumath> ???: let the rendering change deal with the viewing environment
20:14:38 <astearns> s/???/pal/
20:14:47 <joshtumath> weinig: you can't write arbitrary PQ values
20:14:55 <joshtumath> pal: as long as we allow that, that's fine right?
20:15:07 <joshtumath> ... you're just writing HDR values and let the renderer deal with it
20:15:18 <joshtumath> ... as long as that's possible, everything else is optional convinience
20:15:33 <smfr> q+
20:15:33 <ccameron> q+ (for the topic of churning the WindowServer during ramp-up)
20:15:34 <joshtumath> ChrisL: Understand that will be possible but that's not topic
20:16:09 <joshtumath> pal: I think it's important. apps that will want additional control, may want this, but otherwise should be able to let renderer do its thing
20:16:28 <pal> q-
20:16:52 <joshtumath> weinig: I was thinking about this. if getting to parity with what images and video can do... if images have to recompute each pixel value...
20:16:56 <joshtumath> ... then this will have to, too
20:16:59 <astearns> q+ ccameron
20:17:11 <ChrisL> Agree that this is CSS parity for images/video
20:17:12 <joshtumath> ... it's as if you have lots of tiny images that you've loaded that have metadata with 'between these ranges'
20:17:30 <joshtumath> ... comfortable for implementation if it mirrors what images and video can already do
20:17:46 <joshtumath> ... so I think that should quell smfr's concerns
20:17:59 <joshtumath> ... it's something that engines already have to deal with
20:18:33 <joshtumath> ... we should discuss alternative of this proposal. new property with CSS colour values that should be treated as if they are HDR values and the system can do whatever tone mapping it wants
20:18:53 <joshtumath> ... I think there are some formats with no colour map. system decides how to tone map that
20:19:00 <joshtumath> ChrisL: yes PNG and ???? has that
20:19:07 <joshtumath> ... it's just the values
20:19:33 <joshtumath> weinig: so I think benefit to having the gain map, matching something that uses PQ values directly
20:19:43 <astearns> ack ccameron
20:20:04 <joshtumath> ccameron: yes absolutely. right now it's going on in ICC where you say 'here's my headroom dependent ICC profile'
20:20:15 <joshtumath> ... here's the transformation to get to headroom 3 1 0
20:20:37 <joshtumath> ... my goal with that is that can be something you can attach to canvas
20:20:50 <joshtumath> ... 'here's the tone mapping for different headrooms'
20:21:13 <joshtumath> ... and that packet, I'd like to have the same packet between video, images, CSS, canvas
20:21:19 <joshtumath> ... so that's another option
20:21:28 <smfr> q-
20:21:35 <joshtumath> ... perhaps that's better than the suggestion I had
20:22:09 <joshtumath> weinig: we just want to get the model of what's happening in the system. something like: you can attach to px some metadata about how to tone map
20:22:13 <joshtumath> ... and the compositor does it
20:22:41 <joshtumath> smfr: I think both. you map at paint time and ????. I'm not sure whether we redraw in the first case but I think we do
20:22:55 <joshtumath> ccameron: for us, if something is in a layer, we can delegate to the OS
20:23:08 <joshtumath> ... otherwise we rewrite every pixel when headroom changes
20:23:12 <joshtumath> ... we throttle it
20:23:15 <ChrisL> s/???/re-render the whole buffer/
20:23:20 <joshtumath> ... interopolate it out or in
20:23:38 <joshtumath> weinig: but for systems with display lists, etc, they don't have to block paint
20:24:01 <joshtumath> ... a concern is, if we're privacy minded, we don't leak this info through perf characteristics
20:24:14 <joshtumath> ccameron: on some platforms it's observable
20:24:27 <joshtumath> ... but the goal is to push as far down pipeline as possible
20:24:40 <joshtumath> weinig: but if we parallel what images can do, simplifies model
20:24:54 <joshtumath> astearns: where are we at. can we resolve to adopt?
20:25:13 <joshtumath> ... or the idea of a different packet to send around something to explore?
20:25:16 <ChrisL> q+
20:25:27 <joshtumath> ccameron: I want something written down and give ICC something public to point at
20:25:37 <joshtumath> ... it's an idea worth getting out to marinate
20:25:50 <joshtumath> ... get an idea of concerns. but I like the packet idea.
20:26:04 <joshtumath> ... we should try to incorporate that
20:26:19 <joshtumath> weinig: agreed needs to marinate. let engines experiment to see what is feasable
20:26:40 <astearns> ack ChrisL
20:26:41 <joshtumath> ... makes a lot more sense to figure out how for images and video it will start playing before we tackle this
20:26:56 <joshtumath> ChrisL: would like to see this in spec so people can see what we're looking at
20:27:02 <joshtumath> ... can't currently make a HDR colour
20:27:11 <joshtumath> ... rather people get to see something
20:27:29 <joshtumath> ... am rep to ICC. I know they tend to hide things until they're public.
20:27:53 <joshtumath> ... these are things to look at, and we need experimentation that's coordinated. get a stick in the ground to kick around
20:28:02 <joshtumath> weinig: maybe we could say in the spec that this is changing
20:28:04 <joshtumath> ChrisL: yes
20:28:16 <joshtumath> ... an explicit 'DO NOT SHIP!!!'
20:28:29 <joshtumath> astearns: we can point to the issue and put in a competing proposal too
20:28:52 <joshtumath> ccameron: everyone same page about: on chrome, you specify the colour and you get something bright
20:29:06 <joshtumath> ... the goal is for that to not be the case. you opt into a brighter colour is the goal
20:29:15 <joshtumath> ... otherwise you get gamut mapped to SDR
20:29:46 <joshtumath> PROPOSED RESOLUTION: put current proposal in spec with a note that we need to solve this and where discussion is happening
20:30:05 <joshtumath> RESOLVED: add current proposal as proposal into the spec
20:30:31 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11698
20:30:32 <github-bot> Topic: [css-color-hdr] New values for dynamic-range-limit property
20:30:32 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11698.
20:30:32 <joshtumath> s/as proposal/as note/
20:31:07 <joshtumath> said: the current value for dynamic-range-limit is 'high'
20:31:24 <joshtumath> ... we believe UA may want more control based on system conditions
20:31:35 <weinig> q+
20:31:38 <ccameron> q+
20:31:39 <joshtumath> ... we propose value of auto to pick properties from system
20:32:12 <joshtumath> astearns: there was an issue on auto. I thought you wanted to discuss other values first
20:32:22 <weinig> q-
20:32:23 <joshtumath> said: if we're talking about names, this property name is confusing
20:32:34 <joshtumath> ... if we look at dynamic range, 0 is r.
20:32:44 <joshtumath> ... dynamic range also is ????
20:32:56 <joshtumath> ... high is full brightness, 0 is 0 brightness
20:33:14 <joshtumath> ... I think we should change the names of values to show it's in the negative side and limit the ??? of the video
20:33:23 <joshtumath> ... is high high dynamic range or high limit on dynamic range
20:33:27 <joshtumath> ... suggestion of 'none'
20:33:34 <joshtumath> ... I think this is better than existing one
20:33:41 <joshtumath> smfr: or 'constrained'
20:33:55 <smfr> s/constrained/unconstrained/
20:34:09 <joshtumath> ccameron: I wrote the names and with discussion I agree they only make sense if you already know what they're doing
20:34:30 <joshtumath> ... I gave three options at F2F that ephasise these are the limits the author is placing
20:34:40 <joshtumath> ... so how do you say that the page doesn't want to limit itself?
20:34:50 <joshtumath> ... I agree 'high' is not intuitive
20:35:04 <joshtumath> ... so I am flexible on these terms
20:35:10 <astearns> q?
20:35:24 <joshtumath> ... I feel unable to give honest assessment. I was hoping we could vote or something
20:35:38 <joshtumath> ... issues like auto value come from how these proposed values are uncomfortable
20:35:49 <joshtumath> astearns: I prefer no-limit
20:35:59 <joshtumath> smfr: like background: no-repeat!
20:36:14 <joshtumath> ChrisL: I like no-limit as well
20:36:25 <joshtumath> astearns: should we resolve on that with option to bikeshed later?
20:36:49 <joshtumath> ChrisL: three values: you want SDR, as much HDR as you get and 'don't go overboard'
20:36:58 <joshtumath> ?????: could it be 'default'?
20:37:08 <joshtumath> smfr: only one browser has shipped this
20:37:16 <astearns> s/?????/nicole/
20:37:42 <joshtumath> ccameron: everyone serving HDR video will get a surprise if we change the default behaviour
20:37:52 <joshtumath> ccameron: not shipped yet
20:38:13 <joshtumath> ChrisL: just saying with no property specified, what do you get?
20:38:36 <joshtumath> smfr: I think we decided at F2F it should be about limiting. less HDR than what the UA could give
20:38:47 <ccameron> also pre-ramping in HDR headroom
20:38:51 <joshtumath> ... but maybe you want in an image editor on the web to say full HDR
20:39:13 <joshtumath> ... so the OS will constrain how much HDR allowed. and UA. constraints may differ depending on in full screen
20:39:23 <joshtumath> ... can you say 'go away constraint. I want HDR'
20:39:24 <ChrisL> q+
20:39:30 <ccameron> q+
20:39:50 <astearns> ack ccameron
20:39:53 <astearns> ack ChrisL
20:40:05 <astearns> q+ ccameron
20:40:09 <joshtumath> ChrisL: if you have one prop to limit it to less, and another to get more, how do you explain that?
20:40:11 <weinig> q+
20:40:25 <joshtumath> ... I'd rather one prop that gives you the full range. sounds like an auto value to me
20:40:33 <joshtumath> ... but I want to express give me it all or tone it down
20:40:40 <joshtumath> ... and it should be on the same property
20:40:50 <astearns> ack ccameron
20:41:04 <joshtumath> ccameron: the idea of saying I want all the HDR. would you set that on an element?
20:41:13 <joshtumath> ... you're saying 'hey wrap things up'
20:41:39 <joshtumath> ... one thing is when you think you're going in a certain headroom at some point in the future, so you could set the headroom early to get the effect
20:41:50 <joshtumath> ... or 'I know my page will use headroom 5'
20:42:05 <joshtumath> ... I view that as a hint to the OS of what to do. and asking for permission
20:42:07 <smfr> q+
20:42:12 <joshtumath> ... the OS may want to revoke that
20:42:45 <joshtumath> ... my feeling about the ramping, it's not something-- if we attach it to an element, it's not been great
20:42:55 <joshtumath> smfr: That makes sense
20:43:02 <joshtumath> ... it's like the wait lock API
20:43:14 <joshtumath> ... so the property we're talking about is only a limiting property
20:43:20 <astearns> ack weinig
20:43:29 <joshtumath> weinig: smfr came to my conclusion
20:43:39 <joshtumath> ChrisL: and I'm on the same page now as well
20:43:44 <astearns> ack smfr
20:43:48 <joshtumath> smfr: I think we can get back to bikeshedding
20:44:07 <joshtumath> weinig: but auto vs high. I think the default of high or no-limit is good
20:44:22 <joshtumath> ... everything is inherently 'auto'
20:44:26 <smfr> q+
20:44:32 <joshtumath> ... you say 'I don't need the system to do it'
20:44:53 <joshtumath> ... that's a strong thing. you don't want to put in effort to make sure images are non HDR
20:45:11 <joshtumath> ... you're saying there may be HDR pixels in there but ignore them
20:45:28 <joshtumath> ... existing concept of defaulting to 'do what you do' and then let the user ramp it down
20:45:36 <astearns> ack smfr
20:45:46 <joshtumath> smfr: I think there are legacy reason why auto might make more sense
20:46:01 <joshtumath> ... historically we've allowed video to be high, but we might not want that for images
20:46:14 <joshtumath> weinig: do images not have high today?
20:46:26 <joshtumath> smfr: we don't have HDR support in mobile safari
20:46:37 <joshtumath> ... we want to avoid the HDR in the corner of your eye problem
20:47:05 <joshtumath> weinig: you want to avoid accidental HDR? not annoying the user, the user could put 'high' on themselves
20:47:27 <joshtumath> ... I don't think having an annoyance as a blocker is going to be effective. you could make an accidental prevention thing at best
20:47:34 <astearns> q+
20:47:45 <joshtumath> ccameron: I worry about the auto thing being a way to opt into a quirk
20:48:06 <joshtumath> ... I prefer no limit as a default and the UA performs heuristics to make sure HDR is limited by default
20:48:28 <joshtumath> ... if a video occpuies x % of pixel area, you let the image shine through
20:48:42 <joshtumath> ... I think what limit is imposed by the UA needs to be imposed on ????? together
20:48:51 <joshtumath> ... that I think will come back and hurt us
20:48:59 <pal> q+
20:49:07 <smfr> q+
20:49:16 <astearns> q- later
20:49:26 <joshtumath> ... I think best resolution is to say for now, do heuristics for video, etc, and then the permission for headroom could be something we let pages start doing
20:49:47 <joshtumath> ... I think the opt out option is introducing an inconsistency to the model that will tear itself apart
20:50:02 <joshtumath> ... there is a continuum of pages that the author has specified
20:50:21 <joshtumath> ... so basically you specify that and the author says 'I'm outside of that continuum'
20:50:30 <joshtumath> ... I think it will cause compatibility issues
20:50:48 <weinig> q+
20:50:54 <joshtumath> ... I think of it like: a heuristic about the UA is how I'd like to accomplish that
20:51:08 <astearns> ack smfr
20:51:25 <joshtumath> smfr: ccameron said he would like the limits on the whole page, but we can't do that because of the legacy video HDR issue
20:51:30 <astearns> ack pal
20:51:34 <astearns> q- later
20:51:53 <ccameron> +1
20:51:56 <joshtumath> pal: I think having the UA police obnoxious content is ??. It's up to the author to make a page make sense
20:52:08 <joshtumath> ... if you don't want an obnoxious ad, don't let them on the page
20:52:14 <ccameron> and to amplify pal's comment, if we auto-limit things too much, then authors will get used to creating too-bright content
20:52:15 <joshtumath> ... it's too late for the UA to deal with it
20:52:27 <astearns> ack weinig
20:52:36 <joshtumath> weinig: one other option is to think about this from UA stylesheet perspective.
20:52:56 <joshtumath> ... is there a model where img elements get standard or whatever as default. video gets high as default.
20:53:16 <joshtumath> ... there are probably some version of this where concept is still there but reasonable defaults for UA stylesheet
20:53:16 <smfr> q+
20:53:22 <astearns> q- later
20:53:27 <joshtumath> ... doesn't help people using HDR background image, though
20:53:40 <joshtumath> ... someone could still accidentally have a HDR background image
20:53:44 <astearns> zakim, close queue
20:53:44 <Zakim> ok, astearns, the speaker queue is closed
20:54:16 <joshtumath> said: I think you mentioned we should fall back to no limit
20:54:26 <joshtumath> ... but I think opposite. no limit is like auto
20:54:37 <joshtumath> ... some blind heuristics will not be able to do it the same way
20:55:09 <joshtumath> astearns: all of this is intertwined. all the issues.
20:55:35 <joshtumath> ... we need to make decisions on these three issues. I don't think there's anything where we can say this is the output of the meeting
20:55:50 <joshtumath> ccameron: I agree we haven't resolved. I thought at the F2F we agreed auto is not needed
20:56:02 <joshtumath> ... It sounds like that wasn't where we got to
20:56:15 <joshtumath> ... names is close to resolution. auto still remains no consensus
20:56:30 <joshtumath> astearns: can we resolve to change high to no-limit?
20:56:39 <joshtumath> PROPOSED RESOLUTION: change high to no-limit
20:56:48 <joshtumath> RESOLVED: change high to no-limit
20:57:13 <pal> Thanks for the super clear agenda
20:57:13 <joshtumath> astearns: I thought this conversation was useful. meet again in two weeks?
20:57:15 <ccameron> O(1) more thing
20:58:04 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11672
20:58:05 <github-bot> Topic: [css-color-hdr] Clarification on the grammar / spec text for `dynamic-range-limit-mix()`
20:58:05 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11672.
20:58:31 <joshtumath> weinig: so it's just a clarification. whether the mix() function should take other mix() functions as the input?
20:58:42 <ccameron> q+
20:58:54 <joshtumath> ... and the other ?: could only 1 value in it make sense or should min be 2
20:58:54 <astearns> zakim, open queue
20:58:54 <Zakim> ok, astearns, the speaker queue is open
20:59:22 <joshtumath> ccameron: could have mix of mix. it seemed simplier to allow you to mix one value with itself, and have fewer rules
20:59:37 <joshtumath> weinig: it was more the grammar, maybe a typo. I can do a PR
20:59:47 <joshtumath> ChrisL: would be good
21:00:19 <astearns> topic: end
22:02:19 <geheimnis`> geheimnis` has joined #css