Because of this mess a few creative practitioners taught us to separate our content, presentation and behaviors. But, this ideal paradigm is incapable of fulfilling the needs of the web today.

So along came what I will call divergence; or convergence if you look at it from another perspective. Divergence in web development is the braking apart semantics, presentation, and behavior. However, it is not complete separation of the layers.

In divergence you can use presentation with semantics, as long as it’s semantic (not likely to happen because presentation is rarely semantic).  And, you can use behavior within semantics as long as it’s semantic. And, you can use behavior within presentation as long as it’s presentational.

This is basically a conditional AND, not OR, statement versus the boolean ideals behind separation.

For example, in HTML5 we have type=”email”. Attached to this semantic value is form validation, or a behavior; it’s ok to use under divergence.

This is true because the value email is semantic when in use and the behavior supports its semantics. However, if we were to use the font tag we would not be diverging because the font tag is not semantic and presentational, it is only presentational. And, so, we diverge font styling into our CSS only.

If we want to apply JavaScript to our HTML we can’t add it into the HTML body because it is not semantic and behavioral. The JavaScript would need to diverge. And, if we wanted to use behavior within CSS, our presentation, it needs to be both presentational and behavioral.

Under this methodology we keep our semantics, presentation, and behaviors intact while working with new technologies.

More to come later…

A few purists, I’m sure, will be outraged by what I’m saying. But, if the truth be told, the pseudo class hover has been triggered by user action for quite a while. That is, behavior within presentation.

From the CSS specification, “Interactive user agents sometimes change the rendering in response to user actions. CSS provides three pseudo-classes for common cases.”

This has made me question the principle behind separation of content, presentation and design. And, as I have investigated the idea behind separation, inspiring as it is, I have not found it to be practical.

Separation is a novel idea. It has guided the design style of many amazing programmers and artists. It has led to numerous beautiful and functional websites. But, this segregation of content, presentation and behavior is, as I have found it, much like XHTML 2: little more than an idealistic view worth stemming from.

It is time to leave this ideology behind us. It has served its purpose practically and well. Times are changing and new technologies are piping a different tune: divergence.

It is time to start diverging, not separating.

Part Two: Divergence explained

The real power is in the code. If you plan to make a application that needs to find the html elements of a page and you can’t access the DOM give this a shot.

While the application will not give you attributes, yet, or give you a multi-dimensional-array, yet, I think you might find it useful down the road. Please give it a look and tell me what you think.

And, yes! This is open source.

The Changes

• New colors
• New fonts
• Easier to read: headlines, text, and code
• Comment avatars enabled
• Navigation placement
• Tagged added

Still coming

• Awesome home page
• Archives page
• Author’s page
• Regular page design

A Look Back

Here is a last look at what once was, Intel Designer.

This design is being processed and will be converted into a WordPress Theme. There will be a few changes to the design, because of my limitations and knowledge of the WordPress admin.

If you want to help me convert this design to a theme please let me know. I could use some help with the admin controls. Mainly adding baked in meta data fields for the theme.  I would love to get some help with this.

If you have any questions or suggestions feel free to hit me up on twitter. Thanks, for making this blog awesome!

Yes, its 2010, but people still use IE6… not many, but enough to be depressing. Still, all is not lost. I happen to run across lesser known PNG fix for the aging browser. It’s called DD_belatedPNG. Unlike the traditional iepngfix.htc hack this bad boy gives you the ability to use positioned backgrounds and still retain transparency, among other things. Check it out for yourself.

No hairs for IE

However, if you don’t want anything to do with IE6, you’re in luck. Just recently Andy Clark updated his universal IE6 CSS on Google code. The new version lets you scrap the browser completely by serving it a nicely pruned style sheet that does just enough to be professional. Consider it the default style sheet you wish IE6 came with.

Download all examples to get started!

Let’s get to know the CSS background-position property. When you decide to use a background attachment, such as an image, background-position specifies its initial position.

Basically, the property tells your image where it should appear within the element we are working with. The default position for the image will always be the left top corner of the element.

If you want to change that position you need to declare the property in our CSS and add two values. The first value plots your image on the horizontal x coordinate and the second on the vertical y coordinate.

.object {
height: 150px;
width: 150px;
background-attachment: url(bg.gif);
background-repeat: no-repeat;
background-position: 0 0; }

(View Example)

Even though we declared the position in the example, to (x)0px and (y)0px, you do not need to declare this position. Remember, if no position is declared the browser will assume (x)0px and (y)0px by default.

The Values

So, background-position can use up to two values. The values can be keywords, percentages, and lengths (e.g. px, em, etc.). If you declare only one value the second, the y coordinate, will always be 50%, or center.

.object {
background-position: 100%; }

(View Example)

To keep things simple I personally avoid keywords because they have percentage equivalents. I also, reject the notion of ems, because they are not necessary and add unneeded confusion. Remember, if you have a nail use a hammer.

Pixels

Pixels are a bit odd and not because of rendering, your browser is the real issue here.

Browsers use a vertically flipped x/y graph to plot pixels. They do this for a few reasons, but that is for another time and place. All you need remember is that the positive side of the chart starts at the left top corner and works its way to the right bottom.

When declaring your position with pixels the image anchor point will be the left top corner, not be be confused with the default image position.

.object {
background-position: 0 -25px; }

(View Example)

Percentages

If pixels are not working for you percentages might do the trick, if you don’t get tangled in their web.

When you declare a percentage as the value of the background-position property, it’s lined up based on two points.

1. The percentage of the image, as declared
2. The percentage of the element, as declared

This is hard to explain, but basically, when you declare a percentage it takes that percent, say 75%, and lines the axis of the image, at 75%, to that of the element, at 75%.

Let’s imagine together that we have a long and short stick. There they are, on a table, horizontal to your shoulders and parallel to one another, separated by about an inch.

I hand you a brand new vibrant red sharpie.

Now mark the long stick with the red sharpie, about 75% down from the left side. Next, pick up the small stick and measure down from left side, about 75% of its width, and mark the spot with the same sharpie.

Perfect! Now take both sticks and line them up so the marks are next to each other. That is how the browser lines up background images to their elements.

It does not matter if the image or the element is bigger, it doesn’t matter if they are the same size. That’s how it works, nice and simple… just hard to explain.

.object {
background-position: 75% 0; }

(View Example)

The only time percentages get really confusing is when you declare say… 200% or -10%.

Defaults

• If you only specify one value the second is set to 50%, or center
• Images always assume their position at the left top

Reminders

• x/y graph is flipped on its head
• Percentages apply to both the image and element and line up at their respective percentages
• When declaring values the horizontal plot is first, the second is vertical
• If you want your image to be in the left top corner you do not need to set the property
• Avoid, keywords and ems

Learn More

• Sitepoint Reference: background-position
• Snook: Background Position X and Y
• Background Image Parallax Effect
• CSS Background Sprites

It has been long hoped that fonts could one day be embedded on web pages accessibly. That time is now!

Contrary to common belief, font embedding has been around for a long time. In 1996 the W3C chartered its first font working group and developed WebFonts (‘@font-face’). However, its implementation has been stifled by legalities. Dave Shea has spoken on numerous occasions about the problem: font foundries’ weary approach to distribution on the web.

“Currently one of the biggest stumbling blocks to embedded type on the web is of a legal nature rather than any genuine technological barrier. Most of the major browsers have now implemented the @font-face property…” (Dave Shea)

Foundries have been afraid; it’s obvious. Online pirating has been belligerent and font distributors have feared shrinking profits. However, it may be that the recent decline of print has sparked a fire, and the kettle is boiling.

Stoke the fire

Until lately the foundries have steered clear of the web.  When Jeffrey Veen announced Typekit last year only a few had considered the idea. But, this single event proved mind molding, the font makers were starting to get it. As web evangelist Jeffrey Zeldman responded to the unfolding of these events late November 2009, “Yes!”

And it was not too early to celebrate.

Only a few months after Typekit’s public release, FontFonts announced they would be licensing web based fonts to designers directly. A paradigm unknown until now, and it’s about time.

The recent chain of events has been a breath of fresh air. And to the surprise of everyone: things are finally moving forward at a quickened pace.

Font Deck vs Typekit

Typekit has not been the only one making noise. There are other services like it too, but none of these have stirred the pot more than Typekit.

Clearleft, a web design and consultancy in Brighton UK, has been working with the foundries on their product Font Deck. This is exciting because it not only means more competition, but also that foundries are taking things seriously.

Font Deck, similar to Typekit, is a service in which you can register your website with licensing to fonts of your choice. While the list of fonts is limited to participating agencies, the idea alone is enough to make designers Dribbble. And it has!

Mark Boulton, typographic maniac of Mark Boulton Design, has recently launched his new corporate website with embedded web fonts using Typekit. The effects are truly stunning.

In addition, Typekit empowers the use of graceful degradation. This has been a huge leap for accessibility, findability and usability.

However, there is a problem. Currently, some browsers suffer from “font-pop” the lag time between the rendering of text and that of the embedded @font-face. This may seem like a small price to pay, but significant font popping can disorient users while reading text. The impact is debatable but every designer should be aware of its effects.

Web Fonts: The time has come!

Regardless, the time has come. Everyone is talking about it. This month at the SXSW Interactive Conference web fonts came front and center as Jeffrey Veen, Stephen Coles, Roger Black, Bert Bos and David Berlow took stage. To top it off, just last week the W3C announced its second Web Fonts Working Group, chartered to create a standard format for downloadable fonts (another debate in its own right).

A word of warning

Web fonts are a blessing, but they can be a curse! The potential threat today is akin to that of DHTML.

Back in the 90’s, when Netscape invented JavaScript, many designers went over the deep-end. They made their websites ‘dynamic’ and ‘flashy.’

Some felt it would grab and engage users to create pop-ups and animated splash pages. It was a novelty; cool for a day and hated the next. For this reason many thought JavaScript silly or even dangerous, and for good reason too. Obtrusive code has inspired many books dedicated to highly discouraging the idea.

Web fonts are at the same risk! Web Designers may find themselves implementing novelty designs hoping to make a splash. This is not good! It’s up to us to educate ourselves about the potential threats that lay ahead.

It’s not shocking that A List Apart Magazine published two articles in November of 2009 covering the basics of this issue. Jason Santa Maria, Creative director of Typekit, had this to say in his article at the time.

“There’s a serious possibility that by gaining access to the world’s font libraries, we’re opening Pandora’s Box. Many people working on the web today have some knowledge of typography, but my hunch is that many designers are about to feel quite baffled by the new challenges they face.” (Jason Santa Maria)

I totally agree with Jason. It’s time to take a closer look at Typography. There is a dangerously high risk we will end up back in the 90’s; and it’s not just the 90’s that threaten web design either. Font designers will need to start making better rendered fonts, as Tim Brown points out.

Browser makers have known about the black hole threatening to suck in font rendering for a while. Only now has the development team at Microsoft been able to convince the corporate giant to move forward.

The release of IE9 will prove ground breaking. Not just for its enhanced standards support but also for its hardware acceleration and DirectWrite technologies. While the debate goes on, whether IE9 will be enough to keep web design moving forward on the most popular desktop platform, the enhancements made can’t be ignored.

Now is the time for web designers to start taking typography seriously. Developers, too, need to be aware of what should and shouldn’t be done with @font-face. It’s time to stop using back handed techniques. This time it’s for real. It’s time to get excited again… it’s time for web fonts!

Edit: This just in, it looks like I’m not the only one talking about it today. Zeldman makes some good points.

The Effects

To be honest it’s hard to say how IE9 will affect the current climate. IE9 has not erased the presence of IE6 from the drawing board. It’s just another nail in the coffin.

But IE is not the focus here: web standards are!

When we design for the web we are intrinsically designing for more than IE6, a desktop browser. We are designing for a huge number of devices and platforms with varying constraints and environments.

While IE9 is a huge step toward a more accessible web we cannot, and must not, let IE continue to blindside us or skew our perspective.

For too many years we have complained about how IE is evil. The fact is, its not!

Focus on the facts

We need to go back to were it all started. We need a course correction. We need to be realistic about what is possible right now and focus our energy on the future, specifically HTML5. We need to make it our objective to cultivate better constraints with clients. We need to educate them about what is possible now, the new and exciting stuff.

Moving on

Innovation requires exploration, and exploration requires just a bit of devastation.

Consider IE, with it we now have AJAX and better support for CSS, yes IE6 was cutting edge at one time. Even, Netscape was involved in the early days and gave us JavaScript.

Those were hard times, but without the browser wars who knows what would have happened.

It’s time to remember how we got here and put aside our bias. IE is not the enemy, it never has been. It has helped cultivate some of the best features on the web today. However, this would have never occurred without organizations like the W3C and the activists of the time.

So then, what do you think? What is our responsibility, our role in all this? How can we encourage change? How can we support standards and still innovation? What are the boundaries and who makes them, if there are any at all?

Adobe Replies to the hate mail

Adobe has responded and Flash is on the move. Today on the Mobile Flash Blog they busted the myth that Flash would kill battery life.

On top of this Mike Chambers recently debunked the idea that Flash wouldn’t work with touch screen devices, like the iPad. So, if you still think Flash is evil, or won’t work, you might want to dig a little deeper.

What do you think?

At first I didn’t know what to think but I still place my bets on HTML5. However, Flash will be on the battle field for a long time to come.

Just remember, touch screen devices are not a new paradigm for Flash alone, it’s one for web standards as well. So watch those hover effects!