querkmachine/felafel

The FELinesoft Agile Front-End Library.

Hello world, I'm beeps, a Bristol-based frontend developer currently working on the GOV.UK Design System, a product of the Government Digital Service.

Some things to know:

• 🏳️‍⚧️ My pronouns are it/its. Use them.
• 🌈 I'm queer as heck: trans, agender, asexual, panromantic, poly. If you don't support trans rights, stay outta my sight.
• 🤖 I'm a bit of a transhumanist. I don't readily identify as being human and don't particularly want to be.
• 🐾 I'm also a furry (shocker). My fursonas are a shapeshifting alien critter and a robotic Honduran white bat.
• 🖊️ I write about all of the above on my blog, beeps.website/blog.
• 🦣 I tootle about on Mastodon too, @[email protected].

The government's views are not my own, or vice versa.

felafel's Issues

Input masks don't stay "attached" to inputs if rounded corners are used

If rounded corners are being used on inputs, the border-radius is applied individually to the input and the input mask, making them appear disconnected.

Investigate dividing settings file into smaller parts

Currently all configuration options are contained within a single settings file. While this makes it really easy to override all options at once, it makes this file rather bulky, and the majority of the component-level options are only relevant to one component.

It may be prudent to move component options into the relevant component's partial, and encourage passing those options directly, e.g.

@use "../node_modules/fs-felafel/src/scss/settings" with (
	$fs-brand-color: #786999,
	$fs-canvas-background-color: #eee,
	$fs-page-width: 1320px
);
@use "../node_modules/fs-felafel/src/scss/components/input" with (
	$fs-input-mask-text-color: white,
	$fs-input-mask-background-color: black
);

This may also allow for the shortening of some of the more unwieldy configuration option names: $fs-step-indicator-complete-segment-label-text-color could become $fs-complete-segment-label-text-color for example.

Treat brand colour as part of palette

Currently the brand colour is defined as a standalone variable, excluding it from being automatically output alongside the rest of the colour palette (such as colour overrides) or accessed in the same manner.

Refactor to use CSS custom properties

Custom properties, variables but in CSS.

If we had them there's a few benefits:

• Allows for customisation of Felafel without having to use Sass or build processes.
• Makes context-dependent styles easier to work with (e.g. dark mode).
• Properties can be scoped to a specific instance of a component without having to make a new variant of that component.

And a few downsides:

• Custom properties can't be used in all contexts that Sass variables can (e.g. manipulating a colour using Sass' color module).
• No support in IE or old Edge. Fallbacks could be defined, but these add bloat to browsers that won't use them and would ignore any user customisations.

Of note:

• Custom properties are already used in the Choice Cards component for contextually overriding the default card width.
• Use would need to be contextual. Makes sense for things like feedback messages to retain a fixed set of states (success, error, warning, etc.) with contextual colours defined in the global scope, rather than letting these be defined per-instance with custom properties.

Checkbox/Radio: Reducing size doesn't maintain alignment

Reducing he size of these buttons doesn't maintain the alignment of the input with the label, causing the input to appear at the far top-left of the container.

Haven't checked if increasing has any side effect yet.

How to work with configuration maps going forwards?

In v1, user configuration maps completely overrode the default maps. This created build problems as many components assume that certain keys are going to exist for their default styles.

As of v2, the user's configuration maps are merged with the default maps. This allows the user to override the built-in keys if they wish to, but ensures that components can safely assume that a specific key is going to exist. However, this has resulted in automated procedures, particularly those that generate override classes, outputting code that will never likely to be used (i.e. for colours or font sizes the user hasn't specified)—adding unnecessary bloat to the CSS output.

In v3, it would make sense to change this. There are a few possible approaches I can see with this:

1. Add a config flag indicating the user wants to override the map rather than merge with it.
2. Revert to override behaviour and refactor to not error if a key is missing.
3. Revert to override behaviour and refactor built-in components to use a key if it exists, use a fallback if it doesn't.

Note sure on what the bet approach might be here. 1 is the simplest and is backwards compatible, but puts the onus of making sure Felafel can build on the developer. 3 adds more legwork as it would require defining fallbacks for everything, which would be a pain point. A combination of 1 and 2 might be best?

Select: CSS-ize dropdown arrow

The custom element arrow currently uses an external SVG, which is limited in customisability. This should be replaced with a CSS clip-path alternative, such as is used for the Breadcrumbs, Pagination, and Details components.

Refactor to use dynamic imports

Dynamic imports are well supported across modern browsers and can be made asynchronous in order to massively reduce upfront JS download speeds.

Refactor to use CSS logical properties

This is a much more "long term" kinda deal.

Consider updating the current CSS physical properties to use logical properties instead.

Browser support differs for different logical properties, though as of writing all modern browsers support at least some of the logical properties specification.

Although virtually all logical properties can be transpiled to a physical property, there isn't currently a tool that supports doing so for all logical properties. postcss-logical is probably closest, but it has gaps in support and is infrequently updated. Forcing devs to set up a PostCSS build pipeline to make Felafel work also reduces the immediate readiness of the library.

Link hover colour isn't informed by the base link colour

This is fine for the default colour scheme (blue becomes dark blue), however changing the base colour doesn't change the hover from being dark blue. This isn't consistent with how other components with hover/active states work.

Testimonial component: Config settings for rounded corners

For both speech bubble and avatar.

Refactor a11y.focus-ring to use :focus-visible

The :focus-visible pseudo-selector allows the user agent to apply focus styles contextual to the user's behaviour and environment. This usually means that it shows focus styles if the user is navigating via keyboard (or some other non-pointer method) but not if they are using a mouse or touchscreen.

Currently Felafel applies the focus style in all situations. Some implementations of Felafel have taken to hiding the focus style using JavaScript utilities like what-input.

Of the browsers we care about, only Safari does not support :focus-visible, though it appears to be a work in progress. A polyfill made by WICG exists.

Further abstract automatic contrasting colour selection

At the moment each place this is used is manually doing an @if statement checking for existence of a colour value before calling fs-contrasting-color, leading to some repetition of parameters. This could probably be abstracted into its own mixin function.

Make it easier to override colour palette

Easiest way to do this may be to have the (default) built in palette and letting users specify a custom one, and then merging them, rather than directly overriding the default?

Investigate making namespace a variable

Investigate possibility of customising the fs- prefix using a Sass variable, for situations where the association may be undesirable.

Make it easier to override typography size settings

Currently this is very difficult as the default size map is referenced internally a lot. A similar solution to #3 (having a default map and a custom map that are merged together) may be useful?