Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Archive: 'Browsers' Category

Essential Tool: Firefox’s screenshot Command

Everyone has their own idiosyncratic collection of tools they can’t work without, and I’ve recently been using one of mine as I produce figures for CSS: The Definitve Guide, Fourth Edition (CSS:TDG4e).  It’s Firefox’s command-line screenshot utility.

To get access to screenshot, you first have to hit ⇧F2 for the Developer Toolbar, not ⌥⌘K for the Web Console.  (I know, two command lines—who thought that was a good idea?  Moving on.)  Once you’re in the Developer Toolbar, you can type s and then hit Tab to autocomplete screenshot.  Then type a filename for your screenshot, if you want to define it, either with or without the file extension; otherwise you’ll get whatever naming convention your computer uses for screen captures.  For example, mine does something like Screen Shot 2015-10-22 at 10.05.51.png by default.  If you hit [return] (or equivalent) at this point, it’ll save the screenshot to your Downloads folder (or equivalent).  Done!

Except, don’t do that yet, because what really makes screenshot great is its options; in my case, they’re what elevate screenshot from useful to essential, and what set it apart from any screen-capture addon I’ve ever seen.

The option I use a lot, particularly when grabbing images of web sites for my talks, is --fullpage.  That option captures absolutely everything on the page, even the parts you can’t see in the browser window.  See, by default, when you use screenshot, it only shows you the portion of the page visible in the browser window.  In many cases, that’s all you want or need, but for the times you want it all, --fullpage is there for you.  Any time you see me do a long scroll of a web page in a talk, like I did right at the ten-minute mark of my talk at Fluent 2015, it was thanks to --fullpage.

If you want the browser --chrome to show around your screenshot, though, you can’t capture the --fullpage.  Firefox will just ignore the -fullpage option if you invoke --chrome, and give you the visible portion of the page surrounded by your browser chrome, including all your addon icons and unread tabs.  Which makes some sense, I admit, but part of me wishes someone had gone to the effort of adding code to redraw the chrome all the way around a --fullpage capture if you asked for it.

Now, for the purposes of CSS:TDG4e’s figures, there are two screenshot options that I cannot live without.

A screen capture of Facebook’s “Trending” panel.
I captured this using screenshot fb-trend --selector '#u_0_l'.  That saved exactly what you see to fb-trend.png.

The first is --selector, which lets you supply a CSS selector to an element—at which point, Firefox will capture just that element and its descendants.  The only, and quite understandable, limitation is that the selector you supply must match a single element.  For me, that’s usually just --selector 'body', since every figure I create is a single page, and there’s nothing in the body except what I want to include in the figure.  So instead of trying to drag-select a region of the screen with ⇧⌘4, or (worse) trying to precisely size the browser window to show just the body element and not one pixel more, I can enter something like screenshot fig047 --selector 'body' and get precisely what I need.

That might seem like a lot to type every time, but the thing is, I don’t have to: not only does the Web Toolbar have full tab-autocomplete, the Toolbar also offers up-arrow history.  So once I’ve tab-completed the command to capture my first figure, I just use the up arrow to bring the command back and change the file name.  Quick, simple, efficient.

The second essential option for me is --dpr, which defines a device pixel ratio.  Let’s say I want to capture something at four times the usual resolution.  --dpr 4 makes it happen.  Since all my figures are meant to go to print as well as ebooks, I can capture at print-worthy resolutions without having to use ⌘+ to blow up the content, or fiddle with using CSS to make everything bigger.  Also if I want to go the other way and capture a deliberately pixellated version of a page, I can use something like --dpr 0.33.

I have used this occasionally to size down an image online: I “View Image” to get it in its own window, then use screenshot with a fractional DPR value to shrink it.  Yes, this is a rare use case, even for me, but hey—the option exists!  I haven’t used the DPR option for my talks, but given the growing use of HD 16:9 projectors—something we’ve been using at An Event Apart for a while now, actually—I’m starting to lean toward using --dpr 2 to get sharper images.

(Aside: it turns out this option is only present in very recent versions of Firefox, such as Developer Edition 43 and the current Nightlies.  So if you need DPR, grab a Nightly and go crazy!)

A closeup of text on a test page.
A snippet of an image I captured using --dpr 5.  On-screen, the page was at 100% zoom, 16-pixel (browser default) text sizing.  The resulting capture was 4000×2403 pixels.

And that’s not all!  You can set a --delay in seconds, to make sure a popup menu or other bit of interaction is visible before the capture happens.  If you want to take your captured image straight into another program before saving it, there’s --clipboard.  And there’s an option to upload straight to --imgur, though I confess I haven’t figured out how that one works.  I suspect you have to be logged into imgur first.  If anyone knows, please leave a comment so the rest of us know how to use it!

The one thing that irks me a little bit about screenshot is that the file name must come before the options.  When I’m producing a bunch of figures in a row, having to drag-select just the file name for replacement is a touch tedious; I wish I could put the file name at the end of the command, so I could quickly drag-select it with a rightward wrist-flick.  But all things considered, this is a pretty minor gripe.  Well, shut my mouth and paint me red—it turns out you can put the filename after the options.  Either that wasn’t possible at some point and I never retested the assertion, or it was always possible and I just messed up.  Either way, this irk is irksome no more!

The other thing I wish screenshot could do is let me define a precise width or height in pixels—or, since I’m dreaming, a value using any valid CSS length unit—and scale the result to that measure.  This isn’t really useful for the CSS:TDG4e figures, but it could come in pretty handy for creating talk slides.  No, I have no idea how that would interact with the DPR option, but I’d certainly be willing to find out.

So that’s one of my “unusual but essential” tools.  What’s yours?

Undoing oncut/oncopy/onpaste Falsities

Inspired by Ryan Joy’s excellent and deservedly popular tweet, I wrote a small, not-terribly-smart Javascript function to undo cut/copy/paste blocking in HTML.

function fixCCP() {
   var elems = document.getElementsByTagName('*');
   var attrs = ['onpaste','oncopy','oncut'];
   for (i = 0; i < elems.length; i++) {
      for (j = 0; j < attrs.length; j++) {
         if (elems[i].getAttribute(attrs[j])) {
            .replace("return false","return true"));

Here it is as a bookmarklet, if you still roll that way (as I do): fixCCP.  Thanks to the Bookmarklet Maker at for helping me out with that!

If there are obvious improvements to be made to its functionality, let me know and I’ll throw it up on Github.

Ciao, Camino

It’s been obvious for a long time that Camino was withering away, but they’ve formally called an end to the project:

After a decade-long run, Camino is no longer being developed, and we encourage all users to upgrade to a more modern browser. Camino is increasingly lagging behind the fast pace of changes on the web, and more importantly it is not receiving security updates, making it increasingly unsafe to use.

I used Camino for a long time, and only left when it had lagged much too far behind the rest of the browser market.  (Camino used Gecko embedding, which was disabled a couple of years ago.  That change effectively froze Camino’s rendering engine at the level of Firefox 3.6.)

When I migrated away from Camino, I tried a few alternatives and eventually settled on Firefox because its UI was the least unlike Camino’s.  (We like best what we know best.)  There were still some things I sorely missed, though, like simple Flash blocking and whitelisting, the multi-row Bookmarks bar, the keyboard bookmark-activation shortcuts, and the truly great downloads manager.  If you miss those (or would like to experience them) too, here’s how I got them back in Firefox:

  • Flashblock — though its UI isn’t quite as easy as Camino’s Flash preferences, Flashblock works well and allows whitelisting.
  • Multirow Bookmarks Toolbar Plus — the layout of this has gotten a bit wonky under recent Firefox Nightly builds, but still works just fine, and you can even set it to auto-hide itself.
  • Bookmark Shortcut Keys — built for me in Jetpack by Jeff Balogh, this lets you define which keyboard shortcuts trigger the first nine bookmarks in the Bookmarks bar.  I use this all the time, just as I did in Camino.  I’ve defined my shortcuts to be ⌘1 through ⌘9, but you can pick whichever modifier keys you like.  Thanks, Jeff!
  • Download Manage Tweak — adds controls to show a file in the OS, delete the file, remove the file from the list without deleting it, and so on.  As with Flashblock, it isn’t quite as smooth as Camino’s UI, but it does the same job and a bit more besides.

And one more: New Tab Homepage, which makes certain that Firefox loads your Home page, and not the dashboard, whenever you open a new tab.

Oh, all right, one more one more: RSS Icon in Awesombar.  If you still roll that way.

So if you still pine a bit for Camino’s UI features, there’s how you can recreate most of the experience in Firefox.  If you don’t, then peace be with you, as with the entire Camino team.  Thank you all for everything you did to bring OS X a great browser that just felt right.


Maybe all the cool kids already know this, but I didn’t, so I’ll document it for the rest of us:  in Windows, Helvetica is not Helvetica: it’s Arial.  It’s Arial even if you explicitly ask for Helvetica and fall back to a non-sans-serif font family and allow for no other choices—but it’s not Helvetica if you try to get to it indirectly.

To see what I mean, you can load up my testcase in any Windows browser—IE, Firefox, Chrome, whatever—assuming that you haven’t installed Helvetica on your Windows machine.  (If you have, then I’d love to know what results you get.)  Given that you haven’t installed Helvetica, you should see that three of the four bottom-bordered spans are using Arial.  This can be determined due to the shapes of the “GR” characters—they are notably different between Helvetica and Arial.  Here’s what I apply to the first test list item:

#l01 .s01 {font-family: Helvetica, monospace;}
#l01 .s02 {font-family: Arial, monospace;}

My result is that they use exactly the same face, and that face is Arial, which should not have happened.  If Helvetica is not present, the first span should be rendered using a monospace font face.  If it is present, then the first span should have different letterforms than the second.

But it’s the second line where things get really interesting.  There, I assigned local copies of Helvetica and Arial (if they exist) to the invented family names “H” and “A”.  Then I apply this to the second test list item:

#l02 .s01 {font-family: H, monospace;}
#l02 .s02 {font-family: A, monospace;}

The result should be the same as the first line, but it isn’t: the first span gets a fallback font face, and the second span gets Arial.  So while the system redirects requests for Helvetica to Arial, it doesn’t do so in such a way that the invented family name “H” resolves to Arial, even though it was assigned Helvetica (or perhaps I should say “Helvetica”) as its source.

I’d be interested to know if there’s something I’ve overlooked or misunderstood here, because these waters are deep and I suspect my understanding of them is somewhat shallow.

Presto Change-o

Way back in the day, I used to compare web standards to text file formats and browsers to word processors.  The analogy was that in the early days of word processors, they competed on features and file formats—WordPerfect has its own format, WordStar had its own, Word its own, and on and on.  Then, over time, they all converged on supporting a small(ish) number of common formats and competed on features.  And so it would be for browsers, I would say, back in those days.

Well, so it was.  But there was another stage to the analogy that I didn’t bring up because it seemed to so remote, back then: that one of the browsers would start to gobble up or kill off its competitors, as MS Word did in the word processor space.  Sure, there are still alternatives, but how many people use them?

You can argue that this sort of consolidation is inevitable.  You can argue that it has benefits that outweigh the drawbacks, and vice versa.  Certainly having a de facto word processor made publishers’ lives easier in many ways, even if it disrupted life for authors who had invested in other-than-de-facto programs.  It made life easier for people who wanted to extend the word processing space by writing extensions, helpers, and other tools.  And it definitely made life easier for the Office team, which could proceed to add whatever feature they liked without having to worry overmuch about interoperability with others.  (It was, obviously, up to others to be interoperable with them.)

This is the lens through which I view Opera’s announcement that they will migrate to WebKit.  Actually, that’s not true: it’s one of the lenses.  I also remember the first browser wars, and the calls to have all browsers just use Trident, the engine in IE5 and IE6.  It was dominant, after all, and as good as or better than all its competitors, blessed with great resources and smart developers.  I find myself peering through that lens as well.

There are parallels and divergences, of course:  no analogy is ever perfect and no two events are identical.  We could argue about how this is exactly like or not like a decade ago, how this is precisely like or not like the word processor market, and some of us will.  No matter where you fall, of course, the Opera migration to WebKit and the sunset of Presto is going to happen.  As once was said:  The avalanche has already started.  It is too late for the pebbles to vote.

To which I would add: in this case the pebbles have already voted, have been voting for years now, and their votes determined that the avalanche would proceed in this direction and not another.  And no, I don’t mean the users.

Should You Hyphenate?

A couple of weeks back, PPK posted about the sudden emergence of CSS hyphenation support in several browsers (which got picked up by WebMonkey, the lucky dog).  At the time, there was some confusion about whether a lang attribute it required to allow the hyphenation to happen—PPK said it did, but my testing indicated the opposite.

Well, it turned out that at the moment I did that test, I was running Firefox 16, and FF16 apparently honored the -moz-hyphens property with nary lang a attribute in sight.  We might ask how that’s supposed to work, since hyphenation dictionaries are language-dependent, but never mind: it did.  Firefox 17, on the other hand, requires a lang attribute value in order to apply hyphens (note the lack of prefix).

I haven’t gone running down the behavior of other browsers, because the upshot is this: if you want hyphenation to work in a future-friendly way, you need a lang attribute.  What older versions do will become of fading relevance.

All of which raises a fairly important question: should you enable hyphenation?

After all, hyphenation, I am told, was invented to increase the density of text and reduce the number of column inches needed in printed media, where paper can be expensive and space at a premium.  Hyphenation, in other words, was devised as a trick to let authors be a little bit more wordy.  (Also as a way to help reduce interword spacing in fully justified text.)

On the web, of course, we have no physical length constraints: The Web Ain’t Print.  We can run on as long as we like, limited only by our thesaurus, our RSI flare-ups, and the attention span of our readers.

But wait…that’s all true for the desktop web.  We have lovely big monitors and easily resizeable windows and zoomable text.  On mobile devices, however, the real estate is much more limited.  We still have infinite length, yes, but line lengths tend to be a lot shorter on iPhone or Android—particularly if you’ve given your mobile users a nicely readble font size.

Right after PPK’s article hit my aggregator, I turned on hyphenation here on meyerweb.  For desktop reading, at first it caught my eye a bit, but now I don’t see it at all.  Years and years of print reading has made it seem familiar.  Things would be just fine without the hyphens, of course.  But when reading pages on mobile, the hyphens feel useful.  They give me a little bit more reading for each “screenful”, and just feel comfortable.

Thus my recommendation of the moment: if you’re going to use CSS hyphenation, turn it on for mobile contexts.  For desktop—well, that’s a much murkier call.  It may well depend on your font family, layout, default language, and so on.  If you do turn them on, just make sure you have that lang attribute (I put mine on the html element) so your hyphens will persist.

Gradient Repetition

Yesterday, I shared a test of repeating linear gradients and the madness they embody in various browsers.  There were some suggestions for fixes both on the intertubes as well as the comments section of the post, so I should take a moment to explore the reasons for my post and test, and also what I would consider to be stable alternatives to the patterns I was creating.

Primarily the test was to find out how browsers handle repeating-linear-gradient().  Badly, as it turns out, at least for many of them.  Chrome is the worst; far worse than Safari, which I found fascinating.  So I wasn’t actually posting in search of a way around those problems, though in re-reading the post I can see where that impression might have developed.  I was actually running an experiment where my starting hypothesis was that repeating gradients were safe to use.  This was proven to be false.  (Science!)  Having found out that there are glitches and inconsistencies that are sensitive to element size, and seeing how wildly, almost hilariously wrong some engines have gotten this, I came to the conclusion that repeating-linear-gradient() isn’t yet ready for use.

That’s okay.  Not everything in CSS is ready for use.  Almost everything in CSS wasn’t ready for use, once upon a time.  I think color is the one property that was probably stable from the outset, and even that had its quirks in Netscape 4, albeit in the handling of unknown values.  (color: inherit resulted in a shade we lovingly referred to as “monkey-vomit green”.)

Now, as for useful alternatives to repeating-linear-gradient(): the most obvious (as in traditional, as in boring) method is to create a PNG or other pixel image and use the various background-related properties.  For example, given a desire to have a 5-on-5-off pattern (as seen in test #5), you could create a 10×10 PNG and then tile it something like this:

background-image: url(5on5off.png);
background-repeat: repeat-x;
background-position: bottom center;
background-size: 10px 10px;

The advantages here are that A) pixel images are about as safe as you get; and B) if you want to stretch the image vertically, you can do so without having to produce a new image.

A second alternative, only fractionally less safe but rather more efficient, is to replace the external PNG with a regular non-repeating linear gradient.  I much prefer this to the suggestion of sizing and tiling a repeating gradient, because the test shows we can’t have any confidence in consistency with repeating gradients right now.  (This is particularly true in Chrome, which is the worst with small repeated gradients.)  Plain old non-repeating linear gradients, on the other hand, are predictable once you get the syntax right.  Thus:

background-image: linear-gradient(left,
	rgba(255,0,0,0.5) 0px,
	rgba(255,0,0,0.5) 5px,
	rgba(255,0,0,0) 5px,
	rgba(255,0,0,0) 10px);
background-repeat: repeat-x;
background-position: bottom center;
background-size: 10px 10px;

…with, of course, the various vendor-prefixed versions of that first declaration blatted out by your favorite CSS preprocessor, framework, JavaScript shim, brain and fingers, or other tool of choice.  The repeating pattern here is handled by the background-repeat declaration instead of relying on repeating-linear-gradient() to do it for you.  It’s exactly the same as the first alternative except the pixel image has been replaced with a textually-described image.

So why do browsers not just do that internally?  Well, I really don’t know, though it’s quite probable that performance plays an important role.  For repetitions along the primary axes, they could certainly do it very easily.  But the big advantage of repeating-linear-gradient(), and the place where both alternatives can fall flat on their faces unless you are very careful, is in creating repeating patterns that don’t march on one of the primary axes.  Repeating a static linear gradient along the X axis is fine as long as it’s perfectly perpendicular to the X axis, but what happens when you want to repeat a pattern that’s tilted 30 degrees?

Yes, this sort of effect can certainly be worked out by hand or tool—after all, we’ve seen those kinds of patterns done with GIFs and PNGs and the like for decades now—but it’s a lot harder to do.  It’s still what I’d recommend right now, because having a reliably repeated background is usually far better than one whose rendering you can’t predict.

The goal of repeating-linear-gradient() was to make it easy to specify a repeating pattern at any angle and not have to worry about the minutiae.  Unfortunately, until rendering engines actually start properly handling the minutiae, we need to do it by hand if we do it at all.

Repeating Linear Madness

My detailed studies of CSS3 have, of late, taken me into the realm of repeating linear gradients.  I’m not going to attempt a Lovecraft parody for this post, though I seriously considered it.  Instead, I’m going to give you a summary of where we stand with repeating linear gradients, followed by some details.

The summary is as follows: NOT READY FOR PRIME TIME.  In fact, not even ready for safe harbor in Europe.  Whether they will become ready for use is up to the various browser makers.

I came to this conclusion after creating and evolving a test case for pattern regularity.  The test compares a repeated PNG (red) with two theoretically equivalent repeating-linear-gradient images (blue and blue).  The two repeating linear gradients are expressed differently, but should yield the same result.  The visual result of the test should be a perfect interleaving where the blue and red patterns overlap.

To see what I mean, load up the test in Opera; or take a look at this screenshot of the first eight cases, taken in Opera.  Either one will show you the reference rendering for this test case.  Regular repetition and seamless interleaving, no matter what you do with the browser window’s size.  That was and is the intended result.

If you want to go all the way to the other end of the spectrum, load up the same test in Chrome or Canary.  It will be…different, at least in my testing on OS X and Windows.  For extra fun, try dragging the browser window to resize.  AHHHHGGGH.

In Firefox 12/Aurora 14 and Safari 5.1.7, all on OS X, I see something very close to Opera, except there are little one-pixel missteps here and there.  Even better, the positions of these missteps will be different between the two gradient patterns; that is, for a given test the missteps on the top test will almost certainly be different than those on the bottom—assuming there are any at all.  And all that was about as vague as can be because the missteps depend on the width of the element; again, try drag-resizing the browser window.  Crawling artifacts!

I’m sorry, I promised no Lovecraft.

I’ve been told that Firefox 12 for Windows is rock-steady and Opera-regular, but I haven’t yet been able to verify that.  I also haven’t tried out IE10 to see where, if anywhere, they stand with this.  I imagine every build of every Linux browser ever has this nailed 100%, because that’s all Linux users say every time I launch one of these tests.  Go you!

The point of all this being, as if I needed to restate it: don’t depend on repeating-linear-gradient for much of anything right now.  There is pretty clearly a metric massload of work to be done before we can start calling these safe to use.

November 2015