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

121–130 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#121

Post by IshKebab »

matt_kantor wrote: post #119
IshKebab wrote: post #118

Earlier quoted context omitted.

Yes, anywhere in the node tree. Imagine if CSS was specified in HTML-style. We might write this selector: h1, /* don't forget h2! */ h2 { color: /* I love red */ "red"; } Like this: h1 h2 red Which is pretty much exactly the same as what you'd get as a CST from parsing the CSS.

Problem is, the CSSOM models that more like this: Perhaps your takeaway from this is "the CSSOM is bad" (and I don't necessarily disagree), but it's what the "mistake" is talking about.

I wouldn't say that, it's more that the CSSOM doesn't try to preserve comments, which is a perfectly reasonable thing to do. I think most uses cases for modifying CSS that care about comments (e.g. auto-formatters?) would need parsers that return the full CST anyway.

Re: Incomplete list of mistakes in the design of CSS

#122

Post by matt_kantor »

IshKebab wrote: post #121
matt_kantor wrote: post #119

Earlier quoted context omitted.

Problem is, the CSSOM models that more like this: Perhaps your takeaway from this is "the CSSOM is bad" (and I don't necessarily disagree), but it's what the "mistake" is talking about.

I wouldn't say that, it's more that the CSSOM doesn't try to preserve comments, which is a perfectly reasonable thing to do. I think most uses cases for modifying CSS that care about comments (e.g. auto-formatters?) would need parsers that return the full CST anyway.

I see. I was under the impression that you were saying the "mistake" from the post was wrong in its premise. But I guess that's incorrect, rather you think that people shouldn't use the CSSOM for use cases when comments matter, and instead they ought to design their own parsers/representations.

Just curious: do you feel the same about HTML? Should HTML allow comments in more places? I can imagine alternate ways to represent an HTML document that could capture comments within attribute lists, etc (and the DOM could exclude them entirely).

Re: Incomplete list of mistakes in the design of CSS

#123

Post by IshKebab »

matt_kantor wrote: post #122
IshKebab wrote: post #121

Earlier quoted context omitted.

I wouldn't say that, it's more that the CSSOM doesn't try to preserve comments, which is a perfectly reasonable thing to do. I think most uses cases for modifying CSS that care about comments (e.g. auto-formatters?) would need parsers that return the full CST anyway.

I see. I was under the impression that you were saying the "mistake" from the post was wrong in its premise. But I guess that's incorrect, rather you think that people shouldn't use the CSSOM for use cases when comments matter, and instead they ought to design their own parsers/representations. Just curious: do you feel the same about HTML? Should HTML allow comments in more places? I can imagine alternate ways to re…

Nah I think HTML comments are fine. I don't think there would be a benefit to allowing comments in more places and it would make it more annoying when you actually do want to process comments.

If CSS had mandated that comments could only appear in certain places (e.g. before a rule or attribute) I think that would have been fine too, though maybe slightly confusing given the resemblance to C-style comments which are allowed almost anywhere.

Re: Incomplete list of mistakes in the design of CSS

#124

Post by matt_kantor »

IshKebab wrote: post #123
matt_kantor wrote: post #122

Earlier quoted context omitted.

I see. I was under the impression that you were saying the "mistake" from the post was wrong in its premise. But I guess that's incorrect, rather you think that people shouldn't use the CSSOM for use cases when comments matter, and instead they ought to design their own parsers/representations. Just curious: do you feel the same about HTML? Should HTML allow comments in more places? I can imagine alternate ways to re…

Nah I think HTML comments are fine. I don't think there would be a benefit to allowing comments in more places and it would make it more annoying when you actually do want to process comments. If CSS had mandated that comments could only appear in certain places (e.g. before a rule or attribute) I think that would have been fine too, though maybe slightly confusing given the resemblance to C-style comments which are…

Seems like we have broadly-similar perspectives, though I do find it a bit incongruent that the DOM preserves comments while the CSSOM doesn't. It feels like they ought to be in alignment one way or the other (though I also understand the historical reasons why they aren't).

Re: Incomplete list of mistakes in the design of CSS

#125

Post by 6510 »

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.

It is not like we have a choice. I forgot to mention that people also have different eye sight which further complicates things. Some set the font so large half the apps fail to fit. Before many people had one I see someone browse using an enormous TV with very high resolution. The google adds sidebar lived on the other side of the room. % size images upscaled into a pizza of artifacts. There wasn't a website that looked the way intended. A funny I ran into once was Lubuntu system dialogs with the accept button below the screen. I've also seen enough print previews where one cant read the text. The use of colors with poor contrast only on some displays.

We are having a lot of fun pretending it is possible.

Re: Incomplete list of mistakes in the design of CSS

#126

Post by RaftPeople »

wongarsu wrote: post #90
lucideer wrote: post #73

Earlier quoted context omitted.

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

> There were some reasonable concerns. Using tables for both layout and literal tables removes semantic meaning

The simple solution:

(or "data")

Re: Incomplete list of mistakes in the design of CSS

#127

Post by cluckindan »

zwnow wrote: post #41
cluckindan wrote: post #22

Earlier quoted context omitted.

Do not use flexbox for page layout. It invites nested flexboxes, which eats your reflow performance. Use grid instead.

Flexbox is great and having nested flexboxes is also great. It makes building responsive pages a bliss. Learn it if you are having trouble with it, it is really not that difficult. Grids are much more error prone and allow for much less flexibility.

The issue with nested flexboxes is that flexbox containers size their content to match the container.

Therefore, to calculate the size of an item, the sizes of other items need to be known. Now, if one of the items is a flexbox, its item sizes cannot be known until the previous flexbox is laid out.

Of course, properly using flex-grow and flex-shrink can optimize that calculation, but what about deeper nested flexboxes?

Re: Incomplete list of mistakes in the design of CSS

#128

Post by Rendello »

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 agree, but it is funny to me that your Hacker News comment is itself a table. It's in the same vein as "don't freak out, but there's a spooky skeleton inside you!"

Re: Incomplete list of mistakes in the design of CSS

#129

Post by Timwi »

hypertele-Xii wrote: post #95
Timwi wrote: post #84

Earlier quoted context omitted.

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.

No, it does not change the zoom behavior.

Re: Incomplete list of mistakes in the design of CSS

#130

Post by the_other »

DonHopkins wrote: post #105
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.

That's very neat. You'd probably need two words to represent camelCase. And then that might be hard to disambiguate from your `CaSE`.
Post reply on HN