Themes & Components

[claviska]

I want to keep the core lightweight, but at the same time I'd hate for lots of people to adopt Shoelace and then run into Bootstrap Syndrome (every website looks the same).

We can prevent this by encouraging third-party themes and linking to them from the website.

These can be simple copy/paste snippets to start:

/* Shoelace.css dark theme */
:root {
  --body-color: white;
  --body-bg-color: black;
  ...
}

We could do something similar with third-party components, too. I'm posting this here as a TODO and to gather thoughts and ideas.

Ideas

• Cards

[ryerh]

@claviska Any plans for modal dialogs and overlay popovers?

[claviska]

Personally, I hate modals. The panel concept is much less obtrusive IMO. The less things websites throw at my face, the better 😝

That said, if someone writes a proper Shoelace extension to add modal dialogs, I'll be happy to help polish it off and list it as a third-party extension on the website. But I'm not going to be building it out myself any time soon.

[ghost]

Here is a theme loosely based on Solarized Dark..

:root {
  --body-color: #839496;
  --body-bg-color: #073642;
  --color-black: #000;
  --color-primary: #3d9970;
  --color-blue: #0074b9;
  --color-smooth-blue: #275662;
  --color-stripe-blue: #174652;
  --color-deep-blue: #073642;
  --color-orange: #cf751b;
  --color-sunset: #cb4b16;
  --color-red: #cf3136;
  --color-camel: #eee8d5;
  --color-yellow: #ff0;
  --color-sand: #b58900;

  --input-bg-color: var(--body-bg-color);
  --button-bg-color-primary: var(--body-color);
  --badge-bg-color-primary: var(--body-color);
  --alert-bg-color-primary: var(--body-color);
  --state-success: var(--color-primary);
  --state-info: var(--color-blue);
  --pre-bg-color: var(--color-camel);
  --code-bg-color: var(--color-camel);
  --link-color: var(--color-sand);
  --link-color-hover: var(--color-sunset);
  --input-readonly-bg-color: var(--color-smooth-blue);
  --mark-color: var(--color-black);
  --mark-bg-color: var(--color-yellow);
  --switch-bg-color: var(--link-color-hover);
  --table-stripe-bg-color: var(--color-stripe-blue);
  --component-border-color: var(--color-smooth-blue);
  --switch-bg-color: var(--color-sunset);
}
.input-addon { background-color: var(--color-deep-blue); }

[claviska]

Good stuff, @AZcodes. I created a pen to demonstrate this:

https://codepen.io/claviska/pen/preOdK?editors=1100

I need to split the website up into sections and add a place for things like this to show other users what you can do with Shoelace.css!

[claviska]

Heads up! New website and the docs are better organized. https://shoelace.style/

[pkill37]

It's really cool being able to theme shoelace with native, cascading, spec-compliant variables. But it kinda bothers me that I have to transfer 9KB of variables and overwrite them (i.e. transfer more bytes) with my own preferences.

Do you see the problem here? If you want to theme and customise shoelace, you will always transfer redundant bytes (variables that you will overwrite). In a worst-case scenario, if I overwrite all the variables, I would actually force the end-user to transfer 9 useless KB (eventually less than that with compression).

Perhaps variables.css shouldn't be distributed, and instead be expected to be defined by the project. In this scenario the variables are defined only once and there won't be any redundancy. Something to think about.

[claviska]

But it kinda bothers me that I have to transfer 9KB of variables and overwrite them (i.e. transfer more bytes) with my own preferences.

You don't have to. If you're working from the source, you can include your own or even overwrite the existing one — your call.

Perhaps variables.css shouldn't be distributed, and instead be expected to be defined by the project.

Then it would be impossible to serve the project over CDN, which despite a few extra KB, is incredibly useful.

Don't look at the overall size though. Look at the convenience factor for millions of potential users. You can include the entire library from a CDN or locally with a single <link>, then customize only what you need. The absence of a default variables.css would make that impossible. And as new core components are added, their implementations quickly break.

What I see with other frameworks such as Bootstrap, where a preprocessor is required to take full advantage of it, is people including the entire compiled stylesheet (e.g. bootstrap.min.css) and then overriding tons and tons of selectors to "customize it." They do this because it's impossible to load and customize Bootstrap via CDN without loading the compiled version. Shoelace finally makes this possible.

So, comparatively, we're way ahead of the game. And if a few extra bytes are required to keep things convenient, there's nothing wrong with that.

[claviska]

After looking at the discussion in #33, I think the variables problem will go away. Unless you're using the shortcut loader, you'll only be loading core variables plus whatever components you explicitly include. 🤔

[Gonzih]

This demo https://codepen.io/claviska/pen/preOdK?editors=1100 does not work with beta18 version. What changed? I also recently tried to upgrade beta5 -> beta18 and had some issues with customization. It looks like some components get hardcoded color values because of cssnext.

[claviska]

See the release notes for beta17: https://github.com/claviska/shoelace-css/releases/tag/1.0.0-beta17

[Gonzih]

That complicates stuff a bit now. So no live theme switching then anymore?

[claviska]

You can build from source to get all the customizations (and other future CSS features). This way it works with all browsers today. If you want custom properties (i.e. variables) in your own dist, you can use cssnext.io to build it. Just disable it like this:

  cssnext({
    features: {
      customProperties: false
    }
  })

[claviska]

Closing since extending the lib has been documented now.