Live data from Hacker News

CSS: Unavoidable Bad Parts

matklad.github.io

31–40 of 88 posts

Re: CSS: Unavoidable Bad Parts

#32

So many complaints about web technology, where is the replacement? I'd be interested to know if there was the one true layout system that everyone agrees on

The web is probably the closest thing the software industry has to a truly universal, open application platform. There is corporate influence, but it is substantially more vendor-neutral than any other UI platforms.

The web stuff mostly uses licenses such as MIT, Apache 2.0, and BSD. GPL-licensed projects exist, but still many more on permissive side.

Web is based on open standards developed through organizations and specifications are publicly available, royalty-free, and implemented by multiple independent browser engines rather than being owned by a single corporation.

Re: CSS: Unavoidable Bad Parts

#33
> If you “View Source” on any “real” website, you’ll notice that everything has layers and layers of wrapper elements, so you might be tricked into thinking that wrappers are how you solve layout problems. I can’t really agree or disagree here, as I never wrote “production” CSS, but, in my experience, it’s much easier to understand if you do the opposite — restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have.

CSS isn't powerful enough by itself to create any layout you want without modifying the HTML. You almost always need wrapper elements to group elements you want to align together for presentation purposes only (e.g. "a vertically centered row containing one paragraph next to two vertically stacked images"), so there often aren't semantic HTML tags that would make sense.

It's similar to how you use numerous groups/frames in design apps like Inkscape and Figma to help align elements, where nobody would suggest you were a bad designer for using groups that don't have semantic meaning.

You can only really avoid wrapper elements for simple Markdown style pages with simple designs, where the CSS for that is straightforward.

I think in these discussions, it needs to be clearer how complex the page designs being discussed are. The CSS advice that makes sense for simple Markdown style pages is very different to what makes sense for a complex web app UI or a highly designed marketing page.

Re: CSS: Unavoidable Bad Parts

#34

I mean, this has a lot of out of date information which I guess is not surprising for someone who says I'm not an expert and don't do production CSS, but it is weird to get the suggestions that are pretty reasonable for 5+ years ago.

You know, this speaks volumes. Layout is a complicated business, sure, but CSS just keeps having monumental shifts in how you're supposed to approach it year after year; it's as if it's done without any overarching theory/vision but merely groping in the dark, trying things and fixes, and seeing what sticks and doesn't suck too horribly (this latter part is optional; remember Yandex's BEM?)

You really don’t have to change your css. My personal website has been using roughly the same css for a decade. Why not?

Sure if you are a designer and want to follow trends, you’ll have to keep your css skills up to date. But for most websites, you can use css from a decade ago.

Re: CSS: Unavoidable Bad Parts

#35
post #12
post #10

Earlier quoted context omitted.

Yup, using rem for as many things as possible has always been good to me.

This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins. If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.

This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?

Re: CSS: Unavoidable Bad Parts

#36

So many complaints about web technology, where is the replacement? I'd be interested to know if there was the one true layout system that everyone agrees on

The complaints shouldn't require a replacement at least in the web's case the replacement is still the web standard, a better, iterated version. It's a living standard and criticism keeps the platform slowly but surely evolving. I think it's a healthy feedback loop.

Re: CSS: Unavoidable Bad Parts

#37
post #12
post #10

Earlier quoted context omitted.

Yup, using rem for as many things as possible has always been good to me.

This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins. If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.

Thanks for the tip. That does make sense, although I do think having your default CSS-defined font sizes (across your whole app, not just the main content) be a reasonable size should be the first priority.

Also, not having ridiculously oversized margins, like so many 2019-2022 websites trying to look "modern" used to use.

old.reddit.com is one example where the paddings still look good when magnification is set to 150-170% (which I have to do because of the tiny default font size). I think doing it that way but with better readability at 100% zoom, would be a decent solution.

Re: CSS: Unavoidable Bad Parts

#38
post #35
post #12

Earlier quoted context omitted.

This is bad advice. You should only use rem for text, e.g. font sizes and paragraph margins. If the user is on a phone and has a larger default font size due to vision difficulties, making padding scale with the font size takes screen real estate away from the larger text the user needs.

This is true. I use increased font size on my phone, and so many websites are borderline unusable because of massive unnecessary padding. But I am also a culprit of using rem for everything. What is the alternative? Pixels?

Thanks for helping me realize my accidental anti-pattern. Can you link some of the sites that do that the worst.

I want to use those as references to fix my UI (on increased font-sizes on small screens) before releasing an app I've spent 4+ months on.

Re: CSS: Unavoidable Bad Parts

#39

I mean, this has a lot of out of date information which I guess is not surprising for someone who says I'm not an expert and don't do production CSS, but it is weird to get the suggestions that are pretty reasonable for 5+ years ago.

You know, this speaks volumes. Layout is a complicated business, sure, but CSS just keeps having monumental shifts in how you're supposed to approach it year after year; it's as if it's done without any overarching theory/vision but merely groping in the dark, trying things and fixes, and seeing what sticks and doesn't suck too horribly (this latter part is optional; remember Yandex's BEM?)

Would you prefer that CSS never evolve, and our frustrations remain the same? Writing CSS today has gotten significantly easier with flexbox, variables and now nesting. BEM is not part of the CSS spec, that's just a design methodology.

Re: CSS: Unavoidable Bad Parts

#40

> If you “View Source” on any “real” website, you’ll notice that everything has layers and layers of wrapper elements, so you might be tricked into thinking that wrappers are how you solve layout problems. I can’t really agree or disagree here, as I never wrote “production” CSS, but, in my experience, it’s much easier to understand if you do the opposite — restrict yourself to using only markup-meaningful semantic ta…

I think this is a pretty pragmatic take, and I do something similar with all the web apps I’ve created since I started self employment close to 15 years ago.

As you mentioned sometimes there are unavoidable things you need to do in markup to make it work visually. Although lately grid & flex solve 95% of the problems that crop up for me fortunately.

Post reply on HN