One of the tools I mentioned during the talk, the $20USD Xyle scope CSS debugger and analysis tool, is something I’ve been using and recommending since shortly after its release. I think it’s high time I got around to writing up why exactly I think it’s so great.
First and foremost, Xyle scope is not all things to every one. You can get very similar results from tools like the Firefox Web Developer’s Toolbar and a future version of Safari. But I’ll leave someone else to write those ones up.
What I like about Xyle scope is the richness of information it provides about a page’s DOM and CSS, and how easy it is to get to that information. A typical scenario that’s becoming far more common for me is that I come back into a site I last worked on a few months ago, and can’t remember the specific
class values I’ve used, or how specific my selectors ended up being, or increasingly, which files contain which style.
Here’s an example of what I mean. On the front page of this site, there’s a listing of the 5 most recent posts. If I needed to get back into the CSS at some point and start changing the formatting of the dates within that list, traditionally I’d have had to refresh my memory by determining a few things:
- What sort of HTML element the dates are contained in, and whether it has a class or id
- Parent elements, and their respective id/classes
- Which rules in the CSS apply to that element directly
- Which rules in the CSS that element inherits from parents
- The specificity of any of the CSS rules
- Which CSS files the appropriate rules exist within
Any time I need to make an edit to a page, I need to go through that list and figure out all the relevant information about the element in question. Though I only have a single file on this site, these days I favour breaking up a larger site’s CSS into multiple files. This compounds the management problem, since it makes it a bit more difficult to narrow down on the exact rules I need. But that’s only part of the problem, the rest is the mental overhead required to work out myself how the specificity breaks down, and which rules I actually want to edit in order to affect my change.
What I’m getting at is that the mental energy exerted to figure out all of this is something that can and should be done by software. There’s no reason why I shouldn’t be able to just point and click on the element and have all of that information shown to me automatically. Enter Xyle scope.
I load up my page in the built-in browser, and then switch from browse mode to selection mode. The browser is simply Apple’s WebKit engine (the same one as in Safari), and browse mode allows you to navigate a page, whereas selection mode allows you to click on any element and get detailed information about it:
The prevous screenshot gives you an idea of what all that click can tell you. Up in the top right (panel a), there’s a DOM drill-down that shows you the entire hierarchy up to the element you’ve clicked on. It’s informational, but it also acts as a DOM browser: if you need to, you can click on adjacent or parent elements and work your way back up or down the hierarchy (and the rest of the information, as well as the selection within the browser pane on the left, will update accordingly).
Down below the DOM browser (panel b), there’s a markup synopsis that outlines what the HTML elements, classes, and ids are for the element (and its various children, where applicable).
Then down at the bottom right, there’s a split-panel style rule browser. The more comprehensive listing includes selectors and fullrules on the left (panel c), and the summary on the right (panel d) is kind of a navigation for the left that includes just the selectors. The information in the left panel is extremely useful, and gives me exactly what I outlined above.
What we’re looking at in panel c is a summary of the cascade, followed by a listing of all the style rules that could potentially apply to the date in that home page listing I picked as my example. You’ll notice some properties are greyed out; these are properties that don’t actually make up the final styling of the element, since they’re being overridden in other, more specific rules. At a glance I can tell exactly which selectors are applying which properties, obviating the need to sift through multiple selectors and calculating specificity manually.
As well, you’ll notice the word ‘wintermint’ sitting beside each selector in this panel; this is the name of the CSS file that the selector resides in. As I have one single CSS file for the site, it’s not so useful in this instance. But when armed with a tool that clarifies to this level exactly which rules I should be looking at, you can see how that naturally eases any fear of maintaining multiple CSS files. Managing them is a snap with a tool like this.
I don’t just use Xyle scope for debugging; I use it for any sort of editing or CSS creation that involves thinking carefully about specificity issues. It has cut down on the time I spend fooling around in a CSS file trying to figure out exactly where to make my change, and its mastery of specificity has actually impacted the quality of my overall CSS for the better. I can write tighter, more precise style rules without the worry that I won’t be able to make sense of them later. And though other software offers similar results, as I mentioned at the top, I currently prefer Xyle scope’s ease of use and stand-alone nature over built-in browser tools.
No, there’s no Windows version at the moment, but Mac minis are cheap like bubble gum these days. You’ve already got a Mac for testing anyway, right? (And nope, I’m not getting paid for this posting or recommending the software, I’m simply an enthusiastic user.)