Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mistakes in the Design of CSS (2013)

wiki.csswg.org

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Mistakes in the Design of CSS (2013)

#51

Post by pavlov »

Chabsff wrote: post #42
pavlov wrote: post #38

Earlier quoted context omitted.

And this illustrates why margin as defined in CSS doesn’t really make sense at all. Outer margin is not usually a property of the element itself, but its container.

To be fair, it makes sense when you look at the use-case that spawned margins in the first place: , , , , etc... It does make for a fairly elegant way of handling all of those permutations with a reasonable amount of attributes. That comes in to play particularly in cases where you don't have control over which will show up in the wild (e.g. when dealing with Markdown content)

Even for text flows, the margins should be derived from properties of the container.

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.

Re: Mistakes in the Design of CSS (2013)

#52

Post by sproketboy »

PaulHoule wrote: post #30
corethree wrote: post #2

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.

What's the alternative? 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 t…

[dead]

Re: Mistakes in the Design of CSS (2013)

#53

Post by threatofrain »

e12e wrote: post #45
PaulHoule wrote: post #36

Earlier quoted context omitted.

The designer doesn't work semantically. Working with tailwind is like digging the hole for a pool with a spoon instead of a bulldozer. 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, th…

> 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" How is that different from: D { @apply A B C; } Or creating a new utility? https://tailwindcss.com/docs/adding-custom-styles#using-modi...

Note that the Tailwind team strongly anti-recommends @apply and regrets ever putting it in there. As for creating utility classes, well, those are still utility classes. If you do semantic classes then you are fighting against the philosophy of Tailwind as detailed in the Refactoring UI book.

Re: Mistakes in the Design of CSS (2013)

#54

Post by fiddlerwoaroof »

danielvaughn wrote: post #19
fiddlerwoaroof wrote: post #15

Earlier quoted context omitted.

The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.

This sounds interesting - what do you mean by the "built-in extension points"?

I already listed them: doctypes, the lang/type attribute for script/style/link tags, and custom elements/attributes.

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.

Re: Mistakes in the Design of CSS (2013)

#55

Post by zoogeny »

PaulHoule wrote: post #36
unclebucknasty wrote: post #34

Earlier quoted context omitted.

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 developme…

The designer doesn't work semantically. Working with tailwind is like digging the hole for a pool with a spoon instead of a bulldozer. 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, th…

I am a reluctant convert to tailwind. I've been doing HTML since the 90s, before CSS was even really usable for things like page layout. I mean, we didn't even use div in those days - it was table based layouts and spacer gifs.

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.

1. https://getbem.com/

Re: Mistakes in the Design of CSS (2013)

#56

Post by PaulHoule »

zoogeny wrote: post #55
PaulHoule wrote: post #36

Earlier quoted context omitted.

The designer doesn't work semantically. Working with tailwind is like digging the hole for a pool with a spoon instead of a bulldozer. 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, th…

I am a reluctant convert to tailwind. I've been doing HTML since the 90s, before CSS was even really usable for things like page layout. I mean, we didn't even use div in those days - it was table based layouts and spacer gifs. 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…

BEM sucks then you die.

Re: Mistakes in the Design of CSS (2013)

#57

Post by rusk »

fiddlerwoaroof wrote: post #15
rusk wrote: post #13

Earlier quoted context omitted.

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.

The thing is, you could use doctypes like a racket #lang to precisely opt into the new format. Same with the type attribute on style, script and link elements. I’ve always found it a bit sad that we haven’t really taken advantage of the built-in extension points of HTML and related technologies because they’re designed pretty well for breaking changes without breaking compatibility.

Still the same problem. You’ve to get people to use the extensions. You mentioned a few “back in the day” examples and nobody uses these. CSS got the push and gained critical mass initially and that’s that. There’s been plenty of improvements since of course and if you can disregard legacy platforms it all gets a lot easier but that’s where the experts you want to sway define their value.

Re: Mistakes in the Design of CSS (2013)

#58

Post by rusk »

__jonas wrote: post #18
rusk wrote: post #11

Earlier quoted context omitted.

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

Interesting! I am not too annoyed by the coordinate system with flipped y-axis, but I understand that other graphics APIs handle it differently, the vertical-first order I really don't get though. 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.kh…

> OpenGL 1.0

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.

Re: Mistakes in the Design of CSS (2013)

#59

Post by [deleted] »

unclebucknasty wrote: post #39
PaulHoule wrote: post #36

Earlier quoted context omitted.

The designer doesn't work semantically. Working with tailwind is like digging the hole for a pool with a spoon instead of a bulldozer. 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, th…

Exactly. It's the frameworks driving the abuse. 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…

[deleted]

Re: Mistakes in the Design of CSS (2013)

#60

Post by corethree »

cantSpellSober wrote: post #8
corethree wrote: post #2

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.

This article is just about CSS not the entire frontend web stack. Curious though, do you consider server-side-rendered components "frontend?" What about React Server Components?

>This article is just about CSS not the entire frontend web stack.

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?

Post reply on HN