Are there any indicators that can reliably indicate usage of a CSS preprocessor? If so, what preprocessors are used and which ones? (Could property ordering, presence of hacks/comments, misspellings, prefixes, or source mapping comment be used to identify?)
What are the common values in ::before and ::after pseudo-element content properties?
If you leave out the identifiable CSS libraries, how does that affect the numbers? Do they scale by 10% or do the libraries (Bootstrap primarily) use rules/properties disproportionately enough to scale the other results?
What percent of files are minimized?
What does the histogram of selectors per site look like?
Edit: Also, how frequently do dataURIs show up (probably as background images)?
I thought long and hard about trying to identify preprocessor usage reliably because that is a super interesting piece of data, but nothing stuck out as a smoking gun. Sequentially increasing selectors
tr
tr td
tr td a
could be LESS unrolling a nested bit:
tr {
td {
a {
OR... could just be how people write CSS.
I mostly ignored by-domain grouping in my queries, but there is a host of analysis you could do that would get into the modeling portion of data science, teasing our correlation and trying to find 'groups' or styles' of CSS that is written on a site. I had only so much time ;-)
I also did a web perf report that is not fully edited or ready for consumption, but does not that 54% of sites I ran Google Page Speed Insights against didn't compress all of their CSS assets. (Same sample of domains)
What sort of method would be used to cluster those, statistically speaking? Like, given a data set like that, how would you determine if the distribution is multi-modal or unimodal?
Mean shift clustering, for one. This short PDF provides better insight than wikipedia. Does NOT require you to specify the number of clusters like in K-means:
Surely the idea of a one-off crowd sourced mini incubator is at least a little interesting to someone who writes|plans|sells software.
Immediate reactions from me include "Should my company get on board with something like this?", "I wonder what the equity split is like", "Could there be a platform for voting up ideas to work on based on customer validation?", "Should I build that platform to bubble up ideas with a verifiable userbase?"
I use it outside of a Rails project when I don't have the asset pipeline available in my tool chain. It gives me the scalpel to define exactly what happens to my code and files vs. a one-size-fits-all option like LiveReload or Brunch where I need to match a specific filesystem layout.
Should be noted that paths in brunch aren't set in stone. app/ gets some special treatment is all. For instance our current project has app.js, vendor.js, test.js, test-vendor.js, admin.js, admin-vendor.js
I think it's important to note that if this code never grows or changes, then this refactor is totally unnecessary. It DOES add code, and it DOES almost over-decompose the structure.
The payoff, however, is if more features or behaviors were in the pipeline (and when aren't they?). This really sets you up to gracefully manage more complexity by having sensical places to put more code, instead of writing a few more $(document).ready callbacks to ship something on time.
Backbone.js might not be the right tool for the contrived example, but I've come to expect a sacrifice of real-world applicability for smaller, digestible chunks. That the synthesis is up to you is ok, I think.
This is the main issue with trying to catalogue event handlers. Backbone.js, and savvy jQuery developers won't use bind for any sort of dynamic pages, because it's too hard to track handlers and make sure they're rebound properly as the DOM updates. The best solution is to use .on, which generally (argument specific) will set up a listener on a PARENT element of the selector you've put in.
.live() .delegate() and (usually) .on() will leave the handler on a parent node, making sniffing out all active handlers an expensive DOM-walking task.
Yes, but there is still a node that has an event listener on, and it is quite possible to display that in developer tools. Opera Dragonfly already does this, for example. What's not possible is for the browser to know that the event handler on element A only has any effect if the event occurs on descendant elements B and C, for example.
Given this limitation, the only problem with displaying event handlers is that developers who don't understand the underlying event model of the platform might not grasp the correspondence between the high-level abstractions in their library-using code and the low level DOM behaviour. Clearly any such developers will become more effective once they know a little more about the platform they are working on.
Vim can run in "compatible" mode (Vi-like settings) or "nocompatible" mode (Vim-like settings).
:set nocompatible
is used to switch Vim from "compatible" mode to "nocompatible" mode.
A lot of people put it at the top of their .vimrc, usually together with a comment telling that it's needed for many options and features to work correctly.
But Vim actually switches itself to "nocompatible" mode if it finds a vimrc. It can be the default vimrc in /usr/share/vim/vim7x/ or your own .vimrc, it doesn't matter.
You can test this by removing this line from your .vimrc, launching another Vim instance and doing :set compatible? With or without that line, you'll get nocompatible.
Having this line in your .vimrc essentially does nothing: it sets something "on" that was already "on". As such it's useless cruft but it is not dangerous.
The real problem with it is that it demonstrates a dangerous cargo cult trend among Vim users who copy/paste entire vimrcs from Github or top ranking blog posts without thinking about it for a second. Because this line and the comment appeared in a rather famous blog post(1) by a rather famous vimmer it's now just… everywhere.
I have a lot of respect for Steve Losh and I absolutely don't blame him for including this line in his post: it's useless but harmless so there's no big deal. I certainly have a lot of useless redundant stuff in my .vimrc, too. And I'm totally guilty of using his whole .vimrc verbatim when I started.
But all the people who copied this line from him or from others who copied it from others who copied it from him (who probably copied it from someone else, why not?) should show a little less lazyness, I believe. And a more critical mind.
Hmm, maybe I'll get around to looking at his vimrc and seeing what proportion of the settings are in the scraped files. I bet I could further validate your cargo-cult hypothesis.
