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

71–80 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#71

Post by rcxdude »

xboxnolifes wrote: post #18
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

I think it was advised a bit too early, but ever since flexbox entered the scene, tables for page formatting became irrelevant. And just in case, nobody ever said tables were dead. Tables were declared bad practice for page formatting, not for tabular data.

Even for layout, CSS took a long time to catch up with tables in some areas. Tables were not designed for layout, but there's a lot of aspects to them which are easier to grasp and work with than trying to get the same effect with early CSS.

Re: Incomplete list of mistakes in the design of CSS

#72

Post by MrMetric »

redbar0n wrote: post #68

How could CSS (or any language) have been designed so that these mistakes could have easily been corrected today in any case? If the mentioned mistakes or similar language design mistakes were made. Because mistakes will always be made. (Unison lang comes to mind but it’s refactor failsafe seems narrow. How about: Antifragile language design? Self-correcting language?)

Simple: A version specifier, or feature specifiers. Backward compatibility concerns vanish when I can opt-in to a newer spec. Old code keeps working, and new code doesn't suffer for legacy nonsense.

For example, the Circle compiler extends C++ with its `#feature` directive: https://github.com/seanbaxter/circle/blob/master/new-circle/...

Sadly, the closest I've personally seen to this sort of thing in widespread use is `"use strict";` in JavaScript, which is only a single binary switch. You can't, say, turn on a new keyword, disable a keyword, switch to a different incompatible version of some browser API, etc.

I encourage all language designers to include a feature mechanism in a forward-compatible way. Don't overthink the difficulty: It doesn't need to do anything at first, it just needs to not be a parsing error. Treat it like a comment. FYI, this is the same as having a version number or header size in a binary file format's header, which all sane formats have (there are a lot of insane formats out there...).

Re: Incomplete list of mistakes in the design of CSS

#73

Post by lucideer »

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

> I will never understand

I think it's fairly easy to understand if you understand what it was a backlash against. Tables today are used sensibly, for the most part, but the pre-CSS world was truly absurd in its table use.

The reaction may well have been over-the-top, but it wasn't disproportionate given the state of table usage at the time.

CSS's initial forays into layout seem bad today because people think of tables in terms of their intended use (not the now long-gone monstrosities the community actually extracted from them), but in comparison to the previous ecosystem, floats were a relative godsend.

Re: Incomplete list of mistakes in the design of CSS

#74

Post by Devasta »

silverwind wrote: post #44
Devasta wrote: post #27

For me, the mistake is having style attributes in html. You should be able to write Instead of

These namespaces do not merge cleanly, for example `content`.

Oh for sure, its way way too late to do it, but I don't think much of any of the modern web stack would be kept if we designed in the 90s with what we know now.

Re: Incomplete list of mistakes in the design of CSS

#75

Post by netsharc »

Devasta wrote: post #27

For me, the mistake is having style attributes in html. You should be able to write Instead of

Guess who wasn't around when HTML3.2 was introduced...

How about to control the color of links, add the color attributes for links in body?

https://www.w3.org/TR/2018/SPSD-html32-20180315/#body

Re: Incomplete list of mistakes in the design of CSS

#77

Post by MisterMusion »

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 scaling on screen.

A use case for specifying device pixel sizes are thin-lined grids, that can have inconsistent spacing and line width due rounding when you use px on hi-DPI.

How it should be (and OSes should do it) is:

- There is the device pixel e.g. "dp"

- There is a UI scaling unit "u" (the equivalent to CSS px, but not with a misleading name). It could be e.g. defined to be the height of a standard button. This is used for most screen-oriented elements, and u-based sizes can be optionally rounded to whole dp.

- There are physical units independent of u. There is a ratio of these to dp. For print the ratio is e.g. so that 1in = 300dp if it is a 300dpi print. For screen the ratio is based on the actual physical pixel density the OS can either derive from a display device, or the user calibrates it. Physical unit based sizes can optionally be rounded to whole dp.

- The user can obviously set the UI scaling and overwrite the physical unit scaling.

This way you can get display pixel based sizes simply and reliably, UI scaling is not based on a often misunderstood "virtual pixel", and physical objects can be displayed on screen with its actual size (or whatever scaling the user wants).

Re: Incomplete list of mistakes in the design of CSS

#78

Post by IshKebab »

nfw2 wrote: post #4

I'd like to propose for the list: Default heading styles should not have equal top and bottom margin. Headings should be closer to the content they label than to the content they are setting their content apart from. h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility

> 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 use, like which apparently has better accessibility but does absolutely nothing else, so nobody bothers. The whole "semantic web" thing failed partly because of this.

Re: Incomplete list of mistakes in the design of CSS

#79

Post by nfw2 »

IshKebab wrote: post #78
nfw2 wrote: post #4

I'd like to propose for the list: Default heading styles should not have equal top and bottom margin. Headings should be closer to the content they label than to the content they are setting their content apart from. h1, h2, h3 should not have different styles. it's an anti-pattern that leads to broken accessibility

> 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

Re: Incomplete list of mistakes in the design of CSS

#80

Post by IshKebab »

recursivecaveat wrote: post #55
yread wrote: post #49

I don't understand the point about comments. Why shouldn't they be allowed? What object model? >Comments shouldn't have been allowed basically everywhere in CSS (compare to HTML, which basically only allows them where content goes), because it makes them basically unrepresentable in the object model, which in turn makes building editing directly on top of the object model impossible

Imagine you have something like `width / comment /: / comment2 /12px / comment3 /,`. Now you want to load your css into some kind of structured representation, rearrange it, then spit it back out again with that comment intact. The requirement to represent such comments in your structured format so you can retain them is really obnoxious. In html you can just view comments as another node in a uniform tree.

> In html you can just view comments as another node in a uniform tree.

When you parse an AST with comments (or a CST), they do become "just another node in a uniform tree". Think about it - in HTML you have a tree of nodes but comments can be anywhere, which is exactly as obnoxious to deal with as a CST where comment nodes can be anywhere.

This is a terrible reason to not support comments. If it was really important, then probably you should support comments in only a couple of places, e.g. on attributes or on selectors.

But I don't think it is very important. I can't think of a single tool that loads CSS, rearranges it, and then spits it back out in a form that would benefit from comments.

Post reply on HN