meyerweb.com

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

Archive: 'Tech' Category

Cicadients

I’ve been a fan of “The Cicada Principle” since it was first published.  After wandering through a CSS gradients gallery or two back in April, it occurred to me that it ought to be simple to merge the two things.  So I did: thus was born “Cicadients”.  It took me until now to actually blog about it because, well, you know, things were, hey, what’s that weird thing over there?

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!

Visualizing Colors Again

Just a quick followup on HSL color visualizations and CSS: The Definitive Guide.

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?

Combining ‘nth-of-type()’ With Negation

I just recently came across one of those things that’s really obvious once you stop to think about it, and might be really obvious if you think about it from the right angle, but can trip you up if you come at it from a slightly different direction.

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.

Visualizing Colors in HSL Space

I’ve been working through and rewriting the chapters of CSS: The Definitive Guide for its fourth edition, and at present I’m nearing the end of chapter 4, “Values and Units”.  That means I just worked through the color values, which required a lot more of a rewrite than you might think.  After all, when the third edition came out, RGBa, HSL, and HSLa weren’t viable options, so they didn’t get coverage.  Expanding the color-values section to incorporate them posed two major challenges.

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!

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.

A Precise CSS3 Color Table

In the course of expanding my documentation of color values, I failed to find a table that listed all 147 SVG-and-CSS3-defined keywords along with the equivalent RGB decimal, RGB percent, HSL, hexadecimal, and (when valid) short-hex values.  There were some tables that listed some but not all of those value types, and one that listed all the value types (plus CMYK) along with a few hundred other keywords, but none that listed all of the CSS keywords and value types.  And none that I saw used precise values for the RGB percent and HSL types, preferring instead to round off at the expense of some subtle differences in color.

So I created my own table, which you can now find in the CSS area of meyerweb.  Most of it is dynamically generated, taking a list of keywords and RGB decimal equivalents and then calculating the rest of the values from there.  The presentation is still a work in progress, and may change a little or a lot.  In particular, if I can’t find a better algorithm for determining which rows should have white text instead of black, I’ll probably shift away from the full-row background colors to some other presentation.  (Update: it’s been greatly improved, so I’m sticking with the full-row backgrounds.  For now, anyway.)

My thanks to Tab Atkins for his donation of the RGB-to-HSL routine I adapted as well as help improving the pick-light-or-dark-text algorithm; and to the people who responded positively on Twitter when I mused about the idea there.

Update 25 May 12: the table now allows sorting (both directions) on the Keyword, RGB Decimal, and HSL columns.  The sorting and styling code uses methods like el.classList.remove() so it may not function well, or at all, in older versions of Internet Explorer.  The numeric sorts also appear to be borked in Opera and Chrome for no reason I can discern, and it’s not like I did anything fancy in the JavaScript—exactly the opposite, I’d wager.  (Speaking of which, I’m sure my JavaScript is an non-stop amateur-hour horrorshow.  I’m okay with that.  If you aren’t, you might want to avert your gaze.)  If there’s a simple fix that doesn’t screw up other browsers, like Safari and Firefox, I’m interested.  If not, then we’ll all just have to live with it.

Update II 25 May 12: thanks to the folks who responded to my question over at StackOverflow as well as on Twitter, the sorting is now stable across browsers.  Bonus: I feel like thanks to everything I’ve learned along the way, the JavaScript in general is getting halfway to decent.  Go me.

As always: share and enjoy!

Backgrounds, Shadows, Fonts, and the Cascade

The fact that this:

h1 {color: red;}
h1 {color: green;}

…results in green h1 text, but this:

h1 {background:
	url(red-wave.gif) repeat,
	url(green-wave.gif) repeat;}

…results in a red wavy h1 background does my head in every single time.  And it’s the same with text and box shadows, too!  In cases where backgrounds or shadows overlap, the first one you write “wins”, by virtue of being “in front of” the background images that are listed after it.

I know that font stacks are also done in order of most-to-least preferred, but I don’t see them as being equivalent.  The reason is that a font stack is a list of fallbacks—use this face unless it can’t render the glyph or doesn’t exist, in which case try the next one in the list, etc., etc.  Multiple background images and multiple shadows, on the other hand, are not a series of fallbacks.  I expect to see them all, unless I made a mistake of some kind; and I do, constantly, because of this disconnect.  Sure, one could use the multiple background image syntax to create a series of fallbacks—first an SVG file, second a PNG, third a GIF—but that’s not its primary purpose, and I certainly wouldn’t teach multiple background images that way.  That’s not what they’re designed to do.

Maybe writing the problem down here will purge this daemon, but in all honesty, my hopes are not terribly high.

November 2014
SMTWTFS
September  
 1
2345678
9101112131415
16171819202122
23242526272829
30  

Archives

Feeds

Extras