Live data from Hacker News

CSS: Unavoidable Bad Parts

matklad.github.io

11–20 of 88 posts

Re: CSS: Unavoidable Bad Parts

#11

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

TeX [0] is in some sense "the one true layout system", but it's designed for printed documents, so it doesn't work on the web [1]. And in some ways, it's much simpler than CSS (you can build nearly everything from only a dozen typesetting primitives or so), but in other ways it's much more complex (since TeX is itself a fairly complex programming language). It's typesetting quality is still unbeaten by any of its com…

[deleted]

Re: CSS: Unavoidable Bad Parts

#12
post #10
post #3

In 2026, you can avoid the bad parts. > Let's start with the basics: if you write`font-size: 16px`then `16px` is the size of what? Sadly, the answer is "nothing in particular" -- this is a size of a virtual box around the glyph, but the box isn't tight, and the size of the glyph varies, depending on the font. Luckily, `font-size-adjust` property can fix it, and make `font-size` consistent across fonts. All modern bro…

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.

Re: CSS: Unavoidable Bad Parts

#13

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

TeX [0] is in some sense "the one true layout system", but it's designed for printed documents, so it doesn't work on the web [1]. And in some ways, it's much simpler than CSS (you can build nearly everything from only a dozen typesetting primitives or so), but in other ways it's much more complex (since TeX is itself a fairly complex programming language). It's typesetting quality is still unbeaten by any of its com…

My understanding is that it's designed for fixed-size documents? There's a big difference between a layout system for that, and one where size of a document can vary wildly, up to completely opposite aspect ratios

Re: CSS: Unavoidable Bad Parts

#14

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

TeX [0] is in some sense "the one true layout system", but it's designed for printed documents, so it doesn't work on the web [1]. And in some ways, it's much simpler than CSS (you can build nearly everything from only a dozen typesetting primitives or so), but in other ways it's much more complex (since TeX is itself a fairly complex programming language). It's typesetting quality is still unbeaten by any of its com…

I'm not sure if Tex has a way to express mobile/desktop aware layouts, or to enable the reader to adjust only the font size (my ignorance)

Re: CSS: Unavoidable Bad Parts

#15

Note: The following of course varies from site to site based on how design focused the site needs to be. I had thought about writing some things about this, but I will put a quick observation here >restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have. this used to be the best practice advice about 20 years ago. If you've been around long enough…

My experience working with other peoples code is that they often use too many wrappers. I don't mind using some wrappers, often they're just necessary. But I'll often see components with like 4+ nested divs where half of them or more can just be removed with no visual change. Not to mention spans, some people just use spans for everything, it's all divs and spans.

Personally I like to try to use semantic HTML where possible, as it helps with a11y and is nicer to read and work with. But I don't mind using some container/wrapper divs to make things look right.

Re: CSS: Unavoidable Bad Parts

#16
post #13

Earlier quoted context omitted.

TeX [0] is in some sense "the one true layout system", but it's designed for printed documents, so it doesn't work on the web [1]. And in some ways, it's much simpler than CSS (you can build nearly everything from only a dozen typesetting primitives or so), but in other ways it's much more complex (since TeX is itself a fairly complex programming language). It's typesetting quality is still unbeaten by any of its com…

My understanding is that it's designed for fixed-size documents? There's a big difference between a layout system for that, and one where size of a document can vary wildly, up to completely opposite aspect ratios

I guess I'd call it mostly fixed: most TeX engines only produce a single page size at a time, but you generally only need to modify a single variable to change the page size and, after recompiling the document should be perfectly reflowed into the new page size. This is not helpful at all for someone who wants to be able to freely rotate their phone, but it's still better than InDesign or Word where changing the page size will probably break the layout.

There is actually a TeX extension that supports viewers arbitrarily changing the page size of documents [0], but it's fairly new, and as far as I'm aware it has essentially zero adoption.

[0]: https://ctan.org/pkg/hitex

Re: CSS: Unavoidable Bad Parts

#17

Earlier quoted context omitted.

TeX [0] is in some sense "the one true layout system", but it's designed for printed documents, so it doesn't work on the web [1]. And in some ways, it's much simpler than CSS (you can build nearly everything from only a dozen typesetting primitives or so), but in other ways it's much more complex (since TeX is itself a fairly complex programming language). It's typesetting quality is still unbeaten by any of its com…

I'm not sure if Tex has a way to express mobile/desktop aware layouts, or to enable the reader to adjust only the font size (my ignorance)

Yup, you're correct that TeX can't really handle arbitrary page sizes; see my reply [0] to a sibling comment.

[0]: https://news.ycombinator.com/item?id=48487199

Re: CSS: Unavoidable Bad Parts

#18
To call a CSS pixel not an actual pixel but a measurement of an angle at a reading distance is... technically correct... but isn't really representative of how it's actually rendered. On a non Hi-DPI display at 100% scaling in the browser and OS, a px is a device pixel. An css inch is considered 96px, with the assumption that a CSS inch is an imperial inch on a 96 DPI display.

Yes, it's a bit fuzzy now with modern displays (especially when display scaling is not at a whole number haha) but it just kinda feels like searching for something to complain about. If your browser and OS doesn't get in the way you can get exact measurement. This also applies to almost any UI framework that has some integration with the OS.

Re: CSS: Unavoidable Bad Parts

#19

Note: The following of course varies from site to site based on how design focused the site needs to be. I had thought about writing some things about this, but I will put a quick observation here >restrict yourself to using only markup-meaningful semantic tags, and then figure out CSS which works with the markup you have. this used to be the best practice advice about 20 years ago. If you've been around long enough…

It's also worth noting that semantic markup is not a feature of CSS, it is a feature of HTML. CSS has almost no power if something like a scraper or a reader mode chooses to ignore it. Of course that would be pandemonium and we would never get good results.

I feel like something in the CSS camp that could be highlighted in a "great idea, okay implementation, poor reception" that the OP is going for is print stylesheets. Those are incredibly underused.

Post reply on HN