Hacker News Reader

Comment by ianstormtaylor | Hacker News Reader

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.

View on HN

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

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

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.

+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!

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.

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;

  padding-top: 0;

  padding: 0;

Just settle on one (the first one in my opinion for this rule) and get rid of all the other alternatives.

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.

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.

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

That doesn't matter, you had it right the first time and there is a still a reason and a need for being able to specify single elements of a property. Say, you set a specific font size and font family for the body, but want some element to have a slightly smaller font size... having to explicitly repeat all the stuff would make CSS unworkable. (look up the "font" short hand, there is quite a lot in there, and that's just one of so many, e.g. backgrounds and background images)

I'm referring specifically to padding; whether reduction of options is appropriate in other cases I didn't address. The balance if brevity, specificity, and distinct function (e.g., inheritance) is not the same for each of the cases where CSS has multiple forms with overlapping function.

How about if you want to override just one part?

It doesn't make much sense with "padding", but for something like "border: red solid 2px;", how do you override just the color if you don't have the individual components broken out?

Good point. I should have qualified what I wrote previously by saying some CSS properties (like padding) could be simplified with just one way of writing the syntax. I say simplified (but not necessarily shortened) because it means you no longer need to explain that property x can be written this way. Or it can be written that way. Or it can also be written yet another way.

It's not about inheritance, it's about specificity. If you have a generic module that specifies

  padding: 5px;

And you actually the bottom of your element to have more padding, you need to be able to do adjust the bottom padding independently

  padding-bottom: 10px;

Otherwise, you'd be required to tightly couple your our padding requirements with the defaults of the original module

  padding: 5px 5px 10px 5px;

CSS requires you to do that in plenty of other places (e.g. if you make your border 1px wider you have to make the element it's on 2px narrower.)

If you set box-sizing: border-box [1], you don't need to worry about the latter.

If only that worked on all the browsers I was required to support...

Even without border box you can achieve that quite easily (since the conceptual border-box 100% is the default for blocks); you simply need more wrapper elements.

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

Reply on news.ycombinator.com