On Tuesday, March 25, 2025 at 5:12:17 AM UTC-4 Jake Archibald wrote:
Let me try and explain the breaking case again. I'll describe it in terms
of a React component for brevity, but the same issue exists with regular
DOM.
Here's a basic list of items, with a button that randomises the order of
the list. This is one of the main use-cases given for this feature.
export const ListOfStuff = () => {
const [items, setItems] = useState([
{ imgSrc: '…', alt: '…' },
// …
]);
const onButtonClick = () => {
document.startViewTransition(() => {
flushSync(() => {
const newItems = items.slice();
randomSortArray(newItems);
setItems(newItems);
});
});
};
return (
<div>
<ul class="list-of-stuff">
{items.map(({ imgSrc, alt }) => (
<li key={imgSrc}>
<img src={imgSrc} alt={alt} />
</li>
))}
</ul>
<button onClick={onButtonClick}>Randomise!</button>
</div>
);
};
And let's make this all work with this new enticing feature:
.list-of-stuff > li {
view-transition-name: auto;
}
It works! Each item moves from its old position to its new position.
But then, sometime later, another developer on the project wants to be able
to link folks to the first item of the list (it's displayed bigger, as if
it was the main item). That's a small and easy change!
export const ListOfStuff = () => {
// …as before…
return (
<div>
<ul class="list-of-stuff">
{items.map(({ imgSrc, alt }, i) => (
<li key={imgSrc} *id={i === 0 ? 'first-stuff-item' : undefined}*>
<img src={imgSrc} alt={alt} />
</li>
))}
</ul>
<button onClick={onButtonClick}>Randomise!</button>
</div>
);
};
The developer is smart and careful, so they check that `first-stuff-item`
isn't used elsewhere on the page, or even in the codebase, which it isn't.
But, they just broke the transition. It isn't totally broken, parts of it
still kinda work, but it doesn't look right. Specifically, three of the
items no longer move, they just fade.
This isn't anything to do with the old version of the page being different
to the new version. This is an SPA so it's all the same version.
The problem is that, with view-transition-name: auto, adding an ID has a
behavioural side effect. It now tells the view transition that the first
item in the list is the same either side of the transition. It overrides
element equality.
*Until this feature (correct me if I'm wrong), adding a unique ID to an
element was safe. With this feature, that's no longer the case.*
This seems like a worthwhile question to bring back to the TAG and/or the
CSSWG. Looking at the TAG review, it doesn't seem like it was discussed.
I agree with Jake that this is a *huge* footgun.
This is a pretty big change for the platform, and I don't see the benefit.
This issue wouldn't happen if any of the following was done instead:
- Each element was assigned a unique view-transition-name ident
- view-transition-name: match-element was used. It doesn't do anything
with the ID attribute.
- Each element was given a unique data-vtn attribute, and
view-transition-name: attr(data-vtn type(<custom-ident>)) - this is ok
because it isn't overloading an existing attribute with new behaviours, and
developers can easily search the codebase for data-vtn to see how it's used.
Were any of these alternatives considered?
This is in addition to the issues around the API behaving differently
between same-document and cross-document transitions. This is fine with
match-element, as it simply doesn't work cross-document, and the browser
could warn developers if they try to use it. Whereas view-transition-name:
auto is intended to sort-of work cross-document, but will not give the same
results as a same-document transition.
I'm sad that the reasoning given for shipping this is "well, Apple just
went ahead and shipped it so I suppose we should too".
This should 100% *not* be the reasoning for shipping a feature we think is
bad.
Are we seeing real-life interop pressure? How many sites are already using
`auto`? What's the user experience in Chromium for ones that do?
On Mon, 24 Mar 2025 at 20:46, Jake Archibald <[email protected]> wrote:
The example I gave isn't a versioning issue, it results from overloading
the id attribute.
The example I gave wouldn't be broken if view-transition-name was given an
ident. And it's less likely to happen if the name was pulled from a
dedicated attribute eg data-vtn via attr(), since that wouldn't also be
used for things like landmark links.
My advice to developers would be to avoid `auto`. `match-element` is good
for particular SPA (or later, scoped) cases.
I'm sad that Apple have forced a wart into this API.
On Mon, 24 Mar 2025, 20:04 Vladimir Levin, <[email protected]> wrote:
(feature author hat)
I'd like to highlight that view-transition-name: auto does have a need in
MPA, where match-element cannot match anything across different documents.
I agree that the versioning problem that Jake mentioned exists in that
case, but it seems similar to any other versioning problem where
view-transition-name: <ident> is used to identify paired elements: those
may or may not work if the version of the current page matches the version
of the next page.
The reason that we're advocating for shipping view-transition-name is in
part, as Noam mentioned, interop. The other reason is that it does address
a need to automatically match elements based on some criteria across
document navigation. Because of this dependence of CSS on HTML, we likely
do need documentation that highlights developer care required when changing
IDs. However, I still think the value added by the feature exceeds the
risks.
Thanks,
Vlad
On Mon, Mar 24, 2025 at 2:31 PM Noam Rosenthal <[email protected]>
wrote:
On Mon, Mar 24, 2025, 6:20 PM Alex Russell <[email protected]> wrote:
It seems like Jake's concern is well founded. Was this discussed at CSS WG?
Do we understand why this problematic design is going forward in other
engines?
It was discussed multiple times with the CSSWG. They seem to believe that
the ID-based approach is nice for simple cases.
I personally agree with Jake's arguments, but since we had it in the draft
and Apple refused the request to unship, I believe that having a
non-interoperable support for this feature would be worse than shipping the
same thing, while advising people to use the less footgunny match-element
which we ship at the same time and Apple has implemented.
I wanted to stress that addressing this issue of auto generating names was
a repeated request from multiple early adopters of view transitions, and eg
React rolled out their own solution to this problem.
Best,
Alex
On Monday, March 24, 2025 at 6:30:42 AM UTC-7 Mike Taylor wrote:
LGTM2
On 3/24/25 4:22 AM, Domenic Denicola wrote:
Thanks for the quick responses! LGTM1.
On Mon, Mar 24, 2025 at 4:37 PM Noam Rosenthal <[email protected]>
wrote:
On Mon, Mar 24, 2025 at 5:53 AM Domenic Denicola <[email protected]>
wrote:
Generally in good shape, but I have questions about potential open spec
issues.
On Friday, March 21, 2025 at 4:09:17 AM UTC+9 Chromestatus wrote:
Contact emails [email protected], [email protected]
Explainer https://github.com/WICG/view-transitions/blob/main/auto-
name-explainer.md
Specification https://drafts.csswg.org/css-view-transitions-2/#auto-vt-name
Summary
This intent covers two new keywords for view-transition-name: -
'match-element' generates a unique id based on the element's identity and
renames the same for this element. This is used in Single Page App cases
where the element is being moved around and the desire is to animate it
with a view transition - 'auto' generates a unique id based on the
element's id attribute. This value remains the same for the same ids
regardless of the element, but does not otherwise match the
view-transition-name named with the same ident as the id. This can be used
in both Single and Multi Page Apps to match elements based on their id
attributes. Allow the 'auto' keyword as a value for the
'view-transition-name' CSS property. This generates a unique name for the
element, and reduces the burden of having to invent unique names for
participating elements.
Blink component Blink>CSS
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22>
TAG review https://github.com/w3ctag/design-reviews/issues/1001
TAG review status Issues addressed
Risks
Interoperability and Compatibility
None
I guess there is some small compat risk in that people might have
previously named their view transitions "auto" or "match-element", but
we're hoping that's rare?
`auto` was an invalid value in view-transition-1 for this reason, so
`@supports { view-transition-name: auto }` would discover this feature.
`match-element` is a small enough compat risk.
*Gecko*: No signal (https://github.com/mozilla/standards-positions/issues/
1198)
*WebKit*: Shipped/Shipping (https://webkit.org/blog/
16301/webkit-features-in-safari-18-2)
Safari seems to have only shipped "auto" based on that blog post. Do you
know their thoughts on "match-element"? Maybe based on
https://wpt.fyi/results/css/css-view-transitions/match-element-name.html?label=master&label=experimental&aligned
they've also implemented match-element.
They've implemented it already.
https://github.com/WebKit/WebKit/pull/35953
*Web developers*: Positive This is a highly requested feature to prevent
the need to uniquely identify each participating view transition element.
*Other signals*:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, Android, and Android WebView)? Yes
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
? Yes
https://wpt.fyi/results/css/css-view-transitions/auto-
name-from-id.html?label=experimental&label=master&aligned
https://wpt.fyi/results/css/css-view-transitions/
navigation/auto-name-from-id.html?label=experimental&label=master&aligned
I guess
https://wpt.fyi/results/css/css-view-transitions/match-element-name.html?label=master&label=experimental&aligned
is also relevant.
Right.
Flag name on about://flags
Finch feature name CSSViewTransitionAutoName
Requires code in //chrome? False
Tracking bug https://issues.chromium.org/issues/399877975
Estimated milestones Shipping on desktop 136 Shipping on Android 136 Shipping
on WebView 136
Anticipated spec changes
Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
None
Are any of these relevant?
They are, forgot to close some of them :)
- https://github.com/w3c/csswg-drafts/issues/11614
Yes, this one is resolved and implemented.
- https://github.com/w3c/csswg-drafts/issues/11112
A duplicate of the previous one.
- https://github.com/w3c/csswg-drafts/issues/10995
This one is resolved and implemented. Jake Archibald expressed his
reservations about the ID behavior after webkit had already shipped.
We thought that he had some good points, but since this is already shipped
in webkit, I believe that what the working group resolved here
<https://github.com/w3c/csswg-drafts/issues/11614> is satisfactory.
- https://github.com/w3c/csswg-drafts/issues/10978
Implemented, now closed.
Link to entry on the Chrome Platform Status https://chromestatus.com/
feature/6575974796492800?gate=5170335230722048
Links to previous Intent discussions Intent to Prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-
dev/66fe6d9c.2b0a0220.d54b7.1136.GAE%40google.com
This intent message was generated by Chrome Platform Status
<https://chromestatus.com>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_MKpO5%3DC%2B6O3C6v443Ywr8cjU-rHijm%2BvmZrLob5EW1w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_MKpO5%3DC%2B6O3C6v443Ywr8cjU-rHijm%2BvmZrLob5EW1w%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYb_xqtyotWGQ1RvupmYz65DEG51igYe32qm-YSvBvy%2BTQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYb_xqtyotWGQ1RvupmYz65DEG51igYe32qm-YSvBvy%2BTQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to a topic in the
Google Groups "blink-dev" group.
To unsubscribe from this topic, visit
https://groups.google.com/a/chromium.org/d/topic/blink-dev/5LfSXRBkeAY/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
[email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NJq5G9PspB7EW4kQ3EbqB4PD4oF5uQ%3Du0WBRS2%2BuXVcQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2NJq5G9PspB7EW4kQ3EbqB4PD4oF5uQ%3Du0WBRS2%2BuXVcQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/12e18d28-52f0-4ddb-8dec-61ceb0c93886n%40chromium.org.
