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

91–100 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#91

Post by Timwi »

eviks wrote: post #45

> That should be corrected if anyone invents a time machine. :P Why can't this be dealt with with CSS versioning/features where you can opt into your current-color and a lot of more substantive style behavior while leaving currentColor functional?

A lot of the behaviors should just have a toggle to turn them off. For example, there are many situations where margin collapsing is in the way and I keep wondering why there isn't simply a `margin-collapse: none`. It would also be nice to have something like `default-styles: none` that will remove all the default styling for h1/h2/etc. and em/strong/cite/etc. so I don't have to deal with browsers having differing defaults.

Re: Incomplete list of mistakes in the design of CSS

#92

Post by wongarsu »

nfw2 wrote: post #66
0xfffafaCrash wrote: post #13

Earlier quoted context omitted.

moreover h* is just broken whenever dealing with more dynamic content — it simply can’t reasonably be made to work according to accessibility recommendations — and the accessibility guidelines around never skipping a level themselves are ridiculous given the practical reality that dynamic content exists and we have only h1, h2, etc. to work with — the readers and specs are what need to adapt here, not the entire inte…

The problem with trying determine heading depth automatically is the depth is not something that can be deduced just by the structure. If headings are siblings, for example, the may be on the same level semantically or not. One way I've dealt with this in react is combine a Heading component with ContentGroup component. Each content group needs exactly one heading, and heading can't exist without it. Content group ca…

That's how html should have been designed from the start. HTML is originally designed as a very flat hierarchy, e.g. h1 p p p h2 p p h2 p p h3 p h2 p just following each other. When really it would make much more sense to have h{p p p h{p p} h{p p h{p}} h{p}}.

Re: Incomplete list of mistakes in the design of CSS

#93

Post by pglevy »

Vinnl wrote: post #85
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

> the ability to reliably center things. Assuming one agrees that we even did regain it. Is there anyone who does not agree that we can reliably center things in CSS nowadays?

At least one person. https://tonsky.me/blog/centering/

Re: Incomplete list of mistakes in the design of CSS

#94

Post by yiiii »

wongarsu wrote: post #92
nfw2 wrote: post #66

Earlier quoted context omitted.

The problem with trying determine heading depth automatically is the depth is not something that can be deduced just by the structure. If headings are siblings, for example, the may be on the same level semantically or not. One way I've dealt with this in react is combine a Heading component with ContentGroup component. Each content group needs exactly one heading, and heading can't exist without it. Content group ca…

That's how html should have been designed from the start. HTML is originally designed as a very flat hierarchy, e.g. h1 p p p h2 p p h2 p p h3 p h2 p just following each other. When really it would make much more sense to have h{p p p h{p p} h{p p h{p}} h{p}}.

That's what sectioning elements [1] like and where once introduced.Opposite to just using elements their purpose was to create a real document outline, where it would have been possible to only use and their level would be determined by how deep the section is nested, but this approach was never really adapted.

[1] https://www.w3schools.com/html/html5_semantic_elements.asp

Re: Incomplete list of mistakes in the design of CSS

#95

Post by hypertele-Xii »

Timwi wrote: post #84
oneeyedpigeon wrote: post #63

Earlier quoted context omitted.

> We pretend but flexible viewport size is not actually possible. Not beyond a point, but it's still very useful to be flexible up to that. For example, I'm very grateful that a web page will reflow text rather than print everything on one line and force horizontal scrolling.

Yet, for some reason, mobile browsers do not reflow when you zoom in, but instead insist on horizontal scrolling, unlike their desktop counterparts. I've never understood that.

Firefox has a "Desktop site" switch that when disabled changes this behavior.

Re: Incomplete list of mistakes in the design of CSS

#96

Post by Vinnl »

pglevy wrote: post #93
Vinnl wrote: post #85

Earlier quoted context omitted.

> the ability to reliably center things. Assuming one agrees that we even did regain it. Is there anyone who does not agree that we can reliably center things in CSS nowadays?

At least one person. https://tonsky.me/blog/centering/

Haha fair, we do still suck at properly centering text, I'll give you that.

Re: Incomplete list of mistakes in the design of CSS

#97

Post by wanderingstan »

Angostura wrote: post #83
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

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

Re: Incomplete list of mistakes in the design of CSS

#98

Post by MrJohz »

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.

In fairness, the default `display: table` setup is often a pain to work with, so I can understand why people would opt for flexbox instead. One better option, though, might be to use `table` elements under the hood, styled with `display: grid` (and judicious use of subgrid for the intermediate elements) to get more precise control over the layout, while still using the right semantic elements underneath.

Re: Incomplete list of mistakes in the design of CSS

#99

Post by afavour »

dahcryn wrote: post #51
afavour wrote: post #9

Earlier quoted context omitted.

Tables aren’t dead, they never were… when displaying tabular data. When it comes to layout I think you might be wearing rose tinted glasses. Remember having to put a 1px image in a table cell to avoid it disappearing? Remember “best viewed at 800x600”? I’m personally not nostalgic for either.

at least they were specific Today it's usually implicitly designed for iphone, designed for 1080p, or ipad, and you have to guess, strong correlation with whatever device the designer uses in his personal life.

...no? Today's sites use responsive design and adapt to pretty much any screen size.

Re: Incomplete list of mistakes in the design of CSS

#100

Post by DonHopkins »

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

Same reason why JSON prohibits comments: When you parse it, there is no place to represent the comments in the JavaScript object and array tree, so they must be thrown away, therefore it's impossible to write it out with the same comments in the same places.

Same thing with white space: JSON can not round trip white space or comments the way XML or HTML can, because XML and HTML DOM represents comments and white space explicitly.

Also you can't put comments inside elements like class="foo">. There is no way to represent a comment inside an element in XML or HTML DOM.

But CSS lets you, so you can't round trip comments in CSS.

Post reply on HN