That’s not at all minor point.  I don’t believe it overstates the case to say that if CERN hadn’t made the web free and open to all, it wouldn’t have taken over the net.  Like previous attempts at hypertext and similar information systems, it would have languished in a niche and eventually withered away.  There were other things that had to happen for the web to really take off, but none of them would have mattered without this one simple, foundational decision.

I would go even further and argue that this act infused the web, defining the culture that was built on top of it.  Because the medium was free and open, as was often the case in academic and hacker circles before it, the aesthetic of sharing freely became central to the web community.  The dynamic of using ideas and resources freely shared by others, and then freely sharing your own resources and ideas in return, was strongly encouraged by the open nature of the web.  It was an implicit encouragement, but no less strong for that.  As always, the environment shapes those who live within it.

It was in that very spirit that Dave Shea launched the CSS Zen Garden ten years ago this week.  After letting it lie fallow for the last few years, Dave has re-opened the site to submissions that make use of all the modern capabilities we have now.

It might be hard to understand this now, but the Zen Garden is one of the defining moments in the history of web design, and is truly critical to understanding the state of CSS before and after it debuted.  When histories of web design are written—and there will be—there will be a chapters titled things like “Wired, ESPN, and the Zen Garden: Why CSS Ended Up In Everything”.

Before the Zen Garden, CSS was a thing you used to color text and set fonts, and maybe for a simple design, not for “serious” layout.  CSS design is boxy and boring, and impossible to use for anything interesting, went the conventional wisdom.  (The Wired and ESPN designs were held to be special cases.)  Then Dave opened the gates on the Zen Garden, with its five utterly different designs based on the very same document…and the world turned.

I’m known to be a history buff, and these days a web history buff, so of course I’m super-excited to see both these sites online and actively looked after, but you should be too.  You can see where it all started, and where a major shift in design occurred, right from the comfort of your cutting-edge nightly build of the latest and greatest browsers known to man.  That’s a rare privilege, and a testimony to what CERN set free, two decades back.

@supports (text-decoration: blink) {
	#test {
		color: green;
		background: yellow;
		text-decoration: blink;
	}
}

Results in all @supports-supporting browsers I was able to test: green text on a yellow background, except Firefox 22, which additionally blinks the text.  The latest nightly builds of Firefox 23 do not blink the text, thanks to bug 857820.

Discuss.

I mean, what do you think @supports means?  Take a moment to formulate a one-line definition of your understanding of what it does, before moving on to the rest of this piece.

If you’ve never heard of it before and wonder how it works, here’s a very basic example:

body {background-color: white;}
@supports (background-color: cornflowerblue) {
	body {background-color: cornflowerblue;}
}

The idea is that if the browser supports that property:value combination, then it will apply the rule or rules found inside the curly brackets.  In this sense, it’s just like @media rules: if the conditions in the parentheses are deemed to apply, then the rules inside the declaration block are used.  The module refers to this ability as “feature queries”.

There are some logical combination keywords available: and, or, and not.  So you can say things like:

body {color: #222; background-color: white;}
@supports ((background-color: cornflowerblue) and (color: rgba(0,0,0,0.5))) {
	body {background-color: cornflowerblue; color: rgba(0,0,0,0.5);}
}

Okay, but what does that actually mean?  Here’s what the specification says:

A CSS processor is considered to support a declaration (consisting of a property and value) if it accepts that declaration (rather than discarding it as a parse error). If a processor does not implement, with a usable level of support, the value given, then it must not accept the declaration or claim support for it.

So in that first sentence, what we’re told is that “support” means “accepts [a] declaration” and doesn’t drop it on the floor as something it doesn’t recognize.  In other words, if a browser parses a property:value pair, then that qualifies as “support” for said pair.  Note that this sentence says nothing about what happens after parsing.  According to this, a browser could have a completely botched, partial, and generally unusable implementation of the property:value pair, but the act of recognizing means that there’s “support”.

But wait!  That second sentence adds an additional constraint, after a fashion: there must be “a usable level of support”, the lack of which means that a browser “must not…claim support”.  So not only must a browser parse a property:value pair, but support it to “a usable level”.

But what constitutes a “usable level”?  According to everyone who’s told me that I was wrong about vendor prefixes, any browser implementation of a feature should be complete and error-free.  Is that what’s required to be regarded as a usable level?  How about if the implementation has one known bug?  Three?  Ten?  Can any of them be severe bugs?  What about merely serious bugs?  What if two browsers claim usable support, and yet are not interoperable?

So.  How does the definition of @supports match the one-line definition I asked you to formulate, back at the beginning?  Are they exactly the same, or is there a difference?

I suspect that most people, especially those coming across @supports for the first time, will assume that the word means that a browser has complete, error-free support.  That’s the implicit promise.  Very few people think of “supports” as a synonym for “recognizes” (let alone “parses”).  There’s a difference, sometimes a very large one, between recognizing a thing and supporting it.  I’m sure that browser teams will do their best to avoid situations where a property:value pair is parsed but not well supported, but it’s only a matter of time before a “supported” pair proves to be badly flawed, or retroactively made wrong by specification changes.  Assuming that such things will be allowed, in an environment where @supports exists.

If feature queries were set with @feature, as media queries are set using @media, or even if the name were something along the lines of @parses or @recognizes, I’d be a lot less bothered.  The implicit promise would be quite a bit different.  What I feel like we face here is the exact inversion of vendor prefixes: instead of a marker for possible instability and a warning that preserves the possibility of changing the specification when needed, this pretends to promise stability and safety while restricting the WG’s ability to make changes, however necessary.  My instinct is that @supports will end up in the same place: abused, broken, and eventually reviled—except this time, there will be the extra bitterness of authors feeling that they were betrayed.

So how did they do it?  With CSS.  Here it is:

.tweet-display-linebreaks .tweet .js-tweet-text{
	white-space:pre-wrap
}

That’s it.  I’m not going to comment on their selector construction, except in the meta sense that I just did, but that single rule is all it took.

Well, not quite all.  The other thing they’ve done is to trim off any leading or trailing whitespace, and make sure the tweet’s content is right up against the opening and closing tags of the element.  It looks like so:

<p class="js-tweet-text">Y’all ready for this?</p>

When I input that tweet, it was like this, extra linefeeds and all:

Y’all ready for this?

So why do they trim off the edges?  Because if they left any whitespace between the tags and the content, pre-wrap would honor it.  This would happen even if Twitter, and not the author, was the source of the linefeeds between tags and content.  So rather than just ensure the content was placed normally, without any extra space, they went the trim($tweet) route.  I’m sure there are ways to beat the trimming; I haven’t tried to find them.  And there may be perfectly good reasons why they went the trim() route.  Maybe someone from Twitter will drop by to fill us in.

I will also note that white-space: pre-wrap preserves spaces between characters, just like pre elements do.  That means that anyone who double-spaces after sentences will have that space show up in their tweets, for everyone else to see.  Just like with the line breaks, author intent is thus preserved.  Deal with it.

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.

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.

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.

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.

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!

What?

As a recap, the Cicada Principle states that if you pick a few simple patterns that repeat at prime-number intervals, you can create complicated patterns that only repeat at intervals that are the product of the individual intervals.  For example, if you have patterns that repeat every 3, 5, and 7 pixels (respectively), the combination of the three will repeat every 3×5×7 pixels, which is to say every 105 pixels.  Bump up the intervals, and you get some truly staggering numbers.  For example, shift up to 7, 11, and 13 pixels and their combination repeat every 1,001 pixels; combining 11, 13, and 17 gets you 2,431; combining 13, 17, and 23 yields 5,083.

The examples presented in the original article use semi-opaque PNGs to achieve this effect.  All I did was replace their images with images of my own; to wit, CSS gradients.  (Yes, gradients are images, every bit as much as any PNG.  They’re just described differently.)  In doing so, I not only reduced server hits, but I also saved a fair number of bytes.  In the first case, I did so while achieving pixel-perfect fidelity to the original.  In the second case, I didn’t make it exactly the same as the original, but I got fairly close in 0.63KB (2.81KB with prefixes).  I could probably get closer to the original with a little more effort—a couple of my gradients are a little too smeary—but that will probably wait a while, if I ever get to it at all.  But, again, the final result is a kilobyte or two; the original example was 23KB plus extra server hits.

That was the real reason for my efforts, aside from the simple pleasure of doing it: to find out how much more efficient a gradient could be than a raster image in appropriate situations.  I had expected some savings with gradients, but I was frankly astounded by how much was saved.  You can do a lot more with gradients than sunset backgrounds and lickable button highlights.

Of course, gradients are not right for every situation: the third example in “The Cicada Principle”, for example, should only be done with gradients as an example of how not to do it.  Possibly also as a public declaration of deep masochistic tendencies.  Either way, you’d probably crash browsers, and that’s currently the job of radial gradients.

I’ll be very interested to see if people come up with their own cicadient examples.  If you do, let us know about them in the comments!

To take those two things in reverse, I got word from my editor that color is definitely an option for the book, though the exact form it will take is not 100% certain.  The options range from an insert of color plates to printing color on a per-page as-needed basis, and it’s hard right now to know what will make the most sense for the book and its price.  We’re hoping for the per-page approach, but it will depend on just how fast color prices plunge in the near(ish) future and what the book requires.  The glorious, glorious upshot is that I can abandon all thought of grayscale requirements and only concentrate on avoiding light yellows, which I guess print badly.

As for visualizations, I created another to go with the HSL-16 and HSL-147 visualizations I mentioned in an earlier post:

• Getting HSL from RGB — a look at how the arrangement and fading of the three primaries yields the complete hue wheel.  Its point is a little less obvious than the others, but (I hope) only by a little.  If you’ve ever wondered how RGB and the hue part of HSL relate to each other, this visualization should help answer the question.

I think I’m done with visualizing colors for now, but I think I said that before, so you never know.  I mean, you know, colors, man!  What do they mean?

Consider the following two rules, which are equivalent:

li:not(.skip):nth-of-type(odd);
li:nth-of-type(odd):not(.skip);

First off, the order doesn’t matter.  The result is exactly the same no matter which way you write it, which is why I wrote the same thing twice.

Either way, the selector will select the odd-numbered li elements that share a common parent, but not those which have a class of skip.  What it does not do is select the odd-numbered li elements without a class of skip that share a common parent.

Did you catch the distinction?  Natural-language ambiguity (languaguity?) may obscure the precise meaning.  Here’s some example markup (adapted from a test file I set up):

<ul>
   <li>Item 1</li>
   <li>Item 2</li>
   <li class="skip">Item 3</li>
   <li>Item 4</li>
   <li>Item 5</li>
   <li>Item 6</li>
</ul>

The list items selected by either of the previous selectors will be numbers 1 and 5.  Numbers 4 and 6 will never be selected, because they are not odd-numbered members of this set of li elements.  Remember, nth-of-type() refers to element types, as in li or p or h4.  It doesn’t refer to “this type of thing that I am trying to describe here in this whole selector”.

Another way of stating this is that the negation pseudo-class does not act as a filter for the :nth-of-type() portion of the selector.  There is no “do this, then that” ordering of pseudo-classes.  They must both apply, considered independently of each other, for an element to be matched.  (This may remind you of the effects caused by the lack of element proximity, though the root causes are rather different.)

There is a (fairly solid-looking) proposal in CSS4 Selectors called :nth-match() that should allow authors to set up a condition where list items 4 and 6 get selected—for example, :nth-match(odd of li:not(.skip)), unless of course the syntax gets changed—but that’s for the future.  For now, if you need to select every other element of a matched set, you’ll need some scripting to help you out.

First, I couldn’t just drop them in as add-ons; the whole section had to be partially rearranged, and chunks of the text rewritten or replaced.  Okay, yes, I admit, that’s par for the new-edition course, and I’m not complaining so much as describing.  The far more troubling challenge: how to explain HSL in a grayscale book.

(I should note that I’m hoping to convince O’Reilly to make the move to color, even though that likely means reshooting damn near every figure in the text.  Even if full color for 600-700 pages is not economically viable, which has always been the problem in the past, then I’m hoping for at least a set of color plates.  We’ll see!  At present, though, I have to assume we’ll be committing grayscale to paper.)

Partly the challenge here is one of clear explanation and illustration, which is never easy even in the most ideal of environments; but the other part is that I’ve never really been comfortable with HSL.  I know it’s held to be far more intuitive than RGB, but I have 30 years of RGB experience and next to no HSL experience.  I can’t help but have that color my perception (ah HA ha).

In an effort to overcome my discomfort, I started messing around with the relationships between HSL and more familiar colors, starting with keyword sets.  I’ve spun two visualizations out of that effort:

• HTML4 Color Keywords in HSL—wherein I map the sixteen color keywords defined in HTML4 onto an HSL color wheel and grayscale bar.  What I really like about the end result is the clear evidence of careful color selection.  It’s a balanced set, at least mathematically, and seeing the relationships between the colors and thus how to present them helped me develop a fair amount of HSL intuition.

  This was also an excuse to attempt cleverness with CSS Transforms.  The results please me.

• SVG/CSS3 Color Keyword Distribution—mapping out how the full set of 147 SVG/CSS3 (neé X11) color keywords are distributed around the hue wheel.  Not very well, as it turns out.  I don’t know that this taught me very much about HSL itself, but I did get a firmer grip on the interplay between saturation, lightness, and luminance, all of which helped a great deal in the arrangement of the ‘spikes’.

  This one turned into an excuse to play with canvas drawing, after Mårten Björk responded to a Twitter request with a huge head start on the problem.  Originally, this was going to be another Transformapalooza, but I’m glad it went in this direction instead.

Thanks to these visualizations and (more importantly) the programming and thinking I did to create them, I’m now much more comfortable with HSL.  As a result, the “HSL and HSLa Colors” section of chapter 4 is a lot better than it would have been.  I even came up with what I think are some pretty good ways for illustrating HSL in a grayscale environment and ways to link it to the RGB model for the benefit of people like me.  The book will be a lot better for it when it finally comes out.  In the meantime, I hope you enjoy the visualizations!

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.

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.