“There are differences between class and id. Class attributes should be used when you have more than one item on the page with the same class value. Conversely, id values have to be unique to a page.

When I first learned this, I figured I’d just always use class attributes so I wouldn’t have to worry about whether I was duping an id value. However, selecting elements by id is much faster than selecting them by class, so you can hurt your performance by overusing class selectors.”

Huh? I never use ID’s in CSS selectors, but I never experienced slow rendering either. I wanted to test if it’s stupid not to use ID’s.

First I wanted to see if it was even able to create a CSS that was hard to parse. Google has a nice article about writing efficient CSS selectors, so that seemed like a good start before setting up a test. In short there are 2 things that make a fast CSS selector:

• Make rules as specific as possible
  This means that div.content is faster than *.
  You have to be especially specific with the rightmost selector, since the browser reads CSS selector from right to left.
• Avoid (large) descendant rules
  An example of a descendant rule is div.content div.column1 div.columnHeader h2. Descendant rules are less efficient than rules with a single selector, like h2.

Test 1: setting up extremely inefficient CSS

The most inefficient selector by far is *. Combined with large descendant rules you get extremely inefficient selectors:

* * * * * * * * * {
	background: #ff1;
}
* * * * {
	background: #ff2;
}
* * * * * * * {
	background: #ff3;
}

I created a CSS file of about 20KB in size with 3600 asterisks characters (*). I combined it with a very large HTML file (1MB) with 9000 opening HTML brackets (<). Because I only wanted to test the CSS rendering, I added the following JavaScript to be able to load the CSS file on my local computer after the page was loaded.

	Load CSS
	

Results Test 1

All tests were done on my computer (Vista with Intel Duo Core @ 2.4GHz) except for IE7 and IE6. IE7 was tested on a Vista machine with Intel Core Duo SPU @ 2.67Ghz. IE6 was tested on my machine with Virtual PC and on a PC with Windows XP SP3 and a Pentium 3 CPU 3GHz.

The results show that browsers freeze for at least 2 seconds in order to render the CSS. So it is possible to screw up your rendering, but you really have to make an effort for it with large HTML files and unrealistic CSS selectors.

Test 2: setting up a more realistic scenario

In this test I created a more realistic scenario. I took an existing CSS file and altered it until it was 113KB in size and contained about 1050 selectors. I changed the CSS rules until the bulk of the code looked like this:

.Homepage .containerText {
	position: relative;
	margin: 15px auto 0px auto;
	width: 960px;
	background:#ffffff;
}
.Homepage .containerText .containerLeft {
	float:left;
	width:450px;
	padding:10px 20px 45px 10px;
}
.Homepage .containerText .containerLeft p {
	margin:0px 0px 5px 0px;
	color:#414a49;
	line-height:1.286em;
}

So most of the code in the CSS file consisted of descendant selectors with classes and hardly any tag names. The corresponding HTML page was also created from existing code and copy-pasted until the file was 107KB in size with almost 600 opening HTML brackets (<). Now we have a relatively large HTML and CSS, but not unrealistic. Once again I tested it in different browsers:

Results Test 2

All modern browsers responded so fast that I couldn’t really notice it needed rendering time. This means that the CSS file does not need any optimization by utilizing ID’s. The only browser that could profit from more efficient CSS selectors is IE 6. But since I don’t have to support IE 6 anymore, it’s not worth my time.

Conclusion

Writing fast CSS certainly will help some browsers on slow PC’s. But that is a minority of the users. So unless you have special requirements for your website, you’ll be better off focusing on writing logical, maintainable code than trying to get the browser to render a few milliseconds faster. There are some considerations though:

Being more specific

A few years ago I switched from writing .foo to writing a.foo. Adding the tag name in the selector gives me a better idea what I’m styling. Now I know that this coding style is also faster in rendering.

Descendant selectors

Descendent selectors (using more than one element in a CSS rule) are inefficient in rendering, but I won’t give that up. I like to be specific about what element I want to select in CSS. I rather write div.column1 div.article span.date than span.date. The latter is more efficient, but that only works with very small websites because only then you’d still have an overview of the all classes that are in the HTML code.

When I write JavaScript code I try not to ‘pollute’ the global namespace. I try to do the same with CSS by using descendent selectors.

If you need faster rendering, you could alter descendant selectors by making one class that incorporates the whole path. So you’ll get span.column1_article_date instead of div.column1 div.article span.date. Although it would render faster, it also has some drawbacks. Renaming a class afterwards is tedious work, the class names can become very long and the classes can be used outside it’s intended containers, so a class called div.column1_article_date could be used anywhere in the DOM and not just inside div with the class column1.

ID’s and JavaScript

I do use ID’s by the way, Not in CSS though, but for JavaScript for these reasons:

• Specific elements can be easily accessed in plain JavaScript with getElementById.
• If an element has an ID, I can be pretty surre that there is a bit of JavaScript attached to it.
• Using ID’s in your jQuery selectors makes the selectors less dependent on the current HTML structure. It’s easy to break existing jQuery selectors by removing a class in the DOM.

No related posts.

Yeah, Netscape 4. Now that was a browser that just did not want to die. Netscape wasn’t updated after 1998 but in 2001 still about 5% of the internet users used Netscape. I got curious how the web would look like in a browser that is more than a decade old. So I downloaded Netscape 4.7 and loaded some major websites to see how they would look.

The level of accessibility of websites varies enormously. Let’s start with one of the worse:

Amazon.com

Welcome to our new and improved web shop

How the Amazon website should look like

As you can see: Netscape renders the page but context is virtually lost. And it clearly can’t handle the sprite image in the top left corner.

Twitter

A Twitter page in Netscape

How this Twitter-account should look like

The lack of solid white background color in combination with a rich-contrast background image that does get loaded is a serious problem. Not to mention all the hidden information that becomes visible. This website too is not very usable anymore.

Yahoo

Yahoo just blocks you

Yahoo has another approach: It just says that you’re browser is ancient and offers download links to newer browsers.

Google

...while Google just does it's thing

Google doesn’t complain and shows a page that looks remarkably well in Netscape 4. The links in the search results will still send you to websites that look like jigsaw puzzles, though

So you can’t browse with an ancient browser. So what?

Ok, this is indeed not a drama. But think of it this way: the web is a web of content. Content that becomes increasingly inaccessible if you don’t rebuild its content container, the website, every few years. Most organizations do that to be up to par with the latest browsers and designs but some just have to.

Help browsers with a handicap

Keeping content accessible is not just a hobby. It’s a major issue for websites of (semi)government organizations for example. They have to make sure content is open to anyone. Although they focus on handicapped internet users rather than handicapped browsers, one goal remains the same: a user should be able to use a website without the need of CSS, JavaScript or any other ‘fancy’ technique. A :hover is no use to a blind user, neither will color and JavaScript animation. That’s why such a person uses a different browser without such capabilities. And that’s why we have guidelines like WCAG.

It’s not surprising that many websites that follow WCAG guidelines or something comparable  do reasonably well in Netscape 4. I’ll repeat it again: that’s a browser from 1998.

www.section508.gov

Unique: this website looks almost identical in Firefox and Netscape

www.section508.gov in Firefox

The web design of www.section508.gov just don’t look like it stems from the 1990s, it also uses ancient techniques from that era like tables for layout, image spacers and sparse use of CSS. All big no-no’s nowadays, but the website rendering is great.

Dutch web guidelines

In black and white, but ordered and readable.

The same website in Firefox

The difference in rendering between Netscape and Firefox is striking. Netscape is unable to read the CSS, but that’s a good thing here. Accessibility dictates that an HTML document should be structured. So when there’s no CSS to style the document, the document structure will remain.

But why does Netscape not load the CSS? It appears that the media attribute link markup is key here:

Netscape won't load this CSS
<link rel="stylesheet" type="text/css" href="/screen.css" media="screen, tty" />

Netscape *will* load this CSS
<link rel="stylesheet" type="text/css" href="/screen.css" />

Dutch semi-governmental website (www.groenendestad.nl)

The website in Netscape

In Firefox

The last site is a semi-governmental website developed at the company I work, Estate Internet. It’s a relative new site (2 years old) but still usable in both old an new browsers.

Hurdles

So it is possible to make websites that are still usable in ancient browsers. The main obstacle is that old browsers try to render stuff like CSS and JavaScript but choke on it halfway. In case of CSS it’s possible to block Netscape by adding the media attribute, but that’s still a hack. Old browsers should be protected from itself. One option is to just disable everything at the client side that could harm the rendering.

It would be nice if you could send unsupported browsers just the HTML, while others also receive CSS and JavaScript. But browser detection can be error prone. The only stable solution I know that is easy to implement is IE version detection through conditional comments. Consider this piece of code that only gives all non-IE browsers and all IE7+ browser the site’s stylesheet.

<![if !IE]>
    <link href="css/main.css" type="text/css" />
<![endif]>
<![if gte IE 7]>
    <link href="css/main.css" type="text/css" />
<![endif]>

Conditional Comments will help us giving a soon-to-be ancient browser like IE6 the treatment it deserves .

Now it’s time to close Netscape again and start waiting for the new Firefox that supports basic CSS animation.

No related posts.

The template is based on the basic template of JSDoc Toolkit. The HTML structure is basically the same, but with a complete fresh CSS in a separate file. Nothing else is added to the template (yet), so it’s a fast loading website.

There are even no pictures added to the template, although it may not look that way because of the CSS3 styles that generate gradients, shadows and rounded corners. These effects are not visible in IE, except for rounded corners in IE9. So in case of IE, you’ll just see a simpler version of the website.

Here are some screenshots:

Class view

Class overview

File overview

Related posts:

1. Document your Javascript: interview with Michael Mathews of JSDoc Toolkit

Ethan Dunham about Fontspring: "Designers should have control over their fonts".

Putting the quality free fonts in the showroom

Although the website has about 1.5 million page views per month, the website is just one year old. Fontsquirrel was born in January 2009 because Ethan, for years a font designer himself, wasn’t happy with the way free fonts were offered on sites like dafont.com. “There are no free font sites that really focus on quality. What they focus on is quantity,” as Ethan said in an interview for the Web 2.0 Show.

With Fontsquirrel he wanted to fill in that gap. He only selected free fonts that could also be used in commercial products like websites and were “at least half way high quality”. That way the users of Fontsquirrel had a list of quality fonts that could be used in almost anything.

A good start

Ethan had little expectations when he started Fontsquirrel: “I started it as a side project, maybe earn a few dollars on advertising. It was a site I wanted for myself and thought it would be useful to others.” The response was great after the release of Fontsquirrel: “It made it to the front page of delicious.com, right off the bat.”

After a year Ethan has found more than 630 font families that fitted his criteria. The active search has stopped now and new fonts only trickle in from time to time. “But that hasn’t been a problem for the popularity for the site. If you now need a font for your site, you have a place to go to.”

Not all fonts on Fontsquirrel are available as a webfont though. This has to do with licensing issues. Ethan: “I am either not allowed to redistribute fonts (and therefore webfonts) or the license doesn’t allow it.”

Jeffrey Zeldman

The popularity of Fontsquirrel is still growing with 5% to 20% a month. The online media certainly is boosting the trend. Ethan: “There lots of people dropping my name. Jeffrey Zeldman in particular was kind enough to mention me in some blog posts and tweets.”

Because of Jeffrey Zeldman’s popularity and his status as an authority on web development, Ethan was even a bit affraid of his posts since they result in peaks in site visits that the server has to handle. “The problem is that the generator can be processor intensive. Just putting one font through that thing can tie up the server. So I’m a little anxious about getting more and more traffic to the generator. It could end up eating all of my resources.”

“The website is on a decent server, but people are uploading megabytes of fonts. I had one guy asking me why his 20 megabyte font wasn’t converting very well!” Another problem were grunge fonts with tons of vector points that were being run through the auto-hinter. But these problems are now hopefully gone forever: ” I just built in some limitations to keep things humming along. I will not be able to serve all 100% of the people coming, but 90% of you won’t notice a thing.”

Why we need the @font-face generator

Most developers who ever tried to use web fonts in their web site, will most likely know how much trouble one has to go through. You’ll have to at least convert an existing font to EOT and already that can be a pain. For years Microsoft has a tool for generating EOT files, which is called WEFT. But WEFT crahes easily and the UI is cumbersome. That’s why many people take their resort in the simpler but more stable commandline program ttf2eot.

Jonathan Snook wrote a blog post about the steps he had to go through to just be able to use web fonts on his site. That inspired Ethan for making the generator: “I had been doing quite a bit with FontForge and I realized how easy it would be if you’d automate most of that. It started off there, just for fun, and it progressively grew more and more features.”

The @font-face Kit Generator: currently the only complete web font generator

The font face generator can do a lot of conversion now. And it has to: if you want to do it right, you’ll need 4 file types: TTF or OTF for most browsers, EOT for Internet Explorer, SVG for Safari on the iPhone and finally WOFF, the new standard for web fonts.

Under the hood of the generator

FontForge is still a large part of the Ethan’s generator. “I wrote a script that uses FontForge from the command line. But it is also integrated with a few other open source tools. Obviously it is connected to ttf2eot te generate an EOT. Another tool is sfnt2woff for the WOFF files.” The generator now also produces an SVG file, which Safari on the iPhone needs.

No future for Cufón

The @font-face generator even makes a Cufón file. Cufón is a hack to make a browser show non-standard fonts. It uses Javascript to replace text with a line drawing of the font. Cufón aims to be a worthy alternative for the other hack: sIFR.

The fact that the @font-face generator creates Cufón files does not mean Ethan is endorsing it: “I don’t think there’s much of a future for Cufón. It was easy to add to the generator. I did it just for fun. Simo Kinnunen released the Cufón generator as open source, and I just plugged it in to see what happens. So I didn’t spend much time on it. But some people use it instead of @font-face. They think it renders more smoothly.”

Although there seems to be no future for Cufón, it has some advantages over @font-face: Cufón does render well on Windows in contrary to @font-face. We’ll have to wait for IE9 to see good font rendering on Windows browsers. Another advantage of Cufón is that the fonts cannot be pirated, since the original file is not being used.

Future developments for @font-face generator

The work on the @font-face generator is not finished yet. “It’s definitely a work in progress”, Ethan admits. He’s still busy adding new features and tweaks. One of those features is the ability to be able to select alternative glyphs and ligatures: “An OTF can have a normal set of Unicode characters, but it could also have other characters instead of the default. I did come up with a way that you can upload a font and choose which set you want to use. I haven’t implemented that yet.”

The whish list goes on, although Ethan is still in doubt if they’d be useful enough to implement: “You could embed an XML file into a WOFF as meta data, so that you have a font with the foundry information in it. Another thing I’m thinking about is to generate some server-side script to dynamically generate the CSS file, which should send the right font to the right browser.”

…and then there was Fontspring

In early February Ethan published another website: Fontspring. It is something that he had been thinking about for a few years already. “I’ve been in the type business for a long time and wanted to take what I’ve learned selling my own fonts and apply that to selling others.”

The interview for the Web 2.0 show gave him the final push for starting Fontspring: “I shared my observations about what I thought users would like regarding webfonts. Ie: That the idea of renting a font was a bit backwards and that most people would rather have freedom to download and use the fonts as they saw fit. There were a lot of companies jumping into the market and so I dropped everything I was doing and spent 2-3 months building Fontspring.”

“I created a whitepaper describing what it was we were doing and how we could protect their fonts from casual theft. It wasn’t complicated. Small, open-minded foundries said ‘yes’.”

Fontspring.com

Service vs DIY

Fontspring sparked a new discussion about renting versus buying. Most web fonts vendors choose to rent web fonts, while most web developers will most likely opt for buying web fonts. “We are at the owning side of the ‘owning versus renting model’. We think that designers should have control over their fonts and we try to sell it that way. That’s why almost all of the fonts on Fontspring are licensed for unlimited domains. The other advantage is that we’re not just a service: you also get the desktop version of the font.”

Jeffrey Zeldman also has reservations about renting fonts and being dependent on a service. His post on that subject already sparked a discussion on the subject, but it’s most likely that the two business models will live side by side for at least some time.

The DIY model of hosting does not mean that the fonts can be easily pirated. Ethan took some measures to discourage pirating. “I’m trying to do the best of both worlds here. On one hand I want to serve customers who don’t want to be tied to a yearly fee. On the other hand I understand foundries’ concerns about having their intellectual property on the web, all exposed.”

“What I’ve done is take some ideas of existing type services and integrated them in a DIY method. For example: when I make a webfont for Fontspring, I’m subsetting it to a smaller character set. I also removed all the OpenType features, and then scramble some of the internals to render it fairly useless as a desktop font.”

At the time of writing Fontspring is selling 1,044 font families from 36 Vendors. “I’ve actually been pleasantly surprised that the interest level of these type designers for the DIY model is high.” Ethan isn’t finished yet: “Fontspring will continue to sign on new font vendors and improve the quality of the webfonts delivered. I have a list a mile long of improvements to make to the site and user experience.”

More than 1000 font families to choose from

Hinting

All the fonts are generated with the @font-face generator. The font-face generator automatically adds hinting to the font if none is available. The hinting will make the font render better on the screen. Especially Windows browsers need hinting for the rendering.

Different vendors have different approaches to font optimization. Typekit for example does no optimization itself but leaves it up to the designer. The hinting of the fonts on Fontsquirrel and Fontspring are generated automatically, while font foundries like Ascender do all their hinting by hand.

Creating hints by hand ensures the best possible rendering, but that’s no option for Ethan: “Manual hinting is a very niche occupation and takes a lot of time. The automatic hinting does it well enough that you maybe see a few artifacts, but overall it’s gonna be pretty good. Fontspring has more than 1000 fonts. To go through all of them and manually hint them would be impossible. Having to pay somebody to do that would be very expensive obviously.”

A bit about Ethan Dunham

Ethan's avatar on the web

Ethan is a full-time independent web designer in Wilmington, near Philadelphia and has been designing websites since 1996. He also designs fonts for 15 years now. He sells them on Fonthead.com and now also on Fontspring.com.

As a font designer he never worried about the emerging web font technology: “I was one of the first to change the license agreement to allow @font-face. In my experience most people are honest and respect your intellectual property.”

Related posts:

1. My favorite for converting fonts to EOT
2. List of web fonts services and resources

Take for example the method of URL encoding a piece of string. There’s a pretty good chance that you run into a page that advises to use the escape() method for that. And although it seems to work, it will only handle ASCII-characters. You should use the newer method encodeURIComponent() for that.

The reason why escape() is still popular is probably because that method has been around longer, seems to do what you think it should do and is easier to remember. But if you use it for URL encoding, the end result will be buggy. Just Google for ‘escape JavaScript URL’ and you’ll find lots of misinformation on this subject. xkr.us has a a good web page on that subject.

Replace

Another one: replace(). That too seems to do what you think it should. Right? Well, not really. Only the first occurrence of a given string is replaced with another. Once again this is a method that pops up when you search for something like that and quickly copy-paste into your code. If you want to replace all strings you’ll have to use regular expressions. Instead of replace('foo', 'bar') you’ll have to write replace(/foo/g, 'bar'). Please pay attention to the lowercase ‘g’ after the regular expression. That’s what toggles the Global replace.

No related posts.

Michael Mathews

I recently discovered JSDoc Toolkit, a tool that generates documentation of your Javascript code in the form of a website. That was dearly needed because I wanted to give me and other team members a better overview of my growing JavaScript codebase.

The history of JSDoc

The JSDoc-toolkit and its predecessor JSDoc have been around for nearly 10 years now and in both cases the bulk of the code is programmed by Michael Mathews, often shortened to “micmath”. JSDoc started as a solution for the growing Javascript code at the company he worked for: “I couldn’t find any existing tool that did what I wanted, so I just naturally started building my own. I didn’t want to totally reinvent the wheel of course. I basically tried to port Sun’s JavaDoc idea over to JavaScript.” So he wrote a documentation tool in Perl. “Once it was done and we’d used it a bit, I decided to release it as open source on SourceForge. I figured if I found it useful then maybe someone else would as well.”

Although JSDoc is a very useful documentation tool and probably the first free tool as well, it wasn’t received that well back in 2001 according to Michael Mathews: “It seemed the general JavaScript community was not yet ready for JSDoc. Back then the majority of folks doing JavaScript were not in the habit of practicing what you would call ‘Software Engineering’ best practice! It was, more often than not, a field dominated scripting cowboys. The idea of automatic documentation generation, I think, was seen as something unneeded by most. According to the stats from SourceForge, the JSDoc tool was only downloaded a few hundred times in the first several years – and frankly that already seemed amazing enough to me.”

The renaissance of JavaScript

But as the web got more mature, so did the developers. Javascript gained respect in the last few years and the emerge of large libraries such as YUI, jQuery and Prototype showed that Javascript can be used in a complex but constructive way. New ways of coding were used to structure Javascript. Michael noticed the trend: “Since about 2005 JSDoc really started to take off. Since then it’s been downloaded over 30,000 times. It still seems amazing to me.” The latest version of JSDoc Toolkit is downloaded almost 5000 times since it was published in September 2009.

JSDoc in the wild

The term JSDoc by the way is a bit confusing. It refers both to the syntax and the program. The syntax has been relatively successful as well: “I know that a few of Google’s projects use JsDoc comments to extend their functionality. Closure Compiler is a good example of that, though it can be a pain when other projects start redefining the JsDoc syntax for their own purposes in ways that are incompatible with the original project. Of course there is no official standard for JsDoc comments, so I can’t blame them, but that is something I’d really like to see: an official JsDoc standard, I mean.”

“The idea of JSDoc has been picked up by many large projects over the years. However, my application was originally written in Perl and wasn’t very flexible, consequently it got rewritten by others a few times for internal use only. I don’t want to name any names because I personally think that, while perfectly legal to do that, it violates the open source spirit I intended the work to be used in.”

Document your code...

...run the tool...

...and publish the generated documentation website.

The Toolkit of JSDoc

A year after JSDoc was released, Michael resigned as an active contributor to the project. Gabriel Reid took care of JSDoc after that. He maintained and extended it. But around 2006 Michael decided to do a major upgrade for JSDoc. “Big frameworks were the norm and along with that was both the need for API documentation as well as the complexity of writing documentation for all the new and interesting things people were doing with JavaScript. I was beginning to think that, in order to get JSDoc up to speed with this new world, it would need to be rewritten from scratch. So I started a discussion about that on the users’ list. That eventually led to the current incarnation of the project: JsDoc Toolkit.”

The rewrite was written in Javascript itself. That was possible with the open source Rhino platform that parses the Javascript. That wasn’t based on any technical issue: “I just liked the idea of a program parsing itself. As a bonus the users were more likely to be able to modify the source code if it was written in a language they work in.”

Rhino runs on Java and was initially developed by Netscape. Rhino would have been a part of a larger project to port Netscape Navigator to the Java platform, but that never happened. Rhino is still being used and is maintained by the Mozilla Foundation.

How JSDoc works

JSDoc reads the code and the comments. The comments need to be formatted according to the JSDoc convention. It’s a notation that’s used in other tools like Google’s Closure as well and is similar to the JavaDoc convention.

The comments give hints to JSDoc Toolkit how the JavaScript is structured. Unfortunately not all notations are recognized by the tool. In fact: most of the really exotic notations are not recognized. Michael: “People don’t realize how difficult it can be to do static code analysis on a language as dynamic as JavaScript. Well, at least I didn’t. It is provably impossible in most cases to know what the various states of a JavaScript program will be at runtime, just from looking at the source code. I tell people, if you can get a program to know what you want have programmed, just from the plain source code, consider yourself lucky!”

“But for the rest of us JsDoc Toolkit provides a way to document your code in such a way that the tool never has to even see your code. In fact, you can even use JsDoc Toolkit in files with just comments, no code whatsoever! So in that sense there isn’t any code you can’t document with JsDoc Toolkit, as long as you don’t rely on the static code analysis features.”

The word “Toolkit” in the name “JSDoc Toolkit”, by the way refers to the template engine JSPlate. Michael: “I eventually went with the ‘Toolkit’ name mostly because I liked the sound of it, but also as a little nod to a favourite templating system of mine, Andy Wardley’s Perl Template Toolkit.”

JsDoc Toolkit Version 3

Right now Michael is in the middle of programming version 3 of JSDoc of which the first beta should be released somewhere this summer. “Basically there are a few feature requests from JsDoc Toolkit 2 that seem reasonable enough -things like documenting the same symbol more than once- which are utterly impossible due to the core architecture of the tool itself. All those feature requests are now on the table and I’ll try to include them in the new version.”

“One feature that will definitely be supported is the idea of overloaded functions. A typical example would be a function named ‘width()’ that returns the width when it is called with no arguments, but will set the width when called with a numeric argument.”

“This is fundamentally not possible to document in JsDoc Toolkit Version 2. And that really is the point of rewriting the tool for Version 3: it will include, in it’s core, all the lessons learned from the past several years of supporting JsDoc Toolkit. I believe it will provide a much more flexible foundation to build on.”

In addition, Michael will make more use of Rhino than he already did. Until now Rhino was only used to parse the server-side JavaScript. The parser that walks over the source code looking for doc comments and things like function declarations was written by Michael himself. Rhino has a JavaScript parser built in, but it would took “some serious Java hacking” to get it right.

“Fast forward a few years and some important things have changed: namely, Norris Boyd has made accessing Rhino’s internal Abstract Syntax Tree much easier. In fact, it is now as easy to walk over your source code as it is to use, say, DOM nodes to walk over HTML. I’d be crazy not to take advantage of all that free power just sitting there waiting to be used!”

“So Version 3 will have none of my own parser left in it. This means I get to shed about 40% of the project’s code, which was dedicated to just that one task, and can now focus on the more important bits: parsing the doc comments.”

“It also means that, in theory, if Rhino can understand it, you’ll be able to get JsDoc Toolkit to understand it. Of course this is all taking time to get up to speed with, but I’ve decided to use build my tool on top of the new RingoJS framework and that’s made my life much easier, and the process much faster.”

The first beta of version 3 is estimated to be released in early summer.

Continuation

One of the weak spots of the JSDoc project is that most of the time there’s only one active developer working on it. Although the tool is still alive and kicking, it naturally needs some nurturing to prevent it from getting stale. “To be honest it can feel like a real burden sometimes.” Michael admits. “It’s essentially just me these days, and I mostly can’t give the project all the time it deserves.” So developers are welcomed to join in the project: “I’m ready to sign them up! The fact is that I think of JSDoc as my baby. Not that I invented anything new or amazing, I most emphatically didn’t. But I’d lived with it long enough and I’d become associated with it, so I wanted to see it do well in life.”

And so the development continues even though there are now some other tools around like JSDoc. He even used some of them. “I used to write a lot of Perl and JavaScript at the same time and found NaturalDocs to be a great tool because it required a single format that could work in any language.”

Server side JavaScript

Although JavaScript as a program language is appreciated much more than a few years ago, it is still a quirky language. But that’s no problem for Michael: “Yeh, it’s a weird language. But I come from a background of Perl, so I like weird languages! But actually, JavaScript on the server side is a totally refreshing experience. Rhino, for example, allows you to use all the latest cutting-edge JavaScript syntax and features, and you never have to worry about running in an ancient or buggy web browser. I hope and expect that server side JavaScript will really start catching on in the next few years.”

A bit about Michael Mathews

It was hard to find a bit of information about New Yorker Michael Mathews. Although JSDoc has been around for almost 10 years and is downloaded a lot, he hasn’t been interviewed before. He has been asked many times for some assistance though. It can create funny situations: “I was doing some freelance work and the fellow sitting next to me asked if I’d ever heard anything about this ‘JSDoc’ stuff he was trying to use. I said I had heard of it and helped him sort it out. I had to eventually admit that I was the creator of the tool. He seemed a little surprised by that.”

Mathews started as a zookeeper, which he had done for a few years. But it wasn’t that much fun for him. “I basically cleaned up after lots of unusual animals.” When he wasn’t working, he played with his computer. “By the late nineties I was had my own homepage, complete with the large, requisite, ‘Under Construction’ message.” His work behind the computer payed off eventually: “in the fall of 1998 I was employed as a Web Developer for MTV Online, working in Times Square in New York City. It still seems amazing to me.

He now works since 2008 for the BBC in London where he works on the Glow JavaScript library. And yes, everything of it is documented with the help of JSDoc Toolkit.

Glow is a JavaScript library that just, like Prototype and jQuery, makes programming in JavaScript easier. The difference is that Glow supports whatever standard is currently defined by the BBC Standards and Guidelines for browsers, accessibility and usability. This could mean it has to support older browsers that other major JavaScript libraries have already dropped.

Links

• JSDoc Toolkit
• JSDoc Toolkit Twitter
• JSDoc Toolkit 3 Blog
• JsDoc Toolkit Users Group

Related posts:

1. Codeview, a new template for JSDoc Toolkit

IE9 on Vista on the left and IE8 on Windows 7 on the right. The font is Bodoni

For those who read my article on font rendering of professional fonts were surely disappointed to read that their fonts would most likely not render well in browsers on Windows if you use the CSS technique @font-face.

At the moment your best chance of getting a font rendering well in a browser is by buying or renting one from a font foundry like FontFont or Ascender, who optimize their fonts for the web. Fonts that aren’t optimized most likely will not render that well.

Well, there is some good news. IE9 uses Direct2D and DirectWrite and it seems that it does a much better job at font rendering as you can already see in the example on the left. So although we will still be very much dependent on those optimized fonts until the predecessors of IE9 have finally faded away, there is light on the horizon.

Its very exiting to see that the font rendering improved so much. Just look at the zoomed in part of the letter ‘g’:

The letter 'g' of the font Bodoni at 500%. Again: IE9 on the left and IE8 on the right, in case you were still wondering

Some notes on rendering

Not very surprising, but sometimes the rendering of a piece of text in IE9 can result in something that’s significant wider than in IE8:

Two screenshots of identical texts in IE8 and IE9, placed on top of each other

You can still find some rendering glitches like you can see here:

Still some bad rendering in IE9 with Helvetica at font-size 14, 15 and 16

Dax too still renders bad at some font sizes. The first line is IE9. The second line shows the font in Safari, rendering it as it should be.

Just to make it absolutely clear: the fonts in these examples are converted without any hinting improvement.

Related posts:

1. Test: Popular professional fonts as webfont
2. New web font service: Ascenderfonts.com

The Bright Lines, as seen through 'readability'

Lately I came across Readability. It’s a bookmarklet (works only in FF, Safari and Chrome) that alters any website into a more readable one. It does so by presenting it in a book form. At a first glance I thought it as a nice  tool, but I wasn’t sure I was going to use it. Then I thought that it was a real good example that you as a user have more to say than you think.

We always accept the usability of the websites for what it is. If it’’s good, it’s good. If it’s bad it’s bad. But the frontend of the website is built on your computer, in your browser. You have a certain level of control over the HTML, CSS and Javascript.

The most common way to make a website better is by using ad blockers. Yes, some people do live of advertising, but I don’t think that means you should be obliged to see them if you don’t want to. Especially when they distract. The best thing about ad blockers is that it doesn’t require any knowledge of web development at all.

Another example is CoolIris that convert image pages of popular websites like Google Images or Flickr into a 3D wall of images.

A more techie Firefox plugin that I use is Stylish. I use it to add my own CSS to websites I regularly visit. Most of the time I use it to remove section that I regard useless with a simple display: none. A more powerful variation of Stylish is the plugin Greasemonkey. With Greasemonkey you can alter the websites with Javascript. And just like Stylish, you can publish your customization of the website through the plugin.

So that’s a reminder for me to see that websites are not cast in stone. Popular websites will on the client side be hacked by a small minority of users to cater their own needs. And if a site is really in need of improvement, plugins that help non-technical users would spread like wildfire.

Related posts:

1. Popups dodging popup blockers

Screenshot of www.ascenderfonts.com

This year the web font will become omnipresent. It’s possible to convert the fonts yourself and incorporate it into your website with something like Fontsquirrel. But some fonts just need a bit more than just a conversion, since they can look bad in browsers, certainly on Windows. So it was time for me to test some font services, since you may expect that the people behind the web service at least check if a font renders correctly.

Lucky for me that Bill Davis of Ascenderfonts.com asked me to check out their new font service after reading my article on web font rendering. At that time Ascenderfont did not offer trial accounts, so I was happy to take the offer in order to be able to give the service a spin for free.

The Ascender Corporation

The website Ascenderfonts.com is not a company by itself. It is the webshop of the font foundry Ascender Corporation. The company creates fonts, extends glyphs and hinting and resells fonts, so the emerge of web fonts means another opportunity for them to sell their fonts.

The company is founded in 2004 by a few software developers and typographers. One of the founder, Steve Matteson, has worked on both Arial and Times New Roman for Windows 3.1. He also designed Convection which is the font for the Xbox360, Liberation which is used on many Linux distributions and Andale Mono, a mono spaced font that for long had been my favorite font for replacing that less readable Courier. Finally he also designed Droid, the font for Google’s Android platform.

Another founder of Ascender, Tom Rickner, has been involved with the design of fonts like Georgia, Tahoma and Verdana. All fonts we’re familiar with.

Ascender Officially started their web font service in July 2009 but it wasn’t a real option for web developers back then, since they only offered EOT Lite. That automatically meant that the fonts were only visible in Internet Explorer.

Back then EOT Lite was proposed by Ascender to the W3C as a default standard for web fonts. But the W3C chose WOFF as a standard, so in the beginning of January they started to support TTF and WOFF as well. Now all major browsers except Safari on the iPhone are supported.

The service

The fact that the service is now cross-browser has not been promoted yet, so it’s still more or less under the radar. But that could change quickly. They already offer 200+ fonts (Typekit offered at time of writing 400+) but want to have between 500 and a 1000 web fonts within two years.

Getting such a large collection is harder than it seems. Many fonts are by default not suitable for the web. I did a little test recently to see how some popular professional fonts would look like in a browser. All of them did not render well in one or more font sizes. It’s not much better with free and shareware fonts: a study of Ascender concluded that almost 96% of all those fonts have some sort of trouble with rendering in the browser.

So there’s a whole world of fonts that need to be improved in order to be used on the web. It’s easy to see the need. Fonts are a major component of a corporate identity and fonts like Arial or Times New Roman are rarely part of the offline corporate identity. Every company wants to have their online identity in sync with the offline version so that means lots of potential work for Ascender. Making a print font fit for the web starting from 9 pixels and up is worth a few days of work.

The focus on good screen rendering is according to Bill Davis of the Ascender Company the main reason why a web developer should choose for their service. According to Bill some other advantages of their service would be that their service (in contrary to Typekit) works without Javascript and that the licensing is per font and per domain, which should be easy for billing, especially for larger companies.

What I missed when using the Ascenderfont service is a bit more information about the rendering. There are screenshots of Windows and the Mac and you can do a actual font rendering in your own browser, but it’s not as detailed as Typekit that show previews of fonts at different font sizes, of all the major browsers on each major operating system. Okay, maybe it’s a bit too much information, but it is comforting to know that you can check every option before choosing a particular font.

What I do like is that the web fonts are categorized between the ones that are fit for headings and the ones that are fit for body text. Typekit has that function too through tagging, but at the moment only a few fonts are tagged as either headline or text.

What about the font creators?

With all the web fonts popping up everywhere I was wondering how the font foundries themselves look at this new development. Well, the people of Ascender certainly don’t feel uncomfortable with it. Bill Davis of Ascender says that most of their clients fine with web fonts: “Almost all of our clients agreed with our proposal of EOT Lite (wb: similar to EOT, but without URL binding and proprietary compression) as a standard, so that’s a clear sign that font creators see web fonts as a viable way of using fonts in websites.”

Which service must I choose?

Although it’s interesting to compare web services with each other, it will be the font service with the most fonts that will probably win the battle for the clients. Designers want to have a broad choice of fonts to choose from. That is: if they even check if a font is available as a web font on forehand. Every web developer is sometimes confronted with designs created by someone who wanted to make something ‘challenging’ or just don’t know/care about technical limitations. In such a case it’s the service with the most fonts that could most likely offer font that’s in the delivered web design.

Related posts:

1. List of web fonts services and resources
2. Web font rendering in IE9

You can read more about it on their weblog.

Related posts:

1. List of web fonts services and resources