meyerweb.com

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

Archive: June 2012

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!

Parking Lot Safety

When you have children who are new to walking, getting things out of a car while in a parking lot can be a nerve-wracking experience: you know that your kid is capable of walking in any direction, and also that they’re not really aware of the dangers a parking lot can contain.

Following the philosophy of “don’t baby-proof the environment, make the baby proof for the environment”, we had two parking lot rules that worked out pretty well, used for different stages of development.

  1. Hand on the car.  When out of the car, one of the child’s hands must always be touching the car unless a parent is holding their hand.  This sets a bound on how far away they can get from you.
  2. Feet on the yellow line.  The lines separating parking spaces are treated as if they’re balance beams.  The child can walk along the line, but not step off of it, unless a parent is holding their hand.  This keeps the child between cars and away from the flow of traffic.

Obviously, these require training periods, and during that training you have to keep an eagle eye on the kid.  And of course you can’t rely on these rules to keep your children completely safe in a parking lot—only you can do that.  In our experience, though, it greatly reduced our stress levels even in busy Christmas-time lots; plus, it was another way to stress the importance of both safety and obedience.

June 2012
SMTWTFS
May September
 12
3456789
10111213141516
17181920212223
24252627282930

Archives

Feeds

Extras