This is a great article about CSS coding: semantic approach in naming convention.
I am keeping this link for any time I will start a new project and will need to look back at some good advise for CSS naming conventions.
Surprisingly I was not far off with my currently undergoing project bar sorrento.
An image is worth a thousand words.
Nevertheless, I recommend you read the full story.
Many (if not all) HTML tags can have id attribute. This attribute uniquely identifies the tag on a single HTML page. Web designers use ids when they design the page using CSS. Web developers use ids for retrieving DOM objects via JavaScript or functional testing of their sites.
Despite the wide use of id attribute, many of us get it wrong, the value of the id tag attribute to be precise.
According to the HTML 4.0 specification for basic types:
ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
This is a very basic rule and yet many of us get it wrong, not on purpose of course.
The most common mistake come with web applications that display data from a database. Most commonly a database record is uniquely identified in the database by a record id. This is number that is unique per database table. The common mistake is to use this (database) id as a value of the id attribute on a HTML page. The problem is that the database id is a number, but HTML ids cannot start with a digit. Remember HTML ids must start with a letter A-Z or a-z. Therefore the database id needs to be pre-pended with at least a single letter.
Even worse, I have seen web applications to use entity names as ids. These names are semi-unique, but may contain international characters, characters outside of A-Z and a-z range and even spaces.
If you are going to use a prefix before the database id and you want to separate the two, I strongly advise you to use underscore ("_"). My reasons are the following:
Don't use spaces (" ")! The reason for this is simple. Space character is not a valid for id or name attribute.
Don't use hyphens ("-")! If you intend to use an id with JavaScript in the form document.idname.value, you must use a name that is a valid JavaScript variable name. Hyphen (or minus) would break the JavaScript on your page.
Don't use colons (":") or periods (".")! These characters are valid, however if you decide to use CSS or some JavaScript library that uses CSS-like selectors (e.g. jQuery), periods will be mistaken for CSS class selectors and colons for pseudo-class selectors (e.g. :hover for links).
For the geeky ones, it is possible to start an id with a number (if you really want to) but you need to represent this number with its Unicode escaped character.
I use Google Reader for reading blogs. It has become my daily chore as I need to keep track on things happening around our office (we blog internally and externally) as well as other things of my interest.
It was brought to my attention that Jon Hicks created new skin for Google Reader. I thought I would have a look.I had to install Stylish extension for Firefox first. Then I added a new style that I downloaded from Jon's website. And the result?
Before:
After:
I absolutely love it!
It has made reading blogs so much better. Why don't you give it a try?
I found this quite impressive animated GIF that show an evolution of a CSS for a website. The original post with animation was created by Dion Almaer.
Well done!
How can we make feature-rich web site and also offer the way so people with disabilities can access it?
The old way it to produce two version of the website, e. g. Flesh version and HTML only versions. The big drawback of this approach is that the user is presented with the choices first and only then the user enters the website with content. Or some sort of client-side script is run in order to determine the capabilities of the browser. There is no way easy way check the user this way (e. g. the user is blind). Therefore we have a behavior that can be switched ON or OFF.
A better way is progressive enhancement. Initially we have content that we want to publish or present. Then we have the markup – (X)HTML. We add the presentation layer – CSS. At last we add the behavior on top – DOM Scripting.
We still have to answer whether we have some of the functionality in-line or external (*.css and *.js files).
The HIJAX way is :
XMLHttpRequest instead of the server,We have a choice of data format:
eval()innerHTMLAnother important thing is that the browser is an unpredictable environment. The user can be running on any OS with any type of web browser. The only thing that we know is what is on our server. Therefore all business logic should be kept on the server side. For example a table sorting can be done on the client-side by JavaScript. This would off-load the server, but we would have to face the challenges with the differences between JavaScript support on various browsers. On top of that we would have no feedback about the usage of table sorting. If this logic was on the server, we could collect the data about table sorting and improve the website accordingly.
The main benefits of using Hijax approach are that we do not need to spend time building a non-Ajax version. Our web application will be still accessible in the usual way. We do not duplicate the logic (client-side and server-side validation) and the links are spiderable and potentially bookmarkable.
HIJAX is a term coined by. I learnt about Hijax at the Web Directions conference. Jeremy Keith presented Proressive Enhancement with Hijax. He is an author of DOM Scripting: Web Design with JavaScript and the Document Object Model and currently working on his next book Bulletproof Ajax.
In these days we turn for the answers to our questions to the Internet. Sometimes we even refer to it as the wisdom of the crowd.
Take IMDB for example. It is a centralized solution. When it comes to the reviews they are written by the people. But who owns these reviews? Are they real? Can we trust them? Google is the answer to all our prayers. Or as a big sign in front of one church said “Google does not have the answers to all questions.”
We saw the raise of open source. Then we also had a raise of open standards for document formats. They are getting more popular and also more important. The next step will be the open data. Standardizing the data format will also allow for more mashups. Very popular type of mashup these days is the combination of maps and some other proprietary data. If two people publish the data in two different formats, none of them can make use of the other.
Web has evolved. The move is from HTML to XHTML. The benefits are such as that microformats are simple data formats, HTML based, based on existing standards and existing development practices. To mention a few, there is hCard (based on vCard), hCalendar (based on iCal), hReview, hListing- for classfields, hResume and many more.
I also discovered that there are some Firefox extensions that discover microformats on the page and allow the user to see them. One that is worth mentioning is Tails.
Where to do from here? We all publish data on the web. More microformatted data we publish more options of their usage will be present.
More information about microformats can be found at microformats.org, microformatique.com. Read about how to highlight microformats with CSS. New book on microformats by John Allsopp will be coming out in early 2007.
I attended the Web Directions conference last week. One of the eye-opening sessions (at least for me) was “Accessibility 2.0” and “Designing for Accessibility: More simple techniques that make a difference” by Derek Featherstone from FurtherAhead.
Accessibility is about allowing disabled people to use our website. I have never worked on a project that would require access by people with disabilities. I think it really takes a real life experience to realize what these people must go through in their everyday lives. Why should we make it more difficult for them with our web applications? Do you know how many web applications stop working when you switch JavaScript off? You would be surprised to see how big number that is.
There are some guidelines that we can follow in order to make our websites more accessible. If we remove frames, replace menu images with menu using text and CSS, don't use tables for formatting, we make a big step towards accessibility of our websites. Another thing is having PDF documents on the website. PDFs are not accessible and they also need to be downloaded in order to read them and find out that it's not the document that we wanted. Another place for improvement are the web forms. Fields should have labels.
The phrase “people with disabilities don't go to our website” is just a nonsense. They do and they can also bring some revenue. Take for example Tesco Access. Grocery shopping on the web is an ideal service for visually-impaired customers. Imagine trying to tell a can of beans from a can of tomatoes on the shelf if you can't see the labels. Then think about having the description read to you by your computer. Their website was designed for accessibility and because of this feature it boosted revenue by another 4%.
Accessibility is personal. Removing barriers, user testing is personal.
Where do I go from here? Well, I will start at the roots – W3C Web Accessibility Initiative and Section 508. Then I will read Dive into Accessibility book that according to its website answers two questions “Why should I make my web site more accessible?” and “How can I make my web site more accessible?” Australia with its Disability Discrimination Act is six years ahead of USA.
I also found The Illinois Center for Instructional Technology Accessibility very informative. They list the best practices, have software for download (Accessibility Extensions for Mozilla/Firefox lives here) and lots more. Another great resource for developers is Evaluating Web Sites for Accessibility with Firefox by Patrick H. Lauke.
Some of these guidelines are very much a checklist approach. User experience is more important. Therefore we need to sit down with the real user, the one that will be using the system, and work together in order to fulfill the user's needs and expectations of this system.
