Block vs Single Line

Default to single line, because many rules will only contain one or two styles and its a waste and pain to scroll vertically through code. Most editors support the 80 column rule, so if your styles get longer than that, convert to block (easy to set a macro to do it for you in most IDE’s and editors).

.foo { background: #ccc; float: left; margin: 0 10px; }
 
.bar {
	cursor: pointer;
	display: block;
	float: left;
	height: 29px;
	margin: 7px 0;
	padding: 0 16.2%;
	width: 26px;
}

Indentation

It’s so much easier to read code that is indented to show hierarchy and white space that separates or groups similar or related objects together. This is a standard I see most front-end developers following, but if you’re not, smack yourself now and get with the program.

ul { }
	li { }
		li a { }
 
.foo {}
	.bar {}

That’s all on formatting for now. Adopt these standards and read on, because I’m sure I’ll be back on this rant before too long.

Also, for those that will rebuttal and argue that older versions of these browsers don’t support it, to you I’d say look up the statistics of old versions of these browsers being out in the wild and stuff it please, because the percentage of users that don’t upgrade these browsers is so low and insignificant that I really don’t want to hear the argument

That concludes today’s “Tip of the Day” check back again tomorrow!

With growing technology and standards, I take pride in meeting new standards according to W3C, in order to achieve a highly functional site and good user experience for everyone. These standards include but aren’t limited to W3C standards, semantic markup, meeting WCAG usability standards, and Section 508 Compliance. This guide provides a medium level of understanding of accessibility standards. If anything in this article is confusing you, then I recommend you refer to Nathan’s post on Accessible Web Design for a more broad prospective.

Semantic Markup

Working with HTML and XML markup languages, it’s important for the code to be standards compliant by using tags, structure, and information that can be read and translated by all browsers. Semantic Markup is just a way of structuring code so that a browser/machine can do more work and take less off the user. For example, search engines, like Google, are heavily driven on specific tags such as Meta information, Alt tags for images, recognizable XML and HTML formatting, etc. Using meta tags for keywords, content definition, and descriptions all improve functionality for search engines and browsers.

Section 508 overview

• Software Applications and Operating Systems: includes usability for people that are visually impaired, such as alternative keyboard navigation.
• Web-based Intranet, Internet Information, and Applications: assures accessibility to web page graphics by the visually impaired using assistant technology such as screen readers and refreshable Braille displays. This is accomplished by using text labels and descriptors for graphics.
• Telecommunications Products: addresses accessibility for people who are deaf or hard of hearing. This includes technology compatibility with hearing aids, assistant listening devices, and TTYs.
• Videos or Multimedia Products: includes requirements for captioning of multimedia products such as training or informational multimedia productions. Captioning or video descriptors must be able to be turned on or off.
• Self Contained, Closed Products: products with embedded software, such as information kiosks, copiers, and fax machines, often cannot be used with assistant technology. This standard requires that access features be built into these systems.
• Desktop and Portable Computers: discusses accessibility related to mechanically operated controls such as keyboards and touch screens.

WCAG summary

The Web Content Accessiblity Guidelines (WCAG) is the only international draft for following web standards. It describes standards that may be used, should be used and must be used. The WCAG is considered the stable version of standards, but for more current standards for accessible websites you can refer to the Web Accessibility Initiative (WAI). They define standards more relevent and specific to newer Web Browsers, Operating Systems, and so forth.

There is a lot of best practices and examples defined in the WCAG and WAI, and though these standards are important, not every web developer needs to know them by heart or implement them into every site. They are mainly important for sites that provide a service, such as e-commerce, educational resource, government sites, etc. That’s why many times you’ll notice that government sites and educational sites have poor creativity, because they need to focus on delivering content to all audiences more than aesthetics. However, if you’re a web developer and interested in learning more about standards and implementing the, refer to the WCAG and the WAI and start creating hierarchy using headers, putting navigation into lists, and using Title and Alt tags appropriately.

W3C summary

The W3C is a working draft defining all aspects of markup languages and some Object Oriented Programming (OOP) languages used on the web. They define standards that are compatible across multiple browser, operating systems and languages. As web developers, we live by these standards and must know them to properly breakdown a website. These standards are a guideline that we follow in order to have our sites be dynamic and compliant for future technologies and software.

Where does your site fall according to these standards?

Below are some highlights that you should become familiar with as you populate a site with content. It’s important that if your site is developed by a professional that applies these standards, to ask for documentation on how to use functionality that may have been put into place for you, such as Meta tags, Header Tags, and Listed Links.

• Compliance across all major Operating Systems: Windows XP, Windows Vista, and Mac OS X
• Access to the visually impaired: JAWS, Window-Eyes, and Hal
• W3C & WCAG standards
• Organic Search Engine Optimization
• Meta information for pages, scrips, and images
• Alt tags for alternative text on images
• Color contrast and color schemes legible for those with color blindness or vision problems
• Em based layout and font: allowing sizes to be relevant to the browser-defined size for compatibility with mobile devices, increasing the font size in the browser, and different screen resolutions.
• Listed links for navigation hierarchy
• Header tags to establish Hierarchy and SEO

How I try and meet those standards in Web Development

As a web developer, I know the standards well. Like an electrician must know state codes and regulations, I follow standards laid out by federal law (Section 508), good practice guidelines (W3C) and usability requirements (WCAG). I also make sure to read up on other articles and refer to other professionals to practice what is most commonly needed and used, for more in depth on how to tackle accessibility as a web developer, check out Nathan’s post at redswish.

In my last post regarding sIFR, I compared sIFR against a few of the other popular font replacement methods such as Cufon and FLIR. Since there is obviously a great deal of interest in the subject of font replacement, I figured it would be beneficial to show a deeper analysis at sIFR which I believe is the superior out of the three.

A deeper look at pros of sIFR

sIFR is quite different to the many font replacement techniques in the wild. Instead of manually generating each header through an image generator such as FLIR and Cufon do, sIFR is able to load a flash object and replace each element on the fly. The scripted effect works for roughly 95% of world wide web users according to statistics for Flash support and JavaScript support in modern browsers. Note also, that sIFR is by no means required, and degrades gracefully if the user does not have one of these components required. I’m sure some purists would react with contempt, but this method causes no harm to usability and only effects load time if used incorrectly (such as replacing body text rather than headers).

sIFR… what’s not to love?

First and foremost, implementation can be slaughtered. For an inexperienced developer, sIFR can take up to an hour to implement (from what I’ve heard in complaints anyways) and can cause pages to load slowly. From my experience, both are due to an incompetent developer, as sIFR is quite easy to implement if you understand all front-end technologies (which you should be a front-end developer) and only causes slow load time if its used for large blocks of text. Compare sIFR to the first wave of Web 2.0 technologies.. to this day I see wannabe developers implementing 20k+ javascript libraries to do one simple “jiggle” or “ajax” ability, which you can do with a few lines of code if you understand raw JavaScript. We can’t blame the technology for human error.. sIFR is brilliant. It may have a ways to go before it’s perfect, but respecting the principles of semantics, usability, and accessibility.. sIFR by far is winning the race against Cufon and FLIR.

Now to address the purists and their complaint about flash and JS dependency. Plain and simply, if a user falls within the 3-10% that doesn’t have Flash or JavaScript enabled, then BIG DEAL. That’s what good old HTML/CSS are for.. a fall back solution. Should we punish those with modern browsers and technologies for the minority that will get a slightly-less-quality rendering? I don’t punish modern browsers by neglecting the wonders of CSS 3. If Internet Explorer sees a box with square corners instead of rounded.. BIG DEAL. So why should we fight about whether a user has JS or Flash enabled? Heck, you can even use image replacement at that point, if you really want to.

The Big Picture

The real issue is that there aren’t enough fonts supported in Internet Explorer. If we want to point fingers and find something to criticize, there it is. Firefox, Safari, Chrome, Opera.. they’re all supporting more CSS properties such as @font-face. However, due to copyright laws and support from Internet Explorer we are bound to 5-10 fonts that we can reasonably assume the user has installed, and that’s ALL we’ve got. Solutions have been offered and argued but the problems are still much broader.. ranging from font licensing, support and rendering, with no clear solution in sight.

sIFR is one solution of many offered by developers fighting a war for creative freedom. It’s here and now, it’s legal despite the font, and regardless of the few quirks.. it’s usable. If you use it, then I hope you implement it well. If you protest it, then I hope you have valid reasons, and aren’t just complaining because you’re ignorant. Take this post with a grain of salt.. it’s my 2 cents and nothing more.

Read further:

Cufon vs sIFR vs FLIR
Style vs SEO
Fonts and the Law

Validators

• Total Validator: simple HTML/CSS Validator with browser plugin support
• W3C Validator: the organization that defines markup standards, and validates according to those standards
• Cynthia Says: screen reader which will help you with accessibility in mind

Accessibility

• WebAIM: Introduction to Accessibility
• WCAG: Web Content Accessibility Guidelines
• WCAG Overview: Overview of WCAG Standards
• WCAG Tutorial: A useful educational resource to learn the standards
• Section 508: Federal requirements for web accessibility

Javascript Libraries

• jQuery
• Prototype / Scriptaculous
• MooTools

Firefox Plugins for Developers

• CSS Validator
• CSS Viewer
• Web Developer Toolbar
• Firebug

Tutorials

• W3Schools: Very in-depth, free tutorials on the most commonly used web markup and programming languages
• A List Apart: Articles and tutorials on an extensive list of topics
• QuirksMode: Good articles and test pages concerning javascript and CSS

• Copyright is an issue for downloading and sharing fonts via the font-face attribute
• Internet Explorer 6-8 do not support font-face
• Font-face could potentially pose a threat if malicious sites attach/spread viruses via the font files

Until font-face is fully adopted, web developers must resort to complimentary or supplementary solutions to make non-traditional typefaces work. There are few major flash and javascript solutions in existence that offer solutions with different approaches to displaying these typefaces. The three major typeface scripts that I am going to discuss are SIFR, FLIR, and Cufón. Before diving into details about each I’d like to point out that all of these solutions that I discuss are 100% SEO friendly, and all require JavaScript (and flash in the case of SIFR) but degrade to standard markup if JS is not enabled, also note that each of these play well with jQuery.

SIFR (Scalable Inman Flash Replacement)

First I must address the acronym, thought not the most relevant seeming, “Inman” is referring to Shaun Inman who originally conceived the idea of using the DOM and Flash together to support non-traditional typefaces. SIFR uses a flash object to render to the font face, and then Javascript to identify the DOM and replace the text as specified.

Pros of SIFR

• Text can be selected
• Does not violate EULA or copyrights, since font is contained within the SWF object
• You can easily add shadows, anti-aliasing, and other text effects in Flash

Cons of SIFR

• Slightly slower load times
• Requires both JavaScript and Flash to be enabled

My thoughts on SIFR

Some people complain that SIFR is harder to implement, but if you’re a front-end web developer it’s vital to learn and master new technologies including really basic flash. All you have to do is open the flash file included in the zip, change the font of the text to the font you want to use, and then publish it. Instructions are included on how to do this and if it is “too challenging” than you’re in the wrong field!

Many have also commented and argued that SIFR is no more secure to stealing a font file and using it on your website. While I do agree with that statement, the issue is a legal matter. Like it or not, and argue it as you may, Adobe Flash is legally allowed to embed and use fonts that the developer has purchased. This is not true for any of the others.

FLIR (Face Lift Image Replacement)

Using PHP (and the GD library) FLIR renders text into a font of your choice by reading the text in a DOM and sending a request to the server with that string and returning an image of that text rendered in the new font. It’s a very clever idea, and works behind the scenes, but it’s not without it’s quirks.

Pros of FLIR

• Does not violate EULA or copyrights, since font is rendered as an image
• Prints in the font rendered since it is an image

Cons of FLIR

• Requires PHP with the GD enabled
• Text cannot be selected

My thoughts on FLIR

While FLIR is fast and efficient with few flaws, one restriction I cannot overlook is the requirement for PHP and GD on the server. Many corporate websites (addressing the big guys, not the freelancers with this one) work exclusively with .NET on Windows/IIS servers without PHP installed at all. This eliminates FLIR from the mix for many websites unfortunately. In addition, FLIR disables the user to be able to select text. This is not a huge draw back if used on headings, but if used on a even body of text then you’re killing usability.

Cufon

Cufon is basically a new and improved version of Typeface.js, with a focus on faster and easier implementation. Cufon uses the browser to draw vector objects using VML (Vector Markup Language) for Internet Explorer and the HTML 5 Canvas element for the more advanced browsers.

Pros of Cufon

• Faster load times than SIFR and FLIR, since it is all JS and nothing more
• Has all the strengths of Typeface.js with fewer weaknesses.

Cons of Cufon

• Violates EULA and copyrights due to fonts being embedded. Not many fonts are permitted to be rendered with this method
• Text cannot be selected
• You can’t apply a hover state to converted text

My thoughts on Cufon

For many, Cufon is the best solution to work with. It allows for rendering on the fly, and works well for a developer to match a design without having to replace each heading with an image. Cufon even works quickly with large bodies of text! One thing I remain disappointed about is text selection; if this library aims to provide a solution for larger bodies of text, then it seems that text selection is a must.

As I have tested and worked with Cufon, I recommend it for the developer looking for a quick solution but only for personal or non-profit website. I’ve talked with a few professionals including a lawyer and confirmed that Cufon is not a legal solution for font-embedding on ANY website, but that unless you’re developing a large profile commercial site, you should be safe to use it freely.

If you’d like to learn more about Cufon, check out the tutorial on TutsPlus.

Read further:

Cufon vs sIFR vs FLIR
Style vs SEO
Fonts and the Law

In the early design phase, I had a really vague idea of what I wanted my site to be, but I didn’t want it to be “typical” and I hadn’t really seen a site that matched what I was going for. I still started first by looking around at what I liked in other sites, and thinking of how I could incorporate that into my own. Then after the first week I happened to come across a theme that was absolutely gorgeous, by Darren Hoyt and Matt Dawson and used it as my base for development. I love the grid, the structure and the User Interface that this layout has. My approach is once you’ve established your frame, UI, and grid; you can slowly add creative enhancements as you go (at least that’s my preferred approach, some designers and such may argue it, depends on the scope really).

After I applied the new theme, I began my breakdown approach by changing the color scheme, and re-adjusting some of the positions/sizes/padding/etc on the elements of the page. For example, I wanted larger font sizes, better font spacing, a different color scheme, etc. Once i had the theme, I started making the modifications to the style sheets. Most themes will use just one or two stylesheets, editable within WordPress itself under the Design tab, or within the wp-content/themes/yourtheme if accessing the site via FTP. Style are typically labeled style.css or separated into different layout styles like nav.css, type.css, posts.css and so forth.

HTML and CSS

For those of you that are just starting out, I want to go over some basics so that I don’t lose you further down the road. I’m sure if you’ve been reading anywhere on how to make a website you’ve seen the acronyms HTML and CSS. These are two extremely important pieces to front-end development. They define structure and how to present structure.

HTML stands for HyperText Markup Language, which basically means it’s transferable content. HTML serves as the structure of a website. If HTML were part of a building a house, it would be the lumber, doors, windows, drywall, etc.

CSS stands for Cascading Style Sheets, which means transferable/reusable styles. CSS serves as the display of a website. If it were part of building a house, it would be the overall blueprint and floor plan, as well as the paint, trim and furniture.

Hopefully my analogies make sense.. moving forward.

Using CSS to layout your site

So if you downloaded a theme and opened the main CSS files, you’ll see that some of it just clicks. Things like “background-color” are literal to what they’re styling. The hardest part to CSS isn’t colors and fonts, but more in layout like sizes, margins, and paddings. I’m not going to define all the style definitions, but like I said before, CSS is both the blueprint and the paint, so some styles relate to structure and some relate to skin.

The best way to learn CSS is to mess around. The basics that you need to know are elements, classes and ID’s. Elements are HTML defined content, such as <p> paragraph tags, <div> structure tags, <ul> lists, <h1> headers, etc. Classes can be attached to these tags like <p class=”redtext”> in HTML and to style that in the CSS you would define the paragraph tag with the class redtext be writing p.redtext { color: red; } in the style sheet. The period represents the class and the p represents what element that style is attached to. To style all paragraph tags we could simple drop the class and write p { color: red; } because then we’re simply targeting the paragraph element. This principles works the same with id’s which are represented with a # symbol. The difference between an id and class is that a class can be used multiple times in a single page and an ID can only be used once.

Homework

For this next week, try to learn some CSS basics. If you’re a beginner, work from a theme that someone already did the hard part of laying out, and just change colors or adjust sizes slightly and tweak it until your happy. Try and get the site styled with the colors you like and sizes you like. If it looks boxy and boring, that’s GOOD. We don’t want to focus on the creative elements more than we focus on the layout and structure yet.. that comes with time.

***Please direct all comments and questions through this blog post rather than emailing me, that way others can review and build off communication back and forth***

Prerequisites

There are two main phases to web development and they are the most crucial. An application or website needs to have a good User Inteface (UI) and remain highly reliable/functional. These two phases are usually labeled as Front-end development (which covers everything from Graphic Design to coding in XHTML, CSS, Flash, and JS) and Back-end development ( which involves a server side programming language such as PHP, ASP, or Ruby and a database such as MySQL, MS SQL, etc). I’m going to use this terminology often throughout this tutorial, so it’s best that you research these terms now if you don’t know what those technologies are.

Part 1: Design

Lets get started. First I want you to draw a design. You can do this however you want, a lot of people jump right into Photoshop and start designing. I personally like to bust out a pen and paper and sketch first. I like to get a feel for layout, grid, and flow before I get too heavy into a designed mockup. This method may prove useful for those of you who don’t know photoshop, as it will help you understand and learn the process of creative and UI thinking and give you a blueprint to reference if you design without a PSD to breakdown.

Spend some time on this phase. Like I said its the most important phase. Often times, in the professional world, a designer will create 3 completely different mockups or wireframes presenting the same content. This allows and forces the designer as well as the client to see and think with three completely different concepts and ideas for presentation. I recommend that you do such as well. After you develop 3 completely different ideas, sit down with someone else and circle things that you like and dislike about each and try to chose the one that best presents the concept. If you can or want, merge ideas from the other concept designs with the base that you choose. Then refine it like crazy. Many iterations are often necessary to reach a design that you’re completely satisfied with.

The next tutorial will follow in 1 week. This will force those who are following my posts in real time, to spend the amount of time necessary to refine. Feel free to leave comments, ask questions, or make suggestions in the mean time.