Ratchet Performance

[fat]

we're using [foo*='bar'] quite a bit, and these selectors are really expensive. (they're actually the most expensive selector you can run)

Also, CSS evals from right to left (you probably know that) – so doing things like this doesn't actually scope the selector (perf wise makes them even more expensive):

.list [class*="button"]

The above is still running a universal selector * on the entire dom, then checking all attributes for class, then running an expensive regex on each class attr. Then, after it's done that, it checks the dom for list elements, and see's if any of the initial matched elements have a list parent.

I only bring this up because in the sample app i'm building rendering (on the phone) seems a little jank. Also (even without js) the scroll is horrible (though that may be unrelated).

At anyrate, i think we should talk a look at css perf and see if there is anything we can do to improve it.

Also, I remember connor pointing out the other night that the slide.js perf on his phone was a little jank – which is something we should look at in the js.

[dhg]

Word. Was doing it to avoid the double classing of all buttons. <a class="button button-primary"> in favor of just <a class="button-primary">. I thought it was a clever way to minimize markup and CSS bloat. Didn't think CSS performance at the scale we're using it would be an issue at all.

Maybe I'll cut a branch and do a quick and dirty rewrite to see if it helps scrolling issue. If we're talking about the test CSS page though, there is quite a bit of "stuff" on that page. Either way, I'll investigate.

[dhg]

Determined this was not the reason for scrolling issues, but still going to test to see if we can get a performance uptick by removing these universal selectors.

[dhg]

After deliberation, going to punt on this for now. Eventually we should do some performance testing, but for now I'm not seeing any issues and despite selector inefficiency and the benefits of the succinct HTML/CSS is rad.