Part I – Pre(r)amble

When it comes to browser developer tools, Chrome and Firefox are currently in a sort of friendly arms race; each innovation from one drives new ideas for the other, and vice versa. This can only be a benefit to web developers everywhere.

This speed of innovation is also necessary in the face of the rapid development of new W3C specs for both CSS and JS. There are new CSS modules and JS APIs popping up all the time. Some of these require new thinking about how to interact with them in devtools. Firefox’s new Web Audio API node inspector is a brilliant example of this.

A little while ago, Mozilla started using UserVoice to collect ideas for ways to improve Firefox’s devtools, which spurred me to write this. I’d been thinking for a few months about ways of improving the devtools to cater for certain new(ish) features of CSS. Along the way I realised that there’s a fundamental assumption in most devtools features that should be challenged.

So, rather than continue to have the ideas just rattling around my head and failing to be developed, it’s time to subject them to a mass audience.

Part II – Contextual healing

There are two areas of devtools I use far more than the rest: element inspection and script debugging. While I sometimes have gripes with parts of the debugging section, my focus for this post is on element inspection and the computed styles panels.

In the beginning, there was text, and text was all. On first inspection, it makes sense that CSS rules that were written only in text are displayed only in text. But CSS is text that converts to graphical output. Surely we should be able to display individual CSS rules with graphical output in the “styles” panel as well.

Google’s old mantra of “Content is king” was close to the truth, but in Maxwell Smart style, missed it by that much. My opinion is “Context is key^*” ^*Kings are so old-fashioned these days. Besides, in chess it’s the queens who have all the power.

This ties back to the oft-quoted principle of Bret Victor: “Creators need an immediate connection to what they’re creating.” But for me, “Context is key” isn’t just about creators, it’s a basic part of being human. How many conversations have you had that got confused and garbled because one of the participants didn’t have enough context? Twitter, for example, is like a giant social experiment in how to interpret messages without context.

I used to find out breaking news on twitter, now I have to reverse engineer a bunch of jokes to know what’s happening.

— Chris Hallbeck (@ChrisHallbeck) February 11, 2013

So if we work better with more context in human-to-human interactions, why should we expect any less from our tools?

Thankfully, I’m not alone in thinking this. For example, most browser devtools now show a little preview swatch next to colour values for CSS properties, often with a colour picker attached to it for easy selection of a new value.

Lea Verou upped the game with her work on Dabblet, which added a whole heap of contextual previews when hovering over different types of values. While Dabblet isn’t an in-built browser tool, it still showed a way forward when interacting with CSS code.

The Firefox devtools team also has the ongoing “doorhangers” project. Doorhangers are the little preview popup panels that appear when hovering over colours, image URLs, 2D transforms, etc. What’s been implemented so far is only a small chunk of their big list of plans, which I suggest you go and look at: https://gist.github.com/captainbrosset/6681978.

Let’s also not forget the box model panel – the oldest example of providing a different rendering mode in devtools to better show the context of the properties involved.

The key thing about these examples is that they use vastly different rendered displays for different properties. Each display mode has been tailored for the type of property/value, thus giving far greater context than text alone ever could.

However, while all these examples are encouraging, I still feel like there’s something big that’s missing from the story.

Part III – Plain-bellied reads vs star-bellied writes

Now, the Star-Belly Sneetches
Had bellies with stars.
The Plain-Belly Sneetches
Had none upon thars.

Those stars weren’t so big. They were really so small
You might think such a thing wouldn’t matter at all.

— Dr. Seuss, “The Sneetches”

(“The Sneetches” and all quotes listed here © Dr. Seuss Enterprises.)

When inspecting an element, you are able to view the CSS rules applied to it (the “Styles” or “Rules” panel) and the final computed values that the browser uses for rendering (the “Computed” panel). These are effectively the “write” and “read” modes for an element’s style rules.

In “write” mode you can change any aspect of the element’s style at any level of the cascade (other than user agent stylesheets). This is where the contextual helpers come in to play.

In “read” mode you can see the final values and change nothing. You can see which rules contributed to that value, and some of the little UI helpers might still be there (Firefox still shows the small colour swatch next to colour values), but that’s it.

The read vs write paradigm is inherent in a lot of what devtools do. This includes features such as live CSS file editing; even with live updating previews while typing, it’s still just a write operation – there’s no reading of the final computed value.

It all reminds me of the classic Dr. Seuss story “The Sneetches” (one of my all-time favourites).

But, because they had stars, all the Star-Belly Sneetches
Would brag, “We’re the best kind of Sneetch on the beaches.”
With their snoots in the air, they would sniff and they’d snort
“We’ll have nothing to do with the Plain-Belly sort!”

[…]
They never invited the Plain-Belly Sneetches.
They left them out cold, in the dark of the beaches.
They kept them away. Never let them come near.
And that’s how they treated them year after year.

But wait, what’s this strange interloper we see that dares break down the purely read or write boundaries? The Sylvester McMonkey McBean^* of this particular story is something that’s already been mentioned – the humble box model panel. ^*Let’s ignore for a moment the fact that Sylvester McMonkey McBean was a con-man out to make a quick buck and bankrupt the Sneetches. Also, the fact that “The Sneetches” was an anti-racism allegory does not necessarily indicate that I am suggesting browser devtools are racist… OK, so this is perhaps a bit of a strained metaphor, but shush, I’m sticking with it anyway.

At first glance it just looks like another read-only view. Chrome even combines it with the list of computed styles in the same panel. You can hover over different parts of it and have the relevant parts of the page element also highlighted, but that’s still read-only.

Where it breaks down the read/write divide is that the box model values for margin, padding, etc. can be edited directly. Just by clicking (or double-clicking, depending on the browser) on a computed value in the box model section, you enter an edit mode for that value. The usual controls for increment and decrement work (up/down, shift+up/down, etc.) and you can type new values.

Suddenly you are changing the computed values directly. The values are displayed in pixels, but you can enter in other units (%, em, rem) and it still works. As soon as you’re done changing the value, the value switches back to the computed pixel value. The barrier has been broken. In fact, Firefox takes it one step further – if a metric (say, margin-top) was specified in a non-px unit (e.g. “1em”), clicking to edit the pixel-based computed value will display the original value and unit in edit mode.

All the rest of that day, on those wild screaming beaches,
The Fix-it-Up Chappie kept fixing up Sneetches.
Off again! On again!
In again! Out again!
Through the machines they raced round and about again,
Changing their stars every minute or two.
They kept paying money. They kept running through
Until neither the Plain nor the Star-Bellies knew
Whether this one was that one… or that one was this one
Or which one was what one… or what one was who.

Having now identified one area of element interaction that combines reading and writing certain styles into one place, surely there are more lurking around?

Nope.

As far as I can see, that’s where it stops for core browser devtools^*. ^*There’s one experimental Firefox feature I will mention later, but it’s still not in a stable release. There are no other element metrics that can simultaneously display computed values and allow changing the rules that affect them – all in a display mode that makes sense for the individual property.

Part IV – A new paradigm, I hope

Then, when every last cent
Of their money was spent,
The Fix-it-Up Chappie packed up
And he went.

And he laughed as he drove
In his car up the beach,
“They never will learn.
No. You can’t teach a Sneetch!”

In the near future, I’d like to see more devtools features break away from the purely text-based fortress. Context is key. At the very least I want more features to break out of the read OR write paradigm and start merging the two together. I’ve seen people play with Firefox’s 2D transform doorhanger and instantly want to interact with it, only to be disappointed that they can’t.^{* *}Anecdotal evidence being the most scientific and pursuasive of arguments, obviously.

Rather than just say “Here’s a vision I had – go build it,” I will now present some ideas that I’ve thought of so far. Some I’ve already built as functional prototypes. Some are just thoughts rattling around in my head. All of them are visions of what devtools could be.

2D transforms

The first idea that sparked this whole line of thinking. Transforms can be complicated, especially when a matrix is involved.

Providing an abstract visual representation is the first step.^{* *}What’s shown here is something I roughly put together as a Chrome devtools extension many moons ago. When Firefox brought out their 2D transform preview a few weeks later, I found some validation for my ideas. It inspired me to keeping expanding on the idea until it became what you’re reading now. It’s a lot easier to understand a simple picture of a transformed element than it is to try to work out how “transform: rotate(37deg) skewY(-23deg) translateX(3em)” will look.

But this isn’t enough – it’s still a read-only mode. The key lies in merging read-mode and write-mode. First let’s start with a plain, untransformed element, then scale and rotate it slightly.

That’s a good start, but it doesn’t go far enough for me. Interacting with an abstract representation is all well and good, but what if you want to play with the element itself?

That’s better, but now I want to go back and edit a transform that’s previously been applied. No problem, just click on the individual transform section and change it.

Keyframe-based animations

This one bugs me a lot. For transforms, even if the features above weren’t implemented, there is at least a way to know what the element will do. For named animations there is nothing. You can see “animation: somename” in the computed styles panel and that’s it. What does the “somename” animation actually do? No idea, sorry, you’ll have to go digging through the raw CSS to find that out.

Computer-based animators have long been using animation timelines to display and edit their animations. Hell, that’s where the term “keyframe animations” comes from. Why not start with an animation timeline for a CSS keyframe? (For what it’s worth, I’m not claiming this as an original idea – certainly other people have suggested it as well.)

The percentages at the top are the keyframes defined for the animation. Vertical bars in the box for each CSS property indicate that the property has a value set for that keyframe.

The full CSS definition of the keyframes is below the timeline. The graphical and text modes are linked with two-way highlighting to provide better context about exactly which rules apply to what part of the animation.

However, the boxes for each property look rather blank. There’s empty space just waiting to be filled. Each type of property (unit, colour, etc.) could have a different visualisation showing the change to the property’s value of the duration of the animation.

Of course, in order to not make myself a hypocrite, it has to have a write mode as well. Here’s what it looks like all put together:

This is but one possible solution for animations; there are many others. Paul Roget at Mozilla, for example, did a brilliant proof of concept that allowed user control over Firefox’s internal timing clock, thus allowing you to pause or rewind CSS and JS animations together.

Of course, as is inevitable with this kind of rant, by the time I’d finished writing it and getting prototypes ready someone had already proven me wrong. It’s worth highlighting the new feature that’s just landed in Firefox Aurora for editing keyframe animations:

There are some aspects there that I haven’t covered (such as changing the easing, and the transform visualisation is fantastic), but I still feel that being able to see at a glance the change in a property’s value over time is valuable.^{* *}This aspect of my proposal was heavily inspired by Bret Victor’s “Up and Down the Ladder of Abstraction”

The same root problem, different solutions and approaches. This is a Good Thing. No one person has the perfect solution.

However, this is still just one feature of one browser. I want more of this across the board.

The rest

So far I’ve demonstrated specific details of just two particular areas of CSS, but that should be enough to get my point across.

The new experimental animation editor in Firefox is a great step towards a better class of browser devtools. Just think of how many other parts of CSS authoring / debugging / experimenting could be improved in the same way…

Flexbox

Flexbox is great, but remembering exactly what the relevant properties are (making sure that they’re the right version of flexbox) and how they interact with each other is not something I remember easily.

We could have a proper visualisation of what the properties do (interactive, of course), and how the various flex items align with each other.

Colour gradients

Surely there are enough online gradient editors already that I don’t have to explain the concept. There are discussions around a possible implementation for Firefox at https://bugzilla.mozilla.org/show_bug.cgi?id=706102.

3D transforms

All my work on transforms focused on 2D only, for simplicity’s sake. The concept could be extended to work with 3D transforms and involve perspective and perspective-origin properties.

Text formatting

Firefox has a devtools panel that shows which fonts are used by an element or page, with an interactive text preview. This is great, but what about other text options?

Why can’t we see how the line-height and vertical-align properties interact with the x-height of a font? I’ve seen these cause lots of developer confusion before. What about word-break and word-wrap?

Other things I won’t think of, but hopefully other people will

Again, no one person has all the answers. I’m sure other people can come up with far more creative solutions. I welcome it, in fact.

Part V – Future’s so bright

Less whining, more defining

Writing long and vaguely ranty blog posts is all well and good, but it doesn’t really put ideas in front of the people actually making browser tools.

To that end, I’ve found or raised the following feature requests for the things I’ve suggested here. I’ve only focused on Chrome and Firefox for now, as they currently have the greatest speed of development on their devtools.

Browser vendors are always on the look-out for ways to make their developer tools better. If you have ideas for new devtools features, go create some issues too.

In conclusion

We^* can and should demand more from our devtools. ^*By “we” I mean “web developers” in the general sense that anyone who plays in a browser’s devtools is a developer for the web. I’m not advocating that we kill text modes completely and use purely graphical tools, as that just goes from one extreme to the other.

It is the combination of textual and graphical representation that presents the best way forward. Text for explicit declarations and fine-grained input; interactive graphics for getting better clarity of the output. As each representation updates the other at the same time, a greater understanding of the whole is gained.

This is far from a revolutionary idea, but it’s one I really want to see implemented.

But McBean was quite wrong. I’m quite happy to say
That the Sneetches got really quite smart on that day,
The day they decided that Sneetches are Sneetches
And no kind of Sneetch is the best on the beaches.
That day, all the Sneetches forgot about stars
And whether they had one, or not, upon thars.