San Bei Ji » CSS

Coloring the HR element line in CSS

Joe — Wed, 07 Dec 2011 00:37:31 +0000

I never, ever use this element, but HR has been bequeathed new life in HTML5 and I may start using it for providing more thematic break awesomeness to my already blindingly-awesome prose and poetry.

Anyway, someone asked me this question: Is color supported in all browsers by the HR element? To which I replied: “I have no clue. Let me investigate.”

Here’s an initial test:

HR colors I have known... blue:



    red:

    


    green:

Well hambone. Using the text rule for color on WebKit browsers yields no color change. Works fine in all cases in Firefox. IE gives no quarter to the border-color CSS property, but works fine with the text color value. Every browser supports HTML color attributes, but you know that using presentational markup is as wrong as Michelle Bachmann’s views on evolution and vaccination, so you just say no.

So what’s a poor web dev to do? Define a border width:

.red { border:none; border-bottom:thin solid red; }

Replacing the original border-color rule with the shorthand listed here, or just providing an explicit border-width property, will render a consistent 2 pixel line in all browsers. If we just wrote something like border:thin solid red; we’d get a 2-pixel border – see you’d think the HR element is just a line, but in fact the browsers all treat it like a box it seems. So we have to clear it out with border:none; and then add a border-bottom or border-top rule to set a 1 pixel line. If you want different widths, you have arguably more accurate control by only having to argue with one border instead of two.

What… you want to replace that HR with a background image? Good idea. Check out this post at Neatly Sliced for the answer, and gird your loins for the usual IE kludgeries.

A quick book review: Responsive Web Design

Joe — Mon, 14 Nov 2011 19:30:57 +0000

Just finished reading an excellent book: “Responsive Web Design” by Ethan Marcotte. If you build web pages, I want you to read this book. Here’s a few of my thoughts on what I just learned, and why you should read this one too.

The book begins with an overview of the evolution of page layout in web design, starting with it’s roots in printed page design and moving on to today’s reality that there is a multitude of screens and devices out there, with more on the way. We cannot predict what type of device our readers will show up with, and must adjust our belief system (if we have one) to accommodate the new realities that the various screen widths and mobile device sizes present us with.

The second chapter discusses the idea of designing within the constraints of a flexible typographic grid. Grid systems are somewhat of an artificial constraint that designers place on themselves to provide balance and symmetry to page layout, and on screen a new challenge is presented in that the page size is no longer fixed. The main takeaway here is to design content in flexible porportions to the variable screen widths that might be used to access your web pages. Mr. Marcotte puts forth some simple, accessible ideas for developers to leverage, making text more readable on unknown devices by putting forth a formula that I’ll repeat here mostly for the purposes of getting my own head wrapped around it:

target ÷ context = result

To decode Mr. Marcotte’s example, he begins with an assumption of a base font size of 16px. The headline in the comp is defined to be 24px. So to make it flexible, divide:

24 ÷ 16 = 1.5

And so the headline should be defined as 1.5em. Simple and elegant rule of thumb. Now we just need to remember to do it.

Chapter 3 applies this principle to flexible images, and expands upon it. There is the inevitable Questionable Functionality Challenge™ presented to us by Internet Explorer, which is quickly defused. That’s a lot of ink to dedicate to an obsolete web browser and the example demonstrates where the real problem lies by showing how awful text looks in resized images. But you aren’t locking up text in your images, right? I know, I know, it’s an academic example and clearly illustrates the failings of IE’s image resize capabilities. Let’s move on.

Chapter 4 introduces media queries. We’re finally at what I consider to be the coolest and most important part of the book – how to progressively enhance your web page layouts through the media query construct. Mr. Marcotte makes the argument in favor of using the min-width property instead of things like max-width (which tends to yield excessive code) and min-device-width (which only pertains to devices and doesn’t take into account variable web browser windows.) The max-width property is introduced for those that want to stop the insanity. (I do know people that expand their web browser to the full width of their 27″ high resolution monitors.)

Chapter 5 pulls it all together with strategies to integrate responsive design into your team’s workflow; how to make your design process itself a responsive one. He builds the case for Luke Wroblewski‘s “Mobile First” philosophy (a case that was already built up a bit in chapter 1) and finishes it all of with how to incorporate progressive enhancement using JavaScript to selectively pull in a slideshow component only when JavaScript is available and all the stars are in the proper alignment.

Overall, my belief has always been somewhat of the philosophy that there should be just “one web”; no “mobile web” or any other sort of alternate web reality that we should somehow slip into. Today’s mobile devices that are in fact being used to access the web are billed as fully capable web browsing devices, and indeed they are. Why deliver a shrunken-down version of your website just because they have a 3″ wide screen these days? It no longer makes sense in most cases; just reposition your content to accommodate their view. Every chapter includes simple, usable techniques that work, and I feel that these gems of advice should be a core part your future projects.

Lastly, I am very thankful for the appearance of the A Book Apart series. Each one of these volumes is, I believe, how a tech book should be: concise, full of valuable, practical, actionable information. I have read several of these so far, and each one has been a hit. I look forward to more.

Cheatsheet from today’s Open Web Camp “Refactoring for Mobile” talk

Joe — Sun, 18 Jul 2010 05:56:09 +0000

For the Open Web Camp attendees, here’s my cheatsheet from the Refactoring for Mobile talk I gave today at Stanford:

Get it as a CSS file and view it in your favorite code editor:

walkthrough.css

Or preview here:

/* The first thing we need is a media query and to add to the head: */ @media only screen and (max-device-width:480px) { /* For starters, note the two divs #wrapper and #contents. Let's use those to create our structural layout and fold back in some of those design elements. */ #wrapper { background:url(img/back2.png) no-repeat center top; margin-top:-1em; } #contents { text-align:left; width:95%; margin:0 auto; } /* Now, let's style the main navigation buttons. First, we will use inline-block to give block-like behavior to the buttons but retain width based on the content. Then we set the color, font size, and floating, and add a bit of box shadow. */ .menu a { display:inline-block; background-color:#000; float:left; font-size:14px; padding:1em 0.95em; border-left:1px solid #888; -webkit-box-shadow:0px 1px 5px #222; } /* We can now use border-radius to style the left and right buttons instead of image files: */ .first_menu a { border-bottom-left-radius:6px; border-left:none; margin-left:2px; } .menu li:last-child a { border-bottom-right-radius:6px; } /* What if we flip to Landscape? There's a media query for that: */ @media screen and (orientation:landscape) { .first_menu a { margin-left:78px; } } /* Now we can style the body content. #middle-contents is the main containing block. We can use the background image from the main stylesheet, but alternately we can use rgba backgrounds to get finer control. Add border radius and box shadow for depth. */ #middle-contents { /* background:url(img/side.png) repeat-y;*/ background-color:rgba(0,0,0,0.3); padding:1em; border-radius:10px; -webkit-box-shadow:0px 1px 6px #000; box-shadow:0px 1px 6px #000; font-size:1.2em; margin-bottom:1em; } /* Let's style the banner text and have some fun with it using web fonts. Here's a font we'll pull in, using TTF and SVG formats. Sadly, the vendors have many opinions on the solution, but FontSquirrel can help sort it out. */ @font-face { font-family:'Lobster'; src: url('Lobster_1.3-webfont.ttf') format('truetype'), url('Lobster_1.3-webfont.svg#webfontcOtP3oQb') format('svg'); } #logo a { display:block; text-align:center; padding-top:12px; font-family:Lobster, sans-serif; font-size:2.7em; text-shadow:0px 2px 4px #000; } #logo h1 { font-family:Lobster, sans-serif; text-align:center; font-size:1.5em; } /* The float is creating a spacing issue. We can fix that with a clear: */ #header { clear:both; } /* We are getting close. Now on to the bottom of the page. The #comments section is too wide. We need to reset it: */ #comments { width:100%; } #comments textarea, #comments input { width:93%; margin-bottom:0.5em; padding:0.5em; font-size:1.2em; border:1px solid #000; border-radius:6px; } /* That input button could be nicer: */ #comments input.button { display:block; width:80%; margin:0 auto; height:2.5em; padding:0.5em; } /* Now we have something that looks like it was meant for a mobile device. Let's wrap this up by making the final links look like tap-friendly buttons: */ #right-col a { display:block; padding:0.5em; font-size:1.3em; font-weight:bold; text-align:center; background-image: -webkit-gradient(linear, left top, left bottom, from(#666666), to(#666666), color-stop(.5,#333)); border:1px solid #000; border-radius:20px; margin-bottom:0.4em; } /* Maybe those final link items were over the top. Let's restore them to inline links: */ #copyrights a { display:inline; margin:0; padding:0; font-size:small; border:none; background-image:none; } } /* Now add some HTML5: Add placeholder="I think..." to the textarea in comments.php, line 191. Add input types to email and url fields. Finish with atouch icon: (Note to attendees: I forgot to add the piano.png file to my project files. But this works otherwise!) */

Doll up your tabular data

Joe — Sun, 09 May 2010 06:25:06 +0000

In the science realm, we are often confronted with having to look at a dizzying number of flat tables representing experimental data. It wouldn’t hurt to spend a little time thinking about how that information is displayed in it’s native format. And often when we see tables that are ‘nice’, they are rendered as an image, thereby shielding wary and hapless internet searchers from all of the rich and informative data contained therein. I’m often asked to provide feedback on these things, so I was pleased to find a little tutorial with some nice examples of styling tables using CSS3 that I can throw out there. Here you go!

Pimp Your Tables with CSS3 | Codrops

In defense of the vendor prefix

Joe — Mon, 22 Mar 2010 17:39:33 +0000

PPK has written a thoughtful post titled CSS vendor prefixes considered harmful, and in it he outlines the case of why browser vendors should cease use of the vendor prefix condition.

I sympathize with the case, but the very opening example we have a problem: border-radius. When varying corner values are involved, vendor implementation consistency breaks down:
-webkit-border-top-left-radius: 10px; -webkit-border-top-right-radius: 30px; -webkit-border-bottom-right-radius: 40px; -webkit-border-bottom-left-radius: 20px; -moz-border-radius-topleft: 10px; -moz-border-radius-topright: 30px; -moz-border-radius-bottomright: 40px; -moz-border-radius-bottomleft: 20px; border-top-left-radius: 10px; border-top-right-radius: 30px; border-bottom-right-radius: 40px; border-bottom-left-radius: 20px;

I’d say vendor prefixes are an unfortunate but necessary construct until things are a bit more solidified – at the very least between browser vendors, and ultimately as written in a W3C recommendation.

What I think is important though is that developers do include the expected latest draft code of CSS3 at the end of their declaration blocks. Shipping code, both from the vendor perspective as well as the web developer perspective speaks volumes. If IE is going to drop vendor prefixes and is going with the latest draft examples, then good on ‘em.

RGBa and -webkit gradients: Yes.

Joe — Wed, 27 May 2009 22:49:31 +0000

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:

"http://www.w3.org/TR/html4/strict.dtd"> Gradient Test

Hello World!

The woes of CSS color in print typography

Joe — Mon, 08 Dec 2008 04:57:21 +0000

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

Joe — Sat, 09 Aug 2008 02:05:03 +0000

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!