Posts in the Tech Category

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.

• Presto Change-o was published on Wednesday, February 13th, 2013.
• It was assigned to the Browsers category.
• There have been six replies.

Last week, I asked “Should You Hyphenate?”  This week, I’m going to assume that you decided to answer in the affirmative and talk about some good practices (I don’t know if they’re best practices just yet).  This post was actually triggered by a comment from Kevin Hamilton on last week’s post.  He said, in part:

You may want to exclude hyphenation on <code> tags within your blog. For both readability purposes (since many CSS tags already make heavy use of hyphens) and to avoid introducing some confusing/misleading references… Is it re-peating-linear-gradient? Or perhaps repeating-lin-ear-gradient?

He’s absolutely right, of course.  If you’re going to blog about technical topics, or even if you’re just writing a style sheet that you expect to release into the wild for use by anyone, there are some elements that you should avoid hyphenating.  And since hyphens is an inherited property, it isn’t sufficient to set it for a limited number of elements and assume you’re done.  You have to make sure you’ve turned it off for the elements that shouldn’t be hyphenated.

In my opinion, those elements are:

• code
• var
• kbd
• samp
• tt
• dir
• listing
• plaintext
• xmp
• abbr
• acronym

Yes, most of those are old and obscure and in some cases (massively) deprecated, but they’re all elements that could be hanging around on a web site and by their nature shouldn’t have their content hyphenated.  I mean, I would hope that a browser would recognize not to hyphenate an acronym or abbreviation element, but who knows?  Maybe ZOMGWTFBBQROFLMFAOCOPTER has enough word-like strings to qualify for hyphenation in some hyphenation dictionaries.  (Or not.)

“So what about pre?” you ask.  A very good question.  I rate that as a solid “maybe”.  For most uses of pre, the content won’t line-wrap anyway thanks to white-space: pre, so it’s a moot point.  However, if a pre has been set to white-space of pre-wrap, pre-line, or even normal, then hyphenation may well kick in.

At that point, the question is what kind of content the pre contains.  It apparently is no longer meant to be rigidly preformatted, as the element name would imply, so what is it?  If it’s a code block, there should already be a code element present within the pre, so suppressing hyphenation for code will be sufficient.  Ditto if it’s an example of user input (kbd), program output (samp), and so on.  This is why semantic markup matters.  It’s why, if you’ve been using it all along, you can make fine-grained choices here.

Of course, lots of people weren’t as forward-looking as you and anyway nobody’s perfect, so it’s probably a good idea to switch off hyphenation for pre, just in case the more semantic elements were left out.

There are similar questions to confront regarding q and blockquote.  If you’re quoting someone, almost certainly something that someone wrote, is it advisable to hyphenate that text when they didn’t?  I’m honestly not sure if it matters or not.  I’ve personally suppressed hyphenation in those cases, but I did that purely on instinct and I’d love to know what content and typography specialists think of that question.  (Be polite, please.  We’re all learning here.)

For the last interesting question, what about auto-linked URLs?  If we suppress hyphenation for all links, then that solves one problem to introduce another.  What I have noticed is that if you drag-select CSS-hyphenated text, the auto-generated hyphen(s) and line break(s) are ignored when you copy the text.  You just get the original.  That’s why I don’t think it’s really necessary to suppress hyphenation on the a element, though I’m willing to change my mind in the presence of new evidence.

Thus, at the moment, meyerweb’s base style sheet contains the following:

body {hyphens: auto;}
code, var, kbd, samp, tt, dir, listing, plaintext, xmp,
      abbr, acronym, blockquote, q {hyphens: none;}

I may adjust those rules over time, but that’s where I’ve landed.

Update 18 Dec 12: I should make it more clear that this post is intended to be a starting point, not the final word.  I’m not proposing that these are all the elements on which one should ever suppress hyphenation, full stop, end of discussion.  There may well be others, like form labels and textareas and text inputs and so forth, that should also be excluded.  (Though I kind of enjoy watching my text input get auto-hyphenated as I type.  It’s a little surreal.)  Hopefully, this post will get people thinking about exactly how authors should handle hyphenation if they do choose to put it in place, and eventually help us figure out some solid best practices.

• Where to Avoid CSS Hyphenation was published on Monday, December 17th, 2012.
• It was assigned to the CSS category.
• There have been fifteen replies.

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.

• Should You Hyphenate? was published on Monday, December 10th, 2012.
• It was assigned to the Browsers and CSS categories.
• There have been fifteen replies.

Just some quick updates regarding An Event Apart as we transition from our just-finished 2012 schedule to the upcoming 2013 schedule.

If you’re interested in joining us in 2013, you can check out the event nearest you…or maybe the event being held where you’ve always wanted to go!  If you have your eye on Atlanta, bear in mind that the Early Bird rate (which saves you $100) ends on Christmas Eve, so don’t wait too much longer.  And if you were waiting for a detailed schedule in either San Diego or Boston before deciding to register, well, your wait is over.  More schedules will be released as the shows get closer.

I don’t talk very much about An Event Apart, and I probably talk about it far less than I should.  I blame that on the show itself, partly.  Our last show of 2012, held at the opulent Palace Hotel in San Francisco, is now three weeks behind us and I’m still struck a little bit speechless by another year of fantastic attendees and speakers.  The fundamental nature of what we’ve created together really is overwhelming to me, in the best possible way.  Thank you, one and all, for making that possible.

To celebrate the year just past as well as the year to come, we’ve once again made a donation to CFY (formerly Computers For Youth) to help advance their efforts to bring digital literacy and access to impoverished elementary school students.  They’ve already seen great improvements in schools where they operate, and we’re thrilled to support their work.  If you’d like to support them as well, please do, or take a moment in all the end-of-year rush and lend some aid to the charity that speaks most clearly to you.

• Another Year Apart was published on Thursday, December 6th, 2012.
• It was assigned to the An Event Apart category.
• There have been no replies.

I just recently stumbled across a years-ago post where I said, almost as an aside:

Web design isn’t like chemistry, where the precipitate either forms or it doesn’t. If chemical engineers had to work in conditions equivalent to web developers, they’d have to mix their solutions in several parallel universes, each one with different physical constants, and get the same result in all of them.

While that’s still true, the constants are a lot less divergent these days.  The parallel universes that are web browsers are much closer to unity than once they were.

Remember those days?  When major web sites had a home page with two links: one for Netscape users to enter, the other for IE users?

Madness.

We know better now, of course.  Thanks to early pioneers like the organizers of the Web Standards Project, the path of web development was bent to a much saner course.  We still have little glitches and frustrations, of course, but it could be so unimaginably worse.  We know that it could be, because it was, once.

Along the way, the book cover of my friend and business partner’s book, Designing With Web Standards, gave rise to Blue Beanie Day, the day on which we give visible presence to our solidarity with the idea that web standards make possible the web as we know it.  Pictures go up on Twitter, Instagram, and Flickr with the tag #bbd12, and can be added to the Flickr group if you post there.

In this rapidly unfolding age of multiple device platforms and web access experiences, standards are more important than ever, even as they come under renewed pressure.  There will always be those who proclaim that standards are a failed process, an obstruction, an anachronism.  The desire to go faster and be shinier will always tempt developers to run down proprietary box canyons.

But so too will there always be those of us who remember the madness that lies that way.  Come November 30th, thousands of us will don our blue beanies.  I hope you’ll be among us.

Image © Kevin Cornell.  Used with permission.

• Sixth Annual Blue Beanie Day was published on Friday, November 23rd, 2012.
• It was assigned to the Standards and Web categories.
• There have been no replies.

I have a theory, one that I’m sure has been formulated by someone else much earlier than me, that all power users eventually get left behind.  They get stuck in a highly-optimized box canyon of their own making, one that is perfectly tuned to their way of working and interacting with data and is of interest to precisely nobody else in the world.

Let me use myself as an example.  I’m currently running OS X Snow Leopard, 10.6.8, with no intention of upgrading.  This is because after Snow Leopard, there is no more Rosetta.  That means that my preferred personal mail client, Eudora, will not work.  Neither will Word 2004.  Both are, in effect, upgrade deal-breakers for me.

But why would I hang on to such relics?

Well, Eudora has been my mail client for quite literally two decades, and thus it has two decades of archived mail that I can search very quickly and easily.  I have tried out migrations to other clients; they crash trying to suck in 3GB worth of mail text in Eudora’s special format.  I could simply declare a break and move on to a new client with no stored mail, but as soon as I upgrade my OS, even the archives will be inaccessible.  This is a major barrier.  There are possible solutions, but trying them is incredibly time-intensive with no actual guarantee of success.

As for Word 2004, I have it customized so that ⇧⌘S shifts keyboard focus to the Styles combo box.  There I can type the name of the style I want and hit return.  This is really important when I’m writing a book whose files eventually have to be passed off to a publisher’s production staff, whose toolchains depend on proper use of styles.  O’Reilly in particular went to a lot of effort, back in the day, to create style who had vi-style shortcut names, so I can highlight a few words and type ⇧⌘S fc [return] to set the highlighted text in the “literal” style (used for property names and the like).  Versions of Word after 2004 do not possess this feature.  I own Word 2011, and often use it to view documents sent to me by others, but I can’t use it as an efficient book-authoring tool because it amputated a feature I use a lot.

So the objection isn’t a simple “I like what I know, dadgumit!”, though of course I do like what I know (we all do).  The real problem is “I have built my workflow around these things, and breaking them is unacceptable”.

I hear similar complaints from my designer friends.  They’ve gotten so expert at using a particular piece of software that they bemoan even the hint that it will get a significant ‘upgrade’ — which often sounds like “break everything I do while likely adding a metric ton of crap I don’t need” to the power user — or even be discontinued.  Although for the power user, discontinuing is often preferable; at least when software is discontinued, it works exactly as you expect for as long as you can keep it running.

The web doesn’t inherently fix this problem, either.  When Twitter finally retired the API access points that Twitterrific 3 depended upon, my desktop Twitter client irretrievably broke.  Why not upgrade to the latest Twitterrific?  Because version 3 allowed me to display my timeline with all tweets collapsed, except for the currently-active tweet.  It was an incredibly compact, high-density, useful interface.  Version 4 does not permit it.  no other Twitter client I’ve tried permits it.  In fact, every other Twitter client I’ve tried has come off as cartoonishly clumsy and sprawlingly obtrusive when compared to the sleekness of Twitterrific 3 — including, as I say, the newer version of the very same Twitter client.

Granted, that’s more of a UI preference than a functionality problem, but UI preferences are often what drive us to use things, or not use them.  I’m much now less present on Twitter than I was before the break, and when I do go on Twitter, it’s either via the official Twitter client on my iPhone or via twitter.com itself on the desktop.

Getting back to my increasingly-aging OS version, it helps that, to echo one my long-time personal heroes Tim Bray, I have no particular interest in what’s come after Snow Leopard.  Dragging window edges might be nice, but I’ve lived without it for a very long time and rarely ever missed it.  (Not never, but rarely.)

Yes, the newer OS X versions have a whole bunch of hip new cloud features, but in my case that’s actually a bug, not a feature.  I instinctively distrust cloud-based storage for a variety of reasons.  The security concerns are pretty significant for me, and for that matter having everything stored remotely is a good idea only if I have 100% reliable network access everywhere I go.  Well, I don’t (and neither do you).

But of course the rest of the world is moving in a different direction, leaving people like me behind.  That doesn’t mean that the rest of the world has gone mad, or is wrong to move in the direction it does.  This isn’t a querulous demand that everything be frozen in the spot I like because if it was good enough ten years ago, it’s good enough now.  That’s not how the world works.  What I’m doing here, if I’m doing anything worthwhile at all, is documenting the point at which I came to the end of my box canyon, pulled out a guitar, and strummed a quiet ballad to the memory of my own forward progress.

As I say, I think all this happens to every power user at some point or another.  We become enmeshed in a web of interlocking dependencies, and sooner or later lock ourselves into a particular place.  The odds of it happening increase with age, but that’s less a function of biological age than it is elapsed time.  The younger you start, the younger you’re likely to reach this point.

I will have to exit my canyon eventually, of course — but when, how, and why all remain very open questions, and I do not look forward to the turbulent transition periods that are likely to follow.

Special thanks to Tim Bray, Grant Hutchinson, and Jon Tan for their insights and feedback on this post.

• Optimized For the Fast-Fading Past was published on Friday, October 12th, 2012.
• It was assigned to the Observations and Tech categories.
• There have been eighteen replies.

When I announced the serial publication of CSS: The Definitive Guide, Fourth Edition, I failed to address the question how pricing will work.  Well, more decided to break it out into its own post, really.  As it turns out, there are two components to the answer.

First component is the pricing of the pre-books.  Roughly speaking, each pre-book will be priced according to its length.  The assumed base for the electronic version is $2.99, and $7.99 for the print version, with significantly longer pre-books (say, one where two chapters are combined) priced somewhat higher.  How much higher depends on the length.  It’s possible that prices will drift a bit over time as production or printing costs change, but there’s no way to guarantee that.  We’re basically pricing them as they come out.

At the end of the process, when all the chapters are written and bundled into an omnibus book edition, there will be discounts tied to the chapters you’ve already purchased.  The more chapters you bought ahead, the deeper the discount.  If you bought the pre-books direct from O’Reilly, then you’ll automatically get a discount code tailored to the number of pre-book you’ve already bought.  If you bought them elsewhere, then O’Reilly’s customer service will work to create a comparable discount, though that will obviously be a slower process.

The second component is: how much will the codes cut the price of the final, complete book?  That I cannot say.  The reason is that I don’t know (nor does anyone) what minimum price O’Reilly will need to charge to cover its costs while taking into account the money already paid.  I’m hopeful that if you bought all of the pre-books, then the electronic version of the final book will be very close to free, but again, we have to see where things stand once we reach that point.  It might be that the production costs of the complete book mean that it’s still a couple of bucks even at the deepest discount, but we’ll see!  One of the exciting things about this experiment is that even my editor and I don’t know exactly how it will all turn out.  We really are forging a new trail here, one that I hope will benefit other authors — and, by direct extension, readers — in the future.

• Pricing ‘CSS:The Definitive Guide’ was published on Wednesday, October 3rd, 2012.
• It was assigned to the CSS, Projects, Standards, and Writing categories.
• There have been three replies.

I’m really excited to announce that CSS: The Definitive Guide, Fourth Edition, is being released one piece at a time.

As announced last week on the O’Reilly Tools of Change for Publishing blog, the next edition of CSS:TDG will be released chapter by chapter.  As each one is finished, it will go into production right away instead of waiting for the entire omnibus book to be completed.  You’ll be able to get each standalone as an e-book, a print-on-demand paper copy, or even as both if that’s how you roll.  I’ve taken to calling these “pre-books”, which I hope isn’t too confusing or inaccurate.

There are a lot of advantages to this, which I wrote about in some detail for the TOC post.  Boiled down, they are: accuracy, agility, and à la carte.  If you have the e-book version, then updates can be downloaded for free as errata are corrected or rewrites are triggered by changes to CSS itself.  And, of course, you can only buy the pre-books that interest you, if you don’t feel like you need the whole thing.

I should clarify that not every pre-book is a single chapter; occasionally, more than one chapter of the final product will be bundled together into a single pre-book.  For example, Selectors, Specificity, and the Cascade is actually chapters 2 and 3 of the final book combined.  It just made no sense to sell them separately, so we didn’t.  “Values, Units, and Colors”. on the other hand, is Chapter 4 all by itself.  (So if anyone was wondering about the pricing differences between those two pre-books, there’s your explanation.)

If you want to see what the e-book versions are like, CSS and Documents (otherwise known as Chapter 1) has been given the low, low price of $0.00.  Give it a whirl, see if you like the way the pre-books work as bits.

My current plan is to work through the chapters sequentially, but I’m always willing to depart from that plan if it seems like a good idea.  What amuses me about all this is the way the writing of CSS: The Definitive Guide has come to mirror CSS itself — split up into modules that can be tackled independently of the others, and eventually collected into a snapshot tome that reflects a point in time instead of an overarching version number.

Every pre-book is a significantly updated version of their third-edition counterparts, though of course a great deal of material has stayed the same.  In some cases I rewrote or rearranged existing sections for greater clarity, and in all but “CSS and Documents” I’ve added a fair amount of new material.  I think they’re just as useful today as the older editions were in their day, and I hope you’ll agree.

Just to reiterate, these are the three pre-books currently available:

• CSS and Documents (free)  —  the basics of CSS and how it’s associated with HTML, covering things like link and style as well as obscure topics like HTTP header linking
• Selectors, Specificity, and the Cascade  —  including all of the level 3 selectors, examples of use, and how conflicts are resolved
• Values, Units, and Colors  —  fairly up to date, including HSL/HSLa/RGBa and the full run of X11-based keywords, and also the newest units except for the very, very latest — and as they firm up and gain support, we’ll add them into an update!

As future pre-books come out, I’ll definitely announce them here and in the usual social spaces.  I really think this is a good move for the book and the topic, and I’m very excited to explore this method of publishing with O’Reilly!

• ‘CSS: The Definitive Guide’, Fourth Edition was published on Monday, October 1st, 2012.
• It was assigned to the CSS, Projects, Standards, and Writing categories.
• There have been thirty-two replies.