5 ms·

You should distinguish between whether the syntax and general principles of the language are horribly designed or whether the current language features are lack

You should distinguish between whether the syntax and general principles of the language are horribly designed or whether the current language features are lacking. They're very different critiques. The former results in people saying we need to completely scrap CSS and find a new way to layout pages. The latter results in people putting more pressure on and getting more involved in the CSS working groups and browser implementations to get new features pushed to consumers.

crazygringo 13y ago
Well, there's nothing inherently wrong with the syntax or structure of CSS (and things like LESS make it even nicer). I'm talking about things like the way "floats" transformed from a way of wrapping text around pictures (good) to a general-purpose layout mechanism (disaster). About how there's no way to put a footer at the bottom of your page that stays at the bottom if your content is short, but gets pushed down if your content is long (the normal desired use case). About how the only way to get two columns of equal height, but that expand to fit the text, is to use a <table>, but that this is supposedly disallowed because it's "unsemantic". About the complete disaster that float-clearing is, yet how it's central to almost all modern CSS layouts, and fixed only by bizarre byzantine hacks like "clearfix", overflow:hidden (which breaks other things), or the classic "<div style="clear:both;"></div>" which needs to be peppered throughout HTML, negating the whole supposed distinction between HTML and CSS. And finally, the fact that the width of an element doesn't include its border and padding, making for nesting div's that include border and padding much more difficult than it should be. (Although this is, of course, fixed in newer versions of CSS.) In the end, it's not really "current language features", but mainly the disastrous decision to adopt floats as a basic layout concept, instead of grids/columns/etc. (Which is, of course, why so many people wind up using <table> in the end, which has its own problems...)
- joshuacc 13y ago
  "About how the only way to get two columns of equal height, but that expand to fit the text, is to use a <table>, but that this is supposedly disallowed because it's "unsemantic"." This is incorrect. Using display: table and display: table-cell allows you to achieve equal height columns.
  - barrkel 13y ago
    Well yes, if you make a div work like a table and a nested div work like a table cell, you can indeed technically get away without using tables and cells, but you're fooling nobody.
    - jonahx 13y ago
      +1. In what world, other than the current one fraught with our bizarre legacy, would you link the concept of vertical centering with the concept of "tables" and "cells"? How about: "display:non-idiotic-mode" and "display:layout-support-any-sane-person-would-expect", and now you can use "vertical-align"? A bit verbose but more accurate!
    - unclebucknasty 13y ago
      Tables (or grids) are a very natural way of thinking about layout. Just about every webapp/site uses some sort of grid scheme as its layout model. This is probably why the woefully layout-inadequate CSS had to include these hacks to mimic table behavior. So, it's more like CSS is fooling nobody.
- chestnut-tree 13y ago
  I actually wish that CSS didn't have so many different ways to write a rule. Have just one way to write a rule and enforce it strictly. In other words, instead of being able to write any of these padding: 0 0 0 0; OR padding-top: 0; OR padding: 0; Just settle on one (the first one in my opinion for this rule) and get rid of all the other alternatives.
  - dragonwriter 13y ago
    The first one (and the third one, which is closely related) doesn't provide any mechanism to override a single of the padding settings while inheriting the rest. If you could only have one mechanism, and you weren't going to lose significant functionality, it would have to be the longhand padding-top, padding-bottom, etc., set. But I think having the shorthand rule is worthwhile.
    - chestnut-tree 13y ago
      I didn't think padding was inherited? The reason I chose the first example over the second is that, if you only ever specify padding-bottom for example, what are the default values for the other unspecified padding properties? This is why we have the CSS reset technique and normalize.css (more hackery). I would make it mandatory that you declare all four values for the padding rule to remove any ambiguity. That would also mean eliminating shortcuts like padding: 5px 10px 15px; padding: 5px 10px; I think having shorthand rules just adds to the ambiguity and complexity of CSS, because, as you rightly point out, each of the variations has a subtly different meaning from each other. This is not a good thing (in my opinion :-) especially when you consider how lengthy and complicated stylesheets are nowadays for many websites.
      - dragonwriter 13y ago
        > I didn't think padding was inherited? I forgot that padding required explicit "inherit". So, bottom line, yes, it would seem to make sense to just have the single-line complete version: padding: *w* *x* *y* *z*
- ianstormtaylor 13y ago
  No one ever really decided that floats were the way to layout columns as far as I know. It's completely about "current language features". The standards group was just too slow to implement a decent alternative so we had to use floats. But flexbox[1] is the solution to lots of the problems you are mentioning, and it's almost support in all modern browsers, so very soon we can start abandoning floats and absolute positioning in our layouts. Meanwhile, CSS is still a well-designed language in terms of syntax and principles. We just need a few more features that weren't in the original spec as new uses for the web emerge. [1]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...

crazygringo 13y ago

Well, there's nothing inherently wrong with the syntax or structure of CSS (and things like LESS make it even nicer). I'm talking about things like the way "floats" transformed from a way of wrapping text around pictures (good) to a general-purpose layout mechanism (disaster). About how there's no way to put a footer at the bottom of your page that stays at the bottom if your content is short, but gets pushed down if your content is long (the normal desired use case). About how the only way to get two columns of equal height, but that expand to fit the text, is to use a <table>, but that this is supposedly disallowed because it's "unsemantic". About the complete disaster that float-clearing is, yet how it's central to almost all modern CSS layouts, and fixed only by bizarre byzantine hacks like "clearfix", overflow:hidden (which breaks other things), or the classic "<div style="clear:both;"></div>" which needs to be peppered throughout HTML, negating the whole supposed distinction between HTML and CSS. And finally, the fact that the width of an element doesn't include its border and padding, making for nesting div's that include border and padding much more difficult than it should be. (Although this is, of course, fixed in newer versions of CSS.) In the end, it's not really "current language features", but mainly the disastrous decision to adopt floats as a basic layout concept, instead of grids/columns/etc. (Which is, of course, why so many people wind up using <table> in the end, which has its own problems...)

joshuacc 13y ago
"About how the only way to get two columns of equal height, but that expand to fit the text, is to use a <table>, but that this is supposedly disallowed because it's "unsemantic"." This is incorrect. Using display: table and display: table-cell allows you to achieve equal height columns.
- barrkel 13y ago
  Well yes, if you make a div work like a table and a nested div work like a table cell, you can indeed technically get away without using tables and cells, but you're fooling nobody.
  - jonahx 13y ago
    +1. In what world, other than the current one fraught with our bizarre legacy, would you link the concept of vertical centering with the concept of "tables" and "cells"? How about: "display:non-idiotic-mode" and "display:layout-support-any-sane-person-would-expect", and now you can use "vertical-align"? A bit verbose but more accurate!
  - unclebucknasty 13y ago
    Tables (or grids) are a very natural way of thinking about layout. Just about every webapp/site uses some sort of grid scheme as its layout model. This is probably why the woefully layout-inadequate CSS had to include these hacks to mimic table behavior. So, it's more like CSS is fooling nobody.
chestnut-tree 13y ago
I actually wish that CSS didn't have so many different ways to write a rule. Have just one way to write a rule and enforce it strictly. In other words, instead of being able to write any of these padding: 0 0 0 0; OR padding-top: 0; OR padding: 0; Just settle on one (the first one in my opinion for this rule) and get rid of all the other alternatives.
- dragonwriter 13y ago
  The first one (and the third one, which is closely related) doesn't provide any mechanism to override a single of the padding settings while inheriting the rest. If you could only have one mechanism, and you weren't going to lose significant functionality, it would have to be the longhand padding-top, padding-bottom, etc., set. But I think having the shorthand rule is worthwhile.
  - chestnut-tree 13y ago
    I didn't think padding was inherited? The reason I chose the first example over the second is that, if you only ever specify padding-bottom for example, what are the default values for the other unspecified padding properties? This is why we have the CSS reset technique and normalize.css (more hackery). I would make it mandatory that you declare all four values for the padding rule to remove any ambiguity. That would also mean eliminating shortcuts like padding: 5px 10px 15px; padding: 5px 10px; I think having shorthand rules just adds to the ambiguity and complexity of CSS, because, as you rightly point out, each of the variations has a subtly different meaning from each other. This is not a good thing (in my opinion :-) especially when you consider how lengthy and complicated stylesheets are nowadays for many websites.
    - dragonwriter 13y ago
      > I didn't think padding was inherited? I forgot that padding required explicit "inherit". So, bottom line, yes, it would seem to make sense to just have the single-line complete version: padding: *w* *x* *y* *z*
ianstormtaylor 13y ago
No one ever really decided that floats were the way to layout columns as far as I know. It's completely about "current language features". The standards group was just too slow to implement a decent alternative so we had to use floats. But flexbox[1] is the solution to lots of the problems you are mentioning, and it's almost support in all modern browsers, so very soon we can start abandoning floats and absolute positioning in our layouts. Meanwhile, CSS is still a well-designed language in terms of syntax and principles. We just need a few more features that weren't in the original spec as new uses for the web emerge. [1]: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexi...