I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
The dream of the semantic web is over, isn't it?
By which I mean, this is a mix of style and content which means that if you want to re-theme your website you'll have to change all the HTML :(
That's true. They also offer something in regards to themes, but i haven't tried it: w3schools.com/w3css/w3css_color_th.... I think it all depends on the purpose of the development and what kind of pages you are creating. This is a quick win in many situations.
Class attributes aren't semantic content, so nothing wrong with this approach really. The problem with inline styles is that they're too limited: you can't constrain by media queries or other pseudo elements or pseudo classes. Atomic CSS can handle that, and it does so in a way that's much easier to use than fiddling with CSS manually. I recommend checking out the tachyons CSS toolkit.
And I don't even mean generated static sites. I literally mean sites that don't need an API/DB/CMS because they are pure content and easy to manage in HTML?
Oh, say, for instance most sites hosted on GitHub Pages.
Resume sites. Portfolio sites. Restaurant sites. I can go on and on.
You don't need to over-engineer a 6 page restaurant site that hosts directions, menu, and simple things like that.
Don't overlook those pages -- they're still important and a big chunk of what the web is made of.
I find that unsustainable even for tiny restaurant sites.
For example, you likely have your contact info in the contact page and the footer of every page.
Assuming you at least keep your footers separate, that's still two places to change your phone number, working hours, etc.
And this isn't a root comment, this is a response to the person woeing over having to redo their markup for a restyle.
Well, guess what? CSS Garden doesn't work on real-life markup, only on intentionally superfluous one.
I've found it works quite well - those one-off things can keep their one-off utlities, but as you find common/re-used blocks and components you can style them as one thing.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
Same here. I also can use Yogurt CSS to expose it's utility modules into a custom class for those who dislike to inline the styles in their HTML. And also, it is an easy and quick way to refactoring or migrating their existing stylesheet to Yogurt CSS.
Indeed. I understand why some people choose this approach, but it defeats the purpose of classes. I want to define a class of objects which share attributes because those objects represent the same thing on the page (e.g., headings). Using, e.g., "w3-teal" on those headings is essentially just moving my CSS into my HTML, and making it more cumbersome to change that one color in the future. I'd rather just define my "heading" class with whatever shade of teal I want, then change that one color in one place in the future.
Again, I get why some people use libraries like this, but I've noticed a move toward this approach even when it creates more problems than it solves (it doesn't make sense for most enterprise web apps). And the unfortunate reality is that some developers just don't want to spend time understanding CSS to the degree that they do JavaScript.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The dream of the semantic web is over, isn't it?
By which I mean, this is a mix of style and content which means that if you want to re-theme your website you'll have to change all the HTML :(
That's true. They also offer something in regards to themes, but i haven't tried it: w3schools.com/w3css/w3css_color_th.... I think it all depends on the purpose of the development and what kind of pages you are creating. This is a quick win in many situations.
Class attributes aren't semantic content, so nothing wrong with this approach really. The problem with inline styles is that they're too limited: you can't constrain by media queries or other pseudo elements or pseudo classes. Atomic CSS can handle that, and it does so in a way that's much easier to use than fiddling with CSS manually. I recommend checking out the tachyons CSS toolkit.
Why would your content be in your markup files? :O
It should be in the API/DB/CMS.
You know there are static websites, right?
And I don't even mean generated static sites. I literally mean sites that don't need an API/DB/CMS because they are pure content and easy to manage in HTML?
Oh, say, for instance most sites hosted on GitHub Pages.
Resume sites. Portfolio sites. Restaurant sites. I can go on and on.
You don't need to over-engineer a 6 page restaurant site that hosts directions, menu, and simple things like that.
Don't overlook those pages -- they're still important and a big chunk of what the web is made of.
I find that unsustainable even for tiny restaurant sites.
For example, you likely have your contact info in the contact page and the footer of every page.
Assuming you at least keep your footers separate, that's still two places to change your phone number, working hours, etc.
And this isn't a root comment, this is a response to the person woeing over having to redo their markup for a restyle.
Well, guess what? CSS Garden doesn't work on real-life markup, only on intentionally superfluous one.
I think tailwindcss is a nice middle-ground - you can use the pure 'utility' approach like :
But you can also 'compose' classes out of the utilities in your css/sass by doing :
I've found it works quite well - those one-off things can keep their one-off utlities, but as you find common/re-used blocks and components you can style them as one thing.
That makes more sense to me because it's still keeping the presentation stuff in the presentation box.
Same here. I also can use Yogurt CSS to expose it's utility modules into a custom class for those who dislike to inline the styles in their HTML. And also, it is an easy and quick way to refactoring or migrating their existing stylesheet to Yogurt CSS.
Indeed. I understand why some people choose this approach, but it defeats the purpose of classes. I want to define a class of objects which share attributes because those objects represent the same thing on the page (e.g., headings). Using, e.g., "w3-teal" on those headings is essentially just moving my CSS into my HTML, and making it more cumbersome to change that one color in the future. I'd rather just define my "heading" class with whatever shade of teal I want, then change that one color in one place in the future.
Again, I get why some people use libraries like this, but I've noticed a move toward this approach even when it creates more problems than it solves (it doesn't make sense for most enterprise web apps). And the unfortunate reality is that some developers just don't want to spend time understanding CSS to the degree that they do JavaScript.