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

71–80 of 147 posts

Re: Mistakes in the Design of CSS (2013)

#71

Post by corethree »

dtagames wrote: post #3
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.

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

But front end is a high level specification.

The principles of physics remain the same but the machines around those laws of physics should improve.

Re: Mistakes in the Design of CSS (2013)

#72

Post by cantSpellSober »

corethree wrote: post #68
cantSpellSober wrote: post #64

Earlier quoted context omitted.

Oh, strange non-sequitur then. 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.

You haven't answered my question. Why inform me on something obvious that I know? I know the article is about css. And you know that I know. 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…

I thought your question was simply rhetoric. I didn't realize how confused you were.

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.)

Re: Mistakes in the Design of CSS (2013)

#73

Post by mhitza »

threatofrain wrote: post #53
e12e wrote: post #45

Earlier quoted context omitted.

> 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.

> Note that the Tailwind team strongly anti-recommends @apply and regrets ever putting it in there

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

Re: Mistakes in the Design of CSS (2013)

#74

Post by eternityforest »

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.

Re: Mistakes in the Design of CSS (2013)

#75

Post by corethree »

cantSpellSober wrote: post #72
corethree wrote: post #68

Earlier quoted context omitted.

You haven't answered my question. Why inform me on something obvious that I know? I know the article is about css. And you know that I know. 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…

I thought your question was simply rhetoric. I didn't realize how confused you were. 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 associa…

Depends on the situation. They can be one or the other or both. It's meta, you construct code on the backend for rendering on the front end. There's no clear answer to your question other than the code being constructed is front end exclusively while the code constructing the code is hard to categorize.

>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?

Re: Mistakes in the Design of CSS (2013)

#76

Post by 4death4 »

eternityforest wrote: post #74

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…

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.

Re: Mistakes in the Design of CSS (2013)

#77

Post by [deleted] »

PaulHoule wrote: post #10

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. 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 rea…

[deleted]

Re: Mistakes in the Design of CSS (2013)

#78

Post by paulddraper »

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.

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?

Re: Mistakes in the Design of CSS (2013)

#79

Post by pcwalton »

codedokode wrote: post #24

> 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.

Re: Mistakes in the Design of CSS (2013)

#80

Post by e12e »

mhitza wrote: post #73
threatofrain wrote: post #53

Earlier quoted context omitted.

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.

> Note that the Tailwind team strongly anti-recommends @apply and regrets ever putting it in there 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

I think "regrets putting it in there" is a bit strong - I'd be interested in a quote.

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.

Post reply on HN