One of the most interesting features of Stylus is transparent Mixins. One reason they are interesting is that at the time of this writing, this feature is exclusive to Stylus, other CSS metalanguages like Less and Sass do not offer Transparent Mixin support.

We already defined a mixin earlier, when we explored mixins with Jade. Here they are used similarly.

Before we begin with the transparent aspect of Stylus mixin support, let’s build a simple CSS mixin. Perhaps, the best example, as provided by TJ Holowaychuk in this beginner screencast: http://www.screenr.com/bNY uses vendor-specific prefixes.

How about we take his example and expand it to a slightly more challenging scenario.

In case you haven’t come across this challenge before, lets set some context. Browser makers, or vendors, implement proprietary extensions to standard CSS specifications to release and test browser features that have been developed pre ‘Candidate Recommendation’ W3C draft status. Although vendor-specific prefixes can be frustrating for web developers, they are a necessary evil, allowing new properties to be widely tested before they become available as standard CSS properties.

CSS3 features came on the scene quickly with the rapid implementation of webkit based browsers (Webkit is an open source browser layout engine started by Apple Computers). The CSS feature richness of the webkit based browsers caused other browser makers like FireFox and Opera to advance their adoption of CSS3 features as well.

Browser adoption of CSS moved at such an accelerated rate, it literally outpaced the development of the specifications. This lead to browser makers implementing features that were still in “draft” or Beta. This resulted in features being implemented differently by different browser makers as the feature specification was not yet solidified.

To clear up the confusion, and allow developers to implement these features while they were still in the “experimental” stages, browser makers developer browser prefixes. The browser prefixes are prepended to the attribute name to limit its implementation to that specific browser. The most common browser prefixes are:

-khtml- for Konqueror, really old Safari
-moz- for FireFox
-o- for Opera
-ms- for Internet Explorer
-webkit- for Safari, Chrome, Silk, Android and other webkit based browsers

The problem with web fonts

As you learned in the last hack, CSS3 web fonts can be a powerful design tool. It allows you to use any font you desire whether the user has that font installed or not. With all the benefits that come along with using web fonts, there are a few drawbacks as well.

Validate Your Hack, with Built in Form Validation

Form validation is fun again. Well, maybe not fun, but more fun than it ever was before. Okay, let’s just admit it, form validation sucks. It’s not fun, but it is necessary. In the past, you would write a form and then run some very custom code to make sure all your inputs contained what they were suppose to contain. This was done one of two ways, on the server or on the client. For server side validation, you would submit your form and run server side code to make sure all your requirements were met, and if they weren’t you would reload the page with an error or two on it telling the user where the problem was. Client side validation worked pretty much the same, except you would run some JavaScript before the form was submitted to make sure all your conditions were met. For the record, the best kind of validation is when you do both. You should start with validate on the client to give the user an immediate response, then re-validate on the server to make sure your response wasn’t being hacked.

HTML5 isn’t going to help you with the server side validation, but it sure you will make it easier on the client. HTML5 once again takes a tried and true web standard, and re-invents it as native browser functionality. Lets’ dive in!

I have to admit, I was getting a little bored with the input tag. Before HTML5, any real interaction had to be done outside of the tag, weather it be validation, formatting, or graphical presentation, javascript was a necessary polyfill. Well HTML5 has given us a reason to be excited about the the input tag again.
The input tag is not truly an HTML5 tag per say. It’s the same input tag we have had in every previous version of HTML, but HTML5 has added a slew of new features.

Decisions, Decisions

So now you have this whole new world of new HTML5 elements that will let you be both expressive and semantic with your markup. Your cured from the shackles of div-ites and can show your face at parties again!

Your feeling pretty good about yourself until you remember that not all your visitors are using HTML5 browsers, and being the web standards elitist you are, your page has to be backwards compatible. Don’t throw those HTML5 tags out the window just yet, this hack will teach you how to write your code once, and use it on all the browsers out there.

Any browsers made in the past 10 years is going to see your HTML5 tags in one of three ways:

Footer, Header, Nav and Section

The Nature of HTML just cries out for structure and web designers and developers have long conformed to structural components on a page. A common high level page structure may look something like the following:

		
...
		
...
		
...
		
...

The HTML5 DocType

There’s a lot of mystery over HTML5. What is it? What’s the difference between HTML5 and other versions of HTML? Why should I bother to support HTML5? Most of these answers can be found in the first tag on an HTML5 page, the doctype tag.

	<!doctype html>

This tag is symbolic of the array of changes introduced in HTML5: Simplicity.

Let’s take a look at the previous version of the doctype tag from XHTML transitional: