I've learned never to add rules to the asterisk ever, after being badly burned on other projects multiple times.
At first glance, this rule appears more innocuous than others I've seen, because position is never inherited. (Unlike a font-size in a plug-in that broke every inherited font-size on the whole site).
But extra position:relative declarations can cause big problems on mobile browsers (including iOS6) when combined with CSS transitions. Don't ask me why, just browser bugs. I'd be extremely wary of any kind of global layout-fixes like this.
I can't find any information about `position:relative` impacting page render performance. Please share.
Given my experience of low impact on render performance of vanilla properties like this (transitions are a whole 'nother story), I'm much more concerned with whether this is of benefit to developer happiness.
You'll never be able to use `position:absolute` for anything outside of the context of an element's parent, and opting out of this back to default behavior is much more painful than opting in with a better-scoped `.feature * {position:relative}`.
Every new developer will need to wrap their head around nonstandard page flow, and customizations like this have a way of accumulating into a very intimidating environment. As a general rule, I don't want to inherit anything silent and clever without very compelling reasons (* {box-sizing:border-box} passes this test because it makes so many things so much easier).
You'll never be able to use `position:absolute` for anything outside of the context of an element's parent.
While true, I find that the instances that I need something to be absolutely positioned outside of it's context are few and far between. Also, it is quite easy to set position static on the parent elements.
Every new developer will need to wrap their head around nonstandard page flow
I work with a team that is on board with this, so it hasn't been an issue yet.
position:relative is probably not that expensive, but the '*' causes very negative impact - the browser will scan the whole tree trying to match the rules every time the DOM changes.
The '*' selector shoots up the chart, and for some reason the browser lays down a lot more rules then when it's absent. 2ms is not much, but when complexity increases it all adds up (games, client-side apps, etc).
I've read that, his argument is that "it's negligible", not that it doesn't have an impact. In his anedoctal evidence link it's adding 15-30ms to render times.
Add a couple * selectors - one in the reset, one more in your base sheet - plus a couple descendant * selectors, global box-sizing/position rules and you've put a heavy saddle on the matching and rendering engine. It might not matter for 80% of websites, but you need to be aware of it.
Refer to my GitHub repo for the code for my base structure for new projects.
https://github.com/garand/base