Archives

Categories

Meta

Tag: CSS

When you see two CSS selectors can you always say which one has a higher specificity? For example, which of the following selectors would overrule the other?

div.products li > *[data-name="test"] a

:first-child .selected:hover

I don’t always know with some of the more complicated selectors, so I made a little web app to figure it out for me: specificity.keegan.st

The app uses regular expressions to find the parts of the selector which contribute to specificity. It highlights each part with a background colour to help you learn the specificity rules. The core part of the app is a JavaScript module I wrote which is available through npm via:

I just found a great feature of Sass / Compass for automatically generating data URIs: the inline data helper.

In my current project we’re using sprites for most of our icon images, but in some cases sprites didn’t work because the element was larger than the icon and other icons were showing through. In these cases we were using standard background images instead of sprites, but this meant we had an extra HTTP request and the hover images weren’t being preloaded.

Most code editing software has a Find in Files tool, where you can search through all of the files in your project for a string or regular expression. But that isn’t much help if you want to find the files which contain HTML elements matching a CSS selector. That’s why I have built Element Finder.

Element Finder searches through your project for any given CSS selector, for example `.layout-fluid #sidebar`, and provides a list of the files which contain elements matching that selector. In this example that would be any element with an ID of `sidebar` which is a descendant of an element with a class of `layout-fluid`.

This is useful for front-end developers because sometimes when we have to modify a CSS rule, it is not clear if the change will have implications on other pages. This is particularly the case for large projects involving multiple front-end developers.

It is easy to use Element Finder from the command line. First you need to `cd` into the directory you would like to search. Then run `elfinder` and pass in the selector you would like to search for as the `-s` argument.

When you press `Enter`, Element Finder will run and display the results:

Element Finder ignores `.git` and `.svn` files by default. You can ignore other files too with the `-i` argument. If you wanted to search all files except for files in the `partials` folder, you would run:

elfinder -s ".layout-fluid #sidebar" -i ".git, .svn, partials"

Element Finder only searches files with an extension of `html` by default. If you would like to search other files, set the `-x` argument. For example:

elfinder -s ".layout-fluid #sidebar" -x "html, shtml, htm"

If you edit in Vim you can call Element Finder directly from your code editor. Just run:

:!elfinder -s ".layout-fluid #sidebar"

How it works

Element Finder is built with Node JS. JavaScript was designed for interacting with web pages so it is a natural fit for this app. Another benefit is that front-end developers know JavaScript, so it should be easy for other people to fork Element Finder and change it to suit their needs.

Element Finder utilises a number of useful Node JS modules for building command line apps, such as TJ Holowaychuk’s commander.js and node-progress. Elijah Insua’s jsdom module is used to construct a W3C conforming DOM for each HTML file we need to search. Sizzle JS is used to find matches for the search input in the DOM. Sizzle JS is jQuery’s selector engine, which means Element Finder will consistently return the same elements as the jQuery selectors in your JavaScript.

Looking forward

It would be useful to have Element Finder implemented as a plugin in Vim, Sublime Text and other code editors. But in the meantime I hope you will find it useful as a command line app. Technically the app should work in Mac, Windows and Linux, but so far I have only tested it on a Mac. For installation instructions, visit Element Finder on GitHub.