RSS MAD

Validation statistics from Nikita the Spider

About a year and a half ago I mentioned Nikita the Spider: a bulk validation and link checking tool as a useful quality assurance tool. Well, Nikita the Spider has received a lot of fixes since then and has recently been taken out of beta. It is no longer completely free, but the first 125 pages it crawls will cost you nothing.

But what may be more interesting is what Nikita finds when it crawls a site. Philip Semanchuk, Nikita's author, has analysed the statistics Nikita collected during March 2008 and walks you through the results in By The Numbers – March 2008. A few highlights:

• The most common validation error is neglecting to specify an alt attribute for img elements
• The second most common error is failing to escape ampersands
• XHTML doctypes are much more common than HTML doctypes
• Over sixty percent of the crawled pages use a transitional doctype

Of course these statistics are only representative of a very small sample of the pages that exist on the web. In addition to that, those pages live on sites that somebody has actually asked Nikita to crawl, so it is likely that they are more aware of web standards than the average website owner/author/developer.

It's still interesting reading though.

Add 456 Berea Street to your Technorati favorites.

Posted in (X)HTML, Web Standards.

Authentic Jobs API and Affiliates program

If you've been looking for a new job or looking to hire a skilled web professional you may have come across Authentic Jobs. You may also have noticed that there have been Authentic Jobs listings on this site for some time.

The news is that now anyone can display job listings on their site. You can also make some money when someone you refer posts a listing on Authentic Jobs.

To display job listings you will need to apply for an Authentic Jobs API key, and once you have that you can start doing all sorts of with the job listing data. Find more details on that in The Authentic Jobs API Documentation.

Even if you don't want to display job listings you can become an affiliate by applying for The Authentic Jobs Affiliate Program. Once you're approved you will get a personal code that you can use when referring people to Authentic Jobs. For each new full-time listing posted as a result of your referral you will get USD 75, and for each freelance listing your award will be USD 25.

If you're completely new to Authentic Jobs, it is "a targeted destination for standards-aware designers and developers and the companies seeking to hire them." In other words, it is a place where companies looking for modern web professionals can find talent.

Add 456 Berea Street to your Technorati favorites.

Posted in Job openings.

What does Acid3 mean to you and me?

So, last week two browser vendors proudly announced that their rendering engines now achieve a 100/100 score on the Acid3 Browser Test: Opera (Opera and the Acid3 Test) and Apple (WebKit achieves Acid3 100/100 in public build).

Getting a 100/100 score does not mean that the browser has completely passed the Acid3 test, since there are other criteria as well - the animation has to be smooth and the final page has to be a pixel perfect match of the reference rendering. Despite that, it's great news to see browser vendors in a battle to implement standards first. Too bad the biggest two in terms of market share - Firefox and Internet Explorer - didn't take part in the Acid3 race.

What I'm wondering is if, how, and when, this will help Web designers and developers like you and me. How long will it take for the other vendors to catch up enough that the standards that are tested by Acid3 can be used reliably? And what parts of the Acid3 test checks stuff that we really can't wait to use?

What's your thinking on this?

Add 456 Berea Street to your Technorati favorites.

Posted in Browsers, Web Standards.

Designing Web Navigation (Book review)

What? An entire book just about designing navigation on the Web? Yes, that's right. And if you think about it for a while you'll probably realise that there is a need for a book on that subject. Heck, considering the number of sites out there that are incredibly hard to navigate, there is room for plenty of books that explain how to create Web navigation that works.

And you're very likely to have run into problems more than once when trying to figure out how to make a website or Web application easy and intuitive not only for yourself, but for your own or your client's end users, to find their way around. Designing Web Navigation by James Kalbach aims to help you master the fundamentals of navigation design. While there is no guarantee that you will master the subject, reading this book will definitely give you a lot of insight into the problems that you encounter in navigation design as well as possible solutions to those problems.

The way Designing Web Navigation is structured makes it usable not only as a book you read from cover to cover, but also as a reference to keep handy for the next time a tricky navigation problem shows up. It can also give you arguments to use in discussions with clients or other team members when there is something that doesn't feel quite right about the solution somebody is suggesting but you can't put it into words. In fact, it may also make you look at the problem from a different angle and realise that maybe your solution isn't the best one.

The author starts the first part of the book by explaining the foundations of Web navigation. Those foundations include why we even need navigation in the first place, how we use Web browsers to interact with websites, the most common types of navigation on the Web, and how we can label navigation to make it easy to understand.

The second part of the book is called "A Framework for Navigation Design", and is focused on providing you with a systematic approach to designing Web navigation. It does that by describing a number of phases that you will often move through while turning a concept into a working navigation system.

In the third and final part, James Kalbach takes a closer look at navigation in special contexts, such as before and after searching, in social tagging systems, and how Web applications can be navigated.

Throughout the book there are many references to accessibility and internationalisation issues that can be caused by some types of navigation. It's great to see that those two very important aspects of Web navigation aren't overlooked here as they are in many other places.

Overall this is a great book that I enjoyed reading. The examples and references are current and credible. One area that has room for improvement is the layout and typography, which I think could be more usable. Line-length is a bit too long for the book to be a really comfortable read, and page numbers are smaller than the text on websites designed by ad agency art directors.

But don't let that discourage you from picking up a copy of this book. My impression is that there is a lot of research behind this book, and I think all web designers and front-end developers can learn something from it.

Designing Web Navigation

Author: James Kalbach

ISBN-10: 0596528108

ISBN-13: 978-0596528102

Add 456 Berea Street to your Technorati favorites.

Posted in Reviews, Usability.

DOMAssistant bundle for TextMate

Like many other Mac users I do most of my coding in TextMate. It has tons of really nice features, one of which is its extensibility – if you need support for a coding language that isn't included with TextMate, you can add it yourself.

Well, I've been using Robert Nyman's DOMAssistant JavaScript library quite a bit lately, and TextMate doesn't support DOMAssistant's methods and syntax. I was getting a bit annoyed at knowing that I was doing a lot of unnecessary typing because of this, so I decided to create a TextMate bundle for DOMAssistant.

Armed with my copy of TextMate, James Edward Gray II's excellent TextMate: Power Editing for the Mac, and the DOMAssistant documentation, I started hacking away. This was the first time I took a closer look at adding support for a language in TextMate, but it turned out that it really isn't that difficult.

After a few hours of work, the result is a DOMAssistant TextMate bundle with tab triggered snippets for all methods, a code completion dictionary, and documentation links for all DOMAssistant keywords.

• Google Code project: textmate-domassistant
• Direct download link: DOMAssistant-tmbundle-1.0.zip

If you use TextMate and DOMAssistant I think this will save you a few keystrokes :-).

Suggestions for improvement are welcome. Remember that this is my first TextMate bundle, so please be gentle.

Add 456 Berea Street to your Technorati favorites.

Posted in Coding, JavaScript, Mac, Productivity.

First impressions of Internet Explorer 8 Beta 1

So Microsoft released the first beta of Internet Explorer 8 to the public the other day. Press releases and documents on the IE 8 site contain plenty of exciting promises of new and improved features, such as:

• Full and complete CSS 2.1 support
• Partial CSS 3 support
• Better JavaScript performance
• Fixes for a number of long-standing JavaScript bugs
• Built-in developer tools
• WAI-ARIA support

It all sounds very promising, but if you're hoping for IE 8 Beta 1 to catch up with other contemporary browsers, you'd better lower your expectations a bit. I had high hopes after reading about the new features and improved support for standards Microsoft are aiming for in IE 8, but after trying out Beta 1 I have to say that I am a little disappointed.

Yeah I know, I know. It's a beta version, so bugs and problems are to be expected. I still thought IE 8 Beta 1 would be more polished than it is. Anyway, here are some of the areas I have looked a little closer at.

CSS 2.1

Microsoft have made it clear that they aren't done with the CSS 2.1 implementation yet and that there is much more to come in Beta 2, so things will improve. After checking a bunch of the sites I've built recently in IE 8 Beta 1 I can verify that CSS 2.1 support is not complete – some things break. Full CSS 2.1 support is very, very promising though, so I really hope the IE team manages to fulfill this promise.

Built-in developer tools

Internet Explorer is in desperate need of a reliable debugging tool on par with Firebug, and IE 8 does have built-in developer tools for CSS and JavaScript debugging. Great!

I suppose it's unfair to compare IE 8's developer tools to the excellent Firebug extension, but it can't be helped. Firebug has set the bar for what any browser based developer tools need to match.

Unfortunately IE 8's developer tools are currently very lacking in features, look very unpolished, and seem quite buggy. They don't come anywhere close to Firebug. Like CSS 2.1 support, Microsoft is open about the developer tools not being finished, so they will hopefully be much improved in the next beta release.

Zoom

Since IE 8 still refuses to resize text sized in pixels, zoom functionality is very important for people who need larger text. Zooming in IE 7 is a mess, and it is supposed to be improved in IE 8. So is it?

Well... yes and no. Zooming is less likely to create massive horizontal scrollbars than in IE 7, but it has major problems on some sites, where zooming just one step completely destroys the layout (try it on this site to see what I mean). Talk about breaking the web... Zoom appears to need more work before it becomes usable.

Looking forward to Beta 2

I realise I may be coming across as being a bit negative here, but I was really hoping for more after Microsoft's surprising move to let IE 8 use its most compliant standards mode by default. I guess I was hoping for too much at this stage.

To end this on a positive note, it's excellent to see the improvements mentioned on the IE 8 website. Beta 2 is sure to deliver much more than Beta 1, and I'm looking forward to it.

Add 456 Berea Street to your Technorati favorites.

Posted in Browsers.

Surprise of the year: IE8 will use Standards mode by default

When I woke up this morning and checked my RSS feeds I had to rub my eyes and look again. Was I still asleep and dreaming? But no, I was awake, and what I saw reported from multiple sources is that Microsoft has reversed its decision to make IE8 behave like IE7 unless specifically requested.

Wow. I didn't see that coming. And even more surprising is their reason for making the change. In Microsoft's Interoperability Principles and IE8 on the IEBlog, IE General Manager Dean Hachamovitch says:

In light of the Interoperability Principles, as well as feedback from the community, we're choosing differently. Now, IE8 will show pages requesting "Standards" mode in IE8's Standards mode. Developers who want their pages shown using IE8's "IE7 Standards mode" will need to request that explicitly (using the http header/meta tag approach described here).

And in a press release titled Microsoft Expands Support for Web Standards, Microsoft chief software architect Ray Ozzie states that

there is a concrete benefit to Web designers if all vendors give priority to interoperability around commonly accepted standards as they evolve

No, I'm not making this up.

It seems like Microsoft actually listened to the developer community, which is so surprising to me it hasn't quite sunk in yet. As a standards-advocating web developer I have become so used to Microsoft completely ignoring the needs of myself and my fellow standardistas that I could never have imagined them changing their minds on this.

And it doesn't stop there. Dean Hachamovitch goes on to say that:

Long term, we believe this is the right thing for the web. Shorter term, leading up not just to IE8's release but broader IE8 adoption, this choice creates a clear call to action to site developers to make sure their web content works well in IE.

And Ray Ozzie hints at better education for developers who do not use web standards:

we will work with content publishers to ensure they fully understand the steps we are taking and will encourage them to use this beta period to update their sites to transition to the more current Web standards supported by IE8

Sounds great. Thanks for listening!

I hope that this new focus on web standards and interoperability also means cleaning up the horrible, stinking, inaccessible piles of code that are regurgitated by products like MOSS and Visual Studio. I also hope that it means educating Visual Studio cowboys to use and understand web standards.

Add 456 Berea Street to your Technorati favorites.

Posted in Browsers, Web Standards.

Specify a maximum width for em-based layouts

As someone who likes to bump up text size a notch or even two on many sites, I often notice that this behaviour is not something that web designers in general anticipate. However, layouts do tend to be a little bit more robust now than a few years ago, at least at a moderate increase in text size. That's good, though I think in many cases it is just a matter of luck that nothing gets obscured as text size is increased.

One technique that can easily make reading a site a lot more uncomfortable is using an elastic, or em-based, layout such as the one I use here (and talk about a bit more in detail in Fixed or fluid width? Elastic!) without specifying a maximum width in another unit. I've come across a few of those recently, which could perhaps be explained by the fact that the preset fixed width layouts created by YUI Grids CSS are of this kind.

Since the em unit is tied to the browser's text size, increasing that size will have consequences. Let's say you have specified that the total width of a layout is 60em. As text size is increased, so is the entire width of the layout. In the absence of a max-width CSS property that uses another unit, like pixels or percent, that will rather quickly lead to horizontal scrolling - and plenty of it - unless you're browsing with a very wide window on a very wide screen.

And how is that a problem? Well, if you need larger text, you're likely not going to appreciate that in order to get larger text you will have to put up with a lot of horizontal scrolling to find parts of the site. It doesn't make the site completely inaccessible or impossible to use, but it does make things harder for anyone who likes larger text and does not use a very wide browser window. Alastair Campbell talks more about the issues this can cause (and why "elastic" may not be the ideal name for em-based layouts) in Elastic layout - wrong term?.

So just a heads-up: when creating an em-based layout, consider using max-width instead of width. As for IE 6, which does not understand max-width, I tend to either use a dynamic property to give it a maximum width in pixels or just give it a fixed width (again, in pixels). I think both options are better than setting a fixed width in ems since they are less likely to cause massive horizontal scrolling at large text sizes.

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility, CSS, Usability.

The WCAG Samurai Errata are now available

It took nearly two years, but two days ago on 26 February 2008, version 1.0 of the WCAG Samurai Errata for WCAG 1.0 were finally published. As stated in the Introduction, this version is also likely to be the final version.

A quick summary for anyone who is not familiar with the WCAG Samuari or their WCAG 1.0 errata: The WCAG Samurai consisted of a group of accessibility and standards-aware web developers brought together by Joe Clark in 2006. The group's goal was to create a document that provides corrections and updates for the Web Content Accessibility Guidelines (WCAG) 1.0.

The reason to provide corrections is that since WCAG 1.0 was originally published by the W3C in 1999, both web browsers and assistive technologies have evolved. At the same time, accessibility-aware web developers have learned and invented a lot of techniques for building accessible websites. Developers have also learned that some of the techniques that were useful in the past are no longer needed or even cause problems for users.

The WCAG Samurai errata thus removes, rephrases, and adds information that makes WCAG 1.0 more applicable to today's Web. You might also want to read Joe Clark's WCAG Samurai errata released, where he talks a bit more about the errata and the development process used.

So do the WCAG Samurai Errata actually contain any improvements? Yes, definitely. I don't agree one hundred percent with every word in the errata, but all in all I think they make a lot of sense and match what I strive for in my daily work.

Note that you can't use the WCAG Samurai Errata as a standalone document. It should be used in combination with W3C's WCAG 1.0.

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility.

DOMAssistant 2.6 released

Last week Robert Nyman updated the DOMAssistant JavaScript library to version 2.6. As always with a new version of anything there are a number of new features and performance enhancements, but this release also marks a couple of other changes for DOMAssistant.

First a couple of words about performance. In DOMAssistant 2.6, the performance of CSS selectors has been improved a lot – run the SlickSpeed Selectors Test to see just how fast it is. Opinions on the usefulness of the SlickSpeed test vary, but no matter how you spin it, DOMAssistant's CSS selectors are really fast.

A new feature is support for plugins, which among other things will enable people to add stuff like animations and superfluous visual bling bling. The plugin model can of course be used to add useful functionality as well :-).

In order to make DOMAssistant a little less of a one man show and more of a community, Robert also asked a few people, including myself, to join the DOMAssistant Team. Sure, the community around DOMAssistant is still small when compared to that of the major JavaScript libraries on the market. I don't think that's a problem really, since I'm not so sure that massive amounts of forum or mailing list traffic automatically means that something is good.

For Robert's own, more detailed, description of the news and changes in DOMAssistant 2.6, read his post on the DOMAssistant development blog: Releasing DOMAssistant 2.6 - overall fastest CSS selectors, plugins and more.

If you're like me and are more interested in building websites than trying to emulate desktop applications in the browser, DOMAssistant should appeal to you. Give it a try. If you like it, great! If you prefer another library or framework, good for you. Just be aware of the options.

Add 456 Berea Street to your Technorati favorites.

Posted in JavaScript.

Doctype switching for IE 8

So. A few weeks have passed since the version targeting Microsoft will introduce in IE 8 was made official and I posted my initial thoughts in Standards mode is the new quirks mode. I've had time to read many articles and hundreds of comments that discuss version targeting, and have thought some more about what it means and what I think about it.

After that thinking, my initial reaction holds: I don't buy it. It doesn't matter how many arguments in favour of version targeting I read, it still seems so utterly and completely wrong that standards aware web developers will have to opt in to opt out.

I think version targeting as it has been presented is an incredibly bad idea to force upon the minority of people in the web industry who have a clue and work hard to stay updated. If the switch was reversed, i.e. you'd have to insert the meta element if you wanted IE 7 rendering, it would make a lot more sense to me. If your site breaks in IE 8 and you can't or won't fix it, just insert a meta element and the problem is gone.

The argument against reversing the switch is that the clueless are too clueless to ever find out that there is an easy way for them to force IE back to IE 7 rendering. That may be true, but why should we let people who refuse to keep their skills updated get away with it?

Make doctype switching stricter

An idea that makes much more sense than forcing standards aware developers to opt in to opt out was put forward in WaSP Round Table: IE8's Default Version Targeting Behavior. The idea is to keep using the doctype to switch modes, but require a strict doctype with a full URL for standards mode. I like that.

I don't have any statistics to back it up, but my gut feeling is that most of the sites that accidentally trigger standards mode today (and would be most likely to break in IE 8) have either a transitional doctype or an XHTML 1.1 doctype. So unless there are statistics that prove that theory wrong, why not simply let the absence of a strict doctype (HTML 4.01 or XHTML 1.0) be what makes IE 8 pretend it's IE 7?

I believe that many of the people who argue against the version targeting switch would say "Yeah, that seems like a good idea, let's do that." I know I would.

Realistically though, I doubt it matters what you or I think or say. In the end we'll all have to do whatever Microsoft tells us to do. Either that or keep pulling our hair out while dealing with CSS and DOM bugs in IE 7 forever.

Add 456 Berea Street to your Technorati favorites.

Posted in Browsers, Web Standards.

Design Accessible Web Sites (Book review)

It's good to see more books on Web accessibility being published. More books means different authors and different writing approaches, and a greater chance of there being a book available that suits different people.

I mention this because to some people, words such as standards, regulations, or compliance are huge turn-offs that make them effectively stop listening. Maybe Design Accessible Web Sites will sit better with that crowd, since the author, Jeremy Sydik, presents the information in a gentler way, without getting overly hung up on checkpoints and accessibility guidelines.

I think it's a very good approach. There isn't much sense in slavishly following recommendations just to tick checkboxes without knowing what the benefit is. And I've been seeing quite a bit of that lately...

It seems that often when a client requires their website to be accessible, the task of making sure it is accessible is handed over to a back-end developer who also happens to be the only one on the project who has any sort of knowledge of front-end development. But that developer is very rarely aware of what makes a website accessible, so they turn to checking points off the WCAG checklists and checking checkboxes in whichever IDE they are using. And that often leads to badly implemented accessibility, like the issues I mentioned a while ago in Overdoing accessibility.

Apologies for the long introduction, but it's there since I think Design Accessible Web Sites could actually work for the developers I am thinking of. There is not a lot of pedantery and preaching and "you must follow these guidelines exactly, or else". Instead, the author focuses on the end result – if doing this or that actually makes the site more accessible. And in the end that is a lot more important than ticking boxes in a checklist.

The book consists of five parts and goes through everything from best practices to testing to taking a look at the legal situation that surrounds Web accessibility. It's written in a very easy-to-read and friendly manner that makes it a pleasure to read. The advice it contains is correct and up-to-date, and focuses on how the end user is affected instead of following outdated guidelines to the letter.

Speaking of guidelines, the book teaches how to design accessible sites by following ten principles instead of various guidelines. I won't quote the entire list of principles, but a couple of my favourites are these:

Users' time and technology belong to them, not to us. You should never take control of either without a really good reason.

Progressively enhance your basic content by adding extra features. Allow it to degrade gracefully for users who can't or don't want to use them.

Design Accessible Web Sites is an excellent read that I highly recommend.

Design Accessible Web Sites

Author: Jeremy Sydik

ISBN-10: 1934356026

ISBN-13: 978-1934356029

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility, Reviews.

Beware of id and name attribute mixups when using getElementById in Internet Explorer

It is probably old news to the JavaScript experts among you, but since I recently ran into this problem myself and pulled my hair in frustration before a coworker hinted at the solution I think it's worth mentioning:

When using getElementById to get a reference to an element via the id attribute, Internet Explorer for Windows (and some versions of Opera) will also match an element whose name attribute contains the same value.

This doesn't always cause any noticeable problems since in most cases you're not all that likely to have identical name and id values for different elements, but when it does happen it can lead to errors that are very hard to debug.

Here is a simple example HTML document that is susceptible to this problem:

1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2. "http://www.w3.org/TR/html4/strict.dtd">
3. <html>
4. <head>
5. <meta name="description" content="A brief description of the content on this page.">
6. <title>The name and id attributes in IE</title>
7. </head>
8. <body>
9. <div id="description">
10. <p>A description of something.</p>
11. </div>
12. </body>
13. </html>

Now imagine that you want to use JavaScript to do something to div#description. For simplicity's sake, let's say you write the following script that hides the div element by setting its display CSS property to none when the page is loaded:

1. function hideIt() {
2. var obj = document.getElementById('description');
3. obj.style.display = 'none';
4. }
5. window.onload = hideIt;

That works as expected everywhere except in Internet Explorer, where nothing happens. The reason for that is that in IE, getElementById finds and returns the meta element whose name attribute has the value description before it gets to the div element.

You can avoid this either by making sure that there are no name and id conflicts in your document or by using a script that fixes the problem by overriding IE's native getElementById method.

If you were aware of this already, good for you. If not, I hope I saved you some frustration.

Add 456 Berea Street to your Technorati favorites.

Posted in Browsers, JavaScript.

Make sure your website works with or without www

Being a little lazy at times, I tend to skip typing "www." before the domain name when I enter a URL in my web browser. No, it doesn't save me a whole lot of typing, but bear with me here. Most of the time it works fine and I end up on the site I expect.

But it really surprises me how often typing in a domain name without "www." in front results in one of the following:

• My browser displays an error message such as "Safari can't open the page "http://example.com/" because it can't find the server "example.com"."
• My browser finds a server but nothing happens because there is no website configured.
• I am redirected to a parked domain.
• I get a "Directory listing denied" message.

This happens with all sorts of organisations, from the tiniest single-page websites to huge online presences of multi-national corporations.

You can add "www." in front of the domain name and all is fine. But should you really have to do that? What I think should happen is that the web server either responds on the address I entered or redirects me to the www host. Unlike the no-www and yes-www folks I'm "www-agnostic" in that I don't really care if the preferred host is the bare domain name or "www." + domain name. Just make both work and redirect all traffic to one of them, I don't care which. I do however think that it makes a really bad impression when any of the above happens when you try to access an organisation's website without typing "www.".

I'm no DNS or web hosting expert, so there may well be technical reasons that I am unaware of that make it hard or impossible to configure all web servers to work with or without the "www.". But when this sort of thing has happened to clients, it usually turns out that whoever is hosting the site has simply forgotten about it.

Considering how many use their bare domain name in advertising, and looking at colleagues and relatives, I know I'm far from the only one who skips "www." when manually typing in a URL. And do you really want to risk your clients losing visitors due to a misconfigured web server? I thought not, so remember to check this with the persons or companies responsible for the servers your clients' sites are hosted on.

Add 456 Berea Street to your Technorati favorites.

Posted in Usability.

Looking for open source CMS and portal software options

Over the past year or so we've seen a definite increase in the number of questions we get about open source content management and portal software at NetRelations. I'm not quite sure of the reason for this trend, but nevertheless it's refreshing to see people beginning to "think different" in the otherwise very Microsoft-dominated country that Sweden is.

It may be a welcome change, but I find choosing a CMS incredibly difficult, and evaluating them is very time consuming and often frustrating. There are hundreds of options, one worse than the other. To date I have never come across a CMS that doesn't have serious flaws. Even if a CMS looks good at a glance, once you start digging deeper you will always encounter problems with usability, accessibility, and front-end code.

Content Management Systems

A couple of times in the past I have asked my readers for CMS suggestions, but it's been a while now. Last time we ended up using Plone, which was a real pain to work with. I don't know if the situation has improved by now (it's been three years), but just thinking about working with it gives me a stomach ache. So we want to look at other options, and I'd like to ask what you all think.

We've been looking around for a while and two of the very few systems that look like they could be worth spending more time with are ModX and Drupal. Their approaches to content handling are quite different, so they would most likely suit different kinds of clients.

The first thing I would like to get some input on is how good ModX and Drupal really are. I'm thinking both for developers who will need to customise the CMS to fit the clients' needs and for the end users who will work with the admin interfaces to create content and structure sites. I'm looking for answers to the following questions:

• How easy (or hard) are ModX and Drupal to develop for?
• How easy (or hard) is using them to create content and administer websites?
• Are there any problems creating fully standards compliant and accessible websites with either system? Do they allow full (and I really mean full) control of HTML, CSS, and JavaScript or do they contain uncustomisable black boxes?
• Are their admin interfaces reasonably accessible? If not, can they be made accessible?

That's one bunch of questions. Next, the vague topic of "portals".

Portal Software

Some large organisations are asking about open source portal software to use instead of commercial solutions like IBM WebSphere (WPS) or Microsoft Sharepoint (MOSS). I have some experience with both WPS and MOSS, and while making a public-facing website based on either system standards compliant and accessible is achievable with a bit of work, fixing the interface presented to a logged-in user seems more or less impossible. In other words, to be better than either of those two in the web standards, accessibility and usability departments should be really easy.

It seems that most open source portal platforms are Java based. Liferay, JBoss Portal, and Apache Jetspeed are some. They all seem like incredibly complicated pieces of software that are beyond my capability to understand. That has got me thinking... would it be possible to use Plone or Drupal as a portal? Yes, I know I complained about Plone being hard to develop for earlier, but compared to others it is pretty good at web standards and accessibility.

Does anyone reading this have experience from open source portal software? The questions I'm looking for answers to are the same as for the content management systems.

Their standards aren't our standards

As a sidenote it's pretty fascinating to note that when CMS and portal software vendors boast about "Standards compliance", "Open standards", and "Interoperability" they do not mean what you might think they mean.

To them, those terms have little to do with the front-end, so having a "Standards compliant, interoperable" portal solution does not mean that it outputs valid HTML and CSS and will work in any browser. Instead, it means it will run on any server that means the requirements. Huge difference.

To summarise this little call for input: any suggestions, hints, and recommendations on open source content management and portal software are welcome.

Add 456 Berea Street to your Technorati favorites.

Posted in Content Management.

Helping others understand web accessibility

When I hold workshops for people who want to learn more about web standards and accessibility, I often notice that the attendants really have tried to improve their accessibility knowledge. But they get overwhelmed when they go to the official documentation from the W3C and try to understand it.

Mike Cherim brings this up in Making Web Accessibility Accessible, an article that is over a year old but still just as relevant. He notes that accessibility is harder to get into than it should be for several reasons, one of which being that the documentation (WCAG 1.0) is hard to understand. And it doesn't look like things will get much easier when WCAG 2.0 is released and becomes the norm.

In addition to the documentation problem, Mike also mentions the unhelpful attitude held by some people who seem like they don't want to help the less experienced, the misguided or the misinformed, and instead choose to criticise them. I see it too sometimes, and I have probably been guilty of doing that myself. But I really try to help where I can by sharing what I've learned about web accessibility so far. And I'm still learning, so I really appreciate when other people share their knowledge.

Over the years I've spent countless hours writing articles, responding to email and comments, and participating on discussion forums. No matter how much I would like to, there is no time for me to do more unless I quit my dayjob. And since my dayjob is how I pay the mortgage, well, that's not very likely. Writing articles takes lots of time, for me anyway.

Going back to Mike's article, he suggests a few things to think about when you talk about accessibility with other people who work in the fields of web design and development:

• Be a translator: Learn the specs and translate them into English.
• Be willing to give back: If somebody asks for your help, try to find time to respond.
• Accessibility is happy: Give accessibility a smiling face.
• Encourage don't admonish: When somebody makes progress, acknowledge that instead of criticising what they do wrong.

Good suggestions, Mike. I will try to get better at each of them. For instance, I guess I could be a little less grumpy sometimes when I come across bad examples or implementations. But not always... ;-).

Add 456 Berea Street to your Technorati favorites.

Posted in Accessibility.

The Art and Science of CSS (Book review)

The Art & Science of CSS is not a very thick book, and it doesn't have to be since it is not a reference book on CSS. It is a rather quick read, but it contains useful and practical tips on how to create certain design elements with CSS. These are tips that you can adapt and use in your own projects.

Five authors have contributed to this book: Cameron Adams, Jina Bolton, David Johnson, Steve Smith, and Jonathan Snook. Bolton, Johnson, and Snook have written one chapter each, while Steve Smith and Cameron Adams have both written two chapters. It's an author line-up that raises expectations.

There's not a lot to say about the general structure of the book. There is no introduction to CSS or HTML in here. Instead you jump right in and get working on the examples. During the course of the seven chapters you will find new or different ways of styling, creating, or manipulating headings, images, backgrounds, navigation, forms, rounded corners, and tables. Those are the main topics of each chapter, but in each chapter you will pick up other tips as well.

So, what do I think of this book after reading it? Well, it's not bad. Plenty of good tips and useful techniques are described in it. It's not perfect either. I guess it's partly down to personal preference, but I am not too fond of books that have multiple authors unless there is one main editor that makes sure all chapters are at least reasonably similar in style. I can't quite put it into words, but to some extent the different styles distract me from the actual content.

Apart from the difference in writing style between the authors, there is also the difference in coding practices for both CSS and HTML. It's ok for someone who is experienced and can see that the differences are often just personal preferences, but this book is meant for people who aren't CSS or HTML experts. I can easily imagine how confusing it is to see different approaches to font sizing in different chapters of the same book, with no explanation of why. I think consistency would have been good here.

With that in mind, reading The Art & Science of CSS will teach you how to use CSS to accomplish a number of useful design tasks, so I think it's worth its price unless you already know most of what there is to know about CSS.

As with all SitePoint books, there are sample chapters you can download to find out if the book is right for you.

The Art & Science of CSS

Authors: Cameron Adams, Jina Bolton, David Johnson, Steve Smith, Jonathan Snook

ISBN-10: 0975841971

ISBN-13: 978-0975841976

Add 456 Berea Street to your Technorati favorites.

Posted in CSS, Reviews.

Standards mode is the new quirks mode

Just in case you haven't already read the companion articles Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 and From Switches to Targets: A Standardista's Journey at A List Apart, I suggest you do so now.

Back? Good. If you didn't read the articles, here is an executive summary: Because of their immense fear of making broken websites that should be fixed look broken in Internet Explorer, Microsoft are going to make developers add a particular meta element to any page that IE 8 should use its "really, really standards mode, and we really mean it this time" to render.

Now, this is one of those subjects that if you have an opinion on it, it doesn't matter what that opinion is. It will be the wrong opinion to a lot of people anyway, and people will become rude and call you names. Come to think of it, most web related subjects seem to be of that kind these days.

When I first read the articles I just mentioned I shrugged, finished my breakfast, and drove to work. Yawn. Big deal. But after several people have asked me what I think about it, I re-read the articles and the comments posted on them as well as a lot of other people's opinions. And now I have an opinion which will be the wrong opinion to many people. What else is new...

I'm not convinced enough that I can say my opinion will never change, but for the most part I think introducing this switch is a bad idea. If other browser vendors than Microsoft also introduce it I think it's a really bad idea. As do others – read The Internet Explorer lock-in and <META HTTP-EQUIV="X-BALL-CHAIN"> for starters.

So, please tell me why those of us who think this is not a good idea are wrong.

Add 456 Berea Street to your Technorati favorites.

Posted in Browsers, Web Standards.

Simply JavaScript (Book review)

A book that is sub-titled "Everything you need to learn JavaScript from scratch" is obviously not aimed at experienced JavaScript developers. However I don't think Simply JavaScript is suitable for absolute beginners either, since it contains programming examples that aren't all that easy for someone without at least some programming or scripting experience to wrap their head around.

The authors, Kevin Yank and Cameron Adams, get off to a great start by explaining the three layers the Web is built on (presentation, content, and behaviour) and how CSS, HTML, and JavaScript should be used for each separate layer. When a JavaScript book starts by talking about unobtrusive scripting and even mentions that perhaps JavaScript isn't always the best way of solving a problem, you can be reasonably sure that it's been written by someone who knows about modern Web development.

Since this book is not aimed at JavaScript experts, there is a whole chapter devoted to explaining the basics of programming with JavaScript. Variables, statements, conditions and loops, functions, and objects are all talked about in an easy-to-understand way, accompanied by plenty of code examples and illustrative figures.

After the first two introductory chapters, the authors dive into some actual programming for the next several chapters. The DOM, events, animation, form scripting, finding and debugging errors, and Ajax are all discussed in one chapter each. The final chapter takes a look ahead at the future of JavaScript.

Throughout the book, the Core JavaScript library is used to make some common DOM scripting tasks easier. I hadn't heard of Core before, but it seems to do the job and is very lightweight. It's so small that the entire source is included in the book.

Overall I think the authors do a great job of explaining JavaScript. The examples and code are easy to follow and explained well, and the book is written in a friendly and inviting tone. I picked up a few tips and tricks from reading this book, which for me makes it worth the time it took to read it.

Revisiting the sub-title of this book, I think the audience that will get the most out of it falls somewhere in between the novice and expert levels. To me it seems best suited for designers or developers with a decent knowledge of HTML and CSS and some familiarity with JavaScript. If that describes you, I can recommend Simply JavaScript.

As with all SitePoint books, there are sample chapters you can download to find out if the book is right for you.

Simply JavaScript

Authors: Kevin Yank, Cameron Adams

ISBN-10: 0980285801

ISBN-13: 978-0980285802

Add 456 Berea Street to your Technorati favorites.

Posted in JavaScript, Reviews.