Tag Archives: CSS

Coloring the HR element line in CSS

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:

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:

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

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

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
<meta name="viewport" content="width=device-width,
minimum-scale=1.0, maximum-scale=1.0">
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: <link rel="apple-touch-icon" href="piano.png"/>
(Note to attendees: I forgot to add the piano.png file to my project files.
But this works otherwise!)
*/

Doll up your tabular data

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

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.