The current codebase of the component library that was forked from Uno has a couple of things we would like to change:
Use the nl- prefix for components and class names. We would prefer the names to start with nl-, so organisations can have a "fork first" policy where they fork the component and change the prefix so they can iterate quickly on existing components without NL Design System becoming the bottleneck. Contributing the modifications back to NL Design System should be a separate step where there is there isn't as much time pressure to accept contributions and quality comes first.
CSS Variables for design tokens instead of hardcoded values for Rijkshuisstijl.
Web components to initiate complex components via the native instead of custom progressive enhancement scripts.
ES Modules instead of System.js
Web components so for many components there is a lesser need to maintain implementations specific to each framework.
Provide a CSS file that defines CSS variables for the Rijkshuisstijl.
For backwards compatibility with existing Uno class names, it should be relatively to write a SCSS file that makes the current Uno class names an alias for the prefixed BEM class names.
The color modifiers are specific to Rijkshuisstijl, so for badge--robijnrood we will not have a semantic equivalent. More likely we will have nl-badge--dataviz-1 - nl-badge--dataviz-20.
mostly skip for now: it is a very complex component, with infinite variants, we can offer little useful information for the generic variant
link card: https://github.com/nl-design-system/backlog/issues/101 making an entire section clickable to activate an embedded link is such a widely used pattern we need to include it in an early stage. It might not have to come with any card specific styling.
no migration at this stage of these patterns: card grid, card columns
no migration at this stage of this variant (or perhaps, a separate component): list--card-small
do not migrate, the requirements for many users would be too complex at this stage. The Donut Chart for Duo is quite simple though, we could migrate the current version to <duo-donut-chart>
we could investigate global design tokens for dataviz colors (needs issue) so they can be used to configure 3rd party libraries in the correct style
we could offer a code example how to apply CSS variables for dataviz in third party libraries
It is a component that is used in many different interfaces, so many organisations would benefit from it. This would be a good candidate for other organisations to contribute at the stage they encounter the need for it.
For sake of atomic design, this would be an "Attachment" component, and an "Attachment list"
feels like a component that is meant for a very wide range of use cases. From instructions in a form to an polite and informative in-line secondary and tertiary "notification".
As white-label component it would be difficult for organisations to style this, because the design tokens would affect all uses cases
We don't want to migrate this right now, but implement this as separate components: "form instruction" component, "callout" component
"Link list" should be a separate component, because it would disable some features that are generally essential for other list (bullet icons or dashes) and the links should sometimes maximize the clickable area
Lists in articles should be available in NL Design System
there should be design tokens for white space and icons
"Filter list" will not be migrated, that looks like it should be a "Category badge list" component
"Task list" or "process steps list" should be a separate component on the backlog, which seems what the "Decimal with background" variant is all about.
We should have design tokens for this purpose, to have less prominent text in the page while maintaining proper contrast
A "meta" component seems too generic, we could include more specific components such as "article metadata paragraph" that use the relevant design tokens
But generally these meta components should live in forks for their own specific purposes, and graduate to the central repo when there is more need for this.
should not be difficult to migrate, and many websites have this
what design tokens should apply? primary link color?
needs next and prev icons
needs guidance on maximizing clickable area
as with other navigation components, at some point there should be two implementations: one for server-side navigation and one for single page apps. Needs investigation what the API should be for this component to make that work for SPA's.
More than a spinner image, the essential information is that we need to provide to developers is how to inform the busy state for parts of the page, and announce when the information is available.
Also specifically explain what needs to be done for the spinner in the context of form submissions.
Summary: spinner component should probably never be implemented in a page as-is, needs more work than that.
Loading pattern should be a separate item in our backlog
Also investigate the need for a "Shimmer component" and a "Skeleton component"
So maybe, including the spinner component without the relevant extra documentation it might do more harm than good.
Introduction
The current codebase of the component library that was forked from Uno has a couple of things we would like to change:
nl-prefix for components and class names. We would prefer the names to start withnl-, so organisations can have a "fork first" policy where they fork the component and change the prefix so they can iterate quickly on existing components without NL Design System becoming the bottleneck. Contributing the modifications back to NL Design System should be a separate step where there is there isn't as much time pressure to accept contributions and quality comes first.For backwards compatibility with existing Uno class names, it should be relatively to write a SCSS file that makes the current Uno class names an alias for the prefixed BEM class names.
Components
badge--robijnroodwe will not have a semantic equivalent. More likely we will havenl-badge--dataviz-1-nl-badge--dataviz-20.list--card-small<duo-donut-chart>nl-prefixed class namesnl-header__logoslot for this purpose..nl-image { width: 100% }available<div>tables would be out of scope for migration within our time constraints, but help is much appreciated