Tag Archives: CSS

RGBa and -webkit gradients: Yes.

When @malarkey asked if RGBa worked with -webkit gradients, my own curiosity couldn’t resist a quick and fugly test to see. Yes indeed, it works:


Screen shot showing green bleed-through on a -webkit gradient div

The woes of CSS color in print typography

Smoking Room/Prayer Room

As I was working through some documentation on styling CSS for print recently, I came across an oddity. Colors that I was specifying in my print styles were not getting represented properly at print time. Specify a nice shade of gray for some text? Maybe want to ghost print something very lightly on the printed page. No – not in Firefox. In fact, any shade of gray comes out as black in Gecko browsers. This behavior is only slightly more intelligent in Safari and IE7, but in all cases the user agent makes an assumption about what color of text constitutes being “too light” and then defaults to a darker shade of pale that is handled inconsistently across the various browsers. Printing font colors appears to be a messy situation.

Now the reason why the browser vendors have made this assumption is clear: Printing light text on what is almost always white paper is largely unreadable. Furthermore, printing in pure black, devoid of any complex color mixing, can make printing much faster, because the printer doesn’t have to mix in any red, green, or blue ink and can focus on getting the task done. But what is maddening to the designer trying to achieve accurate color representation in print from their web pages is that all of the major browsers assume that they are smarter than the designer, and recolor the text based on their own inconsistent algorithms. Actually, that may be assuming a bit much on the part of the browsers – sometimes the results defy logic.

To investigate further, I created a testing page. This page runs through some of the various color gamuts and creates a list entry for a number of color variations. The results are surprising… Here are some findings:

  • Safari 3: Between rgb(0,0,0) and rgb(107,107,107), things appear fine. But then there is a breakdown between rgb(108,108,108) and rgb(127,127,127) where the text will randomly jump to a light gray – equivalent of rgb(199,199,199). For lack of a better term, I call this area “The Dead Zone,” and we will see it again soon. At rgb(128,128,128), the text color then jumps to black and as you ascend the values towards an expected white color, Safari yields a progressive amount of additional lightness to the text until it finally winds up at around rgb(171,171,171) where it should be 255 for all values.

    The Dead Zone also occurs in the red, green, and blue colorspaces. If you fix red at 127, about halfway between the minimum value of 0 and the maximum value of 255, we get a dead zone between rgb(127,100,100) and rgb(127,127,127). Same ratios happen starting at rgb(100,127,100), and at rgb(100,100,127).

    Finally, Safari renders rgb(0,255,255), rgb(255,0,255), and rgb(255,255,0) inconsistently from their adjacent color values.

  • Gecko browsers such as Firefox, Camino, and Flock print the entire gray space in black. (Exception: Firefox 3 will actually print the color exactly right – see below.) You cannot specify a light gray such as rgb(127,127,127) or anything else. It will always default to pure black whether you like it or not. If you fix a color bucket at 0, you will get semi-accurate color for the rest of the gamut, but the other color combinations will trend towards black text the lighter it gets.

  • In Opera 9, gray shades render accurately up until rgb(185,185,185), and then higher values default to black. In the points tested, the same conversion to black happens after values higher than rgb(127,211,211), rgb(255,156,156), rgb(87,255,255), rgb(209,209,0), rgb(193,193,127), and rgb(177,177,255).

  • IE7 never gets any lighter than rgb(108,104,102) for grayscale, and the rest of the color spaces don’t seem to allow anything lighter than a midrange hue equivalent to around 110 for any given value.

  • One last thing about Gecko browsers: The marker (the little bullet to the left of each list item) will display the correct color value in print, even though the text itself won’t match! Underlines/Overlines/strikethrough will match whatever color the text is though. So at least here you can see what the color was supposed to be…

  • The exception as mentioned above is Firefox 3. Firefox 3 has been tested to print the colors exactly as you see them on screen, and is the only browser thus far that works this way in a predictable manner.

The conclusion I draw from all of this is that color in CSS print typography is woefully inconsistent, and I do recommend defaulting to black text in most cases simply because it is so problematic to predict what color you will actually wind up with in print. If you need color, go with a darker shade and test your print output in the four major modern browsers (IE, Safari, Firefox, Opera) to see what you can get away with.

Please feel free to try the test suite for yourself and let me know your findings in the comments or via a pingback.

Foundation Website Creation with CSS, XHTML, and JavaScript

In a real bookstore

I would have announced this earlier, but somehow with the trip to Taiwan, the subsequent jet lag, and the whopper of a cold I had this past week has delayed me from getting this post out until now. But here it is: My book titled “Foundation Website Creation with CSS, XHTML, and JavaScript” is now out! I saw two copies of it today on the shelf at Barnes & Noble in Walnut Creek earlier today (pictured).

This project came up at a real interesting time. I was just starting the final quarter of my masters degree program through University of Denver in computer information systems, and the last thing I wanted to do was to take on extra work. But of course, this opportunity to collaborate on this project was too good to pass up, so I opted for no sleep for a few months and somehow got both done last June. Man, it feels good to be done.

My fellow authors Jonathan Lane and Meitar Moscovitz and I have put together a book that covers a professional introduction to the core technologies involved in front-end website development. In it we have tried to convey modern best practices from a web standards perspective as well as from a user-centric project management perspective to give the emerging web developer a solid foundation as to what to expect in a professional web design workflow. I hope the readers of this book find the information contained therein to be valuable platforms for further exploration and learning.

The book may be ordered from Amazon, and you might even find it on a local bookstore shelf!

The non-importance of !important

Molly Holzschlag raised a good issue via Twitter yesterday regarding the !important rules in CSS, reprinted here in more or less the order in which her tweets appeared thus far:

TwitterPoll: What does this mean to you? !=

TwitterPoll follow-up. What does this mean to you? !=good

TwitterPoll: Let’s remove the equal sign. What does this mean to you !good

yes, yes, I’m asking ultimately how the fuck !important means BANG IMPORTANT when realistically it should mean not important.

re: !important in CSS? Kill it. Specificity to the rescue.

Say it ten times fastL Specificity, specificity, specificity. Forget !important. Write specific selectors sez me. And night night!

I love Twitter. When it is up and running that is… πŸ˜‰ Such a lively place for discussion.

Random photo of Taroko Gorge from my recent Taiwan trip, just for color.

Molly makes an excellent point here. My little position with the !important rule is that I always thought this to be somewhat of a funny-looking construct. It is just as Molly points out – the exclamation point preceding the word ‘important’ is odd, kind of stuck on there, and is especially confusing to those of us coming from that programming background where the ! means ‘not’ – as in != reading ‘not equal’ and that sort of thing.

The construct itself is generally frowned upon in production-level CSS code. The specificity of the !important rule overrides anything with normal inheritance values, and if your code is littered with it then you really need to go back and look at what your rules are doing with regards to the cascade. A good production stylesheet should be free of any !important rules.

I take from Molly’s tweets that she argues in favor of abolishing the !important construct and that people should use the cascade properly. While I understand this position and agree with it on a philosophical level, I think somehow this functionality should be retained. My proposal is as follows:

  1. Change !important to just important, doing away with the confusing exclamation point and instantly making CSS more legible
  2. Make some declaration that user agents should ignore the exclamation point and really just pay attention to the word “important,” for the sake of legacy support. Yeah more detail is needed here, but you get it.
  3. Make validation issue an explicit warning stating that important should only be used for debugging purposes.

How this would look in the wild:

#hyrule {
  color:blue important;
}

Not a big change really, but it gets rid of the somewhat confusing exclamation point, gets us more towards the ideal which is reduced abuse of the rule in question, and promotes better use of the cascade.

Yes that photo is completely random given the context of this discussion, but I thought it was pretty and it reminds me that I need to do a follow-up on my recent Taiwan vacation… πŸ˜‰

iPhone and mouse events

PPK has written his impressions regarding his shiny brand-new Jesusphone. (I wonder did he get black or white?)

In his post, he tells us the initial reports for the behavior of mobile Safari with regards to things like documentation (missing), mouse event implications (game changing), and how the disjunct state of finger tapping and dragging compares with the continuous state of the traditional OS desktop mouse pointer. In particular, he points out the fact that the assumed ever-present mouse pointer (the little cock-eyed arrow which points black and to the upper left on Mac, and is white and points to the upper right on Windows) can no longer be counted on. And in fact, there is no icon any more. Your fingertip is it, my friend!

With the coming of the iPhone the mouse model has lost its inescapable logic. Mousemove, mouseover and mouseout (and even poor old :hover) have been downgraded to device-specific events that may not survive in the long run.

May not survive… hmmm, interesting impact. I think he could be right here.

But β€” and here lies the problem β€” these events are used in countless web sites and applications for a variety of purposes, and Apple simply cannot afford these sites not working on the iPhone.

Interestingly, so far Apple has found that it indeed can afford to dispense with Flash and Java on the iPhone platform, and while most complain that the checkbox isn’t complete, some argue that Apple is doing just fine and won’t be in any hurry anytime soon. Certainly demand for these babies has been extremely high so far. I would be interested to see how many of such sites absolutely depend on such functionality to work, and how many of those either change their site behaviors or create iPhone-friendly web presences as the demand for the mobile web increases. Wondering… but at the very least, things like these aforementioned mouse events – Flash, Java, and the like – are not yet queued up on Apple’s priority list, or else they chose to take the less-is-better approach. It is an interesting question: How much of the specifications do browser vendors adhere to on such a limited platform such as mobile devices? What is practical? What is feasible?