shoelace-style/shoelace

A collection of professionally designed, every day UI components built on Web standards. SHOELACE IS BECOMING WEB AWESOME. WE ARE LIVE ON KICKSTARTER! 👇👇👇

Shoelace

A forward-thinking library of web components.

• Works with all frameworks 🧩
• Works with CDNs 🚛
• Fully customizable with CSS 🎨
• Includes an official dark theme 🌛
• Built with accessibility in mind ♿️
• Open source 😸

Designed in New Hampshire by Cory LaViska.

---

Documentation: shoelace.style

Source: github.com/shoelace-style/shoelace

Twitter: @shoelace_style

---

Shoemakers 🥾

Shoemakers, or "Shoelace developers," can use this documentation to learn how to build Shoelace from source. You will need Node >= 14.17 to build and run the project locally.

You don't need to do any of this to use Shoelace! This page is for people who want to contribute to the project, tinker with the source, or create a custom build of Shoelace.

If that's not what you're trying to do, the documentation website is where you want to be.

What are you using to build Shoelace?

Components are built with LitElement, a custom elements base class that provides an intuitive API and reactive data binding. The build is a custom script with bundling powered by esbuild.

Forking the Repo

Start by forking the repo on GitHub, then clone it locally and install dependencies.

git clone https://github.com/YOUR_GITHUB_USERNAME/shoelace
cd shoelace
npm install

Developing

Once you've cloned the repo, run the following command.

npm start

This will spin up the dev server. After the initial build, a browser will open automatically. There is currently no hot module reloading (HMR), as browser's don't provide a way to reregister custom elements, but most changes to the source will reload the browser automatically.

Building

To generate a production build, run the following command.

npm run build

Creating New Components

To scaffold a new component, run the following command, replacing sl-tag-name with the desired tag name.

npm run create sl-tag-name

This will generate a source file, a stylesheet, and a docs page for you. When you start the dev server, you'll find the new component in the "Components" section of the sidebar.

Contributing

Shoelace is an open source project and contributions are encouraged! If you're interesting in contributing, please review the contribution guidelines first.

License

Shoelace was created by Cory LaViska and is available under the terms of the MIT license.

Whether you're building Shoelace or building something with Shoelace — have fun creating! 🥾

shoelace's Issues

Safari type number display issue (and password)

There's a display issue for input type number in Safari (10.1.2 Sierra) where the base of the numbers is masked.

Also, password dots are rather low vertically.

Nice job, I'll try it in my next project.

row- utilities does not have an important tag

Summary

Trying to use row-* utilities (like row-end) does not have any effect if the element where it is applied already has a justify-content property set.
Is this expected?

Steps to Reproduce

.component{
   display: flex;
   justify-content: flex-start
}

<div class="component row-end">
     <div>child</div>
</div>

Additional info

• Shoelace version: 17b1732
• Affected browsers: Chrome 63, but I guess all of them.

Is there a possibility to style switches in "off" position the same as for the "on" positions?

This is regarding the Switches span: https://shoelace.style/docs/switches.html

Is it possible to style a Switch with the same classes but in the OFF position (switch button on the left), in combination with the default behaviour for styling the ON position? By default, switch = off is always grayed out.

I would like to have a switch in different colors, whether it's on the "off" or "on" position – image it to be more like an A/B chooser, instead of an ON/OFF switch.

Thanks for any hints on this,
Oliver

Any plans for cards?

Do you have plans for cards? That the only part I need to use shoelace.

Thanks

Themes & Components

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

Extending shoelace.css components?

Can you provide some guidance on how one goes about extending the components you provide.

For example how do I add a .button-flat?

Do I have to edit buttons.css and add my .button-flat inside button, .button {?

Or can I create a new ,css file and add my button class to that while still having access to your buttons.css.

Of course a separate file is preferred so I don't touch yours and have to update it each time you put out a new release.

I have no experience (yet) with PostCSS and cssnext and need to get some idea of where to begin.

Tabs - programmatic selection

The docs for Tabs indicate their is no API, however I need a way to select a Tab in Javascript.

For now I've done this by sending a click event to the Tab, but I don't much like this approach and would prefer a simple api.

Brunch configuration to compile source CSS

Hey, thanks for Shoelace everybody, appreciate the work!

This isn't really an issue, but it may be something you want to add to the documentation, because integrating Shoelace's source files – rather than just including the compiled css – with Brunch was tricky.

First, @import Shoelace into your own css, rather than including Shoelace with npm.styles. If you include via npm.styles, postcss will render the css variables before the css concatenation, so that you won't have access to any of them. shoelace.css will be @imported here, and that will @import everything else, including variables while they're still variables.

@import url('../node_modules/shoelace-css/source/css/shoelace.css');

/* just an example, all css variables are accessible to you at this point */
:root {
  --body-color: green;
  --body-bg-color: cyan;
  --state-primary: tomato;
}

/* then whatever styles you want to add */

Then, include postcss-cssnext as a postcss processor – that's mentioned as necessary in the docs when you're compiling from source.

postcss: {
    processors: [
        require('postcss-cssnext')
    ]
}

Brunch won't follow @imports in css and will throw errors on build without postcss-import:

postcss: {
    processors: [
        require('postcss-import'),
        require('postcss-cssnext')
    ]
}

After that, you'll need to also include the Shoelace js:

npm: {
    /*
		we do not want this, because we want the post-processing 
		to occur after concatenation, not before
		styles: {
			'shoelace-css': ['source/css/shoelace.css']
		},
	*/
    static: [
        'node_modules/shoelace-css/source/js/dropdowns.js',
        'node_modules/shoelace-css/source/js/tabs.js'
    ]
}

And that'll do it – here's the end brunch-config.js! (Zepto and Shoelace are ending up in vendor.js, not app.js in this particular configuration, and we're also making sure Zepto gets prepended first.)

module.exports = {
	files: {
		javascripts: {
			joinTo: {
				'js/vendor.js': /^(?!app)/, // Files that are not in `app` dir.
				'js/app.js': /^app/
			},
			order: {
				before: [
					'vendor/zepto.min.js'
				]
			}
		},
		stylesheets: {
			joinTo: 'css/app.css'
		}
	},
	plugins: {
		babel: {
			presets: ['latest']
		},
		postcss: {
			processors: [
				require('postcss-import'),
				require('postcss-cssnext')
			]
		}
	},
	npm: {
		static: [
			'node_modules/shoelace-css/source/js/dropdowns.js',
			'node_modules/shoelace-css/source/js/tabs.js'
		]
	}
}

Interest in removing jquery dependency?

This is something that I'm considering tackling but was curious how others felt about eliminating jquery/zepto dependency?

Enable dropdown buttons to work with child elements

I am using the following dropdown markup which only works for a click on the caret vs. click anywhere inside the tag.

<a href="#" class="dropdown-trigger a-user-menu">
  <i class="icon-user"></i>
  <span id="user-name"></span>
</a>

To resolve this I changed:

if($(event.target).is('.dropdown-trigger'))

to:

if($(event.target).closest('.dropdown-trigger'))

in dropdowns.js which works with just an <a></a> etc. and if it has nested elements.

Use plain Javascript instead of jQuery / Zepto

One of the main reasons for using shoelace.css is its small size compared to Bootstrap etc.

That said it would be a big plus to use plain Javascript for Tabs and Dropdowns so the jQuery bloat was removed.

<input type="checkbox" class="switch" ..> issue

The docs for switch show:
<input type="checkbox" class="switch" .. >

From what I can see switches.css does not specify any rules for input.switch only for the .switch > input which means there is no need to specify class="switch" for the <input> element.

I also checked this in the Chrome debugger.

Focus ring hidden in input groups

The focus ring for buttons is cut off by the adjacent control due to its stacking position.

This can probably be resolve by setting position: relative to the input-group container and adding a z-index to the focused control.

Use <progress> for progress components

Leaving this here as a "want to, can't do it yet." Maybe we'll be able to use the <progress> element for progress components one day. Right now, I've run into some issues that degrade the experience compared to the current ones.

• There is no standard for styling the progress bar or the progress bar values. For example:
  • Progress bar container:
    • Chrome/Safari: progress::-webkit-progress-bar
    • Edge/Firefox: progress
  • Progress bar value:
    • Chrome/Safari: progress::-webkit-progress-value
    • Firefox: progress::-moz-progress-bar
    • Edge: progress::-ms-fill
• Can't animate the progress bar value in Firefox. This makes it look really jumpy when advancing the value. Also makes it hard to show a proper indeterminate state.
• Edge has a rendering quirk where 100% still shows some of the container (black edge on the right). This is harder to work around than you'd think since max can vary.
  

Here's a fiddle showing my progress (pun intended) in case anyone wants to experiment with it. It demonstrates styling for Chrome/Safari/Firefox/Edge. It does not currently have an indeterminate state: https://jsfiddle.net/40bLrwhp/5/

---

Notes

I'd like to avoid using fallbacks like this because they're too verbose and harder to update with JavaScript:

<progress value="50" max="100">
  <div class="progress">
    <div class="progress-bar" style="width: 50%;"></div>
  </div>
</progress>

HTTP/2

I have recently been educating myself on HTTP/2, for which I recommend

• https://www.youtube.com/watch?v=r5oT_2ndjms
• https://http2.github.io/faq/
• https://www.youtube.com/watch?v=yURLTwZ3ehk
• https://hpbn.co/http2/

I beg the question: with the rise of HTTP/2, will it still be relevant to concatenate shoelace's CSS into a single file for distribution in a production context? Arguably: no.

In HTTP/1.x we concatenate our assets into fewer (often just one) but bigger assets in order to:

• reduce the number of HTTP requests and thus improve parallelism
• improve compression ratios

However that

• means you're potentially transferring bytes you might not need
• delays processing and executing while waiting for the response
• invalidates cache upon a single byte change, forcing another full transfer

On the other hand, HTTP/2 requests

• reuse the same TCP connection per origin, reducing handshake overhead
• are not limited to 6 TCP connections per origin
• are streamed and multiplexed
• can be prioritized
• can push other resources to the client
• headers are compressed

HTTP/2 requests are therefore much cheaper and take advantage of caching much more efficiently. You have more freedom in the number of requests you make. Asset concatenation is only useful when there are significant wins in compression ratios, which has to be benchmarked in the context of the end-user's project anyway. But this is generally outweighed by cache-ability. And there's tons of other HTTP/2 features that I haven't even touched on (server push, prioritisation, etc)

The ideal solution is to strategically concatenate specific files together and use them on specific pages. But this is not something shoelace can do or is responsible for, that should be part of the end-project's build process which we obviously do not control.

To get to the point, I think shoelace should not build and distribute the concatenated version. The CDN distribution is rendered pointless here. Thus there's no need for the shoelace.css file that imports the rest. You just distribute individual files (that may still go through some build process). A potential end-user would then npm install shoelace, import the parts that are relevant to his project and introduce them in their own build process, which ideally would output multiple bundles of files that balance cache-ability and compress-ability. This is how you can achieve maximum performance.

That's how I envision it. Perhaps this is coming off as a bit radical, but the performance paradigm in HTTP/2 is entirely different. I don't claim to be an expert on HTTP/2, but everything we know about performance is not necessarily true anymore, that I can promise you. The rules of the game have changed. If shoelace wants to be a future-proof, bleeding-edge (I've been using these words a lot) framework, it should bring HTTP into the equation as well.

!important Tags

I've just downloaded to give this a test, and the first thing I saw is !important tags everywhere, this actually makes it harder to do anything as if you want to overwrite a style you're going to have to use another !important tag to do so, and same with doing any responsive media queries.

There is just no need for all the !important tags on everything, plus is bad practice and coding standards.

CSS variables are not being used

Summary

Go to https://cdn.shoelace.style/1.0.0-beta22/shoelace.css. All of the variables are hardcoded. In the repo inside my node_modules as well, I see the variables are in the source css, but must be being replaced with their values in the build process.

Additional info

• Shoelace version: 1.0.0-beta22, 1.0.0-beta23

Any plans for nav bars?

I'm very much still learning cutting edge CSS like variables and grid so I was wondering if you have any plans on incorporating some nav bar examples, much like Bootstrap's, of course. Thanks for sharing this project and keep up the great work!

Link styled as button

I see that a button can be styled as a link. Is it possible to style a link as a button too?

Variables don't seem to work any more

Summary

I upgraded from version beta17 to beta19 today, all my color settings are being ignored. Looking at dist/shoelace.css I don't see any var() statements.

After checking beta18 I see the issue was already present there.

Additional info

• Shoelace version: beta17 => beta18/19

---

Note: This issue tracker is ONLY for bug reports and feature requests. If this is a personal support issue, please ask on Stack Overflow.

Issue with React JSX and switches

When using the library with react, the switches don't seem to work when you click them.

Interestingly enough they get rendered as

<input type="checkbox" id="switch-2" value="on">

after react does it "magick"

and not as

<input type="checkbox" class="switch" id="switch-2" checked>

Would assume this causes them to not work when you click them.

Suggestion: add dropdown activation steps to documentation

For example, for the dropdown menus just need the "active" class added to the parent dropdown container to display the menu. Adding this to the documentation would be nice since I had to dig into the javascript source to figure this out.

For those of us who don't want to use the provided javascript for various reasons, it would be useful to provide documentation as to what CSS classes to use to get the interactive behavior. I'm using shoelace right now in a React based project that doesn't include jQuery and I'm trying to keep all UI behavior in the React codebase.

This might be relevant for other areas where javascript is used, too, I just haven't used anything that needs it besides the dropdowns so far.

Great work on the framework. I needed something simple and lightweight but still took care of all the base element styling without me needing to think about it much and shoelace has fit the bill nicely.

Thoughts on Autoprefixer

Now that we switched to PostCSS for minification, it may be time to consider using Autoprefixer too. I don't think there's anything that's unsupported in target browsers at the moment, but for future use it's probably a good idea.

Not sure how much weight this will add to the lib — probably not too much.

I think the target should be last two browser versions. Any other options I should consider?

Thoughts?

CSS-only Tabs

Why not implement css-only tabs instead of including a small js snippet?

.button-link and :active css question

buttons.css has

  &:active:not(:disabled, .disabled),
  &.active:not(:disabled, .disabled) {
    background-color: color(var(--button-bg-color) shade(10%));
    border-color: color(var(--button-bg-color) shade(10%));
    border-top-color: color(var(--button-bg-color) shade(20%));
    border-bottom-color: color(var(--button-bg-color) shade(10%));
  }

However when I click on a .button-link element such as on https://shoelace.style/docs/buttons.html# the :active styling isn't applied. If I apply :active using Chrome Dev Tools it is applied.

IMO for .button-link elements you don't want the :active styling applied, which it isn't.

However I'm curious why it isn't being applied and wonder if this is a bug of some sort or simply my lack of CSS knowledge.

Consistent naming for font-size?

https://github.com/claviska/shoelace-css/blob/master/source/css/variables.css#L208

Currently we have font-size and font-size-small, do you think it makes sense to change them to:
font-size-sm, font-size-md, font-size-lg, etc. like you do for input (https://github.com/claviska/shoelace-css/blob/master/source/css/variables.css#L310)?

Remove jQuery dependency from tabs.js and dropdowns.js

I whipped up a minimal script for tabs and for dropdowns, both on top of jQuery. I'd like to remove this dependency, however, as it can add a lot of weight to projects that aren't using jQuery.

In previous versions of Shoelace, the docs stated:

Tabs are not interactive by default! Shoelace is a CSS starter kit, not a framework. For convenience, a lightweight sample script is provided to demonstrate how to make tabs interactive.

However, it's apparent that pretty much everyone will just copy and paste the sample script and use it. If that's the case, we might as well provide an official version of tabs/dropdowns in the dist so users can load it via CDN.

Objective

My goal for shoelace.js is to provide vanilla JS scripts for tabs and dropdowns that just work, much like the current jQuery-based versions. These should be simple scripts that don't require initialization and don't have any API. Also like the current versions, they need to use event bubbling to ensure dynamically created tabs/dropdowns also work.

Now, before people lose their minds about not having an API and not requiring initialization, I feel this is important to say:

Shoelace components should act like native components as much as possible. This is part of Shoelace's core philosophy.

In the same way you expect a <select> control to open without JavaScript, tabs and dropdowns should activate "without JavaScript."

In the same way you can disable an <input> by adding the disabled property, you can disable tabs and dropdowns by adding the disabled property.

In other words, we're using JavaScript as a shim to make these controls work, not as an extensive plugin that packs in a million features.

Of course, shoelace.js will be completely optional. Users who want a more robust solution are welcome to adopt alternatives such as Tabby.

So that's where I'm trying to go with things. We're basically cloning tabs.js and dropdowns.js in a non-jQuery way. Browser support should include IE11 even though it doesn't support CSS vars, as many users use Shoelace + a polyfill for older browsers.

If you're interested in taking a stab at it, comment here and let me know.

---

Additional planning:

• show and hide events for tabs
  • Should fire on the tabs container
  • Affected tab pane will be passed as second argument
• show and hide events for dropdowns
  • Should fire on the dropdown container
• select event for dropdowns
  • Affected menu item will be passed as second argument

Stacking switches vertically

In https://shoelace.style/docs/switches.html the Variations example you stack switches vertically by wrapping them in a <p> which I assume was for convenience.

If I change to use <div class="switch">...</div> they stack vertically however the css rule:

.switch+.switch {
    margin-left: 1rem;
}

leaves the switches after the first one indented, which isn't appropriate in this scenario. Changing the css to span.switch+span.switch { resolves this.

That said is there a recommended way to stack them vertically that I am not aware of.

The other issue with using a <div> is there is insufficient vertical gap between them.

Adding:

div.switch+div.switch {
    margin-top: 0.75rem;
}

resolves this.

Thoughts?

Shoelace homepage has red background in Edge

https://shoelace.style/
Haven't looked into the cause but the site looks different in Edge compared to (Safari/Chrome/Firefox)
It has a red background, making it hard to read the logo, compared to the correct white background.

Tabs - Color Variations request

Tabs don't currently have Color Variations like buttons, badges etc. It would be good to see these added as the default is quite intense.

FYI I have just started using Shoelace in the last few days and am migrating a complex Bootstrap app over to it. So far I really like what you've done - congrats.

Can you add the possibility for regular links on tabs-nav?

Hi there,
I (mis-)use a tabs-nav on my site as a horizontal navigation - because it suits this case quite well :)

However, it by default prevents opening a new page on click on a tab element. Would it be possible to add such functionality oob as compared to the current behaviour, where it is designed to only show/hide certain tab content containers?

Thanks,
Oliver

CSS combing

Hi,

First sorry for my bad english :)

I really love your project but I notices something that bothers me a bit: the CSS properties order is sometimes strange and could be fixed with a tool like CSScomb

For example : here you could reorder this :

pre {
  max-height: var(--pre-max-height);
  overflow-y: auto;
  font-family: var(--font-family-monospace);
  color: var(--pre-color);
  background-color: var(--pre-bg-color);
  border-radius: var(--pre-border-radius);
  padding: 1rem;
  margin-top: 0;
  margin-bottom: 1rem;
}

into this :

pre {
  overflow-y: auto;
  max-height: var(--pre-max-height);
  margin-top: 0;
  margin-bottom: 1rem;
  padding: 1rem;
  color: var(--pre-color);
  border-radius: var(--pre-border-radius);
  background-color: var(--pre-bg-color);
  font-family: var(--font-family-monospace);
}

And that would be even geater :)

[Suggestion] Consider to remove `height` in `button`

https://github.com/claviska/shoelace-css/blob/master/source/css/buttons.css#L14

So it plays well with other properties like font-size or padding?

CSS variables in media queries

Summary

Doesn't look like CSS variables can be used as media query selectors. They're touted as such in the documentation, but it doesn't work for me.

Steps to Reproduce

1. Use the following in a stylesheet: @media (--breakpoint-lg-down) { ... }
2. View your page under the particular media query constraints
3. Styles are not applied

Additional info

• Shoelace version: 1.0.0-beta22
• Affected browsers: Firefox 57

Moving Forward

This is something I've been thinking about and I'd like to throw it out there to gather feedback.

Shoelace is getting a lot of attention because it champions the use of CSS variables. However, in the real world most people still need to post-process the library with Myth or cssnext because they need support for IE11 (non-existent) and Edge (has a few nasty bugs that make CSS vars really hard to work with).

Furthermore, I feel like the project is stuck between "the future of CSS" and the "now of CSS," and it feels quite debilitating. For example, I'm using an inset box-shadow trick to create hover states for buttons, but I'd really like to use the color function to generate a darker bg color properly. This isn't the only example that bugs me, but you get the idea.

There are other upcoming CSS features that would be really useful, too. @apply can save us a lot of code. Custom media queries can make styling responsive sites much easier. Nesting will make the code less verbose and more readable.

Of course, using any of these features requires post-processing with cssnext, which I'm personally OK with. However, this would renders the CDN version useless, since most of those features don't work in browsers today.

I still want Shoelace to remain "pure CSS," and one day we'll be able to use it 100% without a post processor, but even if CSS variables were 100% across the board a lot of the other features that we could be benefiting from just aren't there yet. 😢

What I'm proposing is changing the primary color to something more generic (tomato ==> --color-blue) and generating a static dist (e.g. no CSS vars). This would mean the dist version is supported in pretty much every browser, but at the expense of losing customization. This kinda sucks, but it will still be super useful for prototyping and it's still much smaller than a lot of the alternatives.

Of course, the docs will be updated to strongly encourage users to post-process the source using cssnext, especially in production.

This is the only way to take advantage of variables and other upcoming CSS features today. And using cutting-edge CSS features via cssnext will raise awareness and get people interested in raw CSS again — even if it does require post processing today.

Anyways, those are my thoughts. Fire away.

The p- prefix for padding clashes with microformats properties

Could you use pad- instead? It's almost as short, and clearer.

.button-block+.button-block inside .input-group margin issue

This is what I get when I place two block-style buttons inside an input group:

I'm trying to understand the need for that rule. Maybe it's a bug?

BTW, I'm using 1.0.0-beta8.

input-sm font size

For <input type="text" class="input-sm" ..> would you consider changing its font-size: .8rem; to font-size: .875rem;. This changes it from 12.8px (which is an odd size) to 14px which is commonly used.

This also matches the font-size you use for <small> and matches Bootstrap form-control-sm.

Customizing

If you’re using the source version of Shoelace (i.e. not the CDN or /dist version)

As a suggestion I would point people to import /source/css/shoelace.css

I dug through the code to get it, but it would save time.

Thanks for a nice library.

input-group: auto instead of 100%

Is there a reason the input-group width is currently set to 100%?
I changed it to "width: auto" on my end.
That way it's better to align groups of buttons with other elements.

My use case is an alert box that contains a single button and a group of buttons, the single button is aligned to the left, the group is aligned to the right.

2.0: Back to the basics (again)

TL;DR – now that browser support has improved for custom props and CSS grid, Shoelace 2.0 will go back to its roots and once again be highly customizable without the need for any sort of build process.

---

As Shoelace evolved, it became clear that we weren't quite ready for certain CSS features in production. I feel I was a bit too premature with pushing Custom Properties and CSS Grid Layout when Shoelace was released back in July, but I think we're ready to move these features to the mainstream.

Edge 16 was released on October 16, and with it brings full support for Custom Properties and CSS Grid Layout. This doesn't include IE11, but I'm OK with that at this point.

Here's what I'd like to do moving forward:

• Remove all cssnext-specific features so you don't have to build Shoelace to use it.
• Rework the build process so the dist contains custom properties. This will make Shoelace easier to use and, once again, customizable via CDN.
• Split variables into their own component files again, making Shoelace much more modular and extensible. For example, you'll be able to include a single third party .css file that inherits your theme/component styles automatically, even from a CDN!
• Address #12 by requiring component classes (e.g. <button class="btn">) for default components. My updated thoughts on this: styling is easier, implementing is easier, and the "namespace" has some benefits.

This is a bit of a backpedal, but I think it's finally time. Of course, this will introduce a breaking change in terms of browser support, so the new version will be 2.0.

Thoughts?

Double font-weight on body ?

Hello,

Is there any reason to apply font-weight twice on body ?

body {
  background: var(--body-bg-color);
  font-family: var(--font-family);
  **font-weight: var(--font-weight);**
  font-size: var(--font-size);
  **font-weight: var(--font-weight-normal);**
  color: var(--body-color);
  line-height: var(--line-height);
}

Support input icons in input groups

Input icons don't currently work in input groups, but they should.

<big> element

In HTML5 <small> is used to represent side comments and small print, thus it is appropriate to style it with a small font size. However <big> conveys no semantic information (you're probably looking for <strong> or <em>) and is obsolete in HTML5.

You should remove it from https://github.com/claviska/shoelace-css/blob/c518eb28e161509e2ae5264dc7a164d804ea1194/source/css/content.css#L44-L46

Many elements are styled directly rather than through a class

Why are many elements styled directly rather than through a class? e.g. tables

What is the reasoning behind it? Bootstrap, for example, doesn't seem to do this.

CSS buttons specificity

Summary

• Noticed with the buttons that they're not easily customised because they have a higher specificity due to this selector :not(:disabled, .disabled). Would it be reasonable to not use this selector and just reset the props in the .disabled, :disabled declaration?

It might even make it easier without all those :not(:disabled, .disabled) selectors and just later on override what is not needed for the disabled state.

Additional info

• Shoelace version: 22
• Affected browsers: Chrome

---

Note: This issue tracker is ONLY for bug reports and feature requests. If this is a personal support issue, please ask on Stack Overflow.

tabs-pane is hidden for disabled tab

If I add the disabled class to a <nav class="tabs-nav"> -> <a href="#tab-1" class="active">Tab 1</a> element the active class is removed which causes the tabs associated <div class="tabs-pane active" id="tab-1"> to also lose it's active class and therefore is hidden.

IMO I should be able to disable tabs to prevent user selection, while still keeping their tabs-pane content visible.

Placeholders not centered vertically in iOS

I don't have time to tackle this over the weekend. This probably isn't a difficult one in case somebody wants to handle it.

Only affects placeholder text on inputs on iOS. You can see an example on shoelace.style.

Validation for textarea

Summary

Thanks for this great minimal CSS lib, love it!
Not sure if it's intended or not. There is no validation modifier for textarea I think.

Steps to Reproduce

1. Add input-invalid to the parent div.input-field of textarea.

Additional info

• Shoelace version: 22
• Affected browsers: Chrome

---

Note: This issue tracker is ONLY for bug reports and feature requests. If this is a personal support issue, please ask on Stack Overflow.

Address accessibility gaps in Shoelace

Let me start off by saying I really like the streamlined approach you've taken with this project. It's nice to see a library like this, using modern CSS. However in looking through the source code, and doing some basic keyboard and screen reader accessibility testing, there are quite a few gaps in coverage that really should be closed to ensure this framework doesn't perpetuate inaccessible user experiences.

I have submitted a pull request to address the following two issues:

• Set focus states for <a> and <button> elements to provide parity for mouse and keyboard interactions.
• An update to the Switch component, as it previously was completely inaccessible to keyboard and assistive technology users.

There are additional accessibility issues that I'd be happy to discuss with you if you are interested in moving forward with these sorts of changes.

Thanks!