Live data from Hacker News

Incomplete list of mistakes in the design of CSS

wiki.csswg.org

51–60 of 132 posts

Re: Incomplete list of mistakes in the design of CSS

#51
post #9

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

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.

Re: Incomplete list of mistakes in the design of CSS

#52
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

https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_...

Re: Incomplete list of mistakes in the design of CSS

#53
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

I'm guessing they mean that comments shouldn't be allowed everywhere, not that they shouldn't be allowed at all? i.e. CSS lets you put comments in many more places than HTML, in such a way that it's hard to practically impossible to represent in an AST? At least that's how I read it

Re: Incomplete list of mistakes in the design of CSS

#54
> The display property should be called display-type.

More importantly to me, "display" has been overloaded with two meanings: Display of the element this rule applies to/how it interacts with surrounding elements (none, block, inline, inline-block) and display of the contents of this element (flex, grid).

Which is why we now also have inline-flex and inline-grid.

Edit: Apparently we can now arbitrarily combine inline/block and flex/grid as two values to "display", no idea when this happened: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...

Re: Incomplete list of mistakes in the design of CSS

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

Re: Incomplete list of mistakes in the design of CSS

#56
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

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 on the parsed version will lose the comments. 2. Dedicate a disproportionate amount of complexity to retaining the comments, and still not really have a good way to handle them through edits/transformations.

Re: Incomplete list of mistakes in the design of CSS

#57
- Making elements somewhat act like they are not there should not have been display:none as as display: has other purposes.

- Values for properties with just two valid values available should have been true and false rather than having one more unique word combo to remember forEach.

- I cant quite describe them but float at times has some weird unexpected behavior.

https://stackoverflow.com/questions/23154201/weird-behaviors...

Re: Incomplete list of mistakes in the design of CSS

#58
post #46

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…

Try resizing a browser window with nested a flex layout.

Re: Incomplete list of mistakes in the design of CSS

#59
post #46

Earlier quoted context omitted.

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…

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.

Re: Incomplete list of mistakes in the design of CSS

#60

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

sidenote: as a teen, i would regularly layout posters and presentations in excel.. the page preview dashed-border and the grid stability was such a relief compared to word

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 details became visible (littering), when smaller important details were lost (a formation of birds over a fishing vessel).

Post reply on HN