Posts in the Browsers Category

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.

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:

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:

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.

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.

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.

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:

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:

…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.

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.

I recently stumbled over a subtle interaction between cookie policies and localStorage in Firefox. Herewith, I document it for anyone who might run into the same problem (all four of you) as well as for you JS developers who are using, or thinking about using, locally stored data. Also, there’s a Bugzilla report, so either it’ll get fixed and then this won’t be a problem or else it will get resolved WONTFIX and I’ll have to figure out what to do next.

The basic problem is, every newfangled “try code out for yourself” site I hit is just failing in Firefox 11 and 12. Dabblet, for example, just returns a big blank page with the toolbar across the top, and none of the top-right buttons work except for the Help (“?”) button. And I write all that in the present tense because the problem still exists as I write this.

What’s happening is that any attempt to access localStorage, whether writing or reading, returns a security error. Here’s an anonymized example from Firefox’s error console:

When you go to line 666, you discover it refers to localStorage. Usually it’s a write attempt, but reading gets you the same error.

But here’s the thing: it only does this if your browser preferences are set so that, when it comes to accepting cookies, the “Keep until:” option is set to “ask me every time”. If you change that to either of the other two options, then localStorage can be written and read without incident. No security errors. Switch it back to “ask me every time”, and the security errors come back.

Just to cover all the bases regarding my configuration:

Firefox is not in Private Browsing mode.

dom.storage.default_quota is 5120.

dom.storage.enabled is true.

Also: yes, I have my cookie policy set that way on purpose. It might not work for you, but it definitely works for me. “Just change your cookie policy” is the new “use a different browser” (which is the new “get a better OS”) and it ain’t gonna fly here.

The user agent may throw a SecurityError exception instead of returning a Storage object if the request violates a policy decision (e.g. if the user agent is configured to not allow the page to persist data).

I haven’t configured anything to not persist data—quite the opposite—and my policy decision is not to refuse cookies, it’s to ask me about expiration times so I can decide how I want a given cookie handled. It seems to me that, given my current preferences, Firefox ought to ask me if I want to accept local storage of data whenever a script tries to write to localStorage. If that’s somehow impossible, then there should at least be a global preference for how I want to handle localStorage actions.

Of course, that’s all true only if localStorage data has expiration times. If it doesn’t, then I’ve already said I’ll accept cookies, even from third-party sites. I just want a say on their expiration times (or, if I choose, to deny the cookie through the dialog box; it’s an option). I’m not entirely clear on this, so if someone can point to hard information on whether localStorage does or doesn’t time out, that would be fantastic. I did see:

User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user.

…from the same section, which to me sounds like localStorage doesn’t have expiration times, but maybe there’s another bit I haven’t seen that casts a new light on things. As always, tender application of the Clue-by-Four of Enlightenment is welcome.

Okay, so the point of all this: if you’re getting localStorage failures in Firefox, check your cookies expiration policy. If that’s the problem, then at least you know how to fix it—or, as in my case, why you’ll continue to have localStorage problems for the next little while. Furthermore, if you’re writing JS that interacts with localStorage or a similar local-data technology, please make sure you’re looking for security exceptions and other errors, and planning appropriate fallbacks.

This morning I caught a pointer to TypeButter, which is a jQuery library that does “optical kerning” in an attempt to improve the appearance of type. I’m not going to get into its design utility because I’m not qualified; I only notice kerning either when it’s set insanely wide or when it crosses over into keming. I suppose I’ve been looking at web type for so many years, it looks normal to me now. (Well, almost normal, but I’m not going to get into my personal typographic idiosyncrasies now.)

My reason to bring this up is that I’m very interested by how TypeButter accomplishes its kerning: it inserts kern elements with inline style attributes that bear letter-spacing values. Not span elements, kern elements. No, you didn’t miss an HTML5 news bite; there is no kern element, nor am I aware of a plan for one. TypeButter basically invents a specific-purpose element.

I believe I understand the reasoning. Had they used span, they would’ve likely tripped over existing author styles that apply to span. Browsers these days don’t really have a problem accepting and styling arbitrary elements, and any that do would simply render type their usual way. Because the markup is script-generated, markup validation services don’t throw conniption fits. There might well be browser performance problems, particularly if you optically kern all the things, but used in moderation (say, on headings) I wouldn’t expect too much of a hit.

The one potential drawback I can see, as articulated by Jake Archibald, is the possibility of a future kern element that might have different effects, or at least be styled by future author CSS and thus get picked up by TypeButter’s kerns. The currently accepted way to avoid that sort of problem is to prefix with x-, as in x-kern. Personally, I find it deeply unlikely that there will ever be an official kern element; it’s too presentationally focused. But, of course, one never knows.

If TypeButter shifted to generating x-kern before reaching v1.0 final, I doubt it would degrade the TypeButter experience at all, and it would indeed be more future-proof. It’s likely worth doing, if only to set a good example for libraries to follow, unless of course there’s downside I haven’t thought of yet. It’s definitely worth discussing, because as more browser enhancements are written, this sort of issue will come up more and more. Settling on some community best practices could save us some trouble down the road.

Update 23 Mar 12: it turns out custom elements are not as simple as we might prefer; see the comment below for details. That throws a fairly large wrench into the gears, and requires further contemplation.