JasonWyatt

This blog is full of stuff, and things.

Find my resume.

permalink The legendary web designer, Mike Kus of Carsonified has been working on changes to the web site for the Future of Web Design conference they hold every year.  A few minutes ago, he tweeted about a really cool little 404 Error page that uses CSS Animations in webkit to create a rotating Earth.

Naturally, I had to dig through the source code to find out what made it spin, here’s what I found:
/********** 404 Page **********/
#earth {
	width:100%;
	height:1500px;
	background:url(../images/presentation/planet_1500.jpg) top center no-repeat;
	position:absolute;
	margin:-1100px 0px 0px 0px;
	-webkit-animation-name: earthRotation;
	-webkit-animation-iteration-count: infinite;
	-webkit-animation-timing-function: linear;
	-webkit-animation-duration: 500s;
	z-index:-1;
}

@-webkit-keyframes earthRotation {
from {
	-webkit-transform: rotate(0deg);
	}
to {
	-webkit-transform: rotate(360deg);
	}
}

This is an awesome use of CSS animation. 

Why? because it is completely progressively-enhanced. If the viewer is not using a webkit browser (Chrome, Safari, etc.), they’ll still see the earth in the background but it won’t be spinning - and they won’t know the difference.  Check it out, here.

Nicely done, Mike.

The legendary web designer, Mike Kus of Carsonified has been working on changes to the web site for the Future of Web Design conference they hold every year. A few minutes ago, he tweeted about a really cool little 404 Error page that uses CSS Animations in webkit to create a rotating Earth.

Naturally, I had to dig through the source code to find out what made it spin, here’s what I found:

/********** 404 Page **********/
#earth {
	width:100%;
	height:1500px;
	background:url(../images/presentation/planet_1500.jpg) top center no-repeat;
	position:absolute;
	margin:-1100px 0px 0px 0px;
	-webkit-animation-name: earthRotation;
	-webkit-animation-iteration-count: infinite;
	-webkit-animation-timing-function: linear;
	-webkit-animation-duration: 500s;
	z-index:-1;
}

@-webkit-keyframes earthRotation {
from {
	-webkit-transform: rotate(0deg);
	}
to {
	-webkit-transform: rotate(360deg);
	}
}

This is an awesome use of CSS animation.

Why? because it is completely progressively-enhanced. If the viewer is not using a webkit browser (Chrome, Safari, etc.), they’ll still see the earth in the background but it won’t be spinning - and they won’t know the difference. Check it out, here.

Nicely done, Mike.

permalink

Introducing jQSlickWrap - The Pixel-Perfect Prose Plugin for jQuery

I’ve been working on a new project over the past four nights after mulling the idea around in my head for a while.

Have you ever needed or wanted to wrap text around an image in HTML but were disappointed that your text was forced to wrap to the rectangular shape of the image’s bounding box - as opposed to the actual contents of the image?

Have you heard of the method of Sliced and Diced Sandbags, but were reluctant to use a server-side script to accomplish something that really belongs on the browser?

Yes? Awesome! No? That’s ok too… I’d like to introduce my new project: jQSlickWrap. It’s a plugin to the jQuery framework, which allows you to easily wrap text around irregularly-shaped images on the browser.

Check it out at its home page, here. If you feel like contributing to the project, you can find it on Google Code

permalink

Make a POSH Search Field With Semantic HTML and CSS

In the tutorial today, we’re going to be building the following search field while sticking to POSH (Plain Old Semantic HTML) principles:

If you’re using a decent browser the our final version above looks great; it’s got a text field with a magnifying glass icon and a button all “contained” within a rounded rectangle border. If you’re unfortunate enough to be forced to use Internet Explorer, or happen to be an Opera fan you won’t see the rounded corners. But this is also part of the point of this tutorial: using progressive enhancement, we’ll construct this field so that it’ll look good and work well on all browsers (even ones with CSS turned off).

But wait! I thought you said we’re using semantic HTML?

That’s right, semantic HTML practices and progressive enhancement are like two peas in a pod. If you’re still wondering what I mean by these two terms, I won’t explain them much in this tutorial, but you can read about them in these great articles:

The Markup

Just like the good progressive enhancement-subscribing web developers we are, we’ll start by writing our markup and then move on to styling it with CSS. Here’s what the HTML for our <form> will look like:

<form action="http://google.com/search" method="get" class="search">
    <input type="text" name="q" size="27"/>
    <button type="submit">Search</button>
</form>

As you can see, the code is really straight forward. We’ve got a <form> element that’s pointed at Google’s search URL (http://google.com/search) using the GET http method. Inside of the <form> are two elements: a text <input> field and a <button>.

What’s so semantic about this?

This markup is semantic in that it’s structure and makeup tell us something about what it means. A form with an input field and a button, whose class is “search”, makes it pretty obvious that it’s describing a search field. We also don’t have lots of messy <div> tags cluttering up the code (or worse: a <table>), it’s nice and clean.

This cleanliness also lends nicely to progressive enhancement. As you can see below, when rendered as-is without styling, it still looks fine and makes perfect sense:

Check it out yourself here.

The CSS

Now that we’ve got our markup, it’s time to make the search field look great. We’ve already assigned the class attribute of our form to search, so let’s go ahead and create a couple of styles: one for the input field and the other for the button. I’ve taken the liberty of introducing some preliminary styles here too (to give us a nice background color and border, as well as a bit of padding).

.search input {
    padding: 5px;
    border: 1px #acddff solid;
    background-color: #ecf8f6;
}
.search button {
    padding: 1px;
    border: 1px #acddff solid;
    background-color: #fffdfa;
}

See the improvements live, here.

Now that we’ve got the skeleton for our styles, we can really start to get down to business. Probably the most obvious difference between the above screenshot and our goal at the top of the tutorial is the fact that the search button hasn’t yet been ‘wrapped’ by the search field. We need to somehow shift the button to the left.

Let’s use the technique of “negative margins” to pull our button over the input field. To know the exact value we want to use for our negative left margin we need to specify a width for our button.

.search button {
    padding: 1px;
    border: 1px #acddff solid;
    background-color: #fffdfa;
    margin: 0 5px 0 -75px;
    width: 65px;
}

By pulling the button onto the search box, we’ve created a new problem: if you type too many characters into the input field they will slip behind the button. We need to set some padding on the field itself to create a bit of a buffer:

.search input {
    padding: 5px 70px 5px 5px;
    border: 1px #acddff solid;
    background-color: #ecf8f6;
}

Reminder: The order of the four pixel values for margin, padding, and border styles are: top, right, bottom, and left (clockwise from the top).

Here’s this step.

We’re getting closer! Now let’s change the styling on the <input> element again, this time we’ll add a background image (a magifying glass icon from FamFamFam’s Silk icon collection):

.search input {
    padding: 5px 70px 5px 5px;
    border: 1px #acddff solid;
    background-color: #ecf8f6;
    background-image: url(../icons/magnifier.png); 
    background-position: 3px 3px; 
    background-repeat: no-repeat;
    background-color: #ecf8f6;
    outline: none;    /* So safari doesn't use the annoying blue rectangle */
}

This works well, we’re setting the background-image to our hosted version of the magnifier, forcing it to not tile itself by setting background-repeat to no-repeat, and shifting it three pixels from the top and left of the field’s corner. There’s one catch. If we type in the field, our text goes right over the magnifying glass image and makes it stand out as a background, instead of as a major feature. We need to add some more padding:

.search input {
    padding: 5px 70px 5px 22px;
    border: 1px #acddff solid;
    background-color: #ecf8f6;
    background-image: url(../icons/magnifier.png); 
    background-position: 3px 3px; 
    background-repeat: no-repeat;
    background-color: #ecf8f6;
}

Check it out:

See it live, here.

Rounded corners, with CSS 3

The new version of CSS, CSS 3, gives us the ability to specify a radius to use when rounding an element’s corners. Unfortunately CSS 3 isn’t completely adopted by any major browser at the time of writing, but Gecko (the engine behind Firefox) and WebKit (the engine behind Safari and Chrome) both provide provisional style properties for rounded corners: -moz-border-radius and -webkit-border-radius.

Let’s add these properties to the styles for both the text field and the button:

.search input {
    padding: 5px 70px 5px 22px;
    border: 1px #acddff solid;
    background-color: #ecf8f6;
    background-image: url(../icons/magnifier.png); 
    background-position: 3px 3px; 
    background-repeat: no-repeat;
    background-color: #ecf8f6;
    outline: none;
    -moz-border-radius: 10px;
    -webkit-border-radius: 10px; 
}
.search button {
    padding: 1px;
    border: 1px #acddff solid;
    background-color: #fffdfa;
    margin: 0 5px 0 -75px;
    width: 65px;
    -moz-border-radius: 7px;
    -webkit-border-radius: 7px;
}

Notice how we used a slightly smaller radius for the button as opposed to the input field, this was because we want the curved corners to “fit” inside each other well. We’re done! Take a look at the final results (look familiar?):

You can also see a live version and inspect its code, here.

We’ve created a beautiful search field using clean semantic HTML, and styled it with some very effective CSS. Also, it’s progressively enhanced; which means it’ll still look and work fine even on browsers that don’t support CSS!

permalink

Getting computed style

nonowarn:

When the computed style of arbitrary element is needed,

var computedStyle = document.defaultView.getComputedStyle(element, null);

should work. But in IE, it doesn’t. But non-tested “cross-browser” version is here:

function getComputedStyle(el) {
   var dview = document.defaultView;
   return dview ? dview.getComputedStyle(el, "") : el.currentStyle;
}

References:

Nicely done! I’ll have to play with this tonight after work..

permalink

CSS Selector Specificity Ambiguity

I was talking with someone last week regarding CSS selector specificity calculations and rules regarding the cascade order. We ended up running into an ambiguity with what the W3C’s CSS spec calls a large base for the specificity ‘number’ concatenation.

I’ve copied and pasted the section from the spec here:

6.4.3 Calculating a selector’s specificity

A selector’s specificity is calculated as follows:

  • count 1 if the declaration is from is a ‘style’ attribute rather than a rule with a selector, 0 otherwise (= a) (In HTML, values of an element’s “style” attribute are style sheet rules. These rules have no selectors, so a=1, b=0, c=0, and d=0.)
  • count the number of ID attributes in the selector (= b)
  • count the number of other attributes and pseudo-classes in the selector (= c)
  • count the number of element names and pseudo-elements in the selector (= d)

The specificity is based only on the form of the selector. In particular, a selector of the form [id=p33] is counted as an attribute selector (a=0, b=0, c=1, d=0), even if the id attribute is defined as an ID in the source document’s DTD.

Concatenating the four numbers a-b-c-d (in a number system with a large base) gives the specificity.

Some examples:

 *             {}  /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */
 li            {}  /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */
 li:first-line {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul li         {}  /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
 ul ol+li      {}  /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */
 h1 + *[rel=up]{}  /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */
 ul ol li.red  {}  /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */
 li.red.level  {}  /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */
 #x34y         {}  /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */
 style=""          /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

My Question

I found this site and this site, both of which attempt to verify that your browser obeys the stipulation of a “large base”, but they don’t try to figure out what that base actually is.

I wonder what this “large base” is defined as in the various browsers. Hit me up on twitter @jasonwyatt or reply on Tumblr.

permalink

Firefox CSS Reload Bookmarklet

If you’re in Firefox, drag this link to your bookmarks bar and when you click it, it will reload all of the CSS files referenced by whatever page you’re currently looking at.

Reload CSS

I can’t take credit for this, however. I first saw it today on the #css channel of irc.freenode.net by user “gimpscape”

permalink

[Dojo] Keep Your Designers Happy, Use Templates

One of the biggest challenges coming up for our team at work will be to devise a workable division of labor between our UI designers and the UI developers. We’ve had a few conversations already and it seems that the point of view of the designers tends to be this: once they give the developers their original designs (graphic assets, CSS, and HTML), the developers often tend to obsfucate and “disgustify” the markup and css. Most developers disgustify it so much that going back into the code to make look and feel modifications down the road is a scary and unfriendly experience for a designer.

As a developer who has had to go into other peoples’ code to modify the look and feel at the behest of a designer/manager/tester, I wholeheartedly agree with this sentiment. Also, it’s one of our jobs as UI developers to separate data, manipulation, and visualization (MVC), it just tends to be forgotten too much.

Dojo, The Culprit?

The worst case scenario for Web UI disgustification is when the developer decides to implement the UI by building the whole DOM structure in JavaScript and injecting the nodes into the page. For some developers I’ve met, they just haven’t worked enough with XHTML and CSS to feel as comfortable working with markup as they do with imperative code. I think this might be a holdover from the days when the majority of our UI development was done in languages like Java or C/C++ and there was no such thing as a UI markup language - the devs got used to the paradigm of instantiating a UI widget, then calling a method on a container widget to add it to the interface.

Dojo tends to exacerbate this problem as it makes building UIs programatically a very easy thing to do.

Dojo Templates to the Rescue

Around here, almost any visual designer will tell you, [X]HTML and CSS are what they’d prefer to work with over JavaScript when designing an interface. Why?

  • When built correctly, the structure of the HTML source has a semantic relationship to the content.

    What this means is that the order in which things appear and the nesting structure they take on actually imply something about the content. This philosophy is not only a nice thing to think about and a good practice for accessibility, but it makes editing code easier.

  • HTML can be previewed in a browser by itself.

    You don’t need to have all your JavaScript dependancies lined up and working to be able to view an HTML template. However, you do have to have everything ready and in place to work with a “live” javascript-built UI.

  • Many designers just plain don’t feel comfortable working with Javascript.

    All visual designers know HTML and CSS, but not all of them feel 100% comfortable poking around in our massive JavaScript files trying to find what they need to change to get something to look just right.

Luckily Dojo provides a really powerful template system which allows developers to wire up the actions and AJAX logic for a widget in JavaScript while still letting designers feel at home while they edit the look and feel in an HTML. The widget can still be highly modular too, keeping the engineers happy.

If we want to forge a good relationship with the designers that are really capable of bringing our UIs to the next level we need to make it as easy as possible for them to jump into our work and help out.

Find More Info