Mistakes in the Design of CSS (2013)
wiki.csswg.org
wiki.csswg.org
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.
Tailwind styles still cascade but in a far more manageable and override-able way. Perhaps you're on to something.
In other cases one can look up how it values id selector for example, or watch the immediate result in the browser, as one adds such a selector.
I am guessing, that over time people, who deal a lot with CSS, will learn the specificity rules automatically.
Tailwind and utility classes make things bloated. Source: been writing HTML and CSS for 20+ years and working with a lot of devs who just don’t get CSS.
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.
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)
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.
But if you had a full algebra/constraints/logic programming system, you could set a solver rule where the first column items had width X, with fairly high priority.
And other rules(like fit-content) on that same property, to specify what the width should be.
The solver would figure out what X should be, and everything in the first column would have that width unless something even more important changed it.
You could even give rules a "layer" in addition to the solver cost, and properties would only take rules from the highest active layer, so you could still do overriding, just explicitly instead of with specificity.
To avoid confusion with different CSS files, layer could be a hierarchal tuple, and you could manually specify the layer of an imported file, forcing all its layers to become sub layers of the one you specified, so you could override a file, or merge two files in one layer, etc.
Would that impact performance negatively?
I'm guessing the solver engine would need lots of work to optimize, but I've never implemented that kind of thing so I don't quite know. I'm not even sure what kind of library could handle it. Something like OptaPlanner?
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.
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..
Out of curiosity, I just briefly looked at the OpenGL 1.0 specification from 1994 [1] and it seems it is also taking coordinates in the order (x,y), I wonder why CSS then decided to go the other way.
[1] https://registry.khronos.org/OpenGL/specs/gl/glspec10.pdf
Right, as I said, top left coordinate system makes sense to me (like in the browser), so does bottom left (like in OpenGL) it's just the fact that CSS expects (y,x) not (x,y) for margins and padding short-hands, regardless of the coordinate system that confuses me.
top left is where reading is assumed to start in Western societies, maybe other systems have the same because of the natural feeling this inspires.
Not quite what I had in mind particularly because opengl was an abstraction layer designed to begin to resolve these kinds of issues in a more domain-oriented way. Go further back I’m thinking more about the 8-bit generation which is … yeah 80s
I don’t know why CSS didn’t try to resolve the issue too, just alluding to why it might have been at odds in the first place.
not
East South West North
It makes a fair amount of sense for the full shorthand with all 4 properties specified.
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.
Disagree. All margins, including horizontal, should collapse. Typically you want 20px between buttons, not 20 + 20.
Traditional graphic designers creating print layouts didn’t use randomly different margins for elements on a page. The margins were derived from a grid system that was applied to the entire page. Within that system, the margin between a body paragraph and a header might be (for example) two grid squares, while the margin between body paragraphs would be one grid square.
CSS designers should have thought more conceptually about the HTML page as a container for text elements. Instead they just created a whole bunch of properties that allow elements themselves to define any spacing anywhere in any units, then tried to patch up the conceptual mess with hacks like margin collapse.
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.
Then again, the cynic in me thinks we'd just endlessly fight over the design decisions anyways.
Back in the day, you could use alternate scripting languages in IE: VBScript shipped by default, but there was also the ability to install an ActiveX extension to enable Python and some others in the script tag.
Finally, CSS itself is starting to get some more programmability via the Houdini APIs.
Then you can do whatever you want, or, more realistically, grab an open source alterna-rendered that does something close to, but not quite exactly, what you want, but close enough.
It's a lot of work to get there from here, but all the forces push that way and I expect it will happen, even if it takes another decade.
Reserve your seats now for the inevitable progression of HN stories, roughly by year:
1. Show HN: My Alterna-render Renders Text Around Arbitrary Images
2. Layout.rs: A Minimal Alterna-Renderer In Rust
3. Layout.rs Has Gotten Too Bloated
4. Why You Should Stop Using Alterna-Renderers And Just Use HTML+CSS
5. Facebook's App Reaches 5 Gigabytes of Rendering Code
6. When to use and not use an alternative renderer
The pure-canvas approach is currently very bad, and most of what makes it so is fundamentally unfixable, because fixing it would require exposing unacceptable details (for privacy or functionality). I’ve written about this quite a few times on HN. A few of the things I tend to mention could conceivably be fixed, but browser-makers have shown absolutely no inclination to address any of it.
No, for at least the rest of this decade, doing things properly will absolutely require using the HTML DOM. And I’m very sceptical that browser-makers will ever seek to make the pure-canvas approach a viable alternative, there are just way too many problems with it.
If you reduce the scope to custom layout and such for CSS, there are interesting experiments in the CSS Houdini project.
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.
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.
Google would like to have Dart replace JavaScript too.
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".)
One of the great ideas from Ted Nelson's
https://en.wikipedia.org/wiki/Project_Xanadu
was transclusion: any document could embed part of some other document. Now Ted saw that being done by a special kind of hyperlink (you're not copying the target but linking to it) and he imagined there was a micropayments system such that I get 10 cents for the document and author of the target gets 1 cent.
In the case of HTML it would be great if you could snip a piece of HTML out of a document together with CSS and associated assets and then incorporate these into another document and have it "just work". I mean, if it was easy to do we wouldn't see people collect and post so many screenshots from X, they could just make an HTML page that embeds the content.
I prototyped a server-side templating system that would break HTML down into a DOM graph and made some progress on the problem of rewriting identifiers such as classes and identifiers in a donor document to address problems similar to the "hygenic macro" problem when it is embedded in a host document. I got it to work in some simple cases but wasn't sure how general I could make it. (In some cases you are going to have to modify the CSS to make the donor work inside the host, for instance, and that probably does involve judgement calls.)
It's quite a miracle that people get CSS to work inside React components, Web components, and stuff like that, given that out of the box CSS doesn't have any mechanism to stop people from using the same classes, not to mention a rather complex mechanism of inheritance, etc.
You mean like an <iframe>?
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.
They repeat the same tailwind classes 20,000 times and if the application gets bigger they repeat it 40,000 times and if they have to change the way it looks it is the mother of all cut and paste jobs.
There is an unholy convergence of the tools being almost but not quite adequate, the platform being driven by companies that have overly favorable unit economics (Google could care less if it cost $2M to make a simple web site) and a designer mindset that is all too comfortable with trading a bulldozer for a spoon.
Tailwind would be a lot more appealing to me if it was coupled with some system where I could say "class X inherits from tailwind classes A, B and C" and thus have a layer of abstraction over just writing properties.
I actually think CSS is the wrong tool for modern webdev. Or rather, it should be the output of a compile process instead of something that designers and developers wrestle with.
In general, we're building these complex SPAs, and still working directly in standards that were intended for a static document model. Part of the reason is we somehow believe we need infinite customizability, so for that we're writing in Assembly.
But, the truth is that user interfaces are largely consistent and should be. Still, even if we did want maximal customizability, we should use tooling that generates the CSS, etc.
And that tooling should be visual. I mean think about the fact that we're trying to hand code visual designs with text. Or that it was so accepted that we're only recently trying to generate the code from design tools like Figma, which is still imperfect.
So many thousands of developer hours lost to this effort. Bass-ackwards to be sure.
I'd point out the grid layout and flexbox as being features ideal for application work and https://www.w3.org/TR/2011/WD-html5-20110405/forms.html#form... is practically a love letter for applications.
How is that different from:
D {
@apply A B C;
}
https://tailwindcss.com/docs/adding-custom-styles#using-modi...
Please link to something that supports this claim, because it's not the first time I've seen it made on HN, but only found it on HN
That said, the documentation does lean heavily away from @apply:
https://tailwindcss.com/docs/reusing-styles#extracting-class...
> If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice.
Personally I think @apply is a useful tool - and I'm not sold on it being always evil.
I'm sure new users of the system will find that. Great job everyone.
FFS
CSS appeals to a programmers mindset. Cascading seems like a good idea. Having classes that are reusable seems like a good idea. Complex selectors seem like a good idea. These are all forms of abstraction, almost like functional composition but not quite.
But after decades of fighting with it, I have to admit that it just doesn't work. The myth that you could change an entire site design just by changing the CSS is a complete myth. I've been party to more than a few whole site redesigns and I can assure anyone unfamiliar that it involved a heck of a lot more than updating CSS (and more than HTML in almost every case as well).
In fact, almost all advancements in CSS (including Sass and Less) seemed to tend toward isolating the effect of changes. Pretty soon most projects had a compenent.html/component.scss pair for every fragment and naming conventions like BEM [1] became the norm. Reusability for things like fonts and colors were handled with CSS variables.
Tailwind is proof to me that isolation is more important for visual design than abstraction/inheritance/cascading. Inline styles would be the same advantage but they are way too verbose.
There was nothing more annoying than including a component on a page and some aspect of the component was visually broken. Like a margin inflated somewhere or a wrong color. And then time would be wasted trying to figure out what was cascading/inheriting. Worse case it was some CSS included at runtime by some JS script that was forced onto the team by marketing. But on large teams there was just a constant collision between page authors, component authors and other stakeholders.
HTML Web Components tried to solve the problem by making the shadow dom isolated but in our experimentation the support was just too inconsistent across browsers. It was also a major pain to debug at the time (maybe this has gotten better?)
I was completely against Tailwind, absolutely hated looking at it and I even used my position as a senior engineer at a company to block its adoption. I felt it flew in the face of the entire premise of CSS and the high-ideal of separating form and content. I now believe I was wrong.
I mean, you were right about that one. It's just that the entire premise of CSS is wrong and its ideal doesn't work.
You should tell that to this site which has been doing exactly that for 20 years: https://csszengarden.com/
I've seen hundreds and hundreds of clever tech demos. I even believed in some of them for a time. Now I realize they were carefully constructed gimmicks.
css zen garden is made explicitly to do one thing and it manages to do that one thing. It's hard for me to even say that it does it very well, clicking through the featured designs. Unfortunately, the dream of redesigning a website that wasn't purpose-made for this particular trick remains but a dream.
But I think it was clear from the very beginning that it was meant to be aspirational. Nobody is really claiming that today with CSS you can arbitrarily change the design of a page just by modifying CSS. If you look at the evolution from earlier designs on the CSS zen garden to later ones, it's clear that advances in CSS itself has made some designs possible. The ::before and ::after pseudo elements I believe are one of these advances that are critical.
> Unfortunately, the dream of redesigning a website that wasn't purpose-made for this particular trick remains but a dream.
I'm not disagreeing that this is a dream. I'm stating that it is meant to be a dream gradually becoming real.
This was particularly a popular idea amongst semantic web people and was talked about a lot in the communities around things like rdf/rss/atom. You might have a reader for desktop, for your palm pilot, for your e-reader, etc. each with their own stylesheets being applied to the original document. XSLT was also a player in this space since you might want to alter the document structure itself ... a stylesheet for the XML structure itself.
Almost all of these wild ideas died on the vine. XHTML was one of the first to go. I haven't heard anyone talking about XSLT recently although it sometimes sneaks out from under a rock in some places. RSS readers are now marginal at best and the format is mostly used for distribution of podcasts these days. And I am not aware of anyone using user stylesheets for the web, or even if it is still possible.
Strangely enough the movement moved more towards open data formats. That is what Tim Berners Lee is working on these days inside the ODI. I think the movement rightly discarded most concerns about styling data or even displaying it at all. But we still have this legacy from the original ideas discussed above. The original semantic web folks were trying to solve both problems simultaneously and the formats we have are tainted by that history.
Easy to do when you don't actually have to update the content or functionality. And even with those advantages, most versions of it look bad.
I feel the same. Give the component a class and then in the SCSS assign the setting there. But inlining each individual CSS setting? I don't get it. Sure maybe great for a quick prototype / MVP. But as a permanent tool? I don't see it.
This mindset is the problem. You don't want or need this abstraction in the CSS, what you want is to encapsulate these styles properties in a reusable "HTML component", and then use that component wherever needed. It then carries those style properties into every instantiation. What use are semantic style classes in this context? Atomic CSS makes perfect sense in this context and makes composable development a breeze by comparison.
I should have also mentioned that your "semantic CSS" is necessarily anti-composable by contrast. Any reusable HTML components with semantic classes now require you to manually lift their CSS definitions into your CSS top-level context, which is a step that isn't required with atomic CSS / tailwind.
This articulates a problem I’ve had with Tailwind for a while, and not quite been able to put words to.
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.
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.
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."
But then if the user is tweaking a specific site, the user should be able to override anything with ! important if they really mean it.
But what's curious is that normally it goes browser < user < author, but with !important, it flips so that browser > user > author. Specifically the part where the browser now outranks the user style is interesting.
@media (scripting) {
noscript {
display: none !important;
}
}
optgroup {
float: none !important;
position: static !important;
white-space: nowrap !important;
word-wrap: normal !important;
}
input[type="password" i] {
-webkit-text-security: disc !important;
}
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 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.
Oh absolutely. Even `important!` would have been better.
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.
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.
All programming languages need some way to provide abstraction, which means hiding irrelevant details, and composition, which means building bigger things out of small things.
CSS related examples are until recently you couldn't say "Use the main theme color" (abstraction; hiding the actual color behind a name.) You still cannot name a group of styles and reuse them, so you cannot say "the dark theme is the base theme with these colors added" (abstraction and composition). If you look at what Tailwind is, the core is just composition: being able to say "this element's style is built out of the following components". The @apply CSS extension that Tailwind provides is pure composition.
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)
That one got fixed without a time machine!
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.
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.
Except no we're not, new processors bring along new features and drop/discourage old ones, on x86 they even run in different modes depending on requirements, and compilers can choose to target specifically new ones and drop support for older processors without them. This isn't a valid comparison.
I think it's a bad thing because even though "you can do anything" it doesn't mean you can do it well because the web was always designed to be narrow and restricted for privacy/security reasons. That's good, but there's large classes of applications (chat clients, music players, image editors, etc) where that shouldn't be an issue and the costs of running in a web-like environment. Which, even if you drop the security features, manifests as worse UX to users due to the layers of indirection you're dealing with between the developer and the host OS.
The principles of physics remain the same but the machines around those laws of physics should improve.
Curious though, do you consider server-side-rendered components "frontend?"
What about React Server Components?
Why waste your effort to inform me something I already know? You know that I know.
>Curious though, do you consider server-side-rendered components "frontend?"
Why are you curious about vocabulary and categorization? If you know what I'm talking about by "front-end-stack" then who cares?
I don't know what you mean specifically by "front end stack", so I asked (unanswered) clarifying questions.
> Why are you curious about vocabulary and categorization
Because the frontend/backend lines are blurring, and I want to define our terms before discussion.
By front end I mean any technology directly associated with rendering and processing on the browser. The lines of this definition are blurry so I will adjust those lines and move them accordingly to fit the intent of what I'm saying here. But again you know my intent so why make me waste my time to specify something you clearly know?
To answer: if there's an article about tomato slices and someone goes on a rant about hamburgers (tomato slices being a small part of the whole) it's not clear or "obvious" that they read or understood the article.
You haven't answered my question, do you consider server-side-rendered components "frontend?" They are "directly associated with rendering and processing on the browser." (Even if they aren't rehydrated.)
>I thought your question was simply rhetoric. I didn't realize you were genuinely confused.
If the tomato is rotten, I'm saying that's the least of your problems if The entire hamburger is rotten. Pretty clear about my intent. Did you honestly think that I was being completely random or did you have another motive for saying something rhetorical?
Agreed, I thought you'd have some insight. IMO you painted with too a broad brush in your OP. Articles that are specific get derailed by overly-broad replies.
This article is a decade old but sadly still relevant. I hope a day will come that it won't be.
> Did you think that I was being completely random
As I already said, I thought it was a non-sequitur.
Stop with the personal obsession, I just want to chat.
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.
Good question! What do you mean? There is no alternative, just enough experience writing it that these mistakes become hardwired, or having browsers updated to interpret "no-wrap" as "nowrap" for ex.
The options you mention make sense, but just a level of abstraction. CSS is still the compile target (unless you're using WASM etc).
Unless you mean alternatives to, say, using things like `!important`?
With transparent compression it shouldn't make pages any bigger on the wire, and given that the browser always has to figure out what styling to apply to each element it shouldn't use any more memory.
Also, if anybody can figure it out, I would absolutely love to see and discuss.
The list-style properties should be called marker-style, and list-item renamed > to marked-block or something.
How about just `mark` instead of `marker-style` to be consistent with other properties that decorate part of an element like `border` or `background`?
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.
Not it's not.
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.