The list reminds me of when people refactor code and then just rename things. Ok, foo should've been called bar, but is that really a design mistake? The biggest design mistake for me is that it contains the letter C - it never should've been cascading. There's probably a need to resolve conflicting rules but it never should've been THE feature around which the language is designed. The precedence algorithm, the specificity etc. has been a source of endless bugs because you almost never know if somewhere somehow an outdated selector is messing everything up in a hidden place far away from what you're actually doing.
Instead the core features should've been simple ways to, well, style. From the beginning you should've been able to e.g. position vertically. There's a huge list of these issues where for a long time the simplest things were difficult and involved too much thought to get anything done. Granted things have improved, but the main issue I have is that standards like CSS should be more practice driven, e.g. what are the things I want to get done and how do I do that. Instead this is how you will override a selector as if that's the most important thing.
This is interesting because my first reaction was to recoil in horror at the idea of CSS without the cascade, but my second reaction was to realie you're actually describing approximately how Tailwind works eg small classes that you can use to apply an aspect of styling to a specific element, and use to build up to a design. Utility classes would be the obvious choice if you couldn't rely on the cascade any more.
Tailwind styles still cascade but in a far more manageable and override-able way. Perhaps you're on to something.
Interesting to think about the implications of a non-cascading system.
First that comes to mind, is how in OOP we have this idea of "composition over inheritance". Would composable style sheets be better? IDK.
Second issue I see is that, by all definitions, browsers come with a default style. What would "No style" even be? Invisible? Or maybe a very basic default? And would that be readable at all? And how do we the override these defaults? Would the existence of any custom styles immediately disable any base styles?
Lots of issues that are mostly "solved" with cascading. But which would need (a) solution(s) without cascading.
I still like exploring the idea, but the more I dive down that rabbit hole, the more I think that actually cascading is a rather elegant solution.
And, as with OOP inheritance, it's up to us to keep it sane. I've always managed to keep my cascading max three levels: browser, basis.css, custom.css. and in neither basis nor custom, do I have inheritance (cascading) chains.
I've even used a Linter to enforce this, years ago. Cannot find it anymore, sadly.
Originally the „cascade“ referres to the ability for both the browser, and the the user, and the website to define styles for a single website. With the browsers styling being the weakest, the users styles the strongest and the websites own styles being in the middle of the cascads
Make flexbox the default layout for everything, and add a flex-snap feature that will snap to the nearest multiple of some given size. I'm not sure we actually would still need grids.
I also wonder if you couldn't have a more transparent and parameterizable auto width algorithm based on a lowest cost solver.
So you could say "If this element wraps, it's cost 50", meaning you want all the boxes to stay on as few lines as possible. Or "Every em of height this element has is cost 10, if anything triggers a scrollbar, that's cost 100".
Maybe instead of flex-grow, you'd just add negative cost to the width of something.
You could have alternate rulesets so the browser could choose one or the other for lowest overall page cost.
Also, class inheritance. I don't see why that's not a thing. "Not needing processors" should be a pretty big design goal.
How would your flex box solution handle a simple two column layout where the first column is a variable size? There isn’t a fixed multiple to “snap” to.
It was in Internet Explorer, everything being misaligned because of this difference was one of the reasons it got the nickname Internet Exploder.
Edit: To be clear this was more of just a fun fact, I agree with this statement. The misalignment was because people would build to content-box without knowing it was different in IE. Worse still IIRC they acted differently even before this CSS attribute was exposed, so you had to make it work both ways if you wanted your site to look nice everywhere.
> background-position and border-spacing (all 2-axis properties) should take vertical first, to match with the 4-direction properties like margin.
I hate that margin / padding short-hands, especially with 2 values, expect vertical first.
In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else?
Now my issue is that I've committed to memory that margin and padding short-hands work the exact opposite way I would expect, so sometimes I still mix them up because I type them 'correctly' and then flip them because I memorized it like that..
I think there’s a historical reason for this, that probably made more sense back in the 90s … I seem to remember learning computer graphics back then and being similarly frustrated by the reversed notation. My guess is it goes back to raster based calculations where you would go down a number of lines and then across. Oh yea orig is top left rather than bottom left as one would also naturally expect
Would be interesting to view websites through a browser that transposes these values while rendering, or otherwise interprets CSS differently in thoughtfully considered ways.
Personally, I think box-sizing being content-box by default was probably the biggest misstep here, and something that genuinely feels at odds with how 99% of the population would design or build something. The fact IE got it right initially and then it took another few years to even get things fixed across the board just feels utterly ridiculous to me.
Also, not having something like Flexbox or Grid earlier on was another mistake that should have been listed too. The fact we had to resort to hacks related to floats and table layout to create basic layouts was an absolute joke, and indicates that the creators at the time had no idea what a site or application would usually be like design or functionality wise.
> The top and bottom margins of a single box should never have been allowed to collapse together automatically as this is the root of all margin-collapsing evil.
Disagree. All margins, including horizontal, should collapse. Typically you want 20px between buttons, not 20 + 20.
The author isn't saying margin collapse should go away entirely (though, having had to implement it, it sure is tempting to get rid of the feature). Rather, they're talking about the situation in which a div is empty and has top and bottom margins. In that case, the top and bottom margins of that element collapse together into one combined margin, along with any preceding and following margins from elements lexically earlier and later in the document, respectively. This is a feature most designers probably don't realize exists, and it makes margin collapsing horribly complicated to implement (and, in CSS, it's important to remember that "complicated" typically means "slow").
I believe (but could be wrong) that this "collapse-through" feature was an accidental byproduct of the original CSS 2.0 definition of "adjoining margins", and not something that the original spec authors specifically contemplated.
But I can get that functionality very easily with an owl selector, whereas opinionated default functionality means there are cases where I have to actively fight the system.
While many of these are obvious and don't need further explanation, the article would benefit a lot from showing a few simple examples for some of these items, or a justification for why the author's proposed naming is better.
Backwards compatibility may be a fundamental design philosophy of the web, but wouldn't it still be possible to support a different document format with a new programming model that gives us a clean break from the past? It's a naive question, I realize, but it's tantalizing to imagine what we could have if we went that route.
Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anyways.
A clean break is hard to manage because of chicken and egg things. If you want to deploy it to your web pages, either you need to ship the required viewer too (and have the user buy in for that), it needs to translate into something today's browsers can use, or you need to do the work both ways.
If your new system is translatable to the old system, it's often not clear what that brings you. And you often end up in the trap that the new system never quite matches the abilities of the old system, so it's hard to abandon the old ways.
That's kinda what something like TailwindCSS is, no? Use their reset & their shorthands, and many of these problems are solved; then your build system translates to the actual CSS standard.
First you need buy-in which means essentially Google needs to support the format in Blink. It needs to be sufficiently specified so Apple supports it in Safari on iOS as well (which means support on Mac and iPad).
Second you'll need a good reason for the new format instead of just implementing it in current browsers. Lots of fancy stuff on the web today is just something that draws to a <canvas> tag and ignores a lot of actual HTML or CSS. We're already seeing a lot of traditionally "desktop" code being able to target WASM as a compile target.
You’d have to get people to use it. Like any established warty system, the warts provide just enough of a moat for established practitioners to keep it just the way it is.
I thought "!important" was always about appealing to the emotions of overwhelmed and confused CSS authors as it seems to make the computer "listen to you" when it doesn't seem to be.
about techniques used to get pixel perfect results with HTML back in the 1990s. The author of that book was quite impressed with CSS as it really does give designers great tools to work with, but it's still got the problem that designers find it hard to be disciplined with. That is, a lot of designers are stuck in a "let's draw a pretty picture" mindset but find it hard to think like "let's develop a system that makes it easy to draw lots of pretty pictures". Thus we get a lot of things like bootstrap and tailwind that erode the idea of CSS classes being somewhat semantic and being related to the structure of the system (e.g. this particular toolbar as it manifests in this application) as opposed to "a generic toolbar that comes out of a framework" or "something that has 15px of margin".)
Well the `!important` is a good example if general misunderstanding of the core basics of the CSS: the cascade.
People usually think it means something like "override everything what was declared up until now in a way I don't need to check the selector specificity", while in reality it means *"teleport this certain declaration to the higher mirror cascade origin realm"*, what is way cooler yet mostly unknown concept of CSS.
There are _Browser_ styles, that are overridden by parts of —
— _User_ styles, that are overridden by parts of —
— _Author_ Styles, that are overridden by —
— !important parts of _Author_ Styles, that are overridden by —
— !important parts of _User_ Styles, that are overridden by —
— !important parts of _Browser_ Styles.
What is a neat mechanism, isn't it? The "weakest" can have the last word here.
Sadly neglected concept of the web standards is that they were conceived not as rigid projectors of what authors create, but as a platform where individual user agents process authors' contents and negotiate the way how their users want to consume it. One of the first Håkon Wium Lie's CSS proposals even had some "weights" for individual attributes, so that user could express "I prefer serif fonts for headings this much" and author could express that "I suggest this sans serif font for heading with such weight, but it is not so important and my content will make sense in different font faces as well, but it is crucial that this particular text will be slanted, otherwise user would miss important aspect of information."
Kind of hard to see Bootstrap and Tailwind so casually lumped together with regard to how they break semantics, as they are at least an order of magnitude apart in that. Bootstrap will throw in a p-0, but Tailwind is designed to essentially make everything a p-0.
And that's an important distinction, as I think the current challenge with CSS for designers (and everyone) is that it now sits between design and development. That is, we've long departed the document model use case, wherein you're simply laying out a static Website that you just want to be consistently styled across pages and easily changeable (perhaps the optimal semantic use case).
We now build apps wherein we encourage essentially inline styles to be co-located with components. That itself is a complete rejection of the semantic CSS model. And it's exactly why Tailwind—being explicit about its purpose in an application development context—goes that order of magnitude beyond Bootstrap.
But, how does a designer work semantically in this context?
I think there are a lot of things wrong with Web development these days and styling at the component level is an example of one. Tailwind is the right tool for the wrong job. It solves a problem that shouldn't exist. And, in doing so, tempts some to believe CSS is the problem.
Edit: Don't get me wrong. CSS has its own problems and a good number of them. But it can't be blamed for not being used semantically in the current Web development environment.
> Thus we get a lot of things like bootstrap and tailwind that erode the idea of CSS classes being somewhat semantic
If everyone is using CSS wrong, then I think that's pretty good evidence that the design is flawed. The semantic/cascade model has proven to be challenging for designers (as you suggest in your comment), difficult to maintain (inheriting a mess of somebody else's CSS is a nightmare), and counter to the component-based encapsulation that seems to be the trend in modern web dev patterns.
> Thus we get a lot of things like bootstrap and tailwind that erode the idea of CSS classes being somewhat semantic
Can you link to somewhere explaining why and how CSS is meant to be semantic? Search bots and screen readers don't read or use class names. They expect certain semantics from HTML tag names and HTML attribute names though.
I think this is mixing up something that is really only meant to be a convenience for developers here.
Tailwind would advocate you wrap up common styles within a web component so the web component filename would take the place of a class name so there's not much difference for developers. Lots of styling is purely decorative as well and doesn't have semantics so there isn't always a useful name to provide e.g. `gallery-container-wrapper` isn't telling you much.
> z-index should be called z-order or depth and should Just Work on all elements (like it does on flex items).
Z-index is one of the most aggravating things I've run into with CSS. It should always Just Work as the author says and be absolute across the whole page and intuitive. But it isn't. And every time I run into a problem where it's not behaving in the way I expect, I have to once again Google 'z index not working' and refresh my memory on all the reasons why it might not be working with the specific example I'm dealing with.
ChatGPT is a CSS deity, I have been using it lately and have been impressed by it. I suppose it's because so many issues were raised about it, so it is now trained on every possible mistake you can make
It shouldn't have had inheritance by default. It was designed at the height of object-oriented programming, and so it had to have inheritance. This results in blocks of CSS turning off stuff in case some outer CSS turned it on.
It really should have been a constraint system. Layout should be something that says that X is to the right of Y, Y is below Z, A and B have the same height, etc. But people didn't really know how to do those back then. See the 2D sketching system in Autodesk Inventor/Fusion to see this done right. That can do more than boxes (it understands curves) but web layout should probably just be boxes.
Maybe it shouldn't be textual at all. Maybe layout should be designed entirely in graphical tools.
Cannot put text on top of text. Boxes must be disjoint. If you want another layer, OK, but layers should work like windows.
No, the biggest mistake in the design of CSS is not realizing they are designing a programming language, and consequently not adding means for abstraction and composition. Less, Sass, Tailwind etc. would not exist if abstraction and composition existed in CSS. This list is just a layer of paint.
Nobody expected entire applications to be built out of HTML, CSS and JavaScript when those languages were being designed.
CSS's main purpose was to get inappropriate bloat out of HTML because HTML was supposed to describe content not what it looks like but the IE vs Netscape browser wars had created a proliferation of new HTML tags that went against the purpose of the language. JavaScript was designed for writing simple scripts to enhance web sites not to be a full programming language.
Web application development was supposed to be done through plugins like Java (applets), Flash and Shockwave. It wasn't until 10-15 years ago that the idea to just do all of this in HTML, CSS and JavaScript occured to anybody because it would have been really slow and inefficient on older hardware (HTML5 video on Youtube instead of Flash used to slow my mid-00s mid range Windows XP laptop to a crawl).
For CSS in particular, the expectation of its creators was that users would specify their own style sheet which would override the web site's style sheet. To the best of my knowledge, this feature ended up being little used and is not even possible in modern browsers.
(The above is what I remember from teaching myself web 1.0 style web development from books in the early 00s as a preteen and then teenager)
I disagree. No one needed that in the 90s when CSS came out, all they needed was a way to reference document styles from one file, rather than adding it manually to every HTML file.
And besides, don't all front-end frameworks just add CSS directives into the HTML anyway? I feel like the incessant urge to make webdev look and feel like pure programming that emerged with the SV gold rush would have led us where we are anyway - except in the universe where CSS was already a full fledged programming language, things would just be exponentially more complex than they are now.
The Entire front end web stack looks like a design mistake.
Backend looks better only because of the flexibility. You can do anything in the back. But the front you're locked into multi decade old tech and the decade old wrappers written around it.
Sorry I can't hear you over the sound of my fifteen hundred microservice infrastructure configured with Chef, no actually Puppet, no actually Ansible, no actually Terraform, no actually Tofu, no actually Pulumi. Wait, what is Docker Swarm and does anyone use it?
I disagree. First of all, all of computing is locked into decades-only technology: assembler language and machine instructions. Everything comes down to that whether you write front or back end and regardless of what other "tech" is in the middle.
Today, we can do anything on the front end. Some of the most popular and complex apps in history are front end apps made with JS/HTML and web components (Discord, Spotify, Photoshop for Web, YouTube, and many others.)
The reason that this "stack" has survived and thrived is precisely that it does, at this point, allow front end devs to do anything and to do it in a way that runs everywhere. And that's a Very Good Thing.
The 1990s style HTML form app that works like a green screen mainframe application? (It seems to be forgotten technology in the age of React like Stonehenge or the Egyptian Pyramids but I think it's quite appropriate for the kind of application it's capable of, which is more > 50% of what people use React for.)
Cross-platform frameworks like GTK, Qt, Tk, FLTK, wxWidgets (was that a winner in the world cup for "ugliest UI"?), Flutter, etc. (I did a shootout of x-platform UI frameworks and concluded that Electron really is the best of the bunch, is it any worse to make people download a 30MB Electron runtime than a 50MB Java runtime or a 25MB Python runtime?)
Apple fanboys inexplicably seem to like iTunes and MacOS, they all swear by xCode but even people who think "it is is all good" when it comes to fruit swear at the App Store when it comes to delays and restrictions. I'm pretty sure there is a good UI framework somewhere inside Windows but it might be hard to find in a maze of twisty little APIs that all look alike:
which makes it straightforward to make an application that targets desktop, mobile, VR and AR headsets. Although it is based on React it has the same entity-component architecture as the Unity framework. I'm sure I could get better performance writing a more-or-less Android app based on Unity but dealing with Facebook's App Store seems like messing around with IBM cards, particularly when I want to target Apple Vision when it comes out and when I need to have an experience for people that don't have a VR headset because those aren't very common yet.
More tools to manipulate scroll targeting, scroll bars, and better access to more parameters around scrolling. Also better tools around display: clip. I spent maybe 6 hours trying to recreate instagram on iOS’s appbar scrolling to hide/reveal and even with some JavaScript, I don’t think it’s actually possible to coax a browser into doing it perfectly. Particularly to have it be completely smooth without scrolling artifacts, and on mobile.
Also, if anybody can figure it out, I would absolutely love to see and discuss.
Flexbox is obsolete and as with JavaScript you are supposed to wrestle with a subset of css aka the good parts.
Sensible user interfaces are a solved problem and it is totally fine that the tutorial industry shows all the other possibilities you have when you don’t need to display content while the framework industry points to general one size fits all solutions from which you can pick the one that fits your specific general use-case and favorite way of displaying the filler text around the advertising content.
Wait what??? Since when is flexbox obsolete I use it all the time, I think I used it today. What had replaced it? Don’t say grid, that’s better for 2d layouts.
There are even more fundamental mistakes in the concept of page styling. For example, that a webmaster should attempt to choose a readable font size and font colour on behalf of their users without knowing anything about the users' needs in that regard.
There used to be a PostCSS plugin that did fix some of these, for example you could write "white-space: no-wrap"
and it would compile to "nowrap" (which is syntactically correct). I can't remember what it was called.
locallost|2 years ago
Instead the core features should've been simple ways to, well, style. From the beginning you should've been able to e.g. position vertically. There's a huge list of these issues where for a long time the simplest things were difficult and involved too much thought to get anything done. Granted things have improved, but the main issue I have is that standards like CSS should be more practice driven, e.g. what are the things I want to get done and how do I do that. Instead this is how you will override a selector as if that's the most important thing.
onion2k|2 years ago
Tailwind styles still cascade but in a far more manageable and override-able way. Perhaps you're on to something.
berkes|2 years ago
First that comes to mind, is how in OOP we have this idea of "composition over inheritance". Would composable style sheets be better? IDK.
Second issue I see is that, by all definitions, browsers come with a default style. What would "No style" even be? Invisible? Or maybe a very basic default? And would that be readable at all? And how do we the override these defaults? Would the existence of any custom styles immediately disable any base styles?
Lots of issues that are mostly "solved" with cascading. But which would need (a) solution(s) without cascading.
I still like exploring the idea, but the more I dive down that rabbit hole, the more I think that actually cascading is a rather elegant solution.
And, as with OOP inheritance, it's up to us to keep it sane. I've always managed to keep my cascading max three levels: browser, basis.css, custom.css. and in neither basis nor custom, do I have inheritance (cascading) chains.
I've even used a Linter to enforce this, years ago. Cannot find it anymore, sadly.
matheusmoreira|2 years ago
laszlokorte|2 years ago
dang|2 years ago
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=25891435 - Jan 2021 (68 comments)
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=18297757 - Oct 2018 (150 comments)
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=10453850 - Oct 2015 (106 comments)
Incomplete List of Mistakes in the Design of CSS - https://news.ycombinator.com/item?id=7665667 - April 2014 (1 comment)
eternityforest|2 years ago
I also wonder if you couldn't have a more transparent and parameterizable auto width algorithm based on a lowest cost solver.
So you could say "If this element wraps, it's cost 50", meaning you want all the boxes to stay on as few lines as possible. Or "Every em of height this element has is cost 10, if anything triggers a scrollbar, that's cost 100".
Maybe instead of flex-grow, you'd just add negative cost to the width of something.
You could have alternate rulesets so the browser could choose one or the other for lowest overall page cost.
Also, class inheritance. I don't see why that's not a thing. "Not needing processors" should be a pretty big design goal.
felixfbecker|2 years ago
4death4|2 years ago
maxloh|2 years ago
Would that impact performance negatively?
Izkata|2 years ago
It was in Internet Explorer, everything being misaligned because of this difference was one of the reasons it got the nickname Internet Exploder.
Edit: To be clear this was more of just a fun fact, I agree with this statement. The misalignment was because people would build to content-box without knowing it was different in IE. Worse still IIRC they acted differently even before this CSS attribute was exposed, so you had to make it work both ways if you wanted your site to look nice everywhere.
__jonas|2 years ago
I hate that margin / padding short-hands, especially with 2 values, expect vertical first.
In my head it's always (x,y) and (width,height) – always horizontal then vertical, I feel like it works like this everywhere else?
Now my issue is that I've committed to memory that margin and padding short-hands work the exact opposite way I would expect, so sometimes I still mix them up because I type them 'correctly' and then flip them because I memorized it like that..
culi|2 years ago
not
East South West North
rusk|2 years ago
unclebucknasty|2 years ago
CM30|2 years ago
Also, not having something like Flexbox or Grid earlier on was another mistake that should have been listed too. The fact we had to resort to hacks related to floats and table layout to create basic layouts was an absolute joke, and indicates that the creators at the time had no idea what a site or application would usually be like design or functionality wise.
codedokode|2 years ago
Disagree. All margins, including horizontal, should collapse. Typically you want 20px between buttons, not 20 + 20.
pcwalton|2 years ago
I believe (but could be wrong) that this "collapse-through" feature was an accidental byproduct of the original CSS 2.0 definition of "adjoining margins", and not something that the original spec authors specifically contemplated.
ForkMeOnTinder|2 years ago
Nathanael_M|2 years ago
mock-possum|2 years ago
pprotas|2 years ago
danielvaughn|2 years ago
danielvaughn|2 years ago
Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anyways.
toast0|2 years ago
If your new system is translatable to the old system, it's often not clear what that brings you. And you often end up in the trap that the new system never quite matches the abilities of the old system, so it's hard to abandon the old ways.
RheingoldRiver|2 years ago
giantrobot|2 years ago
Second you'll need a good reason for the new format instead of just implementing it in current browsers. Lots of fancy stuff on the web today is just something that draws to a <canvas> tag and ignores a lot of actual HTML or CSS. We're already seeing a lot of traditionally "desktop" code being able to target WASM as a compile target.
rusk|2 years ago
maxloh|2 years ago
Google would like to have Dart replace JavaScript too.
PaulHoule|2 years ago
I remember this notorious book
https://www.amazon.com/Creating-Killer-Sites-David-Siegel/dp...
about techniques used to get pixel perfect results with HTML back in the 1990s. The author of that book was quite impressed with CSS as it really does give designers great tools to work with, but it's still got the problem that designers find it hard to be disciplined with. That is, a lot of designers are stuck in a "let's draw a pretty picture" mindset but find it hard to think like "let's develop a system that makes it easy to draw lots of pretty pictures". Thus we get a lot of things like bootstrap and tailwind that erode the idea of CSS classes being somewhat semantic and being related to the structure of the system (e.g. this particular toolbar as it manifests in this application) as opposed to "a generic toolbar that comes out of a framework" or "something that has 15px of margin".)
myfonj|2 years ago
Sadly neglected concept of the web standards is that they were conceived not as rigid projectors of what authors create, but as a platform where individual user agents process authors' contents and negotiate the way how their users want to consume it. One of the first Håkon Wium Lie's CSS proposals even had some "weights" for individual attributes, so that user could express "I prefer serif fonts for headings this much" and author could express that "I suggest this sans serif font for heading with such weight, but it is not so important and my content will make sense in different font faces as well, but it is crucial that this particular text will be slanted, otherwise user would miss important aspect of information."
-- https://www.w3.org/People/howcome/p/cascade.html
unclebucknasty|2 years ago
And that's an important distinction, as I think the current challenge with CSS for designers (and everyone) is that it now sits between design and development. That is, we've long departed the document model use case, wherein you're simply laying out a static Website that you just want to be consistently styled across pages and easily changeable (perhaps the optimal semantic use case).
We now build apps wherein we encourage essentially inline styles to be co-located with components. That itself is a complete rejection of the semantic CSS model. And it's exactly why Tailwind—being explicit about its purpose in an application development context—goes that order of magnitude beyond Bootstrap.
But, how does a designer work semantically in this context?
I think there are a lot of things wrong with Web development these days and styling at the component level is an example of one. Tailwind is the right tool for the wrong job. It solves a problem that shouldn't exist. And, in doing so, tempts some to believe CSS is the problem.
Edit: Don't get me wrong. CSS has its own problems and a good number of them. But it can't be blamed for not being used semantically in the current Web development environment.
yowzadave|2 years ago
If everyone is using CSS wrong, then I think that's pretty good evidence that the design is flawed. The semantic/cascade model has proven to be challenging for designers (as you suggest in your comment), difficult to maintain (inheriting a mess of somebody else's CSS is a nightmare), and counter to the component-based encapsulation that seems to be the trend in modern web dev patterns.
Brajeshwar|2 years ago
seanwilson|2 years ago
Can you link to somewhere explaining why and how CSS is meant to be semantic? Search bots and screen readers don't read or use class names. They expect certain semantics from HTML tag names and HTML attribute names though.
I think this is mixing up something that is really only meant to be a convenience for developers here.
Tailwind would advocate you wrap up common styles within a web component so the web component filename would take the place of a class name so there's not much difference for developers. Lots of styling is purely decorative as well and doesn't have semantics so there isn't always a useful name to provide e.g. `gallery-container-wrapper` isn't telling you much.
unknown|2 years ago
[deleted]
Jeema101|2 years ago
Z-index is one of the most aggravating things I've run into with CSS. It should always Just Work as the author says and be absolute across the whole page and intuitive. But it isn't. And every time I run into a problem where it's not behaving in the way I expect, I have to once again Google 'z index not working' and refresh my memory on all the reasons why it might not be working with the specific example I'm dealing with.
Nathanael_M|2 years ago
stevage|2 years ago
Oh absolutely. Even `important!` would have been better.
n3storm|2 years ago
matheusmoreira|2 years ago
epups|2 years ago
Animats|2 years ago
It really should have been a constraint system. Layout should be something that says that X is to the right of Y, Y is below Z, A and B have the same height, etc. But people didn't really know how to do those back then. See the 2D sketching system in Autodesk Inventor/Fusion to see this done right. That can do more than boxes (it understands curves) but web layout should probably just be boxes.
Maybe it shouldn't be textual at all. Maybe layout should be designed entirely in graphical tools.
Cannot put text on top of text. Boxes must be disjoint. If you want another layer, OK, but layers should work like windows.
noelwelsh|2 years ago
bdw5204|2 years ago
CSS's main purpose was to get inappropriate bloat out of HTML because HTML was supposed to describe content not what it looks like but the IE vs Netscape browser wars had created a proliferation of new HTML tags that went against the purpose of the language. JavaScript was designed for writing simple scripts to enhance web sites not to be a full programming language.
Web application development was supposed to be done through plugins like Java (applets), Flash and Shockwave. It wasn't until 10-15 years ago that the idea to just do all of this in HTML, CSS and JavaScript occured to anybody because it would have been really slow and inefficient on older hardware (HTML5 video on Youtube instead of Flash used to slow my mid-00s mid range Windows XP laptop to a crawl).
For CSS in particular, the expectation of its creators was that users would specify their own style sheet which would override the web site's style sheet. To the best of my knowledge, this feature ended up being little used and is not even possible in modern browsers.
(The above is what I remember from teaching myself web 1.0 style web development from books in the early 00s as a preteen and then teenager)
krapp|2 years ago
And besides, don't all front-end frameworks just add CSS directives into the HTML anyway? I feel like the incessant urge to make webdev look and feel like pure programming that emerged with the SV gold rush would have led us where we are anyway - except in the universe where CSS was already a full fledged programming language, things would just be exponentially more complex than they are now.
creata|2 years ago
That one got fixed without a time machine!
corethree|2 years ago
Backend looks better only because of the flexibility. You can do anything in the back. But the front you're locked into multi decade old tech and the decade old wrappers written around it.
paulddraper|2 years ago
dtagames|2 years ago
Today, we can do anything on the front end. Some of the most popular and complex apps in history are front end apps made with JS/HTML and web components (Discord, Spotify, Photoshop for Web, YouTube, and many others.)
The reason that this "stack" has survived and thrived is precisely that it does, at this point, allow front end devs to do anything and to do it in a way that runs everywhere. And that's a Very Good Thing.
cantSpellSober|2 years ago
Curious though, do you consider server-side-rendered components "frontend?"
What about React Server Components?
PaulHoule|2 years ago
The 1990s style HTML form app that works like a green screen mainframe application? (It seems to be forgotten technology in the age of React like Stonehenge or the Egyptian Pyramids but I think it's quite appropriate for the kind of application it's capable of, which is more > 50% of what people use React for.)
Cross-platform frameworks like GTK, Qt, Tk, FLTK, wxWidgets (was that a winner in the world cup for "ugliest UI"?), Flutter, etc. (I did a shootout of x-platform UI frameworks and concluded that Electron really is the best of the bunch, is it any worse to make people download a 30MB Electron runtime than a 50MB Java runtime or a 25MB Python runtime?)
Apple fanboys inexplicably seem to like iTunes and MacOS, they all swear by xCode but even people who think "it is is all good" when it comes to fruit swear at the App Store when it comes to delays and restrictions. I'm pretty sure there is a good UI framework somewhere inside Windows but it might be hard to find in a maze of twisty little APIs that all look alike:
https://www.reillywood.com/blog/windows-ui-frameworks/
Compare that to the freedom of the web platform. I've lately been playing around with this framework with my Meta Quest 3:
https://aframe.io/examples/showcase/modelviewer/
which makes it straightforward to make an application that targets desktop, mobile, VR and AR headsets. Although it is based on React it has the same entity-component architecture as the Unity framework. I'm sure I could get better performance writing a more-or-less Android app based on Unity but dealing with Facebook's App Store seems like messing around with IBM cards, particularly when I want to target Apple Vision when it comes out and when I need to have an experience for people that don't have a VR headset because those aren't very common yet.
roblh|2 years ago
Also, if anybody can figure it out, I would absolutely love to see and discuss.
r2b2|2 years ago
How about just `mark` instead of `marker-style` to be consistent with other properties that decorate part of an element like `border` or `background`?
mediumsmart|2 years ago
Sensible user interfaces are a solved problem and it is totally fine that the tutorial industry shows all the other possibilities you have when you don’t need to display content while the framework industry points to general one size fits all solutions from which you can pick the one that fits your specific general use-case and favorite way of displaying the filler text around the advertising content.
reidjs|2 years ago
shepherdjerred|2 years ago
Not it's not.
oftenwrong|2 years ago
cantSpellSober|2 years ago
There used to be a PostCSS plugin that did fix some of these, for example you could write "white-space: no-wrap" and it would compile to "nowrap" (which is syntactically correct). I can't remember what it was called.
hknmtt|2 years ago
maxloh|2 years ago