Using CSS framework with semantic markup

I am hoping that there is some kind of CSS/styling framework that works with strictly semantic markup and leads to relatively small files. The way I see things now, this is another example of the "three options, pick two" iron triangle.

Here's what I mean. I'm looking for:

Some sort of visual styling framework (so I don't have to write everything by hand)
...that works with simple, semantic HTML without any class name pollution just for the sake of visual styling. This is my dumb, stubborn opinion, but I feel markup should always be sparse, simple and semantic. Stuff like this:
```
<div class="widget">
```
...and not this:
```
<div class="widget d-flex p-2 bd-highlight">
```
...which leads to relatively small file size(s). On their own, frameworks are actually pretty lean. But to stay light-weight, they require declarative markup. Pre-processors, like Sass, allow you to inherit rulesets directly from frameworks really, really easily. So you can do this:
```
.widget {
    @extend .d-flex;
    @extend .p-2;
    @extend .bd-highlight;
}
```
But it leads really quickly to absolutely colossal file sizes. The rulesets remain tiny, but the selector lists explodes. I would categorically reject this solution just because of this file-size issue.

My gut tells me my options are either to continue writing CSS by hand (dropping #1) or to start declaring styles in my html (dropping #2).

Does anyone know a way out of this? Am I misusing Sass? Is there another type of framework I don't know about? I'm working with Sass and React, but I'm willing to learn from anything out there.

Solution

After digging around quite a bit on this issue, I think that currently there is no sensible way to use a CSS framework with semantic markup without incurring major penalties. I've opted to go with custom CSS for the final build. Some general notes:

Certain frameworks (notably Bootstrap) expose some styling via mixins (@include framework-mixin()). This leads to duplication of rulesets (and thus some bloat), but it is much lighter than what happens when you use @extend for inheritance. However, many core classes are just exposed as regular classes. This means you still face a question of semantic markup or massive file bloat.

It seems most modern frameworks organize their codebase into inheritable chunks. If you are extremely careful to @extend only the exact classes you need, you can end up with (arguably) acceptable file sizes for the final HTML. Rather than including an entire framework css file, consider including only the component files you need. I still found that even these files could grow too huge very easily, but if you are careful, it may work.