Hacker News Reader

Comment by chestnut-tree | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com