[meta] Svelte app themability

chrisfromredfin → credited andy-blum → .

chrisfromredfin → credited lauriii → .

chrisfromredfin → credited mherchel → .

At a discussion at DrupalCon NA 2023 in Pittsburgh, the follow people met to discuss themability and the approaches proposed by Ben Mullins in this issue:

• Lauri Eskola
• Tim Plunkett
• Andy Blum
• Mike Herchel
• Chris Wells
• Ben Mullins

While there, the approaches were discussed, and the following decisions made:

1. First, refactor many of our values into CSS custom properties. This will allow easy overrides for other themes.
2. Second, remove the hashed classnames introduced by the Svelte build, so that markup looks more Drupal-y. Using BEM syntax where possible, this aligns better with Drupal markup today. We may need to refactor some of our existing CSS to this end.
3. Third, allow for the insertion of markup (using Drupal.theme, for example) into component prefixes and suffixes where there's a good opportunity (e.g. the card component).
4. Fourth, and only if there is great clamoring for it, allow users to override individual Svelte files (or pieces of them), though this introduces a build step. Note: a really motivated person could already today fork and rebuild the front-end to their heart's content.

+1 on @chrisfromredfin's comment in #19. I also want to state that there was consensus at the table that "perfect is the enemy of good" and if the insertion of markup into a component prefix/suffix is too time consuming, it should not block beta or stability.

Adding stable-blocking here, but noting from Mike's comment that we will split prefix & suffix out to a non-blocker if it proves too time-consuming.

Is this issue still relevant after 📌 Move styles out of svelte bundle to traditional Drupal library Fixed

Yes, still relevant. Though moving it out, and that does enhance themability, we still want to convert values to custom properties, do BEM syntax, and ideally #3 if possible, allow prefix/suffix inserting with Drupal.theme().

we still want to convert values to custom properties

Is this necessary since the classes aren't obfuscated, the styles are BEMified, and everything is brought in via the Library API? I think once the plan outlined in #3394904 is done and the styles in PB are reduced to just basic layout styles (similar to the views module when viewed in Stark), admin themes will be responsible for theming the PB UI.

allow prefix/suffix inserting with Drupal.theme()

This probably needs someone investigating if this can be done safely. I imagine Drupal.theme() will break a lot of the svelte event bindings.