Wouldn't it be better to use this in the CSS:
*, *:before, *:after { -webkit-box-sizing:border-box; -moz-box-sizing:border-box; box-sizing:border-box; }
It would save alot more space.
Dangerous stuff, that generic selector.
Plus not compatible with oldIE. Means still having to write hacks for it.
Overall it's not much of a poblem. Either way.
who cares about old IE? and what makes it "dangerous"?
What makes it dangerous is that applying it blindly to all divs will break the jQuery menus, just as one example. Believe me, we tried it. The more verbose way ended up being safer.
Also, the generic selector is the slowest possible one, so generally not a good idea to use it unless it's really essenetial for some reason. Since the CSS files all get mashed together and minified and gzipped before being sent to the browser, a few extra lines of CSS aren't a big deal.
I've seen that comment about it breaking the menu in the source code when I was doing my fork. I tried it and had no problems with it, or I fixed, I can't quite remember. If using box-sizing:border-box breaks the menu, then something is wrong with the menu.
As far as the universal selector being slow, that's because your hitting every element, which your doing anyway by with your current method. The talk of generic selectors in CSS being slow is something that runs back to the IE6 days, which is no longer an issue. Please read: http://www.kendoui.com/blogs/teamblog/posts/12-09-28/css_tip_star_selector_not_that_bad.aspx
Actually, * alone is very fast. Just don't use it as a child to something else.
I've done some tests in Wedge and it seems to work well. Only select boxes are broken, but that can be arranged. I'm considering using this hack then. But it also requires ensuring that images have no borders. ;) (or using padding-box, but it's Firefox-only, I'm afraid.)
I am already using it on Protendo - and have no problems with etiher css, speed or js(Mootools)
If the JQuery menu breaks from it - fix that menu instead.
Sure. From memory, what happened is that the hide/show shiz in Superfish was somehow throwing in an extra div in the drop menus on the fly. Border-box being applied to that borked the menu. Since said div was hidden in the js somewhere (in either Superfish or jQuery) the easiest way out was to simply not mass target all divs. Most of them don't need it anyway.
Nope. The current method doesn't hit
every element at all. Only the ones that need it.
Elk aint using MooTools, so not relevant. ;)
Go for it. :)
Oh, I see that Bloc removed his account from ElkArte as well, it's not just me... I'd check at SMF as well, but I don't want to go there™ these days.
Anyway, just wanted to say that I tried this 'technique' as mentioned above, but ultimately I decided against it, because it caused a lot of trouble, and yes, I was able to fix it every time, but then something else would come, and... I've only got so many hours to devote to this tweak, right..? So I reverted my changes, but remain hopeful for a better future.
It's definitely something that should be in a any 'bootstrap' project, but grafted onto an existing large project? Good luck, I guess.
Out of curiosity: what does this box-sizing thing that is so important to be applied to any element of the page? (Yeah I know I should search, but since
@Xarcell suggested I assume he knows better and can give me a hint faster! :D)
Qick example; two boxes with width: 50% and a border of 1px would be more than 100% and ruin your layout.
with box-sizing: border-box; the border is part of that 50%, without border-box it's added to that 50%;
Ohhh... make sense!
Thanks! ;D
That pretty much sums it up. Box-border keeps the parent's width accurate as long as margin isn't used. When you doing responsive design, a simple border of 1px would make your parent element (50% +2px).
There are two ways to fix this. Add box-border to the element, which includes any padding & border sizes into the width(instead of calculated outside the width = adding to it), or use "width: -calc(50% - 2px)". Because of the lack of -calc support in browsers, box-border is perferred. Also, you can apply it to all elements, and avoid massive amounts of -calc(+vendor prefixes) in your stylesheet. I recommend only using -calc when you have used margins, because box-border doesn't protect your width from that. That is also one of the biggest reasons to use wrappers. The amount of extra HTML versus extra CSS code, the HTML wrapper wins. IMO
EDIT: I also want to point out something. IMO, I think that using box-border all on elements, will tell you right away which parent/child elements will cause problems later on down the road in terms of layout control. Especially when it comes to responsive design. I know when I did my fork, admin & profile areas had some serious issues.
Thanks a lot for the explanation :)
There's also a setting (padding-box) that calculates 100% as content + padding instead of content + padding + border, but its use case is limited, just as is browser support.
Always surprised there's nothing for margin-box, though... :P