Re: [w3ctag/design-reviews] CSS view transition auto name generation (Issue #1001)

jakearchibald left a comment (w3ctag/design-reviews#1001)

As well as "adding IDs becomes risky", removing them becomes risky too. Here's a fairly typical case:

Moving IDs to another element:

1. A page contains `<button commandfor="some-element-thing">` and `<div id="some-element-thing">`.
2. A developer decides that the button should target a different element. It seems unlikely that pages are going to link to that particular div, and they search the codebase for `some-element-thing` and do not find it referenced anywhere else. So they move `id="some-element-thing"` to another element.
3. Transitions are broken, because that `id` was necessary to maintain a connection between the elements for a transition.

Cleaning up IDs:

1. A page contains `<button commandfor="some-element-thing">` and `<div id="some-element-thing">`.
2. A developer removes that button, as it's no longer needed. To maintain a clean codebase, they consider removing the id from the other element. It seems unlikely that pages are going to link to that particular div, and they search the codebase for `some-element-thing` and do not find it referenced anywhere else, so they assume `id="some-element-thing"` is safe to remove.
3. Transitions are broken, because that `id` was necessary to maintain a connection between the elements for a transition.

In both of these cases, the transition may not be broken in all cases. In many instances of the transition, element equality may be enough, so the bug is likely to hit production.

This wouldn't be an issue with `<div style="view-transition-name: some-element-thing">`, or `<div data-vt-name="some-element-thing">`.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1001#issuecomment-2768531758
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1001/2768531758@github.com>