Meeting minutes
View Transitions
[css-view-transitions-2] Allow an auto-generated `view-transition-name` that doesn't default to ID
bramus: This issue is about allowing an auto view-transition-name to be generated by specifying a keyword
bramus: a number of keywords suggested, from-element, per-element, self, auto, auto-id
bramus: I asked authors "which keyword conveys using ID and falling back to auto-generated" and "which keyword conveys automatically generated"
bramus: when I asked which is "automatically generated", they picked "auto"
bramus: when I asked about the ID and fallback, the responses ...
bramus: We were thinking 'from-element' but authors expected 'auto' for "automatically generated".
bramus: we could meet developers by reverting previous resolution about auto reading ID and falling back
bramus: and come up with a better keyword
bramus: or push authors towards using attr() function which is suited for this, can use attr(id, auto) for fallback behavior
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
bramus: Authors prefer auto-id for autogenerated, and some suggested generated
bramus: and some others said, don't we have attr() for this?
fantasai: we can conclude from the poll that there is cnofusion over keywords
… wording of poll most likely prompted some of the responses
… using “automatically generated id” pushed authors towards `auto`
… internally we are generating one, bu thtat is just the meachism
… it is an internal detail
… the will never see it … we might not even generate one and use poitner identity
… its not about automatically generating ids, its about the identify of the element object
… poll is propably a but confused on that point
… could try to come up with good keywords but maybe need some more ideas
… but doesnt mean that we should revert decision on `auto`
… in terms of possible keywords: `mathc-elememtn` is an option as we use match in a few other places
… but open to ideas
… at webkit we think `auto` is the right way to define it
… and maybe need other keyword for the other thing
<noamr> I like match-element
astearns: the currently specced behavior for auto is to use the id attr and fall back to auto generated one?
fantasai: its to use the identity of the element
… if there is no id, we look at the element being the same object or not
… in that case, the object hasnt been destroyed - its a singular one that you can map between tree versions
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
… of all options maybe self is nice as it doesnt hit at generating something
… your identtity is the nodes identity
… 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
match-element? same-element?
florian: explanation fantasai just gave: if that can be used. key point is stability … so maybe akeyword like stable?
… if the elemen tis still around it will be the same
… dont describe what we do but the why
noamr: I like match-element. we match not just the id, but the actual elements
… matching two state of the same element
<khush> i'm ok with match-node or match-element
bramus: I like all these suggestions just now, `stable` and `match-element`.
bramus: doesn't seem confusing
bramus: `from-element` implies reading from the element, but matching is matching so seems like a good suggestion
bramus: wrt `auto` part, as DevRel we can hammer on this point, means "try to get a name" not "automatically generate one"
astearns: which method do we expect authors to use most?
noamr: It depends
noamr: Likely use explicit names. Otherwise likely to use auto, it will just work.
noamr: But if they want to specifically say that id attrs don't participate, then use match-element
noamr: I think auto would be more common, it will usually just work.
noamr: element identity, not observable if generated string
astearns: We have a way of using the ID attribute, specifically, by using attr() function
astearns: we have defined `auto` to match the element by ID if there is one, or using other methods if not
astearns: Is there really a use case for "throw out the IDs and only use the opaque element-matching algorithm" ?
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"
noamr: You wouldn't be able to match if element has an ID in only one of the state
khush: or if ID is used for a different reason, and not used in view transitions
astearns: I can see the case, but not expecting authors to run into it much
noamr: cleaner solution to have specific keywords for each behavior
astearns: understand, but that's a theoretical purity argument
khush: We heard from one AirBnB where teams use ids for entirely different things
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
… that would avoid name clasing
… 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.
… that would namespace it and avoid clashes
astearns: this would be an additional thing
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
khush: not sure about this, but maybe could do it for auto-generated ones. Not for those read from attr.
… will be a pain to keep track of where it came fromg
fantasai: fair
noamr: against namespacing because of flexibility of VTs.
… take cross-doc VT with #hero id on one side and one with hero v-t-name on other side
… would want to transition between those
khush: can open issue separately from this
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
bramus: so if you want to auto-generate an ident you use it
fantasai: so ident() should take wjhat?
bramus: `view-transition-name: ident(auto)` to auto-generate an ident
… so we dont have to come up with a keyword for this
fantasai: but that retrurns an actual observable identifier
… which we dont think we want to do
… should still have keyword for it
… can consider is distinguishing between auto keyword actually creating a referencable v-t-n or just an internal matching
… can you selec tagainst the generated identifier is an open question
… would we do that or just use the id attr to match elements but not to select against it
… like `::v-t-g(id)`
khush: would be nice if you could do it for for the `[id]` case
… pretty convenient
fantasai: only downside is that we might have namespace clashes and stuff that you are using for identity in the document
noamr: right, mixing things
fantasai: can agree on keeping `auto` as it is
… and for now add a keyword `match-element` for only looking at element id
… and open issue about mixing the namespaces
astearns: Gonna need async resolution as we are low on people attending
PROPOSED RESOLUTION: Add `match-element` keyword that will only use element identity and not use id attributes.
astearns: will be submitted as an async resolution
RESOLUTION: [Pending async confirmation] `auto` will match elements using their ID attributes, falling back to element identity; `match-element` will only use element identity.
github-bot, take up w3c/
[css-view-transitions-2] How are auto-generated `view-transition-name`s exposed in JS APIs
<github-bot> OK, I'll post this discussion to https://
noamr: how do autogenerated appear in things like getAnimations?
… 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?
ACTION: Open new issue about whether `auto` exposes the ID from the ID attribute as a view-transition-name for pseudo-element matching
bramus: and devtools?
noamr: no, not included
khush: two options
… if we decied that id based names ar ehidden from css then it makes sense to hide everything from auto
… or if name came from id attribute then do expose it but dont expose the identity ones (and expose those as `match-element`)
astearns: the ids that auto uses could be made opaque but if the author uses the attr() fn then they would be exposed?
khush: thats the complication with hiding ids
… if you use attr() then you have all those complications of where you get the strings from
… can punt on this until we decide how to namespace ids
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
bramus: would be useful to expose that name
bramus: if we fall back to match-element strategy, then show that as match-element
bramus: because authors can't target those elements directly
bramus: by having match-element there, clearly can't target
fantasai: q about whether id on one page would match a v-t-n on other is part of the namespacing discussion
… dont have an opionion on direction
… if that worked, then we should make pseudos match that
… but q is then should that work in the first place?
… do we want to expose the name derived from an id in the first place? no opinion right now.
… obviously should not expose autogenerated names
noamr: strong opinion about keeping things simple… if generated by id its just that name
… already doing complicated things that look different
… if the v-t-name comes from an id, then that should be the v-t-n
… if author dont want that, they should do other things
… lets keep things flat
… regardless we can resolve to use the name `match-element` in `getAnimations`
khush: since we are going here … my alignment is wit noam on this. keep it simpel and treat them as names
… dont have author feedback on this though
… not a super strong opinion
… 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?
… then VT wont have this own special thing
… concept would make sense across CSS
fantasai: none of the others have a way of pulling element id
khush: but can imagine anchor-pos doing the same over time
<noamr> I like that auto === id ? attr(id) : match-element
bramus: missed
astearns: but flatness isnt part of the issue
noamr: lets thing about that a bit more
noamr: lets resolve on exposing them as `match-element`
astearns: is ther ea conclict there?
noamr: its just in getAnimations
astearns: which is wrapped in a pseudo
khush: compat risk for users that have used `match-element`
bramus: dont think anyone has used that yet
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
noamr: and tbd if these id-based names are namespaced or not
astearns: should open an issue that
khush: can do that
PROPOSED RESOLUTION: we will use `match-element` in the Animations API when element identity is used
astearns: objections?
(silence)
RESOLUTION: [Pending async confirmation] we will use `match-element` in the Animations API when element identity is used
github-bot, take up w3c/
[css-view-transitions-2] Optionally capture some properties (e.g. opacity/border) as style instead of snapshot
<github-bot> OK, I'll post this discussion to https://
noamr: talked about capturing snapshots not flat but to also capture borders, shadows, opacity, etc
… had homework to figure out the exact way of how this would work and do some compat analysis
… have done both to an extent
<noamr> https://
noamr: wrote an explainer for this
… main question is if this is a net improvement to capturing elements layered or not?
… only works when elements are superimposed on eachother in a way, like cross-fade morphs the animation
… many people use slide animations, like a header sliding offscreen
… when authors do that, capturing the borders separately creates a different effect
… backwards compat it wouldnt affect hat many peole right now, but those that are affected are affected in a big way
… want to get attention to the explainer
… there are afew optoins:
… make it an opt-in
… or create an extra pseudo for the geometry animation
… it does create more things to think about it, but nice thing about that it is that it does what it does today
… you need to only style it if you want to
… third option is to have no opt-in and have authors opt-out by containment thorugh adding an extra container element
… not looking for a resolution now
khush: +1 to what noam said
… am pretty convinced that original capture way might have been a mistake.
… noam dug up styles that authors used to customize animatoins and have found slight animations that were set up
… if you have two things
… where the whole bg changes you dont want those to fade but just want the slide effect
… dont want to break those
… especially on the root level
… also dont want authors to have to create a wrapper around the content int root to fix that
… could maybe resolve that both these modes should exist
… how to select one or the other can be decided later
bramus: +1 on both modes being valuable
a+
astearns: need to read explainer a bit more. wrapper made sense until khushals argument
noamr: should generally avoid people to change their dom for style purposes
bramus: +1
bramus: can the extra speudo give a perf benefit?
noamr: not really. think of border animating
… I encourage ppl to look at the explainer
… especially the geometry part, because we copy over the box model
… also scrollbars and stuff
… food for a next meeting
astearns: thanks for the summary and explainer. its great to have
… will summarize the breakout to the www-style list and set up async resolutions and point people to the explainer
… gonna wrap up
none
github-bot: take up w3c/
[css-color-hdr] Add interpolation between multiple values of dynamic-range-limit
<github-bot> OK, I'll post this discussion to https://
Chris: we have this dynamic range value. but you might have more than value, e.g. in animation, need to decide what happens
ChrisL: we have a PR, we either should merge it or revert. I think it's a good syntax
astearns: inclined to accept the PR
ChrisL: I prefer to review things in place
astearns: objections?
RESOLUTION: Accept the PR
github-bot: take up w3c/
[css-images] Should CSS decorative images respect EXIF-orientation by default
<github-bot> OK, I'll post this discussion to https://
ChrisL: it wasn't clear what we've resolved on
ChrisL: what this means that if you have EXIF that comes before the image data we must respect it
ChrisL: for consistency we should probably ignore it when it comes after
smfr: you mean in the order in which the image is encoded?
ChrisL: yes, which is not always possible
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
schenney: chrome does this but safari does not
ChrisL: there wasn't a discussion on this, can we discuss now?
schenney: one, I implemented this a while ago, the usage data for image-orientation and it's rising, but not in a huge amount
schenney: people use it to avoid applying the image metadata
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
schenney: we'll get pushback if we do that
… if we don't honor image-orientation
noamr: even now, image-orietnation is broken in the sense that it doesn't work on cross-origin images
noamr: which is a real big breakage for people
noamr: I find it a broken CSS property because of that
<ChrisL> +1 to URL modifier
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
noamr: we have url() modifiers now for other things, we can put it there. i think that's the right place
(+1 to that, it was clumsy to have it apply that way)
smfr: it should be per-image, maybe on the image function
smfr: background: webkit started supporting orientation by default on regular images, we just didn't get to CSS images
smfr: I think we can change it to match the chromium behavior
<Zakim> how, you wanted to say "ignore rotation" in that case?
CLilley: URL modifier is perhaps a good way to go
schenney: URL modifier would address the original reason why image orientation is ignored on cross-origin
I url modifiers should be for generic modifiers. We should use image() for image-specific modifiers.
And we should have more of them.
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
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
astearns: if we resolve on ignoring EXIF at the end, does that help with the transition?
dbaron: it wasn't clear to me which cases the resolution applies to
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
PaulG: I suspect we'd want to keep that
fantasai: modifiers should be in image() and not in url()
Yeah since this is explicitly an image *file*, I'm fine with it living on url()
astearns: we can probably resolve on ignoring metadata that's after the metadata
schenney: I thought it was resolved a while ago
ChrisL: it was unclear enough that it's hard to say what a PASS is
smfr: we might not be able to do this in the implementation
fantasai: HTML could add special rules, but in CSS we should say how we handle images with EXIF, regardless of the host language
it should at least be in both
smfr: odd that CSS would define things around the encoding of an image
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.
<dbaron> s/HTML should add that/HTML could add that/
noamr: We talked before in WHATWG about separqting some of those image details to as eaprate spec
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'
<ChrisL> relevant PNG WG issue is w3c/
noamr: We should behave the same way for HTML and CSS
astearns: it is claimed that all browsers ignore post-image-data orientation
astearns: smfr would you validate?
smfr: will validate
astearns: will take it back to the issue about encoding order
… to validate that all browsers do this today
ChrisL: please check with JPEG with PNG, I saw that Safari does something different
smfr: that's why we need more time
(In PNG this is encoded in XMP IIRC)
astearns: for how we override the metadata
<ChrisL> No, it can be but there is also an exif chunk
smfr: this is *this* issue, but we discussed a different one
noamr: also there's a proposal for a url() modifier. not clear yet. But at least not taking the info from image-orientation
schenney: so proposal is phase out a per-image way of specifying it, and phase-out image-orientation property
phase in an image-specific way to do *CSS images*.
dbaron: replaced elements, form HTML, would still obey image-orientation
astearns: so let's continue that part of the discussion in this issue
astearns: action item for smfr to validate the tests
github-bot: take up w3c/
[css-sizing] Intrinsic size of <img> / <video> with aspect ratio but no definite size
<github-bot> OK, I'll post this discussion to https://
<dbaron> github: none
github-bot: take up w3c/
[cssom-view] Spec for offsetTop/Left does not match impls when offsetParent is `position:static` `<body>` element
<github-bot> OK, I'll post this discussion to https://
oriol: we encountered this in servo, that impls are not per-spec
oriol: offsetTop/offsetLeft of the element, when there is no offsetParent, the distance is used
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 padding edge
oriol: there's a bug in firefox but the idea is still the same
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
astearns: probably browsers wouldn't change this and maintain backwards compat
i'm also very sad about this being so weird, but suspect we couldn't fix it without everyone being off by 8px
no one likes to touch offsetLeft issues, I tried before
oriol: it works differently in nested body elements
astearns: so the discrepancy is only about the body?
oriol: impls are doing different things for all body elements
oriol: maybe that's ok
oriol: if it's something is nested we might have to do something, I'm fine either way
<kbabbitt> agree that we probably need to spec current behavior for compat
astearns: the simple thing would be to change the spec to match reality
astearns: what would be the change?
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
oriol: we could establish for all body elements, or just for body that is a child of a root
<Zakim> fantasai, you wanted to ask if this makes sense to make dependent on 'position'
fantasai: no strong opinion; our propagation rules for certain thing depend on body being the child of the HTML element
fantasai: the value of position makes a difference. Does it make sense to depend on position?
oriol: browsers only do this with position:static, otherwise they compute the distance from the body
oriol: it would probably be tricky compat-wise to do something else
PROPOSED RESOLUTION: change the spec to match reality around child-of-root BODY elements
fantasai: we should not be checking in WPTs that aren't backed by a spec
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
oriol: if the body establishes a containing block using position, eg fixed inside relative, it would do the normal thing
<astearns> fwiw I’m OK with tests that pass everywhere but are not specced. This points out things we should spec
oriol: if it's not the offsetParent, we also do the normal thing. so it needs to be in the containing block chain
oriol: if the body is not in the containing block chain, it also wouldn't be the offsetParent and this wouldn't apply
flackr: what is the offsetParent with position:fixed
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
flackr: just making sure there is no additional special case here
oriol: just that from what I can see
objections?
RESOLUTION: change the spec to match reality around child-of-root BODY elements
github-bot: take up w3c/
[css-text-4] text-autospace: what gets copied?
<github-bot> OK, I'll post this discussion to https://
florian: text-autospace, in cjk at the limit between cjk and other, e.g. numeric, it adds spacing because it's typographically expected
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
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
florian: what do we do with copy-paste in this mode? At least in the CJK context we ignore and copy the source
florian: there are individual opinions that we should do the same for french
florian: we were wondering whether this should be different for french, it's more an abuse/correction than styling
florian: the i18n recommendation was to just copy the source
florian: I was wondering about french, perhaps we should copy the original one
fantasai: I would expect it to be copied correctly as a user, definitely for cjk we shouldn't copy
fantasai: there wasn't a obvious agreement in the group about what to do when we use replacement
fantasai: for CJK autospace insertion 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
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
florian: I find the i18n resolution plausible, still on the fence for french. then again it's a bit of a hack
astearns: do we know what browsers do?
fantasai: I suspect they use the underlying text
fantasai: let's close and using underlying text, but come back to it if users complain
fantasai: users can copy stuff that has a space, sometimes they'll get one and sometimes not
fantasai: it's probably better to do the fixup in terms of users, but perhaps we can wait
astearns: inclined to resolve on specifying we should copy the underlying text, perhaps with a note that this can change with user feedback
fantasai: we can be open to changing it if there's user demand for it
Jonathan: it's similar to copying text with text-transform. there are always going to be people unhappy with the decision
… I think this is up to presentation tools
… we shouldn't mangle the actual data
noamr: isn't htis a bit up to the browser? if the browser wants multiple copy functions in the context menu
noamr: is is the standard's job?
fantasai: there's often different format, sure - plain text, or html with formatting, etc
fantasai: we're just talking about plain text copy
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
noamr: we copy capitalization, don't we?
florian: this is contentious, but no
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
fantasai: that's why you don't copy it
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
fantasai: not just for presentation purposes
fantasai: if you're typing regular space instead of nbthinspace, you're doing it because nb thin space is hard to type
noamr: okay so it's more of an error correction
florian: the injection to CJK is styling. the removal and replacement in french is error correction
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
dbaron: a copy operation in many OSes already does multiple things at once
florian: we're only defining plain text here
PROPOSED REOSLUTION: plain text copy must ignore text replaced autospace. open to other feedback
github-bot: take up w3c/
[css-text] Prevent line breaking after explicit hyphens
<github-bot> OK, I'll post this discussion to https://
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?
florian: this issue is to discuss what toggle do we use for this. there are a few options on the table. please chime in