CSS hack: Predictable block elements | Hacker News Reader

CSS hack: Predictable block elements

coderwall.com

39 pointsbitsweet20 comments

Funny thing is that this is how "classic" IE (<=6?) used to calculate things. I personally always found it to be the more sensible way. Not sure why the standards body decided to do the opposite, and then only implement border-box as an afterthought.

(IE 5.5 and older.)

> Not sure why the standards body decided to do the opposite

I've always assumed that they were going by how designers/publishers/typographers traditionally measure things - the "the way it is done" rather than necessarily "the way that is right".

Personally I feel that only counting the content area is right (it sits right in my head), but it is sometimes less convenient in reality because of other limitations of the document and styling models (for example because sometimes know the dimensions of the outer parts as they are inherited from elsewhere). Having the option gives us the best of both worlds, assuming it doesn't get implemented oddly and cause further browser incompatibility issues.

The problem is that there is no "right way", there is only "useful way". Sometimes, you need to specify the width of the content, other times, you need to specify the width of the box so that it fits with the other boxes. Personally, the way I would implement it, is have two css properties, content-width and box-width, that could not be set at the same time.

Paul Irish posted a good article on the ins and outs of using it on every element. If it's good enough for him...

"Border box ftw": http://paulirish.com/2012/box-sizing-border-box-ftw/

This is the original source of the * approach to box-sizing. The OP is a ripoff.

My biggest gripe with Coderwall is that without comments, there's a lot of stolen content in addition to no way to correct someone when they're off about something or give them a better suggestion.

Coderwall does give you links to contact the author if you'd like to suggest something. His Twitter handle is on his profile page.

Correcting someone on Twitter draws a lot more attention to the conversation than necessary and, in my experience, people react more defensively because of it. I also don't think it makes for very good UX to have to go to an entirely different site to ask questions or get refined answers to posts, especially when those conversations are relevant to everyone else who reads it.

Title is a bit misleading, it's a valid CSS property, not a hack. And the width of block elements has always been predictable, albeit slightly confusing (width + padding + border = element width, etc.)

Polyfill for supporting IE < 8: https://github.com/Schepp/box-sizing-polyfill

Tempting, but may be a bad idea. Within hours of applying this to my personal site I got emails that the layout was broken, from people using older browsers.

> "box-sizing" has been supported in IE since version 8. Other browsers still require a vendor prefix

Interesting. The Safari documentation still lists the vendor prefix version, but the browser itself supports "box-sizing" directly, as does Chrome.

Life would be so much easier if instead of "width" we had "content-width" and "total-width", wouldn't it? (conflicts would have to be resolved one way or another, though)

Sounds reasonable, but are there any downsides to consider before adopting...

   * { box-sizing: border-box; }

everywhere...?

Not according to Paul Irish: http://paulirish.com/2012/box-sizing-border-box-ftw/

The biggest downside is that its only supported in IE8+

If you use it sparsingly, like on specific div's only - and you can do that, because box-model:border-box only _really_ matters and is _really-really_ good when dealing with percentage widths, you can fix it with 'behaviour' and css calculations. Done that.

1. The * selector is slow

2. No IE < 8 support

Apparently it is not the case that the * selector is slow, see Paul's article.

>> You might get up in arms about the universal * selector. Apparently you've heard its slow. Firstly, it's not. It is as fast as h1 as a selector

It means that a 300px wide image won't fit inside a 300px wide box any more.

You need to decide whether your sizing for each element depends on your layout or your content, and choose accordingly. If one way is more useful to you nearly all of the time, then use it that way.

However, also be aware that the star rule is the least performant rule in CSS (http://stackoverflow.com/questions/1714096/why-is-the-css-st...).

We use it for the Chartbeat dashboard (demo here: http://chartbeat.com/demo/) and it's been delightful, but we also made the decision while we were already doing a redesign. This meant we weren't just adding another rule to the page which would change everything; we wrote new CSS with this concept in mind.

Reply on news.ycombinator.com