The project we are working on is going to remain under wraps for a little while yet, but I can say that it is something we have wanted to use in our business for some time now, and we have a hunch it might be useful to other businesses too. You can keep up to date with what we are up to on the project’s own blog - Project Dog Food.

Clean URL Design

One of the key features to look for when evaluating a CMS is its ability to publish content with clean URLs. Not only because you want to be publishing content with nice clean URLs, but because this tends to betray the manufacturer’s underlying understanding of how the web works.

Being able to write software and having a good grasp of how the web works are two different skills. All too often you find that content management systems - even big commercial ones - can be written by teams with an understanding of the former, yet not the latter.

So why is this important? In his 2006 presentation Native to a Web of Data, Tom Coates talks of the importance of URL design, summarising by saying:

“Use readable, reliable, and hackable URLs.”

URLs should be readable - a visitor should be able to get a good idea of what the page is about simply through the component parts of a well structured URL. This can be hard to achieve if your content management system constructs its URLs using obscure article or category IDs - the visitor can’t get a sense of the page’s content from numerical IDs. What’s more, descriptive, readable URLs index better for search engines and therefore make your content more findable.

URLs need to be reliable. Once released out into the wild, a URL should continue working, ideally forever. It’s a lot easier to ensure that if your URL is an alias and not a direct representation of the underlying technical infrastructure.

URLs should be hackable - and by that we mean a visitor should be able to intuitively make changes to a URL to get to other content without the need to follow links.

Data Feeds

If you need a content management system, it’s because you’re publishing a lot of data to the web. If you’re publishing information to the web, you should be making that information easy to find, read and track. The best way of doing that is to publish your information in RSS or Atom format at the same time as publishing to HTML.

By having your content management system publish feeds for the content on your site, you not only enable customers to subscribe to your site a receive notification when new items are published, but along with appropriate licensing, you simultaneously enable people to take that information and add value to it in ways you’d never expected.

Data Stored in an Open Format

No CMS is forever, and at some point you will find yourself needing to get the data out of your CMS and into something new. Most content management systems store data either in a relational database or as XML, and it’s important to have an overview of how that information is stored so that you can be confident that when the time comes it will be possible to practically move that data out and into something else.

I always suggest that data is stored in an open format, or at least in a very common format. To say ‘open’ I mean that the format is not owned and controlled by a single commercial entity, but rather a freely usable standard. This helps to ensure that the storage format you are using isn’t going to be discontinued and become inaccessible in the future. XML is a good example of an open format. If storing data in a relational database, MySQL is a reasonable choice as it is both an open source product and also uses a reasonably straightforward dialect of SQL.

I worked with clients in the past where the only method of getting data out of their proprietary format database was to invest thousands of pounds in upgrading to the newest version of the product - simple to be able to move away from it. That sort of surprise is never much fun, and often comes just at the time when your budget has been allocated to putting the new system in place, never mind removing the old.

Customisable and Accessible Administration Interface

Whilst your site visitors will spend their time with your site’s front end, those who are responsible for administrating the site, editing content and so on will be stuck working with the administrative interface. Depending on the scale of your operation, that can be a lot of time for a lot of people. Therefore, the admin interface should be easy to work with.

A lot of the time this means having the ability to customise the interface to your specific needs, being able to turn off unneeded elements to clarify workflows and make life easier. You’ll probably want the ability to brand the interface appropriately, too.

One of the most crucial aspects, however, is the need for the administrative interface to be accessible. Employers have a responsibility to their employees to make sure the systems they provide are usable. Web-based admin pages should follow the same principals of progressive enhancement that your front-end templates are using for the public and your customers. They should work fully without any JavaScript, text should be easily resizable and operation should not rely on a particular input device such as a mouse.

Search

Search is a features that’s often easy to implement, but really hard to get right. This is especially true if your site contains varied types of data. For a straightforward articles-based site, a general full-text search across articles can work well, but do the results accurately reflect the context of the results in a way that guides the visitor to the most relevant articles?

If your site contains, for example, event information or perhaps office or store locations, can the search results page display those data types in a meaningful way so that a visitor can be confident they’ve found what they’re looking for before clicking through to the results?

As the volume of content in your site grows, search becomes an increasingly important method of navigating that content and so it is important to provide a good user experience.

Multi-site Support

If you run, or plan to run, multiple content managed sites it can be really useful to have a single CMS that can handle multiple sites rather than multiple instances of a single-site system. Not only can it save on cost, but also in the administrative overhead of needing to manage, upgrade and maintain multiple systems.

There are also great gains to be had if share any content between sites, with the ability to maintain and repurpose content centrally. If your sites require user accounts, and your visitors are likely to use more than one of your sites, it can be extremely beneficial both to you and the visitor to have those accounts shared across all sites.

Multi-language Support

Whilst it can be unwise to over-anticipate future requirements and buying into them before the needs are real, there are some elements that are important to think about early and be forward-looking on. One such element is the need to support multiple languages on your site.

Even if you don’t implement the technology to deliver your site in multiple languages (and it’s logical not to if you don’t have this need), it is prudent to make sure that your content management system is storing and handling data using Unicode the entire way through the process. Provided that data is stored and handled as Unicode, future expansion to include support for multiple languages becomes much, much easier.

Caching

A site requires content management because it has a large volume of content, or wants to control the way that content is handled, not necessarily because it’s a busy site with a lot of traffic. However, even if a site isn’t likely to be very busy with traffic right away, it pays to think of how it will cope with higher traffic levels sooner rather than later.

Caching is the process of saving the result of expensive operations for reuse the next time that same operation is needed. For example, instead of piecing a page together by going back and forth to the database for each item of content, that process can be performed just once, with the resulting page being stored in a cache. The next time the same page is requested, it can very quickly be retrieved back from the cache without the need to rebuild the page. This reduces the demand placed on your server and therefore enables a site to cope with higher traffic levels more easily.

Many content management systems have multiple levels of caching to help with performance, and it really pays dividends to have the facility to do so available.

Recent and Emerging Technologies

With Web 2.0 taking firm hold, site visitors increasingly expect to see a range of more interactive features. Technologies like Ajax are easy to implement on the front-end, but can your content management system service the requests for data that a needed? Can it output JSON easily?

Most content management systems have the facility to categorise content, but can content also be tagged if needed? Can those tags be searched easily to expose related content? Do your user accounts support OpenID authentication, and are names, addresses, events and the like stored as structured data so that they can be exposed using microformats?

Some of these are relatively new technologies now, but they are becoming more established all the time. If you don’t have support for these features today, will your content management system feel like a dinosaur in a year’s time?

Conclusion

Of course, there are many features to look for when choosing a content management system, and many of them depend on the particular needs of your project. However, by spending time in evaluation and paying notice to some of the more core issues you can help to ensure that your relationship with your next content management system is not an unhappy one.

In addition to several interesting projects we have also taken time to develop our own CMS platform. We’ve found that for a lot of the work we do, the requirements are complex enough to need custom development (as opposed to an off the shelf CMS) but do have some common features. As the majority of our work is for design agencies, another important requirement was that the CMS did not restrict the design of the site in any way. Therefore we have developed a CMS framework that acts as a platform for custom development - giving us a quick way to roll out the common features while also providing a framework for the development of custom elements. We have some projects now up and running on it and it has been fantastic to work with - the only annoying thing is that we didn’t get round to doing this sooner! You can read more about the CMS platform here, and of course get in touch if you would like to know more.

In other news we have a couple of places left on our Beginners CSS Training Course, it will be at least two months before we run another of these courses so if you do fancy learning CSS with us next Friday the 25th April, you can book online. Drew and I will also be at @media in London at the end of May where I will be speaking on a panel entitled Communicating Best Practices. @media is part of London Web Week and on the Tuesday of that week Drew is organising the Microformats vEvent, along with Frances Berriman.

– Rachel Andrew

With Drew joining the company we are going to be able to offer training. This is something that we have had numerous requests for but haven’t had the capacity to do up to now. Our first open CSS one day course will be held on the 29th October 2007 in Maidenhead – read the CSS beginners course page for more details. We will also be able to come and run this course in-house for your company if you have several members of staff to train, get in touch if you would like to discuss that.

In other news, Rachel Andrew’s latest book The CSS Anthology, 2nd edition’ is now on sale. This revised edition of the best selling CSS Anthology brings the “tips, tricks and hacks” up to date covering IE7 and techniques made possible by the widespread adoption of standards compliant browsers.

“It’s just not working!”

When you find a problem, it is very tempting to just fire off an email and presume that the developer will immediately be able to see the problem too. However, by taking a few minutes to describe the problem you have encountered accurately you can prevent any confusion occurring as to what the problem is and save both your time and the developer’s as she won’t need to get back to you to find out what actually happened, or spend a long time trying to reproduce the issue.

A good report

A good bug report tells your developer three vital things:

• What you expected to happen
• What actually happened
• What you did/were doing when it happened

What you expected to happen

There are two kinds of ‘bugs’, the first is where something breaks – you see an error message, your uploaded data disappears, you submit a form and the change isn’t saved. These bugs are generally pretty easy to report and identify as all your developer needs is to know exactly what you were doing or inputting at the time and they should be able to reproduce and fix the issue.

The second kind of bug is where the application doesn’t function as you expected. This might be because the developer has misinterpreted part of the specification or it could be that what you expect just isn’t how something can work. In this case the developer believes that it is working fine – and in fact it is ‘working’ even if it is incorrect. If your bug report is that the feature is broken, the developer may then spend time looking for some error in this part of the application when what they need to realise is that it isn’t working as you expected. By giving the information about what you expected to happen the developer can think ‘ah … you wanted it to do x and it is doing y’ and a resolution can be sorted out quickly.

What actually happened

What actually happened is very rarely ‘nothing’ yet bug reports often contain the phrase, ‘nothing happened’. If what happened was ‘nothing’ in terms of the intended result then explain that in a few more words, for example, if you clicked the submit button on a form and it didn’t submit and go onto the next page you could say,

“The form didn’t submit – it just remained on the same page.”

Or perhaps the form submitted and a blank page displayed,

“After submitting the form a blank page loaded.”

If an error message displays on the screen then include that in the report. Just copy and paste the error message.

If you use Internet Explorer then your browser may not display the error message generated by the server, instead showing a generic error page. You can ensure the IE displays the real error message by going to Tools > Internet Options > Advanced. Then scroll down to the browsing section and uncheck ‘Show Friendly HTTP error messages’.

What you were doing when it happened

Your developer wants to know this information – not because they want to tell you that you were doing something wrong, but because it is highly likely that the bug occurs only when a certain path of actions is followed, or when a certain type of data is entered. The more information you can give your developer the easier it will be for them to reproduce the problem you saw and fix it. Things you should include:

The steps taken
List exactly what you did, in the order you did it if possible. If you can go back and try the same steps again and the problem happens again that is great – note down exactly how you made the problem occur. Your developer will be pleased as you have just saved her time trying to reproduce the issue. Even if you can’t reproduce it, no-one is going to doubt that the problem happened – just describe as much as you can remember how you got to the broken point.

Any data you were entering
If the problem happened after you added some data to a form, include the data with the bug report. If you were uploading something such as an image into the application then include that too.

It may also be helpful to copy and paste the URL out of the address bar of the browser so the developer knows exactly which page you were on at the time.

The browser and operating system you were using at the time
With web applications problems may only be occurring in one browser. Let your developer know exactly what you are using – including the version number - so they can create the same environment to test the problem.

Effective bug reporting can make a huge difference in how quickly problems can be resolved, and prevent frustration on both sides of the process. Including the above information, even if it doesn’t seem relevant, will be appreciated by the developer. You don’t need to write an essay, just a few clear lines explaining the key information of:

• what you expected to happen
• what actually happened and,
• what you did/were doing when it happened.

This will be enough to isolate all but the most complicated of issues, and once an issue can be reproduced it is well on its way to being fixed.

When we work with our clients we often have to steer them in a different direction to that which they had initially envisaged based on our experience and expertise. When I asked Jon Hicks if he would redesign the edgeofmyseat.com website, we hadn’t considered a rebranding exercise. However when he advised that the existing logo wasn’t really fitting with our aims for the redesign, we were happy to take his advice and I love the new chair - it seems far more robust than the wobbly Sunday School chair of the previous branding.

One of my aims in the redesign was to deal with the legacy articles that exist on this site. I don’t want to remove older content dealing with such issues as standards compliancy in Dreamweaver 4 as people are still using this software, and we still get emails from people for whom this content is relevant. Hopefully the new blog style format - which is running on Wordpress - will help to clarify the dates of older content, and that the advice may be a little on the old side! I also want to be able to add more of this style of content to the site, content of interest to the people and companies that we work with - so watch this space!

This redesign is still something of a work in progress, one of the issues with the old site was the lack of case studies and information about the work we have done. Some case studies should be published here over the coming weeks and there are still elements of Jon’s design that need to be implemented across the site, however I wanted to get this live, get some feedback and be able to take the site forward sat in my nice comfortable new seat.

- Rachel Andrew

What is the Disability Discrimination Act?

The Disability Discrimination Act makes it unlawful for providers of goods, facilities and services to treat a person less favourably because of their disability, since 1st October 1999 providers have been required to make ‘reasonable adjustments’ for disabled people to help them to use their services. This legislation quite rightly includes web sites and as it is actually fairly easy to make a site accessible (far easier than needing to adapt a building, for example) there is no reason why site owners should not comply. In fact there are clear business benefits in doing so, that we will look at towards the end of this article.

The code of practice for service providers can be downloaded in PDF format here (http://www.drc-gb.org/open4all/law/Code%20of%20Practice.pdf). It is a fairly lengthy document, and much of it is not of importance to business owners who trade or offer services exclusively online. However it is fairly easy to read and highlights some examples of where accessibility needs to be taken into consideration.

“What does the act make unlawful?
2.2 The Act makes it unlawful for a service provider to discriminate against a disabled person:

• by refusing to provide (or deliberately not providing) any service which it provides (or is prepared to provide) to members of the public; or
• in the standard of service which it provides to the disabled person or the manner in which it provides it; or
• in the terms on which it provides a service to the disabled person.”

Web sites are specifically mentioned in the Code of Practice in several places, including in the examples for “What services are affected by Part III of the Act” 2.13 - 2.17

“An airline company provides a flight reservation and booking service to the public on its website. This is a provision of a service and is subject to the Act”

How are disabled people using the web?

Many disabled people use the web with a standard computer and web browser, and a well designed site will make their experience much better. A visitor with poor eyesight might simply need to increase the text size on your site; another user might not be able to differentiate between colours and only has problems if you have made colour coding the way that different sections are explained within the site, or used a low contrast text colour against your background. A visitor who has cognitive problems and finds it difficult to understand how to get around a site will benefit from a carefully designed navigation system. Another visitor might be unable to use the mouse and is using the keyboard only to get around the site, being able to easily tab between links and other elements makes the site easy to use.

Other visitors might be using some form of assistive technology. This could be a screen reader, which reads out the text on the page.

What sort of changes do I need to make?

Now that we have considered the ways in which our visitors might be using the site, it makes it much easier to see how we can help them. The below list is a brief run down of some of the ways in which existing sites can be adapted to ensure that the information is accessible to all users. It isn’t a step by step guide of how to achieve each adaptation - if you have built your own site the links at the end of this article will assist you in making these changes yourself. My intention here is to give you the knowledge to be able to check out your own site and either make the changes yourself or ensure that your design agency do so.

Valid mark-up

For your site to be accessible the mark-up that creates the pages should validate. That means it should be correctly formed XHTML or HTML. While modern web designers should be well aware of the need to validate their code, older sites may be full of invalid code that can cause problems for assistive technology. To check your site go to http://validator.w3.org/ and type your URL into the box. The report you will get back will show you any errors in the mark-up of the site.

Alternate text on images

Where you have used images on your site you should add alternate text so that a user who cannot see the images understands what they mean - this is especially important if your site uses images for navigational elements in a menu for example. The HTML img tag has an attribute - the alt attribute - that can contain this alternate text, and this should always be utilised.

Ensure text can be resized in the browser

Frequently web sites use a method of setting the text size that prevents users of Internet Explorer using the browser to enlarge the text, this causes a problem to anyone who needs large print. Fonts should always be sized in a way that will allow users to change the font to a more comfortable size if necessary. By the same token text in images should be avoided as there is no way to increase the size of text that has been saved as an image in a graphics programme and then the resulting image added to the page.

Ensure that colour is not used in a way that will confuse users

Make sure that you are not using colour as the only way to identify sections or choices in a site as some users may get the colours confused. For example suggesting that people select the red or green button would be a problem to someone who confuses these colours.

Also, where colours are concerned be careful not to use a combination of colours that might be difficult to read, such as grey text on a light grey background, or two very strong colours such as blue on red.

Check your site in a text only browser

If you can navigate your site easily using a text only browser then your users should be able to do so with a screen reader or other device. You can see how your site acts when it is text only at the online Lynx Viewer. Simply enter your URL and then check whether you can easily navigate from page to page and access all of the content.

Limit use of Flash or other media content - or provide an alternative way to get the information

If information is contained in a Flash or other media element - such as instructions on how to use a product - then providing this information in another format is vital for those who cannot see or hear the information. A link to an alternate page that contains a transcript of a downloadable seminar in movie format, or that explains in a step by step manner something which was demonstrated by a movie means that your information will be accessible to all users.

I’m planning a new site, what should I consider?

If you are going to design and build your own web site, or have an in-house designer, then there are some resources at the end of this article to read or pass onto your team. If you are intending to hire a designer or agency then how can you be sure that your chosen designer can actually deliver what you need in terms of accessibility?

One way is to look at their agency site or portfolio and see if they discuss accessibility at all, then have a quick look using some of the checkpoints above and see if they seem to be practicing what they preach. There is also a fairly new organisation called GAWDS - the Guild of Accessible Web Designers - which has an International membership but there is a good coverage of UK designers and developers all of whom work to develop accessible sites and have had their work checked out by GAWDS prior to their membership being accepted.

When you put together your brief for the web site, make sure that accessibility is part of that brief, and therefore part of what you are paying for. Then listen to your chosen experts as they should be able to explain why certain choices are better than others in terms of accessibility as they design and develop the site.

How does this help my business?

Apart from the legal aspect, creating an accessible web site has clear business benefits. The changes you make to your site to ensure that it is usable by all means that those users who might have clicked the back button are going to stay on your site, if your store is accessible and your competitors is not - who is going to get the custom from those people who benefit from being able to enlarge text or are not confused by colour choices?

In addition to the market sector who really need sites to be accessible, a site that can easily be read by a text only browser is also far more easily indexed by the search engines, which should give you’re a boost in your search engine rankings. A lot of the things that are problematic to disabled users also cause problems to the search engine spiders.

In addition to those using devices other than a standard web browser because of disabilities, there are now a growing number of people who are accessing the web via PDAs or mobile phones. These devices are often far more limited in their display capabilities than a regular web browser and your accessible site is likely to help these users to find what they are looking for.

Summary and further reading

I have not attempted in this article to give a full account of accessibility issues and theory. If you are employing and agency or have in house developers then they should be conversant with these issues and hopefully this article will give you enough information to be able to ensure that they are doing what is necessary. If you are developing your own site, or would just like to read some more about these issues, then the following links should help.

• The Web Content Accessibility Guidelines - http://www.w3.org/TR/WCAG10/
• WebAIM: Techniques and Concepts - http://www.webaim.org/techniques/
• Accessify - http://www.accessify.com

If you have downloaded a copy of the Dreamweaver MX Preview Release you may be pleasantly surprised to find how many of the things that we, as developers wishing to work to the W3C standards, want and need have been incorporated into the program. This article is designed as a quick tour of some of the most helpful new features.

DOCTYPES

Dreamweaver MX now adds a DOCTYPE to your documents. Selecting File > New will launch the New document dialogue where you can select from a wide variety of page types. Selecting ‘Basic Page’ ‘HTML’ will give you a page with an HTML 4.01 Transitional DOCTYPE. You want XHTML? You’ve got XHTML. Before you click ‘Create’ to make your page, check the ‘Make document XHTML Compliant’ checkbox, and you will not only start off with a document with the correct XHTML DOCTYPE, but Dreamweaver will now work in XHTML with this document, closing tags, quoting attributes and generally being the kind of software we’ve all asked for.

New Document

Alt Text

Dreamweaver MX ships with Accessibility features, many of which are turned OFF by default. You probably want to turn these useful reminders on. To do this go to: Edit > Preferences > Accessibility and check the box ‘Images’ below ‘Show Attributes when Inserting:’.

Accessibility Preferences

With this option turned on, each time you insert an image you will be prompted to add alt text, like so:

Image Tag Accessibility Attributes Tag

In the accessibility preferences you can also turn on prompts to add attributes for Form Objects, Frames, Media (such as Flash movies) and Tables. If you are interested in, or are required to use best practices for accessibility then this functionality can serve to ensure you don’t miss attributes.

Page Designs (Accessible)

If you are unsure as to how to use the Accessibility Attributes, there is often no better way than to see them in practice. Dreamweaver MX now ships with a collection of Page Designs, including a separate category for Accessible Page Designs. These can be found by choosing: File > New > Page Designs(Accessible). In this dialogue you will be able to choose from a selection of Accessible Designs for common uses. These can really help you get a head start in understanding how to use the Accessibility Attributes.

The Validator

Dreamweaver MX now has its own validator. The validator preferences can be found by selecting: Edit > Preferences > Validator

Validator Preferences

In this dialogue you can choose which versions of html you would like to validate against. Once your preferences are set you run the validator on the document you are working on by:
For an HTML page
File > Check Page > Validate Markup

For an XHTML or other XML document
File > Check Page > Validate as XML

Your results will appear on the Validation tab of the Results Panel. Double clicking an error will highlight it in your document making it easy to find the offending item.

Validation tab of Results Panel

There is no validator for CSS within Dreamweaver MX, so don’t forget to check that your CSS file is valid by checking it at: http://jigsaw.w3.org/css-validator/

Things to Remember

Whilst I believe the Macromedia have done an outstanding job on bringing Dreamweaver up to this standard, at the end of the day it is still up to the person at the keyboard to ensure that their pages validate, and not rely on any software to ‘do it for you’.

One place you will still need to take care, particularly when working in XHTML is when using third party extensions. Many popular extensions will have been made pre-Dreamweaver MX, particularly in these early days, and may not comply with XHTML or even HTML specifications. Run your page through the validator to find out. Often the changes that will need to be made to the mark-up will be very minor and need not mean you have to stop using your favourite extension - you might just need to switch into code view to make a few small edits before uploading your page.

For more information on the new CSS features in Dreamweaver MX, read my article as published on the Macromedia Web site - Best Practices in CSS with Dreamweaver MX, and also another tutorial on this site ‘Dreamweaver MX and external CSS-P‘.

Once you have downloaded and saved the stylesheet, create a new html or XHTML document in DW and attach your stylesheet using the CSS Style panel.

The CSS Style Panel of the Design Panel Group

Save your document. Type ‘this is the content div’ at the point at which the cursor is in your document. Don’t hit return or anything else! Then select the text you have just written.

At the bottom right of your Property Inspector lives the ‘Quick Tag Editor’ (circled in red in the image below).

Location of the Quick Tag Editor

The Quick Tag Editor can wrap a selection with a tag, and in order to work with the divs defined in our stylesheet we will need to wrap areas of the page in div tags. So, click on the Quick Tag Editor icon and a small dialogue will appear, we need to wrap our selection with a div tag, with the name of our content div in the stylesheet, which is conveniently named ‘content’. Type into the dialogue:

<div id=”content”>

Wrapping text in a div tag using the Quick Tag Editor

Hit return, and your text should now display as per the attributes set for the div named content. Now select your text once again (not the whole div) and in the Quick Tag Editor type:

<p>

This will wrap your first line of text in a paragraph tag - of course you could use <h1> here or anything else that you have defined. Dreamweaver gets confused if you try to wrap a <p> tag in a div and applies the id to the <p>, which is why we seem to be doing this backwards!

You will need to do the same for any other divs that are specified in the stylesheet. However, Dreamweaver is reluctant to let you click outside your initial div in order to add a second, to get around this, the simplest thing to do is switch into code view. Click the cursor after the closing </div> tag, and then switch back into design view.

In my example stylesheet I have a div named ‘navigation’ which provides a right hand navigation bar. Once you have clicked outside of your first div as described above type ‘this is the navigation div’ into your document window. It should show up just underneath the border of your initial div.

Our page in the Document Window

Select this text and with the Quick Tag Editor wrap it with:

<div id="navigation">

The navigation should immediately jump over to the right hand side of the screen. Wrap the text in a <p> tag as we did with the content text.

Once you have set up all your defined divs, you should find that you can work relatively easily with your CSS layouts in Dreamweaver. As an example, in the navigation area add two dummy links - link one and link two. Using my stylesheet these should show up bright orange as that is the main defined link color.

Select the text of one link then, using the CSS view of the Property Inspector apply the ‘nav’ class to this link.

Applying a CSS style with the New CSS View of the Property Inspector

Things to watch out for

If you had ever tried to work with a CSS layout in Dreamweaver 4 you will know that it was a battle for anything other than the simplest of layouts, with Dreamweaver adding inline styles and cheerfully breaking your layouts. Dreamweaver MX is a far better tool for working in this way as long as a few things are remembered:

Don’t drag your divs around the document window - once you have set up your divs, try not to move them. This will probably not cause a problem with divs positioned from the left, but right positioned divs such as our navigation panel may endup with an additional ‘left’ position inserted into the stylesheet, which will spoil the liquid layout of the page. If this does happen, simply remove the additional left position attribute from the stylesheet.

Take care that you are selecting the appropriate text/page element when applying classes and wrapping elements in a div. Sometimes it is worthwhile switching into Code View to check.

I hope that this tutorial has been helpful, you may find that it is easier to set up the initial divs in Code View and then switch to Layout View to add your content. However, this tutorial serves to point out some of the places where problems could occur but also to show that, with Dreamweaver MX, we have a tool where it is possible to work with CSS layouts.

So whose standards are these?

The ‘web standards’ to which we refer, are standards set by the W3C in order to create an html specification that all html authors (thats you and me), browser manufacturers (Microsoft, Netscape, Opera etc.) and manufacturers of tools which write html (Macromedia, Adobe etc.) should follow. The various browser manufacturers have always added in their own special tags and functionality to the HTML specifications and this is not so much a problem. What is a problem is the different ways in which the browsers interpret the standard html tags that we all use to mark up documents.

As an example, imagine if Internet Explorer decided that the <p> tag should be interpreted as being 12 carriage returns whilst all the other browsers interpreted it as 2!
The above is obviously an extreme and unlikely thing to happen, but smaller and similarly problematic differences are present in all of our current browsers. These differences were probably at their greatest with the version 4 browsers that many people are still using today, even though there are much improved versions available for free download.

Why is this a problem?

It’s a problem when browsers don’t stick to standard code for many reasons. Time is a major factor for most of us working as professional designers and developers. The time that it takes to hack around display bugs in each browser could be better spent improving our sites and our skills. In addition, many of the methods used to counteract browser bugs in the version 4 browsers make our sites totally inaccessible to those using alternative browsing devices to view our pages - braille readers and speaking browsers for example.

Are things getting better?

The good news is that they are, the most recent generation of browsers are much closer in their implementation of the W3C standards than ever before. If you code to the W3C standards much of that code will work in most cases, and in many of the cases where there are differences they are no big deal or a slightly different (and still standards compliant) tactic will fix the problem. Even if you do run into a true browser bug, the fact that your code validates will make it much easier to identify the bug and find a way of getting around it by searching the many resources now available to address browser issues.

Is there anything that can be done to encourage more compliance?

The fact that browsers have become more compliant means that browser manufacturers have been listening, but there is still plenty of room for improvement. The Web Standards Project should be your first stop for information on the campaign to get better standards compliance in our browsers and authoring environments. They have done amazing work in bringing the standards issue into the open and the site has pleny of resources to help developers bring their sites up to the standards. The more developers who start to code to standards the better, as it will show those who build our browsers and authoring tools that this is what the development community want.

So what about the tables v. CSS thing that everyone is shouting about?

Part of the W3C recommendation is that tables should not be used for layout but only for tabular data, tabular data is the sort of thing that you might find in an Excel Spreadsheet - for example - if I wanted to make a list of browsers and their known bugs a table would be totally acceptable.

Using a table to layout the design of your site is not an appropriate use, the main reason for this is that it means that a text only browser (or a speaking browser) can’t follow the natural flow of the text and could end up reading the page in totally the wrong order!

When you use CSS to position elements on the page, you can lay out the text in a logical order so that it can be ‘read’ normally with no style applied. All the positioning comes from your stylesheet and so is ignored by anything that doesn’t read CSS.

The benefits of using CSS for layout are further reaching than just helping accessibility. If you wish to change the layout of a CSS based site then all you need do is change a few settings in the linked stylesheet and all the elements move into their new places across the site. You can change the entire look of a CSS based site in just a few minutes - compare that to having to open and edit page after a page of complex tables.
It all sounds great - but I get too many Netscape 4 users to do this

Standards compliant, CSS based layout doesn’t have to mean losing backwards compatibility. Have a look at this site in Netscape 4… still with me? Yes, it looks ‘different’ but if you had never seen the site in a newer browser you wouldn’t know that, and by allowing small differences I get all the above benefits of standards compliance and accessibility without excluding the version 4s.

This is the future, US and UK government legislation has already meant that many developers have had to franticly get up to speed on accessibility issues, we could find similar legislation applied in any area at any time. Our clients are starting to understand much more about the web, it isn’t a great mystery anymore, I can see a time not so far round the corner when clients are going to ask the question ‘… but is it accessible?’. By being prepared for the changes, by understanding the issues and working towards getting it right we can all be a force for change - change for the better.