Shoelace: Many elements are styled directly rather than through a class

[fabiomaia]

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.

[claviska]

I've been a Bootstrap user for years. I still use it in some projects. In my experience, I've never used a <table> without <table class="table">. It's redundant. They're not custom components, they're just elements such as headings, links, etc. The latter are styled by default (in Bootstrap too), so why not other elements?

I've also never used an input in Bootstrap without <input class="form-control">. Why would one want styled inputs on one part of the page and unstyled inputs elsewhere?

If the answer is "because it makes it easier to style myself" then I could argue that it actually makes it _harder_. Shoelace provides a minimal reset that makes it much easier to override its default styles than starting entirely from scratch.

All in all, Shoelace !== Bootstrap. It's a forward thinking experiment that may break paradigms here and there :)

[fabiomaia]

In my experience, I've never used a <table>, for example, without <table class="table">. It's redundant. They're not custom components, they're just elements such as headings, links, etc. The latter are styled by default (in Bootstrap too), so why not other elements?

I actually quite like this argument. Never thought about it that way, but it makes a lot of sense, especially considering Shoelace's general philosophy.

[fabiomaia]

Note that Bootstrap v1 automatically styled tables as well.

http://bootstrapdocs.com/v1.4.0/docs/#tables

Might be interesting to understand why they changed that.

[claviska]

I'd be interested to know that to. I assume it was to please people who used tables for non-table purposes (which is IMO not a good reason).

[evansd]

Bootstrap made this change so that you could use external JavaScript widgets on the page without the default styles trashing their layout. In particular the default table classes caused problems with the jQuery UI DatePicker widget, and apparently the default form styles were also problematic.

[claviska]

Thanks for the links. I think that made sense five years ago, but it's less relevant these days. 😄

I know some people will disagree with my decision, and I realize some third-party controls may still utilize tables [incorrectly] as layout devices. I'm OK with a style collision here and there (although I haven't run into any yet). Until we have custom elements to provide better namespacing, these things will continue to happen no matter how hard to try to avoid it.

I prefer convenience over redundancy.

Most projects these days are aware that they need to provide a certain level of specificity and "resets" of their own to ensure a consistent appearance. Worst case, the developer can choose to patch any display issues they run into themselves. (I suspect there won't be many with modern controls.)

At the end of the day, my argument for styling <table> without a class is the same for styling <a> or <h1> or even <strong> — it's an element, not a component, and Shoelace treats it as such.

[evansd]

@claviska Yeah, I think you've probably made the right decision. I just saw that someone asked about the reasoning behind Bootstrap's decision and I remembered those issues.

[claviska]

No worries. And I wasn't trying to target you specifically. Lots of eyes on this project today and people have certain expectations ("why isn't this like Bootstrap?") so I wanted to write down my thoughts.

I try to keep an open mind, so if there are other valid arguments I'm happy to listen.

[bpicolo]

@claviska for what it's worth, I'm wondering if the logic behind it isn't that, when you want a differently styled variant, in the bootstrap model you just have to remove a class. In this case you'd need to explicitly unstyle all of the defaults.

Not to say shoelace's strategy is bad, it's just a con in the current model, though other models have cons too :)

[claviska]

In this case you'd need to explicitly unstyle all of the defaults.

Well, it's either:

1. Set defaults and require users to override a handful of properties _if and only if_ they want to create a special variation

OR

1. Don't set defaults and make users add redundant classes every time they want a table to look like a table

If you think about it, # 1 actually makes a lot of sense because the default styles are minimal and any variations a user wants to make will have a starting point that, aesthetically, is consistent with the rest of the library.

At least that's my thinking. 🤷‍♂️

[bpicolo]

@claviska it's reasonable thinking, and great job with the cool project :)