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

81–90 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#81

Post by nialse »

yread wrote: post #62
systoll wrote: post #56

Earlier quoted context omitted.

The CSS Object Model. HTML comments are basically just a HTML tag that isn't rendered. Tools that 'compile' the HTML code into a document tree, including browsers, preserve comments as nodes without any extra effort. CSS comments can go anywhere: /*wow*/ .selector /*x*/ {animation /*z*/: 2s /*z*/ linear /*z*/ bounce;} Tools that transform/parse CSS can either: 1. Strip comments before parsing, meaning anything based…

But if it's valid CSS it has to be representable in AST/object model? It's a comment, it can't have any child nodes, it doesn't depend on anything - pretty trivial. And if it's in the tree you can transform it with proper tools. If you are transforming CSS you have to write a proper parser and not just a bunch of regexes EDIT: also why is it useful to have comments in the object model in the first place? To access th…

Round-tripping to CSS and keeping information that may be useful to the user if they would inspect the content I would presume.

A similar issue is CDATA in XML which is not retained when round-tripped. Very annoying, but in line with the spec.

Re: Incomplete list of mistakes in the design of CSS

#83

Post by Angostura »

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.

Re: Incomplete list of mistakes in the design of CSS

#84

Post by Timwi »

oneeyedpigeon wrote: post #63
6510 wrote: post #60

Earlier quoted context omitted.

On commodore 64 the screen is just a fixed size grid of characters. No one ever had issues making an ui. We pretend but flexible viewport size is not actually possible. If you are making a painting for example the size of the canvas greatly influences what can and can be done. I made a stunning landscape photo one time that looked great only when displayed at roughly the size of a hand. If made larger undesirable det…

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

Re: Incomplete list of mistakes in the design of CSS

#85

Post by Vinnl »

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?

Re: Incomplete list of mistakes in the design of CSS

#86

Post by cluckindan »

tim1994 wrote: post #59
cluckindan wrote: post #58

Earlier quoted context omitted.

Try resizing a browser window with nested a flex layout.

Should you optimize for resize performance? I guess that depends on the app. Use the tool that fits the requirements.

Resizing is not the optimization target, it just makes reflow performance visually apparent.

Re: Incomplete list of mistakes in the design of CSS

#87

Post by mananaysiempre »

wk_end wrote: post #46
dekoidal wrote: post #31

Earlier quoted context omitted.

From 2014 https://jakearchibald.com/2014/dont-use-flexbox-for-page-lay...

Browser performance tips from 2014 mean very little twelve years on. Not only have machines gotten faster and networks gotten faster, rendering engines gotten faster. And I'm doubtful it nested flexboxes would've been all that much of a problem in most cases even then. The most important thing is to use the right tool for the job. If grid lets you express what you want in the most straightforward way, use it; if flex…

The article is largely about layout shifts caused by flexbox during loading, and while networks have indeed gotten faster, they haven’t gotten faster uniformly across situations and people. Being able to show things properly while they are still downloading remains useful.

Re: Incomplete list of mistakes in the design of CSS

#88

Post by semolino »

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"

This is what Cascade Layers was designed to solve:

https://developer.mozilla.org/en-US/docs/Learn_web_developme...

A lingering bit of weirdness is that all !important declarations, no matter the layer they appear on, are interpreted as being part of their own implicit layer.

Re: Incomplete list of mistakes in the design of CSS

#89

Post by Timwi »

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 is true, but my feeling is that with CSS, a lot of the weird decisions are for backwards compatibility with way back when HTML was just tag soup and browser implementations were haphazard.

Re: Incomplete list of mistakes in the design of CSS

#90

Post by wongarsu »

lucideer wrote: post #73
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 tabl…

Tables as a layout primitive are fine. Lots of modern layout engines are based around vstacks and hstacks, which are just single table rows and columns. Most paper forms use a 2d table layout, and newspapers arrange their articles in a 2d table layout.

There were some reasonable concerns. Using tables for both layout and literal tables removes semantic meaning, nested tables can get complicated to layout, and layout the whole page as a giant table makes it difficult to adapt to screen size. But the first could easily be solved by adding a tag that works exactly like table but is for layout, the other two are about overuse of tables in the absence of viable options. We could have easily kept table layouts for the parts where it makes sense and augmented it with something css-like for the parts where it doesn't.

Post reply on HN