My main issue isn’t even that CSS exists, or its current functionalities. It’s the expectation that, if you’re creating a web page, you must use CSS extensively, and ditch every single “pure” HTML feature that might solve your problem.
On a practical level, what’s intrinsically wrong with the center tag? Or tables for alignment? Those might be bad in some situations, but they’re rather succinct and simple ways to get what you want.
“But what if in the future…” - address future problems in the future. As soon as they appear - not before or after that.
Have you even made a production grade front end project?
You can’t use “pure” HTML solutions because every browser can display these differently. You have to use CSS to make a website look and behave modern. “Pure” center tag is clunky and doesn’t work everywhere and that’s “by design” (That behavior is defined in specification, and we can’t change specification to meet today’s standards because that would make it non backwards compatible). Additionaly you need to make your website scale to wide range of devices. And sometimes you need to even add JS to fix some of the issues if you don’t want the developer to implement a non-maintainable solution taking him 5 hours, if he could do that in JS in 5 minutes.
Look CSS is not perfect. It’s hacky solution to a problem, but news flash: most software engineering is. And it’s proved to be working.
“But what if in the future…” - address future problems in the future. As soon as they appear - not before or after that.
That’s the stupidest thing I’ve read today. I hope you’re not any kind of engineer. There are some situations where it might not be worth it to future-proof something, but if you apply that to everything you end up needing a full rewrite instead of just adding a feature.
Tables are for displaying data, not styling. They worked in the past because there was no alternative but they are the wrong tool for the job; like cutting a board with a hammer.
Any tool or resource is for whatever usage people make out of it.
The distinction between data and layout is not some inviolable dogma.
Tables still work in the present, even if there are alternatives nowadays.
like cutting a board with a hammer
Frankly, that is a short-sighted and really dumb analogy.
A hammer won’t be able to cut the board. A table will however be able to create the basic layout of a site.
A better analogy would be cutting some wood with a knife. Sure, if the chunk of wood is really thick you’ll waste a lot of time doing it, and you’ll probably want an axe or saw instead; but even the knife will do it. However, if it’s just some thin branch, the knife will do the trick.
And it’s the same deal here. If you’re making a huge site, full of SEO and machine-generated “content” and 4MiB of Javascript and lots of “marketing opportunities” (i.e. spam = advertisement) from your “associate partners” (i.e. spammers = advertisers), that’s going to be maintained by some intern, you’ll probably want to use CSS. But if you’re making some simple homepage,
<table><tbody><tr><td>
side panel
</td><td>
maincontent
</td></tr></tbody></table>
will do the trick. For everything else, it depends.
Not with that attitude it won’t. I assure you that, with enough tenacity and/or a large enough hammer, one can absolutely cut a board.
Your analogy is definitely closer though. However, I’d say it’s closer to using a flathead screwdriver to chop a mortise. Possible, without too extreme of measures but results are unlikely to be optimal, to hold up well to a heavy load, or offer fine controls.
A simple site, like something that could work on Gopher or Gemini, or simple home page will absolutely do fine though. And, if that’s what’s required to avoid SEO trash, I’ll live.
It’s the easiest way to bloat up a web page, and turn 1kb of text into 5mb of download.
People whine about cryrocurrency wasting energy; it’s nothing compared to the petajoules wasted on bloated web pages, full of unneccessary Javascript and CSS.
To be fair most of that bloat comes from the Javascript; if your CSS stylesheet is above, say, 100Kb, odds are that you’re doing something wrong.
The major damage that I see is on another level: raising the bar for what you’re expected to know, just to make a site and publish some stuff. It’s the wrong way to go - the development of new tech should enable more people to do more stuff, not the opposite.
Configuring your bundler properly has to be done once per app, and it can significantly cut down on your app’s size.
People expect to see apps, not web pages, but we can be smart about it. Tree shaking has been around for years now, if you build your app properly your bundle will only include the pieces of code that actually gets referenced, e.g. if you pull in a 2 megabytes large library but only use it for one function, only those few lines from the lib will end up in your bundle.
My main issue isn’t even that CSS exists, or its current functionalities. It’s the expectation that, if you’re creating a web page, you must use CSS extensively, and ditch every single “pure” HTML feature that might solve your problem.
On a practical level, what’s intrinsically wrong with the center tag? Or tables for alignment? Those might be bad in some situations, but they’re rather succinct and simple ways to get what you want.
“But what if in the future…” - address future problems in the future. As soon as they appear - not before or after that.
Have you even made a production grade front end project?
You can’t use “pure” HTML solutions because every browser can display these differently. You have to use CSS to make a website look and behave modern. “Pure” center tag is clunky and doesn’t work everywhere and that’s “by design” (That behavior is defined in specification, and we can’t change specification to meet today’s standards because that would make it non backwards compatible). Additionaly you need to make your website scale to wide range of devices. And sometimes you need to even add JS to fix some of the issues if you don’t want the developer to implement a non-maintainable solution taking him 5 hours, if he could do that in JS in 5 minutes.
Look CSS is not perfect. It’s hacky solution to a problem, but news flash: most software engineering is. And it’s proved to be working.
That’s the stupidest thing I’ve read today. I hope you’re not any kind of engineer. There are some situations where it might not be worth it to future-proof something, but if you apply that to everything you end up needing a full rewrite instead of just adding a feature.
Tables are for displaying data, not styling. They worked in the past because there was no alternative but they are the wrong tool for the job; like cutting a board with a hammer.
Any tool or resource is for whatever usage people make out of it.
The distinction between data and layout is not some inviolable dogma.
Tables still work in the present, even if there are alternatives nowadays.
Frankly, that is a short-sighted and really dumb analogy.
A hammer won’t be able to cut the board. A table will however be able to create the basic layout of a site.
A better analogy would be cutting some wood with a knife. Sure, if the chunk of wood is really thick you’ll waste a lot of time doing it, and you’ll probably want an axe or saw instead; but even the knife will do it. However, if it’s just some thin branch, the knife will do the trick.
And it’s the same deal here. If you’re making a huge site, full of SEO and machine-generated “content” and 4MiB of Javascript and lots of “marketing opportunities” (i.e. spam = advertisement) from your “associate partners” (i.e. spammers = advertisers), that’s going to be maintained by some intern, you’ll probably want to use CSS. But if you’re making some simple homepage,
<table><tbody><tr><td> side panel </td><td> main content </td></tr></tbody></table>will do the trick. For everything else, it depends.
Not with that attitude it won’t. I assure you that, with enough tenacity and/or a large enough hammer, one can absolutely cut a board.
Your analogy is definitely closer though. However, I’d say it’s closer to using a flathead screwdriver to chop a mortise. Possible, without too extreme of measures but results are unlikely to be optimal, to hold up well to a heavy load, or offer fine controls.
A simple site, like something that could work on Gopher or Gemini, or simple home page will absolutely do fine though. And, if that’s what’s required to avoid SEO trash, I’ll live.
Well, we have these devices with smaller screens these days. And people really want to use them for browsing the web as well.
It’s the easiest way to bloat up a web page, and turn 1kb of text into 5mb of download.
People whine about cryrocurrency wasting energy; it’s nothing compared to the petajoules wasted on bloated web pages, full of unneccessary Javascript and CSS.
To be fair most of that bloat comes from the Javascript; if your CSS stylesheet is above, say, 100Kb, odds are that you’re doing something wrong.
The major damage that I see is on another level: raising the bar for what you’re expected to know, just to make a site and publish some stuff. It’s the wrong way to go - the development of new tech should enable more people to do more stuff, not the opposite.
Hello, non minified bootstrap reporting
I would absolutely consider using non-minified bootstrap doing something wrong
Configuring your bundler properly has to be done once per app, and it can significantly cut down on your app’s size.
People expect to see apps, not web pages, but we can be smart about it. Tree shaking has been around for years now, if you build your app properly your bundle will only include the pieces of code that actually gets referenced, e.g. if you pull in a 2 megabytes large library but only use it for one function, only those few lines from the lib will end up in your bundle.