15:55:03 <RRSAgent> RRSAgent has joined #css
15:55:08 <RRSAgent> logging to https://www.w3.org/2025/03/26-css-irc
15:55:08 <Zakim> RRSAgent, make logs Public
15:55:09 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:58:18 <JoshT> JoshT has joined #css
16:00:01 <dholbert> dholbert has joined #css
16:00:07 <gfaujdar> gfaujdar has joined #css
16:00:14 <oriol> oriol has joined #css
16:00:28 <kbabbitt> kbabbitt has joined #css
16:00:29 <kizu> kizu has joined #css
16:00:33 <kizu> present+
16:00:58 <ydaniv> ydaniv has joined #css
16:00:59 <bramus> present+
16:01:09 <JoshT> present+
16:01:20 <rachelandrew> present+
16:01:31 <flackr> present+
16:01:38 <alisonmaher> alisonmaher has joined #css
16:01:43 <alisonmaher> present+
16:01:53 <kbabbitt> present+
16:02:03 <oriol> present+
16:02:21 <weinig> present+
16:03:30 <ydaniv> present+
16:03:33 <Di> Di has joined #css
16:03:44 <jfkthame> jfkthame has joined #css
16:04:04 <TabAtkins> present+
16:04:04 <Kurt> Kurt has joined #css
16:04:25 <gfaujdar> present+
16:04:26 <schenney> schenney has joined #css
16:04:28 <andreubotella> andreubotella has joined #css
16:04:35 <TabAtkins> ScribeNick: TabAtkins
16:05:05 <astearns> https://github.com/w3c/csswg-drafts/issues?q=state%3Aopen%20label%3A%22Async%20Resolution%3A%20Call%20For%20Consensus%22
16:05:17 <TabAtkins> astearns: A number of async issues, take a look
16:05:30 <miriam> present+
16:05:55 <TabAtkins> astearns: f2f meeting next week, make sure you're in the wiki whether you're in person or virtually
16:06:07 <TabAtkins> astearns: lmk what time of day you'll be around virtually, so I can arrange the agenda to suit
16:06:09 <fantasai> -> https://wiki.csswg.org/planning/newyork-2025
16:06:13 <TabAtkins> astearns: i'll be working on the agenda this afternoon
16:06:20 <TabAtkins> astearns: so availability will be useful very soon
16:06:36 <TabAtkins> astearns: Next is another availability poll for a Summer meeting in Europe.
16:06:36 <astearns> https://app.rallly.co/invite/3lTXIzw6dXxW
16:07:05 <vmpstr> present+
16:07:11 <smfr> smfr has joined #css
16:08:06 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11716
16:08:06 <github-bot> Topic: [css-sizing] Resolved value of min size properties doesn't round-trip
16:08:06 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11716.
16:08:26 <TabAtkins> oriol: summarizing last time...
16:08:30 <PaulG> PaulG has joined #css
16:08:34 <PaulG> present+
16:08:43 <jfkthame> present+
16:08:49 <smfr> present+
16:08:55 <bkardell_> present+
16:08:55 <TabAtkins> oriol: min-height and min-width have initial value of 'auto' but for back-compat gCS() returns 0 on all elements except flex and grid items
16:09:13 <TabAtkins> oriol: however, Sizing 4 added a new effect to 'auto', when you're using aspect-ratio
16:09:20 <TabAtkins> oriol: so it's not equivalent to zero on those elements
16:09:40 <TabAtkins> oriol: so my proposal was that if aspect-ratio had a non-initial value, gCS() would stay as 'auto' rather than becoming 0
16:09:58 <TabAtkins> oriol: Ian wanted to time to check on stuff, he just said he's okay with this special-casing, not sure if he means the proposal
16:09:58 <weinig> q+
16:10:09 <TabAtkins> TabAtkins: I read his comment as meaning your proposal, yeah
16:10:28 <TabAtkins> weinig: Is there a known compat concern with just returning auto always for min size properties?
16:10:34 <TabAtkins> weinig: do we think it'll actually break sites?
16:10:40 <TabAtkins> oriol: Not sure
16:10:49 <astearns> ack weinig
16:10:58 <TabAtkins> oriol: Possibly the editors that said it originally have an idea. but changing that seems riskier.
16:11:10 <TabAtkins> oriol: so not suggesting changing that for now, can do another issue to investigate
16:11:25 <TabAtkins> dbaron: I think changing a behavior that's small-integer number of years old is much less scary than changing a 20yo behavior
16:11:29 <TabAtkins> weinig: fair enough, just wanted to mention it
16:11:35 <astearns> ack fantasai
16:11:57 <TabAtkins> fantasai: yeah, because this affects the initial value, which is what you'll usually get back for it, and for a property that's 20+ years old
16:12:05 <TabAtkins> fantasai: we didn't do a compat analysis, but we suspected there would be a problem
16:12:11 <dbaron> I'm dating it back to when getComputedStyle was interoperable, which I think is newer than the min-width/min-height properties! :-)
16:12:34 <TabAtkins> astearns: so the proposed resolution si that when aspect-ratio is non-initial, then min-size:auto serializes as 'auto' in gCS() (rather than being censored to 0)
16:12:41 <TabAtkins> dholbert: in both axises, right?
16:12:43 <TabAtkins> oriol: yes
16:12:57 <TabAtkins> RESOLVED: When aspect-ratio is non-initial, then min-size:auto serializes as 'auto' in gCS() (rather than being censored to 0)
16:13:15 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11093
16:13:15 <github-bot> Topic: [css-sizing] Should `aspect-ratio: <ratio>` obey `box-sizing` on replaced elements with auto preferred sizes?
16:13:15 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11093.
16:13:20 <TabAtkins> oriol: I closed this issue, I think it's done
16:13:32 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2707697957
16:13:33 <github-bot> Topic: [css-values-5] Maybe min, max and step should not be part of the random-caching-key
16:13:33 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11742.
16:13:55 <dholbert> ScribeNick+ dholbert
16:13:56 <fantasai> scribe+
16:14:09 <fantasai> TabAtkins: The random() functions currently, by default, are maximally random.
16:14:17 <fantasai> TabAtkins: two axes controlling how they resolve
16:14:28 <fantasai> TabAtkins: 1. Which property they're in, and what index in the declaration
16:14:40 <fantasai> TabAtkins: 2. whether same across all elements or different
16:14:46 <fantasai> TabAtkins: can change either of these
16:14:56 <fantasai> TabAtkins: Force same across properties/instances by applying custom ident
16:15:05 <fantasai> TabAtkins: or force same across elements by using special keyword
16:15:15 <fantasai> TabAtkins: some opposition from oriol about the way that the element sharing was phrased
16:15:40 <fantasai> TabAtkins: He preferred previous model where elements shared by default, and opt out
16:15:53 <fantasai> TabAtkins: Since then several people commented preferring that starting with maximal randomnes is better
16:15:57 <oriol> q+
16:16:08 <astearns> ack oriol
16:16:12 <fantasai> TabAtkins: so my proposal is to adopt the proposed model, and then address naming quesiton
16:16:49 <fantasai> oriol: My concern is that when you provide the keyword, not clear that you would share across instances but not across elements
16:17:02 <fantasai> oriol: In our other properties with custom elements, you get same behavior for same custom ident
16:17:07 <fantasai> oriol: I worry it could create some confusion
16:17:22 <fantasai> oriol: But I think if you provide random() with no parameter, maximizing randomness is better
16:17:36 <astearns> ack fantasai
16:18:17 <TabAtkins> fantasai: one option is that "no parameters" is maximum randomness, using a custom ident gives you global correspondence, and using custom-ident+a keyword gives you shared in an element, but differetn across elements
16:18:47 <fantasai> TabAtkins: Yes, that would be a "per-element" keyword, discussed already
16:18:58 <fantasai> TabAtkins: I don't like that because it breaks independence of omitted chunks
16:19:17 <fantasai> TabAtkins: omitting all params shouldn't be different from the behavior of omitting each individually
16:19:27 <fantasai> TabAtkins: We usually adhere to that model, so I prefer to stick to that model.
16:19:47 <fantasai> TabAtkins: Specifying peels back specific aspect of randomness.
16:20:04 <fantasai> TabAtkins: rather than doing an inversion as soon as you specify anything
16:20:53 <fantasai> fantasai: I don't mind either way, just saying this is another possible syntax model.
16:21:09 <fantasai> astearns: so should we resolve on this model of maximal randomness?
16:21:26 <fantasai> RESOLVED: Accept the proposal for changing random caching as stated in the issue.
16:21:41 <fantasai> TabAtkins: We need to name the share-randomness-across-elements keyword
16:22:58 <fantasai> TabAtkins: some options were `element-shared` and `all-elements` ... other suggestions in issue
16:23:23 <fantasai> Proposal is at https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2707697957
16:23:37 <fantasai> [this should go into the resolution]
16:23:49 <fantasai> astearns: Do we have existing keywords related to this idea?
16:23:56 <bramus> q+
16:24:02 <fantasai> Suggested keywords https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2708387121
16:24:21 <lea> lea has joined #css
16:24:31 <astearns> ack bramus
16:25:18 <astearns> ack fantasai
16:25:28 <bkardell_> +1
16:25:34 <TabAtkins> fantasai: I think I agree with tim on match-element being confusing, it doesn't really convey... we're not matching this value to this element, liek it does in VT
16:25:44 <TabAtkins> fantasai: it's "this function should match across all elements", different concept
16:25:51 <bkardell_> thisfunctionshouldmatchacrossallelements
16:25:59 <TabAtkins> astearns: should we resolve on 'element-shared'?
16:26:03 <TabAtkins> fantasai: element-shared sounds weird
16:26:25 <bkardell_> I think I disagree all elements sounds more obv
16:26:50 <TabAtkins> straw poll: 1) element-shared, 2) all-elements, 3) both of these suck, i have a better idea
16:26:59 <TabAtkins> 1
16:27:00 <schenney> 1
16:27:00 <ydaniv> just "shared"?
16:27:02 <astearns> 1
16:27:07 <bkardell_> 1
16:27:09 <Kurt> 1
16:27:11 <fantasai> 2, but I wish I could pick 3
16:27:16 <miriam> 2
16:27:21 <alisonmaher> 1
16:27:24 <bramus> 1
16:27:26 <ydaniv> 1
16:27:26 <oriol> Maybe 3) shared-across-elements? Or 2)
16:27:31 <vmpstr> (abstain)
16:27:40 <kizu> 2
16:27:58 <dbaron> 1 (weakly)
16:28:23 <dbaron> (what about across-elements?)
16:28:34 <fantasai> +1 dbaron
16:29:01 <oriol> Not clear if across-elements is varying across elements or caching across elements
16:29:28 <kbabbitt> match-across-elements ?
16:30:18 <fantasai> fantasai: match-elements ?
16:30:29 <fantasai> TabAtkins: too close to v-t-n: match-element
16:30:38 <fantasai> ydaniv: by-property?
16:31:18 <masonf> masonf has joined #css
16:31:37 <dholbert> (I'm not particularly enthusiastic about either of the options but I don't have a better suggestion )
16:31:48 <emilio> (same as dholbert)
16:32:09 <fantasai> PROPOSED: Go with element-shared for now, keep renaming issue open because we're all unhappy with it
16:32:23 <fantasai> RESOLVED: Go with element-shared for now, keep renaming issue open because many people are unhappy with it
16:33:05 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11396#issuecomment-2715874704
16:33:06 <github-bot> Topic: [css-display-4] Initial value of `reading-flow`
16:33:06 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11396.
16:33:23 <fantasai> TabAtkins: https://github.com/w3c/csswg-drafts/issues/11396#issuecomment-2715874704
16:33:37 <fantasai> TabAtkins: reading-flow changes the order that elements will show up in a11y tools to better match visual layout
16:33:49 <fantasai> TabAtkins: reading-order applies to children, and explicitly reorders
16:34:06 <fantasai> TabAtkins: This can help opt things out of visual reordering
16:34:18 <fantasai> TabAtkins: After some discussions about what needs to be done here, we have 4 points
16:34:30 <fantasai> TabAtkins: 1. Initial value should stay as normal.
16:35:00 <fantasai> TabAtkins: 2. Adding a 'source-order' value, which has no effect on reading-flow normally, but creates reading-flow container side-effects: allows reading-order, and applies tabindex scoping
16:35:17 <fantasai> TabAtkins: 3. 'source-order' applies to block containers as well as flex/grid
16:35:26 <fantasai> astearns: let's pause there
16:35:39 <fantasai> astearns: Any concerns about resolving on initial value of reading-flow as normal?
16:35:48 <fantasai> RESOLVED: Initial value of reading-flow is "normal".
16:36:11 <fantasai> astearns: proposed to add 'source-order' value that will also apply to block containers
16:36:25 <fantasai> RESOLVED: Add 'source-order' value applying also to block containers.
16:36:32 <fantasai> TabAtkins: Next batch of questions was about defaults.
16:36:53 <fantasai> TabAtkins: 1. Suggestion that perhaps dense grids could automatically opt into an appropriate reading-flow value by default
16:37:06 <fantasai> TabAtkins: But suggestion to not do that
16:37:19 <fantasai> TabAtkins: so suggested to resolve not to have an effect on dense grids
16:37:25 <astearns> ack fantasai
16:37:40 <TabAtkins> fantasai: we raised this issue because dense grids are ac ase we might want to ahve autoamtic behavior
16:37:43 <TabAtkins> fantasai: but also some concerns with that
16:37:53 <TabAtkins> fantasai: it would apply the tab-index scoping bheavior by default, which might not be expected
16:38:09 <TabAtkins> fantasai: tho that's a bit more of an edge case, since positive tabindexes are strongly discouraged (due to bad effects)
16:38:46 <TabAtkins> fantasai: the other aspect is , Tab when you suggested we shoudl apply one fo the visual reordering modes to dense-packed grids by default, th epushback wasn'ta bout not doing anything, it was that it would reorder everything in the grid, not just the auto-placed items
16:39:08 <TabAtkins> fantasai: so if an author was placing key items and auto-placing around those, it woudl be harmful to switch the entire grid into a naive visual scan of the grid
16:39:17 <TabAtkins> fantasai: so if we're goign to do something by default it needs to have a lesser effectd
16:39:33 <TabAtkins> fantasai: something that wouldn't break layouts that are using explicit placement with auto placement
16:39:49 <TabAtkins> fantasai: so i dont' think we necessarily shouldn't do anything for dense packing, but we shoudln't use one fo the existing values by default
16:40:23 <fantasai> TabAtkins: You're suggesting a new value not discussed as a default. That's concerning, would like default value to be well-thought-out
16:40:50 <fantasai> TabAtkins: I suspect problem space, while potentially useful, is complex.
16:41:03 <fantasai> TabAtkins: naive visual scan is simple to talk about and understand
16:41:23 <fantasai> TabAtkins: More complicated behavior, would want to be much more deliberate in designing
16:41:33 <fantasai> TabAtkins: So prefer to go with no special behavior
16:41:56 <fantasai> fantasai: That is what this issue was for discussing.
16:42:19 <fantasai> TabAtkins: We want to be shipping this soon, and issue was open since December (SO MANY MONTHS AGO)
16:42:32 <fantasai> TabAtkins: so we want to close the issue with no change.
16:42:36 <TabAtkins> (I did not say "so many months ago", that's scribe editorializing)
16:43:10 <Rossen5> Rossen5 has joined #css
16:43:38 <TabAtkins> TabAtkins: So, Elika, are you objecting to the default behavior for dense grids being nothing special?
16:43:49 <TabAtkins> fantasai: I think we should still think about it, but it shoudln't block shipping
16:44:30 <fantasai> TabAtkins: Unsure about changing later, but if we're sticking with no special behavior for now it's fine with me
16:45:20 <fantasai> fantasai: sounds like we should just move on then, and leave the issue open
16:45:33 <fantasai> TabAtkins: We want a resolution for no change.
16:45:44 <TabAtkins> But without prejudice
16:45:44 <dholbert> TabAtkins: this isn't leaving the issue open; I'd like to resolve it, but without prejudice
16:46:11 <dholbert> astearns: so no change to the spec, are you ok with that fantasai?
16:46:32 <dholbert> fantasai: I think this is an open issue, we shouldn't close it. we should keep thinking about this
16:47:02 <dholbert> TabAtkins: I'm proposing we resolve on no-change-for-now
16:47:52 <dholbert> fantasai: a resolution of no-change means the wg has decided they don't want to make a change
16:48:18 <dholbert> TabAtkins: that's not the proposed resolution. I'm suggesting we close the question, not closing the issue
16:48:32 <dholbert> TabAtkins: maybe we resolve no-change-for-now- because there's no proposal. I'm fine with that
16:48:49 <dholbert> PROPOSED: No change for now, because there's no proposal
16:49:08 <dholbert> RESOLVED: No change to the default behavior for reading-flow and dense grid for now, because there's no proposal
16:49:26 <dholbert> TabAtkins: last point on this issue:
16:49:43 <dholbert> TabAtkins: whether or not reading-order works by default.
16:50:02 <dholbert> TabAtkins: per  spec right now, reading-order only works on children of reading-flow containers (those with non-default initial value)
16:50:34 <dholbert> TabAtkins: now that we have source-order (which just makes something a r-f container), you can take any flex/grid/block and turn on reading-flow for it, and the only effects are tab-index scoping & allowing reading-order to work on its children
16:50:49 <dholbert> TabAtkins: apple proposes that we let r-o work by default *and* opt the element's parent into being a r-f container
16:50:57 <dholbert> TabAtkins: (presumably w/ source-order value)
16:51:02 <dholbert> TabAtkins: we prefer not doing that
16:51:23 <dholbert> TabAtkins: objections: 1st from emilio: because you need to know whether things are a r-f container for various purposes, it's annoying to have that depend on the children
16:52:09 <dholbert> TabAtkins: 2. more important from me personally: because there are side-effects, and they might be unwanted, I don't like being a parent being implicitly opted in for something that might be variable across a page or  between pages (if you have multiple similar containers and only some of them have a reading-order child)
16:52:22 <dholbert> TabAtkins: or if the child's reading-order gets toggled on/off (and has side effects on parents)
16:52:38 <dholbert> TabAtkins: I don't think it makes sense for a11y order to be toggled by this implicit behavior
16:52:55 <dholbert> TabAtkins: Also, the dependence on a parent/child relationship here is relatively rare in css
16:53:08 <dholbert> TabAtkins: where that happens in CSS, it's extremely tied together - grid parent/grid-child, etc
16:53:20 <dholbert> TabAtkins: that doesn't feel like the case for reading-order
16:53:30 <dholbert> TabAtkins: I'd prefer having r-f be opted in before r-o turns on
16:53:42 <Rossen5> q?
16:53:59 <dholbert> TabAtkins: It's possible that an author sets one and then never tests it. The failure case is that the page works the same as it does today
16:54:16 <dholbert> TabAtkins: the perf and the unpredictability of container creation make me lean towards no-to-implicit-creation
16:54:20 <emilio> +q
16:54:35 <dholbert> emilio: that was meant to be a +1
16:54:37 <emilio> ack emilio
16:54:43 <Rossen5> ack fantasai
16:54:44 <dholbert> present+
16:55:03 <dholbert> fantasai: we discussed this with our a11y folks and they raised various  questions that we haven't finished digging into
16:55:11 <argyle> argyle has joined #css
16:55:14 <dholbert> fantasai: and those might invalidate some parts of Tab's argument
16:55:23 <dholbert> fantasai: so I'd object to taking a resolution either way for now
16:55:44 <dholbert> TabAtkins: any details? This feels analogous to other parent/child relationships across aria where opting in is important
16:56:29 <dholbert> fantasai: one of the qs is should we even have these [...]  Is this tab-index scoping behavior, on-the-whole, better or worse than not having that automatic tab-index scoping behavior
16:56:43 <dholbert> fantasai: if it's worse, then some of the premises of Tab's arguments are invalid
16:57:02 <dholbert> TabAtkins: I think we adopted the tabindex scoping behavior on the recommendation of w3c a11y folks, so that part feels like it should be fine
16:57:11 <dholbert> TabAtkins: I'm ok leaving this open to wait for your feedback
16:57:43 <PaulG> I'll make sure APA knows about it
16:57:43 <dholbert> Rossen5: no resolution on this one for now then. we'll await feedback from fantasai and team
16:58:09 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11748
16:58:09 <github-bot> Topic: [css-scroll-anchoring] anchoring within contenteditable elements
16:58:09 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11748.
16:58:55 <dholbert> vmpstr: [starts desccribing]
16:59:18 <dholbert> [we realize there's 1 minute remaining, plan when to actually discuss it]
17:00:34 <Rossen5> Zakim, end meeting
17:00:34 <Zakim> As of this point the attendees have been kizu, bramus, JoshT, rachelandrew, flackr, alisonmaher, kbabbitt, oriol, weinig, ydaniv, TabAtkins, keithamus, gfaujdar, miriam, vmpstr,
17:00:38 <Zakim> ... PaulG, jfkthame, smfr, bkardell_, dholbert
17:00:38 <Zakim> RRSAgent, please draft minutes v2
17:00:39 <RRSAgent> I have made the request to generate https://www.w3.org/2025/03/26-css-minutes.html Zakim
17:00:47 <Zakim> I am happy to have been of service, Rossen5; please remember to excuse RRSAgent.  Goodbye
17:00:47 <Zakim> Zakim has left #css
17:14:24 <Linux_Kerio> Linux_Kerio has joined #css
19:07:15 <annevk> annevk has joined #css
19:07:47 <weinig> annevk: https://github.com/w3c/csswg-drafts/issues/11307#issuecomment-2718858571
19:10:19 <astearns> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11429
19:10:19 <github-bot> Topic: [css-color-hdr] Initial value of `dynamic-range-limit`
19:10:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11429.
19:10:24 <heycam> heycam has joined #css
19:10:32 <ccameron> ccameron has joined #css
19:10:33 <heycam> present+
19:10:35 <annevk> scribe: annevk
19:11:54 <annevk> smfr: We'd like HDR to be constrained by default, including images, but excluding videos as they have been the exception for a long time. Web developers get to opt-in to no-limit through CSS.
19:12:38 <annevk> smfr: We only want to give video content no-limit access by default, not video element border colors and such.
19:13:57 <annevk> smfr: We'd also want to limit cross-origin documents by default, excluding videos again. And we'd use a sandbox flag [editor: Permissions Policy] to let the embedder enable that after all.
19:14:32 <annevk> weinig: I think this makes it hard-if-not-impossible for content producers to match colors.
19:15:38 <annevk> ccameron: As a moral position, there are good arguments for any of the defaults. I'll agree with everything at some level. Do we consider it acceptable for different element types to have different default behaviors? I would not want that to be in the specification.
19:16:21 <annevk> ccameron: In another collaboration we very much try to make images and videos to behave the same.
19:17:29 <annevk> ccameron: Does constrained-high work with CoreAnimation? I think I have to use a shader.
19:18:34 <annevk> smfr: I don't think we can change the HDR behavior of YouTube. And I don't think we can ship no-limit by default as it'll look weird.
19:19:06 <annevk> weinig: There are not that many websites. Can we get the websites fixed?
19:19:38 <annevk> smfr: It's the embedding pages that would have to set the Permissions Policy.
19:19:53 <annevk> weinig: What's the goal of doing that?
19:20:09 <annevk> smfr: To prevent abuse essentially.
19:20:20 <annevk> weinig: I suspect ads will just abuse video.
19:20:27 <annevk> smfr: Seems harder to deploy.
19:20:44 <annevk> weinig/ccameron: People will do it if they want it.
19:22:13 <annevk> ccameron: I don't think images need to be constrained. Most of the photos look fine on a white background. HDR video content also seems mostly reasonable and is written to co-exist.
19:22:30 <annevk> ccameron: Also, even with constrained there can be bad content.
19:24:12 <annevk> ccameron: The path I thought might be reasonable: the unset default value is implementation-defined, ideally the same across all types. And then we regroup in a year and agree on a default.
19:26:07 <annevk> smfr: I'm sympathetic to the argument that "valid" HDR will get better. I'm worried about antagonistic HDR.
19:26:41 <annevk> ccameron: That's why I have thought about making standard the default and you'd have to opt-in.
19:26:54 <annevk> weinig: And then you'd require Permissions Policy for cross-origin documents too.
19:27:21 <annevk> ccameron: antagonistic HDR already exists, I've been assigned bugs.
19:29:05 <annevk> ccameron: for instance, a green screen background that hides content between sRGB and P3 green so only end users with a P3 screen see it (and it might circumvent certain tools).
19:29:26 <annevk> ccameron: because of that a no-HDR default is reasonable.
19:30:47 <annevk> weinig: I think any kind of sandboxing flag that we do should be absolute.
19:30:59 <annevk> ccameron: this would break YouTube embeds.
19:31:35 <annevk> weinig: that seems really easy to work around. It could be a quirk for a while that we work on phasing out.
19:31:48 <annevk> weinig: there's just not enough video websites for this to be a real problem.
19:32:44 <annevk> weinig: I'm also not sure it's such a big concern to break it as it's still early HDR days
19:33:27 <smfr> q+
19:34:05 <annevk> ccameron: I'm trying to give no-limit a go, gathering feedback as I go, but am prepared to switch to SDR. But for now we have quite a few partners that expect no-limit...
19:34:46 <astearns> ack smfr
19:35:43 <annevk> smfr: 1) I'm doubtful about great resets. Much less concerned about starting with less HDR and going towards more. 2) Who are the people that really want great HDR?
19:36:08 <annevk> ccameron: for 2) name any website that does a gallery of photos and they have opted in.
19:36:42 <annevk> smfr: Do they care about HDR in CSS images, SVG images, etc? Or primary content only?
19:37:33 <annevk> ccameron: mainly the primary content, but I've had people complain about it not being present in the gallery view (server-side downscaled images, say 6 in a row)
19:38:14 <annevk> ccameron: next steps?
19:38:49 <annevk> smfr: We have to check internally on some things.
19:39:05 <annevk> annevk: Do these websites rely on no-limit or specify the CSS property?
19:39:15 <smfr> q+
19:39:28 <annevk> ccameron: They rely on no-limit. Some enforce lower limits server-side.
19:39:39 <astearns> ack smfr
19:40:01 <annevk> smfr: Would it be possible for Google-controlled ad networks to control the amount of HDR?
19:40:23 <annevk> ccameron: I can ask, not sure I can answer.
19:41:28 <annevk> astearns: Okay, so smfr is going to be checking if the default for video could be constrained. ccameron is going to check on ad networks (but might not be able to answer).
19:41:41 <annevk> astearns: I'm against not specifying a default.
19:42:50 <annevk> astearns: If we specify constrained and Safari ships that, we can maybe change it. But if we go with no-limit we can't change it.
19:43:28 <annevk> ccameron: Keep in mind, it'd be pretty hard for us to change it at this point.
19:44:53 <Said7> Said7 has joined #css
19:45:24 <Said7> Said7 has left #css
19:45:34 <emeyer> emeyer has joined #css
19:45:52 <Said2> Said2 has joined #css
19:46:01 <annevk> annevk has joined #css
19:47:00 <annevk> ccameron: It seems unlikely that if the standard ends up on something other than no-limit, Chrome would be able to align...
19:48:26 <annevk> weinig: I don't agree with the idea that HDR will make things worse. It's really easy to make shitty web content without HDR. I don't think this will make it significantly worse.
19:49:35 <annevk> ccameron: I also think there's a possibility that enshrining SDR will make the web look shittier as people end up expecting their images to look bad.
19:49:47 <emeyer> emeyer has left #css
19:50:13 <annevk> smfr: I think HDR can be a real problem for people.
19:51:19 <annevk> weinig: I think we can impose limits, but I don't think any of it will deter people from writing bad HDR.
19:51:44 <annevk> ccameron: I think a limit on cross-origin documents seems far more reasonable and might be doable.
19:52:45 <annevk> smfr: Question about iframe elements. If you apply the property on the element, does it impact the nested document?
19:52:51 <annevk> weinig: CSS logic says no.
19:53:05 <annevk> smfr: Fair, I just want it to be clear as it might go against expectations.
19:53:08 <astearns> github-bot, take up https://github.com/whatwg/html/issues/11165
19:53:08 <github-bot> Topic: Add target HDR headroom to `CanvasRenderingContext2D `
19:53:08 <github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/11165.
19:53:45 <annevk> [Not minuting as people can just read the proposal.]
19:55:55 <annevk> weinig: So this controls the HDR headroom for input into the canvas?
19:55:59 <annevk> ccameron: Yup.
20:02:54 <astearns> Sam’s proposal for definitions to spec against: https://github.com/w3c/csswg-drafts/issues/11307#issuecomment-2718858571
20:04:04 <annevk> What's color-hdr?
20:21:42 <astearns> (our draft shortname, but annevk dropped) https://drafts.csswg.org/css-color-hdr-1/
20:41:07 <emeyer> emeyer has joined #css
20:41:55 <emeyer> emeyer has left #css
21:10:18 <dholbert> hmm, https://drafts.csswg.org/ is loading slowly today; getting hammered by crawlers or something?