feat(css): input-tile

[oddvernes]

resolves #526
resolves #529

[changeset-bot]

🦋 Changeset detected

Latest commit: 99e01d4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@digdir/designsystemet-css	Minor
@digdir/designsystemet-react	Minor
@digdir/designsystemet	Minor
@digdir/designsystemet-types	Minor
@digdir/designsystemet-web	Minor

Not sure what this means? Click here to learn what changesets are.

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

[github-actions]

Preview deployments for this pull request:

storybook - 10. Apr 2026 - 14:33

www - 10. Apr 2026 - 14:41

[Febakke]

This looks great 🎉 I have no notes on the design. What do you think about creating component variables for background colors on the different states? If I wanted a heavier "hover" state for instance i could just overwrite the background color variable for hover? Does that make sense?

I noticed the error message was placed inside the "tile". Would it be possible for our users to add it outside of the border? Looks a little weird inside to me, but there might be usecases where this make sense. Here are some example on how I would have set it up.

What do you think about the read-only variant? I noticed that I get the "clickable" cursor when im not over the input / label element. Not sure if its a problem.

I noticed some weird screen reader behaviour on some of the examples, but we can look at that later maybe?

[oddvernes]

This looks great 🎉 I have no notes on the design. What do you think about creating component variables for background colors on the different states? If I wanted a heavier "hover" state for instance i could just overwrite the background color variable for hover? Does that make sense?

Yes I have thought about this too, can add this with transparent as default

I noticed the error message was placed inside the "tile". Would it be possible for our users to add it outside of the border? Looks a little weird inside to me, but there might be usecases where this make sense. Here are some example on how I would have set it up.

Error message immediately below the input is a built in feature from before so this is why I included an example. We just don't use it in our examples, usually we add ValidationMessage to the Fieldset as your image

What do you think about the read-only variant? I noticed that I get the "clickable" cursor when im not over the input / label element. Not sure if its a problem.

This is an oversigth, will fix!

I noticed some weird screen reader behaviour on some of the examples, but we can look at that later maybe?
👍

[oddvernes]

Setting it as ready for review because i want feedback before adding www docs. The tile example story is in checkbox

Questions:

• Naming. I called it selection-tile (since it affects selection controls only). It could alternatively be called selection-panel 🤷
• selector. class or data-attr or both? (currently it is both). Normally components have class as outermost selector and data-attr for modifiers. This is both outermost and a modifier

I also introduce a new layer here (ds.utils) since this is a utility and utilities should generally have highest specificity since it is something meant to modify something existing

I made a utils.css thinking we could put other stuff here (like potentially data-pad that @eirikbacker suggested and other planned layout stuff). But the amount of code perhaps suggests it should be individual files (selection-tile.css)

[mimarz]

Some thoughts from slack discussion:

• How do we flag experimental CSS features?

[oddvernes]

Some thoughts from slack discussion:

* How do we flag experimental CSS features?

The only way to do it I can think of is how we did it for things like .togglegroup that got re-named to .toggle-group, you start off with data-experimental-selection-tile / .ds-experimental-selection-tile and then when it is ready add on data-selection-tile / .ds-selection-tile without removing the old selectors. Then a year down the line remove the old selectors in a future major.
But I don't really see the purpose of this. It feels like overkill and built in breaking change just to communicate something that can be noted in docs without creating future work 🤷

[mimarz]

Meeting 19 march with @oddvernes @Barsnes @mimarz

• selection-tile 👍
• Define as class for now, add data attr later if needed.
• Add new experimental export and folder with named file for feature so people can import it as; @digdir/designsystemet-css/experimental/selection-tile.css.

[mimarz]

Meeting today with @mimarz @oddvernes and @eirikbacker.

@eirikbacker suggested to look at if we could build this into ds-field as a variant instead of separate class to reduce concepts/utils. He'll follow up with an example/poc for how that could be solved.

[oddvernes]

Ready for review again 👍
For docs I just duplicated the "group" story for each component with outline variant and used the same description everywhere so it is easy to edit with search and replace if needed