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 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.
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".
On Mon, 24 Mar 2025 at 20:46, Jake Archibald <jaffathec...@gmail.com> 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, <vmp...@chromium.org> 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 <nrosent...@chromium.org>
>> wrote:
>>
>>>
>>>
>>> On Mon, Mar 24, 2025, 6:20 PM Alex Russell <slightly...@chromium.org>
>>> 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 <
>>>>> nrosent...@chromium.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 24, 2025 at 5:53 AM Domenic Denicola <
>>>>>> dome...@chromium.org> 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 nrosent...@chromium.org, vmp...@chromium.org
>>>>>>>
>>>>>>> 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 blink-dev+unsubscr...@chromium.org.
>>>>> 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 blink-dev+unsubscr...@chromium.org.
>>> 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
>> blink-dev+unsubscr...@chromium.org.
>> 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 blink-dev+unsubscr...@chromium.org.
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJ5xic-wyYHmVj2Uvxpbuk%3DoAuswa-pKKEiY2SdzQZ%3D9RVcaoQ%40mail.gmail.com.
