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

Incomplete list of mistakes in the design of CSS

wiki.csswg.org

Post reply on HN
Print view View original

101–110 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#101

Post by idbehold »

wanderingstan wrote: post #97
Angostura wrote: post #83

Earlier quoted context omitted.

> Related: I also love when I can't paste tabular data into Excel/etc. anymore Except that’s exactly where tables should be used. So if you can’t, someone has really misunderstood CSS. Use it for tables, not for layout.

I’ve gotten in several arguments over the years where webdevs insisted on showing tabular data using flexbox or hardcoded div widths or worse. They insisted that html tables were never ever to be used and couldn’t be persuaded.

If you try to render tables with millions of cells the browser does a really poor job and the performance is abysmal. The only solution when you need to render that many cells is to virtualize the table and only have the visible cells (plus some buffer) actually in the DOM at a time. That plus weird restrictions browsers put on certain table elements (looking at you thead) that prevent them from being "sticky" headers means that the developer is left with absolutely positioned divs as the only solution. Blame browser vendors for not providing a native way to present tabular data with more than a few hundred thousand rows without causing performance issues.

Re: Incomplete list of mistakes in the design of CSS

#102

Post by IshKebab »

nfw2 wrote: post #79
IshKebab wrote: post #78

Earlier quoted context omitted.

> h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility How does that hurt accessibility? Are you saying people use h3 in order to get its style even when they didn't mean h3? I think the opposite could happen too - if they all have the same style then people might just use h1 everywhere which is probably just as bad. People tend not to use elements that have no obvious…

> Are you saying people use h3 in order to get its style yes, and that people assume the purpose of having different tags is to control styling

I mean, they aren't wrong. That is part of the purpose. Of course now we try and do it via CSS but it's definitely still fine to use as bold and as italic, even if the semantic pedants will insist that they mean "Bring attention to" and "Idiomatic" (that name's stretched so thin you can see through it!).

Re: Incomplete list of mistakes in the design of CSS

#103

Post by crazygringo »

MisterMusion wrote: post #77

The biggest problem IMHO is how the unit system with regards to pixels and physical units is designed. A px is not a device pixel but a physical unit of length 1/96 inch. This nonsense is technical not a CSS-only thing but based on a 80s hack by Microsoft and Apple. As a result you can not specify device pixel sizes directly, (you have to calculate them from devicepixelratio in js), and physical units relate to UI sc…

Hard disagree. Not having access to true device pixels is a feature, not a bug -- especially when you consider that common screens today range from 90 dpi to 600 dpi. And then not to mention browser zoom on top of that.

Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore. We use antialiasing instead to ensure that widths and weights maintain proportionality no matter what resolution and zoom level you use. Trying to snap to pixels is an anti-feature with modern screens. It made sense when everyone used low-resolution screens and antialiasing wasn't commonly used in OS's and programs. But it hasn't made sense for well over a decade now.

Re: Incomplete list of mistakes in the design of CSS

#104

Post by PunchyHamster »

anonymars wrote: post #6

I will never understand the bizarre scene of the web's smug collective declaration that tables were dead and not to be used juxtaposed against the years it took to regain the ability to reliably center things. Assuming one agrees that we even did regain it. Related: I also love when I can't paste tabular data into Excel/etc. anymore For the record, I don't hate the idea of stylesheets, but...sheesh

This is somehow worse than "never use goto"; because there are plenty of good uses for tables, and CSS was lacking features for forever after the clowns declared "tables bad" and the other clowns followed without thinking

Re: Incomplete list of mistakes in the design of CSS

#105

Post by DonHopkins »

the_other wrote: post #70

‘text-transform: uppercase’ should be ‘text-transform: UPPERCASE’, for the LOLZ.

Brilliant idea, but "case" is redundant, and upper/lower is incomplete, so there should be:

text-transform: CASE; text-transform: case; text-transform: Case; text-transform: casE; text-transform: cASe; text-transform: CaSE; etc...

I've wanted the latter to write headlines about NeWS and NeXT and NeRF.

Re: Incomplete list of mistakes in the design of CSS

#106

Post by dnpls »

groby_b wrote: post #7

It is extremely funny to me that the list thinks the mistake about !important was using the exclamation mark sigil, and not the concept of a single priority level. In the words of one of my CS profs, from a few decades ago: "There are only 3 numbers - zero, one, and infinity. And 'one' is often a mistake"

There is no need for more priority levels, because precedence is already defined by inline > #ID > .class / [attribute=""] / :pseudo-classes / elements / ::pseudo-element / universal selector (*). And the order they're written, if both have the same priority. The !important just exists to override that order.

Re: Incomplete list of mistakes in the design of CSS

#107

Post by MisterMusion »

crazygringo wrote: post #103
MisterMusion wrote: post #77

The biggest problem IMHO is how the unit system with regards to pixels and physical units is designed. A px is not a device pixel but a physical unit of length 1/96 inch. This nonsense is technical not a CSS-only thing but based on a 80s hack by Microsoft and Apple. As a result you can not specify device pixel sizes directly, (you have to calculate them from devicepixelratio in js), and physical units relate to UI sc…

Hard disagree. Not having access to true device pixels is a feature, not a bug -- especially when you consider that common screens today range from 90 dpi to 600 dpi. And then not to mention browser zoom on top of that. Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore. We use antialiasing instead to ensure that widths and weights maintain proportionality no matter what resolution…

You already have access to device pixels, you just have to calculate it yourself.

Anti-aliasing is not a good solution for orthogonal lines with low device pixel ratios like 1.25 or 1.5. which will be around for a long time. Browsers disagree with you - they don't use anti-aliasing for orthogonal measurements, they round. Which means they do in fact pixel-snap.

I agree that it can be misused like using device pixels for UI, but my suggestions makes the distinction more explicit.

Re: Incomplete list of mistakes in the design of CSS

#108

Post by jan_Inkepa »

crazygringo wrote: post #103
MisterMusion wrote: post #77

The biggest problem IMHO is how the unit system with regards to pixels and physical units is designed. A px is not a device pixel but a physical unit of length 1/96 inch. This nonsense is technical not a CSS-only thing but based on a 80s hack by Microsoft and Apple. As a result you can not specify device pixel sizes directly, (you have to calculate them from devicepixelratio in js), and physical units relate to UI sc…

Hard disagree. Not having access to true device pixels is a feature, not a bug -- especially when you consider that common screens today range from 90 dpi to 600 dpi. And then not to mention browser zoom on top of that. Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore. We use antialiasing instead to ensure that widths and weights maintain proportionality no matter what resolution…

>Trying to optimize to some kind of perfect pixel alignment shouldn't be a goal anymore.

If you're trying to display pixel art (or make games with pixel art), being able to have integral upsizing is very useful. Antialiasing doesn't cut it, and the eye notices when you do non-integral nearest-neighbour upscaling and some pixels are the wrong size.

Re: Incomplete list of mistakes in the design of CSS

#109

Post by mcphage »

edent wrote: post #2

When I occasionally venture I to standards-land, I always ask "what user research have you done on this?" So many weird design choices in computing are because one person said "this seems right to me" without considering other viewpoints or consulting with the wider community. Sure, you probably dont want death by committee, but a tiny cabal engaging in groupthink often produces unhelpful results.

This feels like the origin of a lot of these mistakes (and more besides): they weren't based on "what is it that lots of real designers are actually trying to accomplish?". Why did it take so long to get support for pinstriping, when prior to that there were 1001 different ways to try and accomplish it, because so many people wanted it? Why did it take so long to get layout functionality that even just matched the power of what CSS was intending to replace? Or vertical alignment, or drop shadows, etc, etc, etc. I like CSS and the intentions of it, but man, it was designed from a place of having no idea what people wanted to do.

Re: Incomplete list of mistakes in the design of CSS

#110

Post by anonymars »

Popeyes wrote: post #48
tobr wrote: post #39

Earlier quoted context omitted.

For what it’s worth, the very page we’re on here still uses tables and spacer gifs, in 2025. (EDIT: I don’t mean to imply that this is good, just an inescapable observation in this context)

Probably why there are endless reworkings of the site.

I imagine it's also why its size is measured in kilobytes and loading time in milliseconds
Post reply on HN