A lot of styles are being applied without you having to set a class. For example, all tables are styled. This can get in the way really fast if you want to do your own styles for a element.
It's not redundant, an element selector has a different specificity than a class selector. Much easier to maintain when Everything Is A Class (especially when paired with BEM, for very flat selectors). It's the reason Bootstrap stopped doing this.
Who cares if it's redundant? Classes are cheap and repeated strings cost you almost nothing after Gzip.
When you mix element selectors with class, ID, and multi-class (.foo.bar) selectors the specificity of each is different, and overwriting them means writing needlessly complicated selectors that are then in turn harder to maintain.
Bootstrap 4 goes as far as eliminating most sibling/child combinators (>, +, etc) because they add specificity. Anyone that's tried to write custom classes for list elements in Bootstrap 3 (.list-inline>li) has experienced this.
BS has actually has an .h1 class. Eventually a design calls for an <h2> that needs to have the visual appearance of an h1 but for SEO or HTML semantics reasons needs to be an h2.
Maintaining any site of a certain size it spirals into a nightmare quite quickly. Look at how Bootstrap 4 can add a dropdown to a <div> or a <nav>. If your rule was just `nav {}` you wouldn't have that portability, `.dropdown` is clearly superior. On sites of scale modular CSS wins every time.
>It's not Bootstrap. Different paradigm.
Could have fooled me as a lot of the class names and styling are identical. If the m-* and p-* spacing utilities are identical, is it really a different paradigm? BS has (Sass) variables as well.
Should I expect an <a> with `.text-success` to overwrite `.tab-group a`? Or do I need a new class for `.tab-group .text-success`?
Look at how BS4 broke up Navs from being `.navbar > li > a` to being .navbar, .navbar-item and .navbar-link and think about why they did.
In the meantime, a borderless table could be a modifier: table-borderless (i.e. like table-striped or table-bordered).
Just a different approach than what a lot of folks are used to :)
For that reason, I'll generally choose a <table>...</table> with a default style over having to do <table class="shoelaces-table">...</table> every time.
If you really do want to completely override the table style, it looks like it's just a matter of removing the respective line in https://github.com/claviska/shoelace-css/blob/master/dist/sh... and rebuilding.
Also, most modern browsers have a "developer" mode that shows exactly what CSS rules come from where. If the provided style really is getting in the way, it should be (relatively) easy to figure out what specifically is getting in the way (and then addressing it in your own CSS) instead of just blowing away the whole table style and starting from scratch. Looking at https://github.com/claviska/shoelace-css/blob/master/source/..., it doesn't look like it's doing all that much that'd be likely to conflict with anything in a way that would absolutely necessitate starting from scratch.
That's what we used to think when Semantic CSS was the big buzzword, lots of articles from '08-'11 preached it as the gospel. Turns out when a language is based on customizing presentation, presentation is semantic.
> I had a number of locations that I highlighted with a blue background and rounded corners. I called it `location` since it highlighted each of the locations
> When I opened the online store, I had a list of products and wanted to highlight each product using the same design pattern. Problem was, they weren’t locations. They were products. Being the lazy developer I was, though, I just reused the `location` class and applied it to my products. Clearly not ideal (but hey, it worked)!
> The design function was, of course, to highlight something. That was what I should’ve called it!
The new problem, though, is that in this case, if the developer wants to eventually use a different style for locations v. products, he'll now have to do the thing he was trying to avoid in the first place and have to create the new style.
If he stuck to letting HTML describe the content and CSS describe the presentation of that content, then when his tastes inevitably change, he'd just need to change one or the other class' styles in his CSS and call it a day.
This is even more relevant if you're using some kind of CSS preprocessor language (or whatever the term would be) like SASS/SCSS or LESS, since you can define that style as a mixin and apply it to each of the styles for specific content classes as you see fit.
Of course, what he did can still be compatible with HTML being content-declarative if you use a class like "important" or "special" or something; that way, you're still describing what the thing is without polluting HTML with presentation details. You can likely even mix that together ("important product" or "important location"), which would then pave the way for having unimportant products/locations.
> Turns out when a language is based on customizing presentation
Except HTML (especially HTML5) is not based on "customizing presentation". HTML is based on describing documents and the contents thereof. There were a few violations of that principle once upon a time (<b>, <i>, <u>, <blink>, <marquee>, etc.), but these are vestigial at worst (and outright eradicated at best), leaving a language that really is meant to declaratively describe content.
CSS is the language that is based on customizing presentation, and always has been (and hopefully always will be, though I can't wait for the day when CSS becomes Turing-complete).
>Except HTML (especially HTML5) is not based on "customizing presentation"
Right, I meant CSS, and the HTML classes you use to support it. h1.highlight is just as semantic as h1.
>CSS is the language that is based on customizing presentation
Right, so your CSS should be based on class names that point to their design function. Not "what something is".
>the "CSS" class names absolutely should reflect "what something is"
The example and article above goes to show exactly why that's wrong, if their function is design, they should reflect their design function. This is not theoretical, it is based on practice.
Again: you have things backwards. Classes are there to describe what an HTML element is supposed to represent. CSS uses these to decide how that thing is to be displayed. JavaScript uses these to decide how that thing is to behave.
> The example and article above goes to show exactly why that's wrong
Except they don't, as I already explained.
> if their function is design, they should reflect their design function.
Yes, and the design function of an HTML element class is to describe what that element is. The fact that CSS is able to make use of them is a side effect of that.
If you really want to abuse HTML semantics, then go ahead; nobody's stopping you. Just don't pretend that it's the correct approach.
> This is not theoretical, it is based on practice
And the standard practice is a tangled mess of <div class="grid grid-3-7 highlight">. Doesn't mean the standard practice is actually good, or that there's no room for improvement.
I already agreed with you: "they should reflect their design function"
You seem to be conflating semantic classes with presentational ones:
If all your articles have a blue border, maybe it makes sense to have .article have a border property. If your events, articles, and recipes all share the same Card format, it makes better since to keep those styles in .card.
>Except they don't, as I already explained.
You didn't explain; I said just remove the `highlight` class.
>Doesn't mean the standard practice is actually good, or that there's no room for improvement.
Not on its own, but the fact that this arose out of the maintenance nightmare that was "semantic CSS" from 5 years ago explains why it is now a best practice.