14:57:55 <RRSAgent> RRSAgent has joined #css
14:58:00 <RRSAgent> logging to https://www.w3.org/2024/10/30-css-irc
14:58:00 <Zakim> RRSAgent, make logs Public
14:58:01 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:01:08 <noamr> noamr has joined #css
15:01:12 <noamr> present+
15:01:31 <bramus> present+
15:03:49 <castastrophe> castastrophe has joined #css
15:04:01 <castastrophe> present+
15:04:57 <khush> khush has joined #css
15:05:05 <bramus> ScribeNick: bramus
15:05:38 <fantasai> scribe+
15:05:47 <fantasai> Topic: View Transitions
15:05:52 <github-bot> Subtopic: [css-view-transitions-2] Allow an auto-generated `view-transition-name` that doesn't default to ID
15:06:16 <fantasai> bramus: This issue is about allowing an auto view-transition-name to be generated by specifying a keyword
15:06:33 <fantasai> bramus: a number of keywords suggested, from-element, per-element, self, auto, auto-id
15:07:10 <fantasai> bramus: I asked authors "which keyword conveys using ID and falling back to auto-generated" and "which keyword conveys automatically generated"
15:07:27 <fantasai> bramus: when I asked which is "automatically generated", they picked "auto"
15:07:42 <fantasai> bramus: when I asked about the ID and fallback, the responses ...
15:08:00 <fantasai> bramus: We were thinking 'from-element' but authors expected 'auto' for "automatically generated".
15:08:17 <fantasai> bramus: we could meet developers by reverting previous resolution about auto reading ID and falling back
15:08:27 <fantasai> bramus: and come up with a better keyword
15:08:51 <fantasai> bramus: or push authors towards using attr() function which is suited for this, can use attr(id, auto) for fallback behavior
15:09:10 <fantasai> bramus: or keep previous resolution of using auto for fallback behavior, but then we need to come up with a very good keyword for the autogeneration
15:09:32 <fantasai> bramus: Authors prefer auto-id for autogenerated, and some suggested generated
15:09:39 <fantasai> bramus: and some others said, don't we have attr() for this?
15:10:07 <bramus> fantasai: we can conclude from the poll that there is cnofusion over keywords
15:10:15 <bramus> … wording of poll most likely prompted some of the responses
15:10:27 <bramus> … using “automatically generated id” pushed authors towards `auto`
15:10:39 <bramus> … internally we are generating one, bu thtat is just the meachism
15:10:59 <bramus> … it is an internal detail
15:11:13 <bramus> … the will never see it … we might not even generate one and use poitner identity
15:11:25 <bramus> … its not about automatically generating ids, its about the identify of the element object
15:11:38 <bramus> … poll is propably a but confused on that point
15:11:48 <bramus> … could try to come up with good keywords but maybe need some more ideas
15:11:56 <bramus> … but doesnt mean that we should revert decision on `auto`
15:12:19 <bramus> … in terms of possible keywords: `mathc-elememtn` is an option as we use match in  a few other places
15:12:25 <bramus> … but open to ideas
15:12:32 <emilio> present+ (irc only)
15:12:39 <astearns> q+
15:12:42 <bramus> … at webkit we think `auto` is the right way to define it
15:12:44 <khush> q+
15:12:49 <astearns> ack fantasai
15:12:52 <bramus> … and maybe need other keyword for the other thing
15:12:53 <noamr> I like match-element
15:13:21 <bramus> astearns: the currently specced behavior for auto is to use the id attr and fall back to auto generated one?
15:13:31 <bramus> fantasai: its to use the identity of the element
15:13:57 <bramus> … if there is no id, we look at the element being the same object or not
15:14:22 <bramus> … in that case, the object hasnt been destroyed - its a singular one that you can map between tree versions
15:14:34 <astearns> ack astearns
15:14:36 <astearns> ack khush
15:14:59 <bramus> khush: spec might say to generate one, but conceptually get the point that that is one way to implement it. you don”t need strings to establish identity
15:15:10 <bramus> … of all options maybe self is nice as it doesnt hit at generating something
15:15:15 <florian> q+
15:15:18 <bramus> … your identtity is the nodes identity
15:15:38 <bramus> … auto is confusing. kind of a grab value in css to figure out automatically what to do which is what we doing here as well
15:15:47 <astearns> ack florian
15:16:02 <fantasai> match-element? same-element?
15:16:06 <bramus> florian: explanation fantasai just gave: if that can be used. key point is stability … so maybe akeyword like stable?
15:16:13 <bramus> … if the elemen tis still around it will be the same
15:16:23 <noamr> q+
15:16:23 <bramus> … dont describe what we do but the why
15:16:30 <astearns> ack noamr
15:16:47 <bramus> noamr: I like match-element. we match not just the id, but the actual elements
15:16:59 <bramus> … matching two state of the same element
15:17:13 <bramus> q+
15:17:22 <khush> i'm ok with match-node or match-element
15:17:34 <fantasai> bramus: I like all these suggestions just now, `stable` and `match-element`.
15:17:38 <fantasai> bramus: doesn't seem confusing
15:17:45 <astearns> ack bramus
15:17:49 <fantasai> bramus: `from-element` implies reading from the element, but matching is matching so seems like a good suggestion
15:18:16 <fantasai> bramus: wrt `auto` part, as DevRel we can hammer on this point, means "try to get a name" not "automatically generate one"
15:18:35 <fantasai> astearns: which method do we expect authors to use most?
15:18:41 <fantasai> noamr: It depends
15:18:54 <fantasai> noamr: Likely use explicit names. Otherwise likely to use auto, it will just work.
15:19:10 <fantasai> noamr: But if they want to specifically say that id attrs don't participate, then use match-element
15:19:19 <fantasai> noamr: I think auto would be more common, it will usually just work.
15:19:56 <fantasai> noamr: element identity, not observable if generated string
15:20:11 <fantasai> astearns: We have a way of using the ID attribute, specifically, by using attr() function
15:20:24 <fantasai> astearns: we have defined `auto` to match the element by ID if there is one, or using other methods if not
15:20:40 <fantasai> astearns: Is there really a use case for "throw out the IDs and only use the opaque element-matching algorithm" ?
15:21:26 <fantasai> khush: Point came up last time, if these are only two (auto and attr(id)), then there's no way to say "I want to match based on element identity even though I put an ID on it"
15:21:42 <fantasai> noamr: You wouldn't be able to match if element has an ID in only one of the state
15:21:58 <fantasai> khush: or if ID is used for a different reason, and not used in view transitions
15:22:12 <fantasai> astearns: I can see the case, but not expecting authors to run into it much
15:22:26 <fantasai> noamr: cleaner solution to have specific keywords for each behavior
15:22:37 <fantasai> astearns: understand, but that's a theoretical purity argument
15:22:52 <fantasai> khush: We heard from one [missed]
15:22:53 <astearns> ack fantasai
15:23:17 <bramus> fantasai: in terms of the name clashing we might want to consider namespacing ids taken from the element vs names that we put direclty into css
15:23:18 <astearns> s/[missed]/AirBnB where teams use ids for entirely different things
15:23:23 <bramus> … that would avoid name clasing
15:23:54 <bramus> … already have  pseudo selelcting syntax but are not using the ! sign for keywords. Could say tha ti fyou pull the id from the attr, then it gets prefixed with the ! sign in the matching.
15:23:56 <noamr> q+
15:24:02 <bramus> … that would namespace it and avoid clashes
15:24:04 <fantasai> s/!/#/g
15:24:10 <bramus> astearns: this would be an additional thing
15:24:36 <bramus> fantasai: would mean for auto and I guess attr() tha twe are generating the namemt hen you would use v-t-g(#id) to select and style it
15:24:37 <bramus> q+
15:24:58 <bramus> khush: not sure about this, but maybe could do it for auto-generated ones. Not for those read from attr.
15:25:09 <bramus> … will be a pain to keep track of where it came fromg
15:25:13 <bramus> fantasai: fair
15:25:17 <astearns> ack noamr
15:25:29 <bramus> noamr: against namespacing because of flexibility of VTs.
15:25:51 <bramus> … take  cross-doc VT with #hero id on one side and one with hero v-t-name on other side
15:25:57 <bramus> … would want to transition between those
15:26:08 <bramus> khush: can open issue separately from this
15:26:16 <astearns> ack bramus
15:26:44 <fantasai> bramus: Just realized, we could not tackle this problem as part of view transitions, keep auto as it is, and look at the ident() function and allow it to take a keyword
15:26:57 <fantasai> bramus: so if you want to auto-generate an ident you use it
15:27:23 <bramus> fantasai: so ident() should take wjhat?
15:27:38 <bramus> bramus: `view-transition-name: ident(auto)` to auto-generate an ident
15:27:55 <bramus> … so we dont have to come up with a keyword for this
15:28:13 <bramus> fantasai: but that retrurns an actual observable identifier
15:28:20 <bramus> … which we dont think we want to do
15:28:27 <bramus> … should still have keyword for it
15:28:55 <noamr> q+
15:28:56 <bramus> … can consider is distinguishing between auto keyword actually creating a referencable v-t-n or just an internal matching
15:29:06 <bramus> … can you selec tagainst the generated identifier is an open question
15:29:24 <bramus> … would we do that or just use the id attr to match elements but not to select against it
15:29:42 <bramus> … like `::v-t-g(id)`
15:30:03 <bramus> khush: would be nice if you could do it for for the `[id]` case
15:30:07 <bramus> … pretty convenient
15:30:32 <bramus> fantasai: only downside is that we might have namespace clashes and stuff that you are using for identity in the document
15:30:38 <bramus> noamr: right, mixing things
15:30:50 <bramus> fantasai: can agree on keeping `auto` as it is
15:31:08 <bramus> … and for now add a keyword `match-element` for only looking at element id
15:31:28 <bramus> … and open issue to mix the namespaces
15:31:30 <noamr> q-
15:31:39 <fantasai> s/to mix/about mixing/
15:32:11 <bramus> astearns: Gonna need async resolution as we are low on people attending
15:32:47 <bramus> PROPOSED RESOLUTION: Add `match-element` keyword that will only use element identity and not use id attributes.
15:33:05 <bramus> astearns: will be submitted as an async resolution
15:33:45 <fantasai> RESOLVED: [Pending async confirmation] `auto` will match elements using their ID attributes, falling back to element identity; `match-element` will only use element identity.
15:34:12 <bramus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10978
15:34:12 <github-bot> Topic: [css-view-transitions-2] How are auto-generated `view-transition-name`s exposed in JS APIs
15:34:12 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10978.
15:34:31 <bramus> noamr: how do autogenerated appear in things like getAnimations?
15:34:54 <khush> q+
15:35:00 <bramus> … what would these auto-generated ones look like? Aavailble as strings? Or give them a name of `match-element` or `*` or not show them at all?
15:35:05 <fantasai> ACTION: Open new issue about whether `auto` exposes the ID from the ID attribute as a view-transition-name for pseudo-element matching
15:35:17 <bramus> bramus: and devtools?
15:35:19 <astearns> ack khush
15:35:22 <bramus> noamr: no, not included
15:35:46 <bramus> khush: two options
15:35:49 <bramus> … if we decied that id based names ar ehidden from css then it makes sense to hide everything from auto
15:36:46 <bramus> … or if name came from id attribute then do expose it but dont expose the identity ones (and expose those as `match-element`)
15:36:53 <bramus> q+
15:37:25 <bramus> astearns: the ids that auto uses could be made opaque but if the author uses the attr() fn then they would be exposed?
15:37:30 <bramus> khush: thats the complication with hiding ids
15:37:45 <bramus> … if you use attr() then you have all those complications of where you get the strings from
15:38:00 <astearns> ack bramus
15:38:01 <bramus> … can punt on this until we decide how to namespace ids
15:38:01 <noamr> q+
15:38:38 <fantasai> bramus: if value derived from ID attribute and expose it, if you have an element with an ID on one page and a different one on a different page with a view-transition-name of hero, then one transitions to the other
15:38:46 <fantasai> bramus: would be useful to expose that name
15:38:57 <fantasai> bramus: if we fall back to match-element strategy, then show that as match-element
15:39:04 <fantasai> bramus: because authors can't target those elements directly
15:39:12 <fantasai> bramus: by having match-element there, clearly can't target
15:39:32 <bramus> fantasai: q about whether id on one page would match a v-t-n on other is part of the namespacing discussion
15:39:37 <bramus> … dont have an opionion on direction
15:39:47 <bramus> … if that worked, then we should make pseudos match that
15:39:57 <bramus> … but q is then should that work in the first place?
15:40:28 <bramus> … do we want to expose the name derived from an id in the first place? no opinion right now.
15:40:36 <bramus> … obviously should not expose autogenerated names
15:40:39 <astearns> ack noamr
15:40:55 <bramus> noamr: strong opinion about keeping things simple… if generated by id its just that name
15:41:09 <bramus> … already doing complicated things that look different
15:41:25 <bramus> … if the v-t-name comes from an id, then that should be the v-t-n
15:41:35 <bramus> … if author dont want that, they should do other things
15:41:39 <bramus> … lets keep things flat
15:41:42 <khush> q+
15:41:55 <bramus> … regardless we can resolve to use the name `match-element` in `getAnimations`
15:42:13 <astearns> ack khush
15:42:28 <bramus> khush: since we are going here … my alignment is wit noam on this. keep it simpel and treat them as names
15:42:36 <bramus> … dont have author feedback on this though
15:42:46 <bramus> … not a super strong opinion
15:43:06 <bramus> … if this pattern is adopted like anchor-name and there is no matching concept, do we want to have this namespacing concept across css props then?
15:43:14 <bramus> … then VT wont have this own special thing
15:43:15 <bramus> q+
15:43:25 <bramus> … concept would make sense across CSS
15:43:33 <bramus> fantasai: none of the others have a way of pulling element id
15:43:43 <bramus> khush: but can imagine anchor-pos doing the same over time
15:43:51 <astearns> ack bramus
15:44:04 <noamr> I like that auto === id ? attr(id) : match-element
15:45:03 <bramus> bramus: missed
15:45:04 <bramus> astearns: but flatness isnt part of the issue
15:45:15 <bramus> khush: lets thing about that a bit more
15:45:20 <bramus> s/khush/noamr
15:45:33 <bramus> noamr: lets resolve on exposing them as `match-element`
15:45:39 <bramus> astearns: is ther ea conclict there?
15:45:44 <bramus> noamr: its just in getAnimations
15:45:52 <bramus> astearns: which is wrapped in a pseudo
15:46:15 <bramus> khush: compat risk for users that have used `match-element`
15:46:40 <bramus> bramus: dont think anyone has used that yet
15:47:17 <bramus> khush: so if you use auto and we use the id attr then we expose the id attr as string, and if we use identity then we expose match-element
15:47:31 <bramus> noamr: and tbd if these id-based names are namespaced or not
15:47:37 <bramus> astearns: should open an issue that
15:47:45 <bramus> khush: can do that
15:48:33 <bramus> PROPOSED RESOLUTION: we will use `match-element` in the Animations API when element identity is used
15:48:44 <bramus> astearns: objections?
15:48:49 <bramus> (silence)
15:49:11 <bramus> RESOLVED: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used
15:49:20 <bramus> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10585
15:49:20 <github-bot> Topic: [css-view-transitions-2] Optionally capture some properties (e.g. opacity/border) as style instead of snapshot
15:49:20 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10585.
15:50:14 <bramus> noamr: talked about capturing snapshots not flat but to also capture borders, shadows, opacity, etc
15:50:28 <bramus> … had homework to figure out the exact way of how this would work and do some compat analysis
15:50:34 <bramus> … have done both to an extent
15:50:38 <noamr> https://github.com/WICG/view-transitions/blob/main/nested-explainer.md#layered-capture
15:50:40 <bramus> … wrote an explainer for this
15:51:05 <bramus> … main question is if this is a net improvement to capturing elements layered or not?
15:51:24 <bramus> … only works when elements are superimposed on eachother in a way, like cross-fade morphs the animation
15:51:38 <bramus> … many people use slide animations, like a header sliding offscreen
15:51:57 <bramus> … when authors do that, capturing the borders separately creates a different effect
15:52:18 <bramus> … backwards compat it wouldnt affect hat many peole right now, but those that are affected are affected in a big way
15:52:31 <bramus> … want to get attention to the explainer
15:52:42 <bramus> … there are afew optoins:
15:52:47 <bramus> … make it an opt-in
15:53:10 <bramus> … or create an extra pseudo for the geometry animation
15:53:25 <khush> q+
15:53:34 <bramus> …  it does create more things to think about it, but nice thing about that it is that it does what it does today
15:53:44 <stepheckles> stepheckles has joined #css
15:53:46 <bramus> … you need to only style it if you want to
15:54:17 <bramus> … third option is to have no opt-in and have authors opt-out by containment thorugh adding an extra container element
15:54:25 <bramus> … not looking for a resolution now
15:54:26 <astearns> ack khush
15:54:35 <bramus> khush: +1 to what noam said
15:54:48 <bramus> … am pretty convinced that original capture way might have been a mistake.
15:55:04 <bramus> … noam dug up styles that authors used to customize animatoins and have found slight animations that were set up
15:55:14 <bramus> … if you have two things
15:55:35 <bramus> … where the whole bg changes you dont want those to fade but just want the slide effect
15:55:38 <bramus> … dont want to break those
15:55:41 <bramus> … especially on the root level
15:56:08 <bramus> … also dont want authors to have to create a wrapper around the content int root to fix that
15:56:16 <bramus> … could maybe resolve that both these modes should exist
15:56:23 <bramus> … how to select one or the other can be decided later
15:56:35 <bramus> bramus: +1 on both modes being valuable
15:56:37 <bramus> a+
15:56:38 <bramus> q+
15:56:56 <bramus> astearns: need to read explainer a bit more. wrapper made sense until khushals argument
15:57:04 <schenney> schenney has joined #css
15:57:33 <bramus> noamr: should generally avoid people to change their dom for style purposes
15:57:36 <bramus> bramus: +1
15:57:50 <astearns> ack bramus
15:58:23 <bramus> bramus: can the extra speudo give a perf benefit?
15:58:37 <bramus> noamr: not really. think of border animating
15:58:43 <bramus> … I encourage ppl to look at the explainer
15:58:57 <bramus> … especially the geometry part, because we copy over the box mode
15:59:04 <bramus> s/mode/model
15:59:09 <bramus> … also scrollbars and stuff
15:59:11 <kizu> kizu has joined #css
15:59:19 <bramus> … food for a next meeting
15:59:30 <bramus> astearns:thanks for the summary and explainer. its great to have
15:59:36 <PaulG> PaulG has joined #css
15:59:49 <bramus> … will summarize the breakout to the www-style list and set up async resolutions and point people to the explainer
15:59:52 <bramus> … gonna wrap up
15:59:58 <bramus> topic: none
16:00:52 <kbabbitt> kbabbitt has joined #css
16:01:24 <astearns> astearns has changed the topic to: Oct 30 agenda: https://lists.w3.org/Archives/Public/www-style/2024Oct/0015.html
16:01:28 <kbabbitt> present+
16:01:33 <argyle> present+
16:01:35 <joshtumath> joshtumath has joined #css
16:01:37 <kizu> present+
16:01:42 <ChrisL> present+
16:01:58 <noamr> noamr has joined #css
16:02:03 <noamr> scribe+
16:02:17 <jfkthame> jfkthame has joined #css
16:02:21 <joshtumath> present+
16:02:37 <jfkthame> present+
16:02:38 <lea> lea has joined #css
16:03:04 <noamr> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10271
16:03:04 <github-bot> Topic: [css-color-hdr] Add interpolation between multiple values of dynamic-range-limit
16:03:04 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10271.
16:03:09 <smfr> smfr has joined #css
16:03:40 <stepheckles> present+
16:03:46 <noamr> Chris: we have this dynamic range value. but you might have more than value, e.g. in animation, need to decide what happens
16:03:49 <lea> present+
16:03:52 <oriol> oriol has joined #css
16:04:13 <rachelandrew> present+
16:04:24 <noamr> ChrisL: we have a PR, we either should merge it or revert. I think it's a good syntax
16:04:31 <oriol> present+
16:04:44 <davidleininger> davidleininger has joined #css
16:04:48 <davidleininger> present+
16:05:03 <noamr> astearns: inclined to accept the PR
16:05:12 <noamr> ChrisL: I prefer to review things in place
16:05:19 <noamr> astearns: objections?
16:05:34 <TabAtkins> RESOLVED: Accept the PR
16:05:54 <alison> alison has joined #css
16:05:56 <noamr> github-bot: take up https://github.com/w3c/csswg-drafts/issues/4165
16:05:57 <github-bot> Topic: [css-images] Should CSS decorative images respect EXIF-orientation by default
16:05:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/4165.
16:05:59 <alison> present+
16:05:59 <ydaniv> ydaniv has joined #css
16:06:04 <ydaniv> present+
16:06:50 <noamr> ChrisL: it wasn't clear what we've resolved on
16:06:53 <flackr> present+
16:07:05 <noamr> ChrisL: what this means that if you have EXIF that comes before the image data we must respect it
16:07:11 <smfr> present+
16:07:23 <noamr> ChrisL: for consistency we should probably ignore it when it comes after
16:07:31 <schenney> q+
16:07:41 <noamr> smfr: you mean in the order in which the image is encoded?
16:07:42 <miriam> present+
16:07:46 <noamr> ChrisL: yes, which is not always possible
16:07:57 <noamr> q+
16:07:57 <astearns> ack schenney
16:08:29 <noamr> schenney: I agree with ignoring after the image, but the q was whether the orientation should look at the image-orientation property on the element
16:08:36 <noamr> schenney: chrome does this but safari does not
16:09:00 <noamr> ChrisL: there wasn't a discussion on this, can we discuss now?
16:09:44 <noamr> schenney: one, I implemented this a while ago, the usage data for image-orientation and it's rising, but not in a huge amount
16:09:51 <SebastianZ> SebastianZ has joined #css
16:09:52 <noamr> schenney: people use it to avoid applying the image metadata
16:10:17 <smfr> q+
16:10:20 <noamr> schenney: from that point of view the current chrome behavior is preferrable for web devs. but the long term is perhaps to not have that property
16:10:28 <gfaujdar> gfaujdar has joined #css
16:10:30 <noamr> schenney: we'll get pushback if we do that
16:10:43 <noamr> ... if we don't honor image-orientation
16:10:43 <ChrisL> q+ how to say "ignore rotation" in that case?
16:10:50 <TabAtkins> scribe+
16:10:50 <bramus> scribe+
16:10:52 <SebastianZ> present+
16:10:57 <astearns> ack noamr
16:11:06 <TabAtkins> noamr: even now, image-orietnation is broken in the sense that it doesn't work on cross-origin images
16:11:12 <schenney> q+
16:11:14 <TabAtkins> noamr: which is a real big breakage for people
16:11:22 <TabAtkins> noamr: I find it a broken CSS property because of that
16:11:51 <gfaujdar> present+
16:11:56 <ChrisL> +1 to URL modifier
16:11:57 <TabAtkins> noamr: having it apply to CSS images, it's a bit weird you have something for the whole lement and apply it to all images. i'd expect it to be a url modifier or something, a keyword that says you read the exif
16:12:07 <TabAtkins> noamr: we have url() modifiers now for other things, we can put it there. i think that's the right place
16:12:11 <astearns> ack smfr
16:12:12 <noamr> scribe+
16:12:13 <TabAtkins> (+1 to that, it was clumsy to have it apply that way)
16:12:20 <noamr> smfr: it should be per-image, maybe on the image function
16:12:40 <noamr> smfr: background: webkit started supporting orientation by default on regular images, we just didn't get to CSS images
16:12:47 <noamr> smfr: I think we can change it to match the chromium behavior
16:12:55 <astearns> ack how
16:12:55 <Zakim> how, you wanted to say "ignore rotation" in that case?
16:12:57 <PaulG> q+
16:13:04 <noamr> CLilley: URL modifier is perhaps a good way to go
16:13:05 <astearns> ack schenney
16:13:20 <noamr> schenney: URL modifier would address the original reason why image orientation is ignored on cross-origin
16:13:21 <fantasai> I url modifiers should be for generic modifiers. We should use image() for image-specific modifiers.
16:13:26 <fantasai> And we should have more of them.
16:13:40 <astearns> ack dbaron
16:14:08 <noamr> dbaron: I'm more hesitant about modifiers. they make sense for features we want permanently. my impression is that this feature is more fore compatibility during transition
16:14:29 <noamr> dbaron: if we want to end up always honoring the metadata, we should only add as many features as we need for that, rather than add more granularity
16:15:10 <noamr> astearns: if we resolve on ignoring EXIF at the end, does that help with the transition?
16:15:28 <noamr> dbaron: it wasn't clear to me which cases the resolution applies to
16:15:38 <astearns> ack PaulG
16:16:08 <noamr> PaulG: for a11y I'd be concerned that if people relied on this feature for WCAG orientation, I wouldn't want to get rid of it
16:16:17 <noamr> PaulG: I suspect we'd want to keep that
16:16:23 <astearns> ack fantasai
16:16:32 <noamr> fantasai: modifiers should be in image() and not in url()
16:16:36 <noamr> q+
16:16:46 <astearns> ack noamr
16:17:10 <TabAtkins> Yeah since this is explicitly an image *file*, I'm fine with it living on url()
16:17:40 <ChrisL> q+
16:17:45 <noamr> astearns: we can probably resolve on ignoring metadata that's after the metadata
16:18:11 <noamr> schenney: I thought it was resolved a while ago
16:18:12 <astearns> ack ChrisL
16:18:28 <noamr> ChrisL: it was unclear enough that it's hard to say what a PASS is
16:18:36 <smfr> q+
16:18:40 <noamr> q+
16:18:56 <astearns> ack smfr
16:19:17 <noamr> smfr: we might not be able to do this in the implementation
16:19:33 <astearns> ack noamr
16:20:57 <astearns> ack fantasai
16:21:19 <noamr> fantasai: HTML should add that, but in CSS we should say how we handle images with EXIF, regardless of the host language
16:21:23 <smfr> q+
16:21:33 <noamr> it should at least be in both
16:21:38 <fantasai> s/should add that/could add special rules/
16:21:39 <astearns> ack smfr
16:21:56 <noamr> smfr: odd that CSS would define things around the encoding of an image
16:21:58 <noamr> q+
16:22:02 <fantasai> It doesn't need to be in both. It's a rendering question, it needs to be in CSS. HTML can optionally say stuff, but it doesn't need to -- we do.
16:22:11 <dbaron> s/HTML should add that/HTML could add that/
16:22:15 <TabAtkins> noamr: We talked before in WHATWG about separqting some of those image details to as eaprate spec
16:22:38 <TabAtkins> noamr: it never happened because nobody had time, but I think right now, relying on parts of HTML that defines how images are decoded, relying on that inside of CSs, is the best we'
16:22:42 <ChrisL> relevant PNG WG issue is https://github.com/w3c/png/issues/310
16:22:46 <TabAtkins> noamr: We should behave the same way for HTML and CSS
16:23:04 <noamr> astearns: it is claimed that all browsers ignore post-image-data orientation
16:23:12 <noamr> astearns: smfr would you validate?
16:23:29 <noamr> smfr: will validate
16:23:38 <noamr> astearns: will take it back to the issue about encoding order
16:23:51 <noamr> ... to validate that all browsers do this today
16:24:09 <noamr> ChrisL: please check with JPEG with PNG, I saw that Safari does something different
16:24:20 <noamr> smfr: that's why we need more time
16:24:28 <noamr> (In PNG this is encoded in XMP IIRC)
16:24:38 <noamr> astearns: for how we override the metadata
16:24:46 <ChrisL> No, it can be but there is also an exif chunk
16:25:03 <noamr> smfr: this is *this* issue, but we discussed a different one
16:26:06 <TabAtkins> noamr: also there's a proposal for a url() modifier. not clear yet. But at least not taking the info from image-orientation
16:26:28 <TabAtkins> schenney: so proposal is phase out a per-image way of specifying it, and phase-out image-orientation property
16:26:45 <TabAtkins> phase in an image-specific way to do *CSS images*.
16:26:54 <TabAtkins> dbaron: replaced elements, form HTML, would still obey image-orientation
16:27:14 <TabAtkins> astearns: so let's continue that part of the discussion in this issue
16:27:35 <noamr> astearns: action item for smfr to validate the tests
16:28:10 <noamr> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10605
16:28:10 <github-bot> Topic: [css-sizing] Intrinsic size of <img> / <video> with aspect ratio but no definite size
16:28:10 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10605.
16:28:52 <dbaron> github: none
16:28:57 <noamr> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10549
16:28:57 <github-bot> Topic: [cssom-view] Spec for offsetTop/Left does not match impls when offsetParent is `position:static` `<body>` element
16:28:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10549.
16:30:00 <noamr> oriol: we encountered this in servo, that impls are not per-spec
16:30:33 <noamr> oriol: offsetTop/offsetLeft of the element, when there is no offsetParent, the distance is used
16:31:01 <noamr> oriol: implementations do something different with body which has position static, they use its parent (document element), and use the border edge instead of a border edge
16:31:13 <noamr> oriol: there's a bug in firefox but the idea is still the same
16:31:27 <dholbert> dholbert has joined #css
16:31:42 <noamr> oriol: I think what the spec says makes more sense, that even though browsers are doing something different, we should probably align the spec with reality
16:31:52 <kbabbitt> s/instead of a border edge/instead of a padding edge/
16:32:16 <noamr> astearns: probably browsers wouldn't change this and maintain backwards compat
16:32:20 <TabAtkins> i'm also very sad about this being so weird, but suspect we couldn't fix it without everyone being off by 8px
16:32:34 <noamr> no one likes to touch offsetLeft issues, I tried before
16:33:04 <noamr> oriol: it works differently in nested body elements
16:33:07 <dholbert> present+
16:33:37 <noamr> astearns: so the discrepancy is only about the body?
16:33:47 <noamr> oriol: impls are doing different things for all body elements
16:34:04 <noamr> oriol: maybe that's ok
16:34:49 <noamr> oriol: if it's something is nested we might have to do something, I'm fine either way
16:34:59 <kbabbitt> agree that we probably need to spec current behavior for compat
16:35:31 <noamr> astearns: the simple thing would be to change the spec to match reality
16:35:49 <noamr> astearns: what would be the change?
16:36:41 <noamr> oriol: we'll add a case where if the offset parent is body with position static, we'd take its parent's border edge instead of its padding edge. Need to analyze some details
16:37:01 <kbabbitt> kbabbitt has joined #css
16:37:16 <noamr> oriol: we could establish for all body elements, or just for body that is a child of a root
16:37:19 <noamr> q-
16:37:24 <astearns> ack fantasai
16:37:24 <Zakim> fantasai, you wanted to ask if this makes sense to make dependent on 'position'
16:37:46 <noamr> fantasai: no strong opinion; our propagation rules for certain thing depend on body being the child of the HTML element
16:38:07 <noamr> fantasai: the value of position makes a difference. Does it make sense to depend on position?
16:38:22 <noamr> oriol: browsers only do this with position:static, otherwise they compute the distance from the body
16:38:37 <noamr> oriol: it would probably be tricky compat-wise to do something else
16:39:24 <noamr> PROPOSED RESOLUTION: change the spec to match reality around child-of-root BODY elements
16:39:29 <flackr> q+
16:39:30 <noamr> fantasai: we should double check with WPT
16:39:41 <astearns> ack flackr
16:39:46 <fantasai> s/double check with WPT/not be checking in WPTs that aren't backed by a spec/
16:40:02 <noamr> flackr: is it just that the body element is position:static, or possibly when the body element is not a containing block? Do we need to worry about position:relative containing position:fixed
16:40:44 <noamr> oriol: if the body establishes a containing block using position, eg fixed inside relative, it would do the normal thing
16:41:03 <astearns> fwiw I’m OK with tests that pass everywhere but are not specced. This points out things we should spec
16:41:08 <noamr> oriol: if it's not the offsetParent, we also do the normal thing. so it needs to be in the containing block chain
16:41:38 <noamr> oriol: if the body is not in the containing block chain, it also wouldn't be the offsetParent and this wouldn't apply
16:41:45 <noamr> flackr: what is the offsetParent with position:fixed
16:42:23 <noamr> oriol: this is only a special case when the body is the offsetParent. So if position prevents the body from being a containing block it would also not be the offsetParent
16:42:33 <noamr> flackr: just making sure there is no additional special case here
16:42:43 <noamr> oriol: just that from what I can see
16:42:53 <noamr> objections?
16:43:01 <noamr> RESOLVED: change the spec to match reality around child-of-root BODY elements
16:43:24 <noamr> github-bot: take up https://github.com/w3c/csswg-drafts/issues/8511
16:43:24 <github-bot> Topic: [css-text-4] text-autospace: what gets copied?
16:43:24 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/8511.
16:43:58 <noamr> florian: text-autospace, in cjk at the limit between cjk and other, e.g. numeric, it adds spacing because it's typographically expected
16:44:26 <noamr> florian: the property has a syntax variant that it's not inserting but rather replacing the spacing, because sometimes that there is an explicit space
16:45:03 <noamr> florian: similar, outside of cjk, this is used to insert spaces in french before some punctuations. In some cases there is a narrow space, and CSS does it for people because people don't do it
16:45:24 <noamr> florian: what do we do with copy-paste in this mode? At least in the CJK context we ignore and copy the source
16:45:41 <noamr> florian: there are individual opinions that we should do the same for french
16:46:02 <noamr> florian: we were wondering whether this should be different for french, it's more an abuse/correction than styling
16:46:18 <noamr> florian: the i18n recommendation was to just copy the source
16:46:36 <noamr> florian: I was wondering about french, perhaps we should copy the original one
16:46:40 <noamr> q+
16:47:27 <noamr> florian: I would expect it to be copied correctly as a user, definitely for cjk we shouldn't copy
16:47:32 <noamr> s/florian/fantasai
16:47:56 <noamr> fantasai: there wasn't a conclusion in the group about what to do when we use replacement
16:48:04 <astearns> ack noamr
16:48:10 <fantasai> s/conclusion/obvious agreement/
16:49:25 <noamr> fantasai: for CJK we shouldn't copy, but for french, narrow spaces etc, a lot of other contexts wouldn't fix it, e.g. word wouldn't correct pasted stuff
16:49:37 <fantasai> s/CJK/CJK autospace insertion/
16:49:57 <noamr> florian: for having the spaces manually inputted into the text, it might be intentional, but if you're copy/pasting into an email, it's nicer if there was a space there
16:50:23 <noamr> florian: I find the i18n resolution plausible, still on the fence for french. then again it's a bit of a hack
16:50:35 <noamr> astearns: do we know what browsers do?
16:50:42 <noamr> fantasai: I suspect they use the underlying text
16:51:05 <noamr> fantasai: let's close and using underlying text, but come back to it if users complain
16:51:27 <noamr> fantasai: users can copy stuff that has a space, sometimes they'll get one and sometimes not
16:51:44 <noamr> fantasai: it's probably better to do the fixup in terms of users, but perhaps we can wait
16:52:19 <noamr> astearns: inclined to resolve on specifying we should copy the underlying text, perhaps with a note that this can change with user feedback
16:52:32 <noamr> fantasai: we can be open to changing it if there's user demand for it
16:53:09 <noamr> Jonathan: it's similar to copying text decorations. there are always going to be people unhappy with the decision
16:53:16 <noamr> ... I think this is up to presentation tools
16:53:21 <noamr> ... we shouldn't mangle the actual data
16:53:59 <TabAtkins> noamr: isn't htis a bit up to the browser? if the browser wants multiple copy functions in the context menu
16:54:07 <TabAtkins> noamr: is is the standard's job?
16:54:19 <TabAtkins> fantasai: there's often different format, sure - plain text, or html with formatting, etc
16:54:20 <jfkthame> s/copying text decorations/copying text with text-transform/
16:54:24 <TabAtkins> fantasai: we're just talking about plain text copy
16:54:43 <TabAtkins> fantasai: we do say that we collapse white space for a plain text copy, for example. if you didn't do that, the text would be a big mess if there's indentation
16:54:49 <TabAtkins> noamr: we copy capitalization, don't we?
16:54:56 <TabAtkins> florian: this is contentious, but no
16:55:14 <TabAtkins> fantasai: text-transform is a bit different because it's not correcting the text, it's providing a style. we're clear in the spec that it's a contextual style
16:55:19 <TabAtkins> fantasai: that's why you don't copy it
16:55:40 <TabAtkins> fantasai: the cases we're considering doing the transform are where the literal text isn't actually represetntative of the char string the author wants
16:55:46 <TabAtkins> fantasai: not just for presentation purposes
16:56:04 <TabAtkins> fantasai: if you're typing regular space instead of nbthinspace, you're doing it because nb thin space is hard to type
16:56:09 <TabAtkins> noamr: okay so it's more of an error correction
16:56:31 <noamr> florian: the injection to CJK is styling. the removal and replacement in french is error correction
16:56:33 <TabAtkins> florian: yeah, at laest part of it. the injectin of spacing in cjk contexts is styling. the removal/change of what's there (in french) is correction
16:56:54 <noamr> dbaron: a copy operation in many OSes already does multiple things at once
16:57:18 <noamr> florian: we're only defining plain text here
16:58:17 <noamr> PROPOSED REOSLUTION: plain text copy must ignore text replaced autospace. open to other feedback
16:58:40 <noamr> github-bot: take up     https://github.com/w3c/csswg-drafts/issues/3434
16:58:42 <github-bot> Topic: [css-text] Prevent line breaking after explicit hyphens
16:58:42 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/3434.
16:59:22 <noamr> florian: browsers might to suppress hyphens in special words like t-shirt. Which property controls this? hyphen: none doesn't. Maybe a new value? Maybe a new value of the break property?
16:59:56 <noamr> florian: this issue is to discuss what toggle do we use for this. there are a few options on the table. please chime in
17:05:35 <antonp> antonp has joined #css
17:09:32 <astearns> topic: end
17:12:51 <astearns> zakim, end meeting
17:12:51 <Zakim> As of this point the attendees have been noamr, bramus, castastrophe, (irc, only), kbabbitt, argyle, kizu, ChrisL, joshtumath, jfkthame, stepheckles, lea, rachelandrew, oriol,
17:12:54 <Zakim> ... davidleininger, TabAtkins, alison, ydaniv, flackr, smfr, miriam, SebastianZ, gfaujdar, dholbert
17:12:54 <Zakim> RRSAgent, please draft minutes v2
17:12:56 <RRSAgent> I have made the request to generate https://www.w3.org/2024/10/30-css-minutes.html Zakim
17:13:03 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:13:03 <Zakim> Zakim has left #css
19:24:43 <a-ja> a-ja has joined #css
23:19:50 <keithamus8> keithamus8 has joined #css