fix(Table): add support for clickable rows (and clickable cards)

[eirikbacker]

Summary

• Resolves Clickable table rows #3348

Background:

• OpenUI is working on a Link Area Delegation spec, where they propose different solutions. I think we can draw inspiration from this: https://open-ui.org/components/link-area-delegation-explainer/
• But we should name it data-clickdelegate so it makes more sense to use in combination with button and input (not only links) - aligning with Open UIs latest discussions (Link delegation to descendant openui/open-ui#1104 (comment)), even though they have not updated the explainer page itself
• Then we can polyfill the :click-delegate-hover and :click-delegate-active with class names: .\:click-delegate-hover and .\:click-delegate:active matching the convention from https://github.com/oddbird/popover-polyfill ☺️

Note:

• This technique will work for cards with heading as well, so we can update this logic and deprecate the old logic in time :)

Question:

• This requires id="" for all connections. I think the W3C Open UI group should consider the data-clicktarget (or defaultlink) attribute they initially proposed, so we do not need lots of id generation. This is an very early proposal, so we do not know where they land. Do you guys want us to go for the data-clicktarget attribute, or the id direction?

✅ With data-clicktarget: ⬅️ Implemented this solution after feedback from @stianmorsund

<tr data-clickdelegate>
  <td><button data-clicktarget></button></td>
<tr>

❌ With id:

<tr data-clickdelegate="my-button">
  <td><button id="my-button"></button></td>
<tr>

Checks

• I have read the contribution guidelines
• I have added a changeset (run pnpm changeset if relevant)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9d8d679

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Preview deployments for this pull request:

storybook - 7. Jan 2026 - 13:21

www - 7. Jan 2026 - 13:27

[Barsnes]

Can you add a story and doc (both react and html) for this on www as well?

[Barsnes]

Should we add some error reporting here if it finds multiple targets?
I assume a data-clickdelegate should only have one data-clicktarget

Suggested change

	const getDelegateTarget = ({ target: el }: Event) => {
	const scope = el instanceof Element ? el.closest(CLICKDELEGATE) : null;
	const target = scope?.querySelector(CLICKTARGET);
	const skip = target && (el as Element).closest(SKIP); // Ignore if interactive
	return ((!skip || skip === target) && target) || undefined;
	};
	const getDelegateTarget = ({ target: el }: Event) => {
	const scope = el instanceof Element ? el.closest(CLICKDELEGATE) : null;
	const target = scope?.querySelector(CLICKTARGET);
	const skip = target && (el as Element).closest(SKIP); // Ignore if interactive
	if (target.length > 1) console.warn(`Multiple ${CLICKTARGET} found for element: ` + el.closest(CLICKDELEGATE))
	return ((!skip || skip === target) && target) || undefined;
	};

[Barsnes]

Right just saw the querySelector, but we should probably check for more, to make sure this is used correctly?

[eirikbacker]

mm, I do not think we need this - in that case we need to do querySelectorAll which causes worse performance. If someone puts multiple targets, isn't it okay we just default to the first found? ☺️

[Barsnes]

Seems to work fine now in the preview deployments.
We'll wait with merging this until then.

Since this can be used basically anywhere, should we consider adding this under "utilities"? Since it is not specific to table, but table needs styling.

We also need to add tests for this function

[Barsnes]

We'll wait with merging this until then.

With this I meant wait for sideEffects to be handled in a different pr.. :P

[eirikbacker]

Added under utilites now, but need the useClickDelegate for now to work around tree shaking, and since we for now only demonstrate in table, I have added the loading in table ☺️
"We'll wait with merging this until then." - what is "then"? :D
tests are definitely needed. Is it something you guys can help with? (a bit stuck with some Mattilsynet chores here :o)

[Barsnes]

I can add tests to this :)

Also added a second comment about "then" 😓

[Barsnes]

I think PR looks good now. We should however make sure side effects is set to true so we can get a cleaner implementation of this.

[eirikbacker]

I think PR looks good now. We should however make sure side effects is set to true so we can get a cleaner implementation of this.

So do you want to wait for #4367 before merging? ☺️

[Barsnes]

I think PR looks good now. We should however make sure side effects is set to true so we can get a cleaner implementation of this.

So do you want to wait for #4367 before merging? ☺️

yes :)
Just makes it easier for us, since we won't have to clean something up "right after" merging