Source : articlesbase.com
Graphic design always has and likely always will be a very important part of marketing and of business in general. With the advent and exponential growth of the internet and e-business, graphic design suited to print and to the web is more important than ever—and will only grow in importance. For the success of your business, you need to locate a skilled graphic design professional that understands the art and the importance of graphic design in the electronic age.
As a successful business owner (or well-informed entrepreneur), you quite likely understand that one of the keys to success in business is securing the services of great service partners—in this case, the services of a great graphic design professional. And surely you also know that a great professional partner is one that understands your needs—even when you don't.
If your graphic design pro does understand your needs, he or she will understand that you are using your graphic designs as a means of marketing and branding. As such, designs must be attractive, interesting, and reproducible, without being overwhelming. They must also work as well on-line as they do off-line—because even electronically-based businesses have to write a letter now and then.
Graphic designs must put a professional face on your business or organization. Graphically designed materials will be the picture that sticks in the head of website visitors, clients, and other businesses, and that memory must be good or will either be forgotten—or worse—remembered in distaste. Graphic designs must have the ability to translate across all marketing avenues—things as basic as vehicle presentation, letterhead, print media, and so on.
Graphic design for the web must also be managed in such a way that it allows for the incorporation of the important aspects of web design that allow you to be found on the web—namely, web design and search engine optimization. Graphic design must primarily suit the needs of your human clientele, while accommodating the functions of search engines and spiders.
However, graphic design from your graphic design professional must serve your practical needs as well. It must achieve the goals you've set in a way that meets your budget. A good graphic design provider will have the ability to offer a variety of graphic design services and options for pricing.
What Did We Learn About Hiring A Graphic Designer?
To recap, we learned that
* Graphic design is historically important to marketing and business success
* Not all graphic design professionals understand the needs of businesses operating online (in whole or in part)
* All branding materials need to flow and work both online and off
* Graphic design is fundamentally important to website appeal for visitors and clients
* Graphic designs must be representational, capable of serving as your professional face-forward
* Graphic design for the web includes accommodating the functions of search engines and spiders.
For internet business, including those that are service-based but using the internet as a marketing tool, finding a good graphic design team to design your website is important. Make sure that you choose a graphic design pro who understands the whole picture, and who can deliver that whole picture to you with an eye to both flare and function.
Thursday, January 31, 2008
Wednesday, January 30, 2008
About Web Site Design Usability
A good website provides the first hand information about your company and its operations. Therefore, it must have the best visibility in all important search engines like Google, Yahoo and MSN. Having a strong visibility into search engines help a website o get viewed a number of times.
Thus, it is important to ensure the proper website design to make it really visible and user friendly. A good website must catch the users’ attention and provide them their desired information at once. Otherwise, your site is a waste of their time.
Here are few tips that may help a web site to earn praises from the ultimate users. Go through the below mentioned three important aspects of web site:
A Clear and Simple Navigation System
A good website design must present clear cut information about the company that too in simple understandable words. It should have simple navigation system to facilitate users to address their queries easily and conveniently.
Keep the Content Simple and Understandable
Users login to getting the relevant and necessary information. A beautiful design may attract users but it cannot retain their interest until and unless it provides something meaning to the users. It should have a value for visitors to keep them at the site and encourages them to return. Content is also the best way to boost your site in search engine rankings.
Always it is important to frame the content keeping in the mind the requirements of the search engines. Present your content with your users in mind.
Support Your Brand
It is better to make a website that supports your brand to a great extent. This helps a website to build its customer base. When your site is strongly branded, that means that visitors will think of you first when they go shopping for your product or service.
Thus, it is important to ensure the proper website design to make it really visible and user friendly. A good website must catch the users’ attention and provide them their desired information at once. Otherwise, your site is a waste of their time.
Here are few tips that may help a web site to earn praises from the ultimate users. Go through the below mentioned three important aspects of web site:
A Clear and Simple Navigation System
A good website design must present clear cut information about the company that too in simple understandable words. It should have simple navigation system to facilitate users to address their queries easily and conveniently.
Keep the Content Simple and Understandable
Users login to getting the relevant and necessary information. A beautiful design may attract users but it cannot retain their interest until and unless it provides something meaning to the users. It should have a value for visitors to keep them at the site and encourages them to return. Content is also the best way to boost your site in search engine rankings.
Always it is important to frame the content keeping in the mind the requirements of the search engines. Present your content with your users in mind.
Support Your Brand
It is better to make a website that supports your brand to a great extent. This helps a website to build its customer base. When your site is strongly branded, that means that visitors will think of you first when they go shopping for your product or service.
Tuesday, January 29, 2008
Dreamweaver CS3 Review
Adobe Dreamweaver CS3 has always been a solid tool for creating and maintaining Web sites. The latest version builds on an already powerful product by adding support for Intel processors, Photoshop integration, and templates and tools that simplify CSS (Cascading Style Sheets) design. It also expands into new territory by adding the Spry Framework for Ajax, a combination of technologies that includes JavaScript, CSS, and HTML for building interactive user interfaces such as pop-up navigation menus, tabbed panels, interactive tables, special visual effects, real-time form validation, and more, without having to return to the server to refresh the page.
Universal at last
Dreamweaver CS3 is the first version of the Web-design program to appear with the Adobe name; it’s also the first version to run natively on Intel Macs. Running on an Intel Mac, Dreamweaver CS3 is more responsive than Dreamweaver 8 ( ) running on Rosetta: startup time is faster; typing feels quicker; and sitewide operations, such as updating templates and broken links, are speedier. For example, updating a template in Dreamweaver CS3 on our 2.66GHz dual-core Xeon Mac Pro took just under a minute, as opposed to nearly four minutes in Dreamweaver 8. In another test, we relocated a site file in Dreamweaver, a process that necessitated changes to the site’s page links. It took Dreamweaver CS3 just 11 seconds to change all the links on our 350-page Web site, compared with 43 seconds for Dreamweaver 8.
The long and winding road
Full integration of Dreamweaver into the Adobe pantheon of creative programs will take time. Unlike Flash CS3, which has adopted the Adobe look-and-feel, Dreamweaver CS3 has the same user interface as Dreamweaver 8 (this may be welcome news for longtime users accustomed to the Macromedia style).
However, Dreamweaver CS3 does provide helpful integration with Photoshop ( ), offering a streamlined workflow for getting images from Photoshop into Dreamweaver. You can copy all or part of a layered or sliced Photoshop (PSD) document and paste it directly into a Dreamweaver page. You can even drag a Photoshop document from your desktop, Bridge, or the Dreamweaver Files panel onto an open Dreamweaver page. A new image-optimization window lets you apply compression settings and save a file into your site; the optimized image then appears on the Web page.
Dreamweaver CS3 also remembers the location of the original Photoshop PSD document—but only if you’re using Photoshop CS3. Clicking on Dreamweaver’s Edit button launches Photoshop and opens the PSD file; after making changes in Photoshop, you just copy the layer, the slice, or the portion of the image you want, and then paste the new, edited image back into Dreamweaver. The old image is replaced, and all of the optimization settings you applied previously are reapplied.
And this version of Dreamweaver includes Adobe’s new Device Central. This program (which is integrated with several other programs in the suite) shows how different mobile devices display Web content. You can preview a Dreamweaver CS3 page in more than 200 different mobile-device profiles; each profile simulates the display of a particular phone—in many cases, complete with a photo of the phone. Each profile also includes information about the phone’s screen size and the type of HTML, Flash, and video it supports. Device Central uses Opera Mini (a browser for handheld devices) to simulate the Web-page display. Since not all phones ship with Mini, what you see in Device Central may not exactly match what appears on a particular phone.
Building the new Web
One of the most significant additions in this version of Dreamweaver is a new set of tools for adding interactive elements to a Web page. Based on the Spry framework, these new tools go far beyond the eye candy of Dreamweaver’s old timeline animations, and they’re a significant improvement on the simplistic JavaScript produced by the previous Dreamweaver behaviors. Spry widgets—prebuilt blocks of code that you can insert into your pages—add helpful user-interface elements to a page; the Spry Menu Bar widget, for example, is a navigation bar that supports two levels of pop-up menus—the perfect way to cram a lot of links into a compact space. Form-validation widgets are coded to ensure that data is submitted correctly—for example, to make sure that a field isn’t empty or that it contains a properly formatted e-mail address or phone number. This widget offers more features and produces much more professional-looking forms than the Validate Form behavior that shipped with Dreamweaver for years. Several other page widgets make it easy to present a lot of content in a small space; for example, the Tabbed Panels widget lets you place content into separate tabbed areas, each of which is revealed by clicking on a tab.
For people who do like eye-candy, Spry effects let you draw attention to your Web pages with effects that fade out, shrink, grow, or shake an image or other page content. The Spry Data Set feature lets you take data from an XML file and display it in a table. People viewing the Web page can sort the table by clicking on column headers, and they can even see detailed information about one item—all without downloading a new page from the Web server.
Solving CSS woes
CSS is a Web designer’s main tool for creating beautiful and functional Web sites that adhere to proper Web-coding standards. Unfortunately, CSS is also a confusing technology, and thanks to the idiosyncrasies of Web browsers, creating Web pages that look and work the same on Windows machines and Macs, and on Microsoft Internet Explorer, Mozilla’s Firefox ( ) and Apple’s Safari ( ) is often difficult. This is especially troublesome to Mac-based Web designers because the most popular Web browser, Internet Explorer 6 for Windows, also has the most problems handling CSS. Dreamweaver CS3 adds two new elements—CSS layouts and the Check Browser Compatibility feature—that cut down on the laborious trial-and-error often associated with CSS-based Web design.
The CSS layouts contain the basic HTML and CSS necessary to create the most common page layouts—two-column, three-column, liquid-width, and fixed-width, for example. These templates offer more options than the few CSS templates offered in Dreamweaver 8, and also unlike the templates in the previous version, these are basic layouts without any graphics or excessive styling, so you can modify and add to them to create your own look-and-feel. In addition, the Dreamweaver CS3 layouts include all the necessary CSS workarounds required to make the designs work well in all current Web browsers.
The new Check Browser Compatibility feature lets you check a Web page for CSS or HTML code that might not work correctly in a particular browser. Potential errors are identified, and a single click takes you to Adobe.com’s CSS Advisor, which provides suggestions for how to fix the problem.
Dreamweaver CS3 improves on the program’s already powerful CSS tools. Dreamweaver’s display of CSS-based design within the program’s interface has also improved, getting closer to the “what you see in Dreamweaver is what you’ll get in a Web browser” ideal. New CSS management tools simplify the process of reordering styles in a style sheet, renaming styles, and moving styles between style sheets.
Universal at last
Dreamweaver CS3 is the first version of the Web-design program to appear with the Adobe name; it’s also the first version to run natively on Intel Macs. Running on an Intel Mac, Dreamweaver CS3 is more responsive than Dreamweaver 8 ( ) running on Rosetta: startup time is faster; typing feels quicker; and sitewide operations, such as updating templates and broken links, are speedier. For example, updating a template in Dreamweaver CS3 on our 2.66GHz dual-core Xeon Mac Pro took just under a minute, as opposed to nearly four minutes in Dreamweaver 8. In another test, we relocated a site file in Dreamweaver, a process that necessitated changes to the site’s page links. It took Dreamweaver CS3 just 11 seconds to change all the links on our 350-page Web site, compared with 43 seconds for Dreamweaver 8.
The long and winding road
Full integration of Dreamweaver into the Adobe pantheon of creative programs will take time. Unlike Flash CS3, which has adopted the Adobe look-and-feel, Dreamweaver CS3 has the same user interface as Dreamweaver 8 (this may be welcome news for longtime users accustomed to the Macromedia style).
However, Dreamweaver CS3 does provide helpful integration with Photoshop ( ), offering a streamlined workflow for getting images from Photoshop into Dreamweaver. You can copy all or part of a layered or sliced Photoshop (PSD) document and paste it directly into a Dreamweaver page. You can even drag a Photoshop document from your desktop, Bridge, or the Dreamweaver Files panel onto an open Dreamweaver page. A new image-optimization window lets you apply compression settings and save a file into your site; the optimized image then appears on the Web page.
Dreamweaver CS3 also remembers the location of the original Photoshop PSD document—but only if you’re using Photoshop CS3. Clicking on Dreamweaver’s Edit button launches Photoshop and opens the PSD file; after making changes in Photoshop, you just copy the layer, the slice, or the portion of the image you want, and then paste the new, edited image back into Dreamweaver. The old image is replaced, and all of the optimization settings you applied previously are reapplied.
And this version of Dreamweaver includes Adobe’s new Device Central. This program (which is integrated with several other programs in the suite) shows how different mobile devices display Web content. You can preview a Dreamweaver CS3 page in more than 200 different mobile-device profiles; each profile simulates the display of a particular phone—in many cases, complete with a photo of the phone. Each profile also includes information about the phone’s screen size and the type of HTML, Flash, and video it supports. Device Central uses Opera Mini (a browser for handheld devices) to simulate the Web-page display. Since not all phones ship with Mini, what you see in Device Central may not exactly match what appears on a particular phone.
Building the new Web
One of the most significant additions in this version of Dreamweaver is a new set of tools for adding interactive elements to a Web page. Based on the Spry framework, these new tools go far beyond the eye candy of Dreamweaver’s old timeline animations, and they’re a significant improvement on the simplistic JavaScript produced by the previous Dreamweaver behaviors. Spry widgets—prebuilt blocks of code that you can insert into your pages—add helpful user-interface elements to a page; the Spry Menu Bar widget, for example, is a navigation bar that supports two levels of pop-up menus—the perfect way to cram a lot of links into a compact space. Form-validation widgets are coded to ensure that data is submitted correctly—for example, to make sure that a field isn’t empty or that it contains a properly formatted e-mail address or phone number. This widget offers more features and produces much more professional-looking forms than the Validate Form behavior that shipped with Dreamweaver for years. Several other page widgets make it easy to present a lot of content in a small space; for example, the Tabbed Panels widget lets you place content into separate tabbed areas, each of which is revealed by clicking on a tab.
For people who do like eye-candy, Spry effects let you draw attention to your Web pages with effects that fade out, shrink, grow, or shake an image or other page content. The Spry Data Set feature lets you take data from an XML file and display it in a table. People viewing the Web page can sort the table by clicking on column headers, and they can even see detailed information about one item—all without downloading a new page from the Web server.
Solving CSS woes
CSS is a Web designer’s main tool for creating beautiful and functional Web sites that adhere to proper Web-coding standards. Unfortunately, CSS is also a confusing technology, and thanks to the idiosyncrasies of Web browsers, creating Web pages that look and work the same on Windows machines and Macs, and on Microsoft Internet Explorer, Mozilla’s Firefox ( ) and Apple’s Safari ( ) is often difficult. This is especially troublesome to Mac-based Web designers because the most popular Web browser, Internet Explorer 6 for Windows, also has the most problems handling CSS. Dreamweaver CS3 adds two new elements—CSS layouts and the Check Browser Compatibility feature—that cut down on the laborious trial-and-error often associated with CSS-based Web design.
The CSS layouts contain the basic HTML and CSS necessary to create the most common page layouts—two-column, three-column, liquid-width, and fixed-width, for example. These templates offer more options than the few CSS templates offered in Dreamweaver 8, and also unlike the templates in the previous version, these are basic layouts without any graphics or excessive styling, so you can modify and add to them to create your own look-and-feel. In addition, the Dreamweaver CS3 layouts include all the necessary CSS workarounds required to make the designs work well in all current Web browsers.
The new Check Browser Compatibility feature lets you check a Web page for CSS or HTML code that might not work correctly in a particular browser. Potential errors are identified, and a single click takes you to Adobe.com’s CSS Advisor, which provides suggestions for how to fix the problem.
Dreamweaver CS3 improves on the program’s already powerful CSS tools. Dreamweaver’s display of CSS-based design within the program’s interface has also improved, getting closer to the “what you see in Dreamweaver is what you’ll get in a Web browser” ideal. New CSS management tools simplify the process of reordering styles in a style sheet, renaming styles, and moving styles between style sheets.
Sunday, January 27, 2008
Book Review : Black And White In Photoshop CS3 And Lightroom by Leslie Alsheimer
Getting great images in black and white is not just removing the color from the image or transforming it into grayscale; rather it is a different state of mind. In color you have similar tonal values, but completely different effects. The same colors in black and white can look drab. To create compelling images in black and white you must learn how to look at things differently. You must find the contrasts, the shapes, the textures, and the lines within the images. It is the goal of Black and White in Photoshop CS3 and Lightroom to help you do this.
Black And White In Photoshop CS3 And Lightroom is 241 pages long and comprises six chapters.
Chapter 1, "Color Management in Black and White," describes the fact that color management is an extremely complex subject. The type of topic that makes all but the hardiest eyes glaze over. But to do black and white you must understand what it is and how it affects the outcome of your images. In this chapter you will learn about color management, color working spaces, ambient lighting conditions, setting up your monitor, calibration, software, print profiling and printer settings.
Chapter 2, "Highest Quality Capture: Workflow Phase I," describes how to capture for black and white. The first phase of your work flow is to obtain the highest quality image. You will examine types of capture formats, bit depth, high bit capture, as well as an overview on scanning. You will also learn about exposure evaluation tools such as the histogram, as well as how to read and interpret the histogram data. Here you will learn about the blinking highlight indicator, digital darkroom dangers, and how to handle noise and interference in digital capture.
Chapter 3, "Black and White in Lightroom: Workflow Phase II," shows you how to integrate workflow practices within Lightroom. Because there are many possible steps from capture to print, there is really no single "right" way to manage a workflow. Here you will start with a hybrid workflow that you can use to learn what works right for you. Topics include importing, downloading and backing up your images, Lightroom editing, global adjustments, exporting, and bridging to Photoshop.
Chapter 4, "Black and White in Photoshop," now concentrates on methods of processing from within Photoshop. Here the author concentrates on more advanced options that are available in Photoshop as well as on their founding theories and methodologies. In this chapter you are encouraged to experiment before moving on. The methods include Grayscale Mode Change, Lab Color Mode, Channel Mixer, Hue Saturation Technique, Black and White Standalone Feature, and Black and White in Camera Raw 4.0.
Chapter 5, "Image Editing in Photoshop," begins with an overview of the best practices in non-destructive editing in Photoshop such as Adjustment Layers. It also describes the new features in CS3. Because Photoshop is such an extensive program, it is impossible to cover all types of adjustments. Here you will learn how to monitor your adjustments by using the histogram. Then you work with levels and curves, setting black and white points, dodging, burning, neutral density filters, vignetting, working with film grain effects and digital infrared. You will also work with hand coloring black and white, toning techniques, split toning, and duotones.
Chapter 6, "Printing," describes techniques for getting the best out of your digital printing. Because of the new technological advances in the quality of digital, the darkroom has been replaced and in that photographers must now embrace change, not by replacing the old, but by integrating the new. In this chapter you will learn about ink and how it affects your printing, about paper and profiles that work with your printer. You will then be introduced to a printing workflow that includes setting size and resolution, soft-proofing, sharpening and setting your printer driver for best effects. There is even a section on printing from within Lightroom.
Black And White In Photoshop CS3 And Lightroom explains in clear and easy to understand steps what it takes to generate quality black and white images using Photoshop and/or Lightroom. It is really geared for the intermediate to advanced user who is looking to understand both workflow and color management techniques.
There are a number of thing that I like about Black And White In Photoshop CS3 And Lightroom. First, I like the fact that it takes you down a number of paths on creating black and white images. It doesn't just say this is the best way and so that is all you learn. Second, I like the step-by-step approach to guide you through what you need to do to get results like this.
The only problem I had was that there were no image downloads that I could find to use in following the instruction. I understand the copyright issues that can be involved with some of the images in the book, but it seems that some non-proprietary images could be created and used for some of the more advanced concepts. Other than that, I think that if you want to become a master of Black and White photography then Black And White In Photoshop CS3 And Lightroom is highly recommended reading.
Black And White In Photoshop CS3 And Lightroom is 241 pages long and comprises six chapters.
Chapter 1, "Color Management in Black and White," describes the fact that color management is an extremely complex subject. The type of topic that makes all but the hardiest eyes glaze over. But to do black and white you must understand what it is and how it affects the outcome of your images. In this chapter you will learn about color management, color working spaces, ambient lighting conditions, setting up your monitor, calibration, software, print profiling and printer settings.
Chapter 2, "Highest Quality Capture: Workflow Phase I," describes how to capture for black and white. The first phase of your work flow is to obtain the highest quality image. You will examine types of capture formats, bit depth, high bit capture, as well as an overview on scanning. You will also learn about exposure evaluation tools such as the histogram, as well as how to read and interpret the histogram data. Here you will learn about the blinking highlight indicator, digital darkroom dangers, and how to handle noise and interference in digital capture.
Chapter 3, "Black and White in Lightroom: Workflow Phase II," shows you how to integrate workflow practices within Lightroom. Because there are many possible steps from capture to print, there is really no single "right" way to manage a workflow. Here you will start with a hybrid workflow that you can use to learn what works right for you. Topics include importing, downloading and backing up your images, Lightroom editing, global adjustments, exporting, and bridging to Photoshop.
Chapter 4, "Black and White in Photoshop," now concentrates on methods of processing from within Photoshop. Here the author concentrates on more advanced options that are available in Photoshop as well as on their founding theories and methodologies. In this chapter you are encouraged to experiment before moving on. The methods include Grayscale Mode Change, Lab Color Mode, Channel Mixer, Hue Saturation Technique, Black and White Standalone Feature, and Black and White in Camera Raw 4.0.
Chapter 5, "Image Editing in Photoshop," begins with an overview of the best practices in non-destructive editing in Photoshop such as Adjustment Layers. It also describes the new features in CS3. Because Photoshop is such an extensive program, it is impossible to cover all types of adjustments. Here you will learn how to monitor your adjustments by using the histogram. Then you work with levels and curves, setting black and white points, dodging, burning, neutral density filters, vignetting, working with film grain effects and digital infrared. You will also work with hand coloring black and white, toning techniques, split toning, and duotones.
Chapter 6, "Printing," describes techniques for getting the best out of your digital printing. Because of the new technological advances in the quality of digital, the darkroom has been replaced and in that photographers must now embrace change, not by replacing the old, but by integrating the new. In this chapter you will learn about ink and how it affects your printing, about paper and profiles that work with your printer. You will then be introduced to a printing workflow that includes setting size and resolution, soft-proofing, sharpening and setting your printer driver for best effects. There is even a section on printing from within Lightroom.
Black And White In Photoshop CS3 And Lightroom explains in clear and easy to understand steps what it takes to generate quality black and white images using Photoshop and/or Lightroom. It is really geared for the intermediate to advanced user who is looking to understand both workflow and color management techniques.
There are a number of thing that I like about Black And White In Photoshop CS3 And Lightroom. First, I like the fact that it takes you down a number of paths on creating black and white images. It doesn't just say this is the best way and so that is all you learn. Second, I like the step-by-step approach to guide you through what you need to do to get results like this.
The only problem I had was that there were no image downloads that I could find to use in following the instruction. I understand the copyright issues that can be involved with some of the images in the book, but it seems that some non-proprietary images could be created and used for some of the more advanced concepts. Other than that, I think that if you want to become a master of Black and White photography then Black And White In Photoshop CS3 And Lightroom is highly recommended reading.
Thursday, January 24, 2008
Bulletproof HTML: 37 Steps to Perfect Markup ( Part 2 )
18. What are block-level and inline elements?
HTML employs two main categories of element types: block-level elements and inline elements. The differences between them are mainly semantic and grammatical.
Block-level elements are usually "containers" for other elements. Examples of block-level elements are div, p, form and table. Some block-level elements (e.g., p) can only contain text and inline elements. Others (e.g., form) can contain only block-level elements (in the Strict DTD). And some, like div, can contain text, inline elements and block-level elements. By default, block-level elements are rendered with an implicit line break before and after; in other words, we cannot have two block-level elements side by side using only Strict HTML. (To do so would require CSS.)
Inline elements are elements that can exist "inline" within text. Examples include a, em, q and span. An inline element can contain only text and other inline elements. An inline element cannot contain a block-level element, with one exception: object (which is known as a replaced inline element, the same as img). Inline elements, when rendered, do not have any implied line breaks before or after.
In some cases, additional restrictions are placed on child element types. For instance, anchor links (a) can contain text and inline elements, but not other a elements; you cannot nest links.
The rules are somewhat different between the Strict and Transitional DTDs. In the Strict DTD, some block-level elements, including body, blockquote and form, can only have block-level children. In the Transitional DTD, they can also contain text and inline elements as immediate children.
19. Can I make an inline element block-level with CSS?
No. This is a common misconception. Beginners sometimes think that by applying the display: block declaration to an a element, they will be able to put a block-level h1 inside the link. That is not the case.
HTML has block-level and inline elements. CSS has block and inline boxes (plus a few others). These are very different things. The distinction in HTML has to do with semantics and syntax, while the distinction in CSS has to do with rendering and presentation. By default, block-level elements generate block boxes, and inline elements generate inline boxes (this is a grossly simplified explanation, but is generally true). The display property can change the type of the generated box, but CSS cannot change the grammatical or syntactical rules of HTML.
20. Why are external CSS and JavaScript files a good idea?
From a maintenance perspective, a full separation of content, presentation and behaviour is something to strive for. Then, if we want to change the colours of our site, we can simply edit a single style sheet instead of updating possibly thousands of HTML documents. If we use style attributes and write inline CSS, we will have to edit all of those HTML documents when redesigning our site, instead of simply editing a single style sheet file.
There is also another issue: both CSS and JavaScript often contain characters that have special meanings in HTML. If the CSS code or JavaScript code is embedded into the HTML document, these characters need to be escaped. If we have embedded JavaScript, and use the archaic practice of "hiding" the script code within SGML comments (), we cannot use the decrement operator (--), because the double hyphen will terminate the comment.
21. Should I use p or br?
The p element marks up a paragraph of text. A paragraph is one or more sentences that deal with a single thought.
A line break (br) is mostly a presentational tool, and should be handled by CSS rather than HTML. However, there are a few cases where line breaks can be said to have semantic meaning, for instance in poetry, song lyrics, postal addresses and computer code samples. These can constitute legitimate uses for br, but using br to separate paragraphs is definitely an abuse of the br element.
On the other hand, p has a very clear semantic meaning: it denotes a paragraph. Sometimes web authors tend to treat p as a generic block-level container element, but that's not correct. It's not uncommon to see a label and an input field wrapped inside a p within a form, but I would argue that it's semantically wrong. A label and an input field do not constitute a "paragraph".
22. What does "semantic" mean?
se-man-tic [si-'man-tik]
adj. Of, pertaining to, or arising from the different meanings of words or other symbols.
(definition from dictionary.com)
When we talk about "semantic markup", we mean the proper use of element types -- based on their meaning -- to mark up content. The opposite is "presentational markup" or "tag soup", where authors choose element types because of their default rendering, rather than their semantic meanings.
An example: This is a semantically correct way to mark up the top-level heading of a web page:
This is an unsemantic (presentational) way to do it:
Heading Text
The semantic richness of HTML is quite limited. HTML was originally used by physicists to exchange scientific documents, and that shows quite clearly in the set of available element types. HTML would probably have had a very different set of element types if it had been invented by accountants or librarians.
HTML has two semantically neutral element types as well: the block-level div and the inline-level span. Neither of those two implies any particular semantics about its content; div is just a "division of the document", while span is a "span of characters". On the other side of the spectrum we have element types with clearly defined semantics: p (paragraph of text), table (tabular data), ul (unordered list), and so on.
The purpose of HTML is to mark up the semantics of a document, and -- to some extent -- to show the structure of its content. HTML has nothing at all to do with the way this document looks in a browser (although browsers have a default style for each element type).
23. Should I replace b and i with strong and em?
Only if you really mean to emphasise something. These notations are not interchangeable.
In the Bad Old Days, authors would use b and i to emphasise words.
In the Equally Bad Modern Days, authors use strong and em to make text boldfaced or italic.
em signifies semantic emphasis. The content to which it is applied should have some sort of emphasis when read out loud (louder, more slowly). strong indicates even stronger emphasis, but is now often considered redundant (you could nest em elements to indicate increasing emphasis). Some experts recommend that strong be used only for certain page elements that should be clearly indicated (like a "current page" indicator), and not to mark up words or phrases in the body copy.
b and i have no semantics; they only indicate bold or italics. They are useful for adhering to typographic conventions that do not have a semantically correct element type in HTML. For instance, ship names are traditionally written in italics, but there is no ship element type in HTML. Thus we can use Titanic.
24. Why are layout tables considered harmful?
* It is semantically wrong to mark up non-tabular information as a table.
* They can cause accessibility or usability problems (especially with some assistive technologies), particularly when nested several levels deep.
* They mix presentational issues with the content, making it difficult or impossible to achieve alternate styling and output device independence.
* They bloat the document markup with lots of unnecessary HTML tags, which can be detrimental for low-bandwidth users (those using dial-up connections or mobile devices) as well as for the web server's load and bandwidth.
25. Should I use divs instead of layout tables?
No, we should use semantically correct element types as far as possible, and only revert to divs when there are no other options.
Abusing divs is no better than abusing tables. We can set id and class attributes on virtually any element type. We can assign CSS rules to virtually any element type, not only to divs.
26. Are tables deprecated?
Not at all. table is the proper, semantically correct element type to use for marking up tabular data: information that has relationships in two or more dimensions. Tables are not deprecated, but layout tables are an issue.
27. What is the correct use of the address element type?
address is used to mark up contact information for the page (or for a part of a page). This can be a postal address, an email address, a telephone number, or virtually any contact details. address is a block-level element that can only contain text and inline elements. The default rendering is italic in most browsers, but that can be changed easily with CSS.
A common misconception is that address is meant to be used to mark up only postal addresses, but that is not the case.
28. What is the correct use of the dfn element type?
dfn is used to mark up the "defining instance" of a term. It's a typographic convention, especially common in scientific documents, to italicise a new term -- one with which the reader cannot be expected to be familiar -- the first time appears in the text. The default rendering of dfn is thus italic.
A common misconception is that dfn means "definition", and many authors use it in the same way they use abbr or acronym (by using the title attribute to provide an explanation of the term). A certain term should only be marked up with dfn once in a document (where it is first used and explained).
29. What is the correct use of the var element type?
var is used to mark up a variable, or replaceable, part of some text. It's a typographic convention to italicise such variables, which will be replaced by actual data in real life. For instance, in a telephone system manual, the instruction for relaying incoming calls to another extension could look something like this:
* 21 * extension #
Here, a var element is used to mark up "extension" (which will be italic by default). Someone trying to program the telephone system to relay his incoming calls to extension 942 would type "*21*942#". Thus the var element indicates that you shouldn't actually type "e-x-t-e-n-s-i-o-n", but enter the actual extension number instead. The word "extension" is a variable.
A common misconception is that var should be used for marking up variables in programming code samples.
30. Should I use quotation marks within or around a q element?
No, the specification clearly says that it is the responsibility of the user agent to add quotation marks to inline quotations. Unfortunately, some older browsers (such as Internet Explorer 6) do not comply with the specification and will not add quotation marks. An option is to insert the quotation marks with JavaScript, and use some special styling with CSS to insert quotations for IE users with JavaScript disabled. Some CSS-only solutions have been proposed, but they will fail in non-CSS browsers such as Lynx.
31. What is the difference between abbr and acronym?
No one really seems to know the answer to this one! Even the HTML specification contradicts itself on this point.
abbr was a Netscape extension to HTML during the "browser wars". acronym was Microsoft's extension. Both meant the same thing, more or less. Both element types were incorporated into the HTML specification, with different semantics. The problem is that no one seems to be able to explain what those semantics are.
Let us look at a couple of dictionary definitions, then:
ab-bre-vi-a-tion [uh-bree-vee-'ey-shuhn]
n. A shortened or contracted form of a word or phrase, used to represent the whole.
ac-ro-nym ['ak-ruh-nim]
n. A word formed from the initial letters or groups of letters of words in a set phrase or series of words.
The definition for acronym says that it is a word, i.e., it can be pronounced. Thus, "NATO" would be an acronym, formed from the initial letters in the phrase "North Atlantic Treaty Organization". "FBI", however, would not be an acronym according to the dictionary definition, because it is not pronounced as a word, but rather spelled out (eff bee eye). And this is where the problems begin. "FBI" is technically known as an initialism, about which the dictionary has the following to say:
in-i-tial-ism [i-'nish-uh-liz-uhm]
n. 1. A name or term formed from the initial letters of a group of words and pronounced as a separate word.
2. A set of initials representing a name, organization, or the like, with each letter pronounced separately.
The first definition is almost the same as for acronym, but the second is more relaxed. However, there is no initialism element type in HTML, and the confusion is exacerbated by the fact that "acronym" in normal American parlance is used as a synonym for "initialism".
The HTML specification offers the following definitions:
abbr: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).
acronym: Indicates an acronym (e.g., WAC, radar, etc.).
So far it looks like the specification is adhering to the dictionary definitions, which means that "FBI" should be marked up with abbr since it can't be pronounced as a word. However, a few paragraphs further down, the specification says,
Western languages make extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.", as well as abbreviations like "M.", "Inc.", "et al.", "etc."
Are you confused yet? I am. The safe thing to do then should be to always use abbr, since all acronyms are abbreviations, but not vice versa. However, there's a slight problem with that approach. Microsoft was so miffed when the W3C decided to use abbr for abbreviations and initialisms instead of their acronym, that they actually refused to support abbr! (They've started supporting abbr in Internet Explorer 7, though.)
So, what's a poor web author to do? Why should we even bother? It might be nice to have an element to attach a title attribute to, but we could use SPAN for that. The idea, allegedly, is that marking up abbreviations and acronyms would be beneficial for assistive technologies; especially screen readers. But screen readers tend to ignore abbr and acronym, since no one knows how to use them properly and Microsoft doesn't support abbr. It's a catch-22.
The answer to this frequently asked question is: I don't know! I, personally, use abbr for obvious abbreviations like "Inc." and for initialisms like "FBI", and I use acronym for things that can be pronounced as words, like "GIF". But due to the ambiguity of the specification, I cannot fault anyone for marking up "FBI" as an acronym (although "Inc." certainly is not an acronym). And what about "SQL", which some spell out and others pronounce as "sequel"? (I'd use abbr.)
32. Why is deprecated?
The most common "feature" that beginners ask about is the target attribute for links. This feature is deprecated (disapproved of) in HTML 4.01 Strict, but it's still valid in HTML 4.01 Transitional. Many other element types and attributes that are allowed in Transitional are removed from Strict.
The reason for deprecating those items is that the W3C wants to promote the separation between content (HTML), presentation (CSS) and behaviour (JavaScript). Making an element centred within the viewport is a presentational issue; thus it should be handled by CSS instead of a center element. Opening a new browser window is a behavioural issue; thus it should be handled by JavaScript rather than a target attribute.
Typically, the deprecated features are those that arose during the browser war era of the late 1990s, when browser vendors were competing by adding various extensions to HTML to make it into some sort of page layout language. These features were included in HTML 3.2 to bring some sort of order to the chaos, but this is not what HTML was intended for. When HTML 4 was released, the authors tried to "reclaim the Web" by deprecating what they saw as "harmful" parts of HTML 3.2, at least in the Strict DTD.
In other words, things are deprecated for a reason. Don't use those features unless you absolutely have to.
33. Must I have an alt attribute for every image?
Yes, the alt attribute is required for the img element type. Why? Well, not all users can see images and not all user agents can understand or display images. For example:
* A person who is blind or has very low vision cannot see an image. A screen reader cannot describe an image.
* Users with slow connections (dial-up or mobile) sometimes disable images for faster surfing.
* Text browsers like Lynx do not support images.
* Search engine bots cannot understand images.
Thus we have to provide a text equivalent for each image, using the alt attribute. This text equivalent should not describe the image; it should convey the equivalent information. Writing good text equivalents is not easy, and it takes a lot of practice. Remember that the text equivalent is displayed instead of the image.
So what is a good text equivalent for a given image? That depends on the context in which the image is used! It's not like there is a single "perfect" text equivalent for each image. Let us look at an example: say we have an image of a grazing cow. This particular cow happens to be an Aberdeen Angus. Let us then consider a few use cases for this image.
* In the first case, this image is used as a generic illustration for an article about beef cattle farming in Scotland. The actual cow isn't germane to the article; it's just an illustration, a decorative design element that draws the reader's eye and relieves the monotony of the text. In this case, the image doesn't convey any relevant information. Therefore it should have an empty text equivalent: alt="".
* In the second case, the image is used on a children's web site about farm animals. The page shows pictures of various animals: a horse, a sheep, a pig, a cow, etc. Next to each image is a block of text that presents some facts about each species. In this case, alt="Cow:" could be appropriate. It's not important that it's an Aberdeen Angus; the picture represents bovine quadrupeds in general.
* In the third case, the image is used on a site about different breeds of cattle. Here it is used to illustrate what an Aberdeen Angus looks like, and how it is different from other breeds. The page comprises a number of images, each with a caption that identifies the breed, but no other textual information. In this case, the text equivalent should describe the particular attributes and traits that are specific to an Aberdeen Angus: the robust build, the massive chest, the relatively short legs, the buffalo-like hump behind the head, etc.
* In the fourth case, the image is used on a photographer's portfolio page. It's one image among several others, with very different motifs. This is one of the few cases where the alt attribute might actually include a description of the image itself, e.g., "A black Aberdeen Angus grazing in the sunshine with Ben Nevis in the background."
As we can see, the appropriate text equivalent depends on the context. Sometimes (often, actually) it should be empty, because the image doesn't convey any information that isn't available in the accompanying text. Some claim that such images should be background images specified via CSS, but there are many cases where that is impractical and where the image is really part of the content -- even though it doesn't convey any useful information to those who cannot see it.
For images that contain text, the text equivalent should of course replicate the text in the image. For things like pie charts, the text equivalent should convey information about the percentages -- the same information as the image conveys.
The alternate text shouldn't be too long. Some browsers don't word-wrap text equivalents, and they cannot be formatted in any way. If we need a longer text equivalent, we should put it somewhere else and link to it via the longdesc attribute.
Internet Explorer and old Netscape browsers display the alt attribute in a tool-tip when the user hovers the mouse pointer over the image. This constitutes an incorrect use of text equivalent data. We should use the title attribute for "tool-tip" information. To suppress the alternate text appearing in tool tips, we can use an empty title: title="".
34. What is the difference between class and id?
An id uniquely identifies a particular element in an HTML document. It's like a social security number, providing a unique handle for that element. Just as two people cannot have the same social security number, no two elements in a document can have the same id. ids must be unique within the page.
A class says that an element has some traits which it (possibly) shares with other elements. An element can belong to more than one class. An analogy could be professions: a person could be both a carpenter and a nurse, and there are many carpenters and many nurses. (They all have unique social security numbers, though.)
Both ids and classes are mainly used with CSS and/or JavaScript. In CSS, an id has higher specificity than a class, making it easy to specify special rules for a specific element. With JavaScript we can look up an element using its id (document.getElementById()).
We assign ids to page elements that can occur, at most, once per page, like a navigation menu, a footer, a sidebar, etc. We can also assign ids to specific elements that only occur once in the whole site, like a specific image, if we want to have certain CSS rules for it, or manipulate it with JavaScript.
We assign classes to elements that share some common traits, usually display properties via CSS rules.
ids and class names should be as "semantic" as possible. They should describe what something is, not what it looks like. Thus, id="menu" is much better than id="left"; especially if we redesign and move the menu to the right-hand side.
ids and class names are case sensitive, even in HTML. We shouldn't rely on case-sensitivity, though (i.e., we should not use names that differ only in case).
35. Why doesn't id="123" work?
Values for the id, name and class attributes must start with a letter (A-Z or a-z).
36. Why doesn't work?
There are two reasons in this case.
Attribute values that contain characters other than letters, digits and a few other characters must be enclosed in quotation marks (double or single). Any attribute value that needs to contain a space, for instance, must be quoted. The easiest and safest solution is to always quote attribute values. To include quotation marks in a quoted value, we have two options. We can either use the "other" quotation mark to enclose the value (alt='My "new" car', alt="Jane's car"), or use an entity or reference (alt="My "new" car", alt='Jane's car'). (Note that the ' entity cannot be used with HTML.)
The second reason is that there are spaces in the URI. These need to be encoded as shown here:
"%20" means "a character with code point 0x20". 0x20 is the code point for the space character. This applies to URIs only, not to attribute values in general.
37. How can I include an HTML page in another HTML page?
With a Strict DTD, there is only one valid option: the OBJECT element type:
Unfortunately, support for object is all but non-existent in Internet Explorer.
With a Transitional DTD, we can also use the iframe element type:
A much better approach is to handle inclusion on the server-side. Using server-side includes (SSI) is the simplest way to include a file into another, as long as they are from the same domain:
Note that this technique cannot be used to include a complete HTML document within another, though; it can be used only with fragments of HTML.
Other server-side technologies allow us to perform more advanced tasks. Your web server must support those technologies, of course. Often, shared servers with free hosting don't provide any such technologies -- not e
HTML employs two main categories of element types: block-level elements and inline elements. The differences between them are mainly semantic and grammatical.
Block-level elements are usually "containers" for other elements. Examples of block-level elements are div, p, form and table. Some block-level elements (e.g., p) can only contain text and inline elements. Others (e.g., form) can contain only block-level elements (in the Strict DTD). And some, like div, can contain text, inline elements and block-level elements. By default, block-level elements are rendered with an implicit line break before and after; in other words, we cannot have two block-level elements side by side using only Strict HTML. (To do so would require CSS.)
Inline elements are elements that can exist "inline" within text. Examples include a, em, q and span. An inline element can contain only text and other inline elements. An inline element cannot contain a block-level element, with one exception: object (which is known as a replaced inline element, the same as img). Inline elements, when rendered, do not have any implied line breaks before or after.
In some cases, additional restrictions are placed on child element types. For instance, anchor links (a) can contain text and inline elements, but not other a elements; you cannot nest links.
The rules are somewhat different between the Strict and Transitional DTDs. In the Strict DTD, some block-level elements, including body, blockquote and form, can only have block-level children. In the Transitional DTD, they can also contain text and inline elements as immediate children.
19. Can I make an inline element block-level with CSS?
No. This is a common misconception. Beginners sometimes think that by applying the display: block declaration to an a element, they will be able to put a block-level h1 inside the link. That is not the case.
HTML has block-level and inline elements. CSS has block and inline boxes (plus a few others). These are very different things. The distinction in HTML has to do with semantics and syntax, while the distinction in CSS has to do with rendering and presentation. By default, block-level elements generate block boxes, and inline elements generate inline boxes (this is a grossly simplified explanation, but is generally true). The display property can change the type of the generated box, but CSS cannot change the grammatical or syntactical rules of HTML.
20. Why are external CSS and JavaScript files a good idea?
From a maintenance perspective, a full separation of content, presentation and behaviour is something to strive for. Then, if we want to change the colours of our site, we can simply edit a single style sheet instead of updating possibly thousands of HTML documents. If we use style attributes and write inline CSS, we will have to edit all of those HTML documents when redesigning our site, instead of simply editing a single style sheet file.
There is also another issue: both CSS and JavaScript often contain characters that have special meanings in HTML. If the CSS code or JavaScript code is embedded into the HTML document, these characters need to be escaped. If we have embedded JavaScript, and use the archaic practice of "hiding" the script code within SGML comments (), we cannot use the decrement operator (--), because the double hyphen will terminate the comment.
21. Should I use p or br?
The p element marks up a paragraph of text. A paragraph is one or more sentences that deal with a single thought.
A line break (br) is mostly a presentational tool, and should be handled by CSS rather than HTML. However, there are a few cases where line breaks can be said to have semantic meaning, for instance in poetry, song lyrics, postal addresses and computer code samples. These can constitute legitimate uses for br, but using br to separate paragraphs is definitely an abuse of the br element.
On the other hand, p has a very clear semantic meaning: it denotes a paragraph. Sometimes web authors tend to treat p as a generic block-level container element, but that's not correct. It's not uncommon to see a label and an input field wrapped inside a p within a form, but I would argue that it's semantically wrong. A label and an input field do not constitute a "paragraph".
22. What does "semantic" mean?
se-man-tic [si-'man-tik]
adj. Of, pertaining to, or arising from the different meanings of words or other symbols.
(definition from dictionary.com)
When we talk about "semantic markup", we mean the proper use of element types -- based on their meaning -- to mark up content. The opposite is "presentational markup" or "tag soup", where authors choose element types because of their default rendering, rather than their semantic meanings.
An example: This is a semantically correct way to mark up the top-level heading of a web page:
Heading Text
This is an unsemantic (presentational) way to do it:
Heading Text
The semantic richness of HTML is quite limited. HTML was originally used by physicists to exchange scientific documents, and that shows quite clearly in the set of available element types. HTML would probably have had a very different set of element types if it had been invented by accountants or librarians.
HTML has two semantically neutral element types as well: the block-level div and the inline-level span. Neither of those two implies any particular semantics about its content; div is just a "division of the document", while span is a "span of characters". On the other side of the spectrum we have element types with clearly defined semantics: p (paragraph of text), table (tabular data), ul (unordered list), and so on.
The purpose of HTML is to mark up the semantics of a document, and -- to some extent -- to show the structure of its content. HTML has nothing at all to do with the way this document looks in a browser (although browsers have a default style for each element type).
23. Should I replace b and i with strong and em?
Only if you really mean to emphasise something. These notations are not interchangeable.
In the Bad Old Days, authors would use b and i to emphasise words.
In the Equally Bad Modern Days, authors use strong and em to make text boldfaced or italic.
em signifies semantic emphasis. The content to which it is applied should have some sort of emphasis when read out loud (louder, more slowly). strong indicates even stronger emphasis, but is now often considered redundant (you could nest em elements to indicate increasing emphasis). Some experts recommend that strong be used only for certain page elements that should be clearly indicated (like a "current page" indicator), and not to mark up words or phrases in the body copy.
b and i have no semantics; they only indicate bold or italics. They are useful for adhering to typographic conventions that do not have a semantically correct element type in HTML. For instance, ship names are traditionally written in italics, but there is no ship element type in HTML. Thus we can use Titanic.
24. Why are layout tables considered harmful?
* It is semantically wrong to mark up non-tabular information as a table.
* They can cause accessibility or usability problems (especially with some assistive technologies), particularly when nested several levels deep.
* They mix presentational issues with the content, making it difficult or impossible to achieve alternate styling and output device independence.
* They bloat the document markup with lots of unnecessary HTML tags, which can be detrimental for low-bandwidth users (those using dial-up connections or mobile devices) as well as for the web server's load and bandwidth.
25. Should I use divs instead of layout tables?
No, we should use semantically correct element types as far as possible, and only revert to divs when there are no other options.
Abusing divs is no better than abusing tables. We can set id and class attributes on virtually any element type. We can assign CSS rules to virtually any element type, not only to divs.
26. Are tables deprecated?
Not at all. table is the proper, semantically correct element type to use for marking up tabular data: information that has relationships in two or more dimensions. Tables are not deprecated, but layout tables are an issue.
27. What is the correct use of the address element type?
address is used to mark up contact information for the page (or for a part of a page). This can be a postal address, an email address, a telephone number, or virtually any contact details. address is a block-level element that can only contain text and inline elements. The default rendering is italic in most browsers, but that can be changed easily with CSS.
A common misconception is that address is meant to be used to mark up only postal addresses, but that is not the case.
28. What is the correct use of the dfn element type?
dfn is used to mark up the "defining instance" of a term. It's a typographic convention, especially common in scientific documents, to italicise a new term -- one with which the reader cannot be expected to be familiar -- the first time appears in the text. The default rendering of dfn is thus italic.
A common misconception is that dfn means "definition", and many authors use it in the same way they use abbr or acronym (by using the title attribute to provide an explanation of the term). A certain term should only be marked up with dfn once in a document (where it is first used and explained).
29. What is the correct use of the var element type?
var is used to mark up a variable, or replaceable, part of some text. It's a typographic convention to italicise such variables, which will be replaced by actual data in real life. For instance, in a telephone system manual, the instruction for relaying incoming calls to another extension could look something like this:
* 21 * extension #
Here, a var element is used to mark up "extension" (which will be italic by default). Someone trying to program the telephone system to relay his incoming calls to extension 942 would type "*21*942#". Thus the var element indicates that you shouldn't actually type "e-x-t-e-n-s-i-o-n", but enter the actual extension number instead. The word "extension" is a variable.
A common misconception is that var should be used for marking up variables in programming code samples.
30. Should I use quotation marks within or around a q element?
No, the specification clearly says that it is the responsibility of the user agent to add quotation marks to inline quotations. Unfortunately, some older browsers (such as Internet Explorer 6) do not comply with the specification and will not add quotation marks. An option is to insert the quotation marks with JavaScript, and use some special styling with CSS to insert quotations for IE users with JavaScript disabled. Some CSS-only solutions have been proposed, but they will fail in non-CSS browsers such as Lynx.
31. What is the difference between abbr and acronym?
No one really seems to know the answer to this one! Even the HTML specification contradicts itself on this point.
abbr was a Netscape extension to HTML during the "browser wars". acronym was Microsoft's extension. Both meant the same thing, more or less. Both element types were incorporated into the HTML specification, with different semantics. The problem is that no one seems to be able to explain what those semantics are.
Let us look at a couple of dictionary definitions, then:
ab-bre-vi-a-tion [uh-bree-vee-'ey-shuhn]
n. A shortened or contracted form of a word or phrase, used to represent the whole.
ac-ro-nym ['ak-ruh-nim]
n. A word formed from the initial letters or groups of letters of words in a set phrase or series of words.
The definition for acronym says that it is a word, i.e., it can be pronounced. Thus, "NATO" would be an acronym, formed from the initial letters in the phrase "North Atlantic Treaty Organization". "FBI", however, would not be an acronym according to the dictionary definition, because it is not pronounced as a word, but rather spelled out (eff bee eye). And this is where the problems begin. "FBI" is technically known as an initialism, about which the dictionary has the following to say:
in-i-tial-ism [i-'nish-uh-liz-uhm]
n. 1. A name or term formed from the initial letters of a group of words and pronounced as a separate word.
2. A set of initials representing a name, organization, or the like, with each letter pronounced separately.
The first definition is almost the same as for acronym, but the second is more relaxed. However, there is no initialism element type in HTML, and the confusion is exacerbated by the fact that "acronym" in normal American parlance is used as a synonym for "initialism".
The HTML specification offers the following definitions:
abbr: Indicates an abbreviated form (e.g., WWW, HTTP, URI, Mass., etc.).
acronym: Indicates an acronym (e.g., WAC, radar, etc.).
So far it looks like the specification is adhering to the dictionary definitions, which means that "FBI" should be marked up with abbr since it can't be pronounced as a word. However, a few paragraphs further down, the specification says,
Western languages make extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.", as well as abbreviations like "M.", "Inc.", "et al.", "etc."
Are you confused yet? I am. The safe thing to do then should be to always use abbr, since all acronyms are abbreviations, but not vice versa. However, there's a slight problem with that approach. Microsoft was so miffed when the W3C decided to use abbr for abbreviations and initialisms instead of their acronym, that they actually refused to support abbr! (They've started supporting abbr in Internet Explorer 7, though.)
So, what's a poor web author to do? Why should we even bother? It might be nice to have an element to attach a title attribute to, but we could use SPAN for that. The idea, allegedly, is that marking up abbreviations and acronyms would be beneficial for assistive technologies; especially screen readers. But screen readers tend to ignore abbr and acronym, since no one knows how to use them properly and Microsoft doesn't support abbr. It's a catch-22.
The answer to this frequently asked question is: I don't know! I, personally, use abbr for obvious abbreviations like "Inc." and for initialisms like "FBI", and I use acronym for things that can be pronounced as words, like "GIF". But due to the ambiguity of the specification, I cannot fault anyone for marking up "FBI" as an acronym (although "Inc." certainly is not an acronym). And what about "SQL", which some spell out and others pronounce as "sequel"? (I'd use abbr.)
32. Why is
The most common "feature" that beginners ask about is the target attribute for links. This feature is deprecated (disapproved of) in HTML 4.01 Strict, but it's still valid in HTML 4.01 Transitional. Many other element types and attributes that are allowed in Transitional are removed from Strict.
The reason for deprecating those items is that the W3C wants to promote the separation between content (HTML), presentation (CSS) and behaviour (JavaScript). Making an element centred within the viewport is a presentational issue; thus it should be handled by CSS instead of a center element. Opening a new browser window is a behavioural issue; thus it should be handled by JavaScript rather than a target attribute.
Typically, the deprecated features are those that arose during the browser war era of the late 1990s, when browser vendors were competing by adding various extensions to HTML to make it into some sort of page layout language. These features were included in HTML 3.2 to bring some sort of order to the chaos, but this is not what HTML was intended for. When HTML 4 was released, the authors tried to "reclaim the Web" by deprecating what they saw as "harmful" parts of HTML 3.2, at least in the Strict DTD.
In other words, things are deprecated for a reason. Don't use those features unless you absolutely have to.
33. Must I have an alt attribute for every image?
Yes, the alt attribute is required for the img element type. Why? Well, not all users can see images and not all user agents can understand or display images. For example:
* A person who is blind or has very low vision cannot see an image. A screen reader cannot describe an image.
* Users with slow connections (dial-up or mobile) sometimes disable images for faster surfing.
* Text browsers like Lynx do not support images.
* Search engine bots cannot understand images.
Thus we have to provide a text equivalent for each image, using the alt attribute. This text equivalent should not describe the image; it should convey the equivalent information. Writing good text equivalents is not easy, and it takes a lot of practice. Remember that the text equivalent is displayed instead of the image.
So what is a good text equivalent for a given image? That depends on the context in which the image is used! It's not like there is a single "perfect" text equivalent for each image. Let us look at an example: say we have an image of a grazing cow. This particular cow happens to be an Aberdeen Angus. Let us then consider a few use cases for this image.
* In the first case, this image is used as a generic illustration for an article about beef cattle farming in Scotland. The actual cow isn't germane to the article; it's just an illustration, a decorative design element that draws the reader's eye and relieves the monotony of the text. In this case, the image doesn't convey any relevant information. Therefore it should have an empty text equivalent: alt="".
* In the second case, the image is used on a children's web site about farm animals. The page shows pictures of various animals: a horse, a sheep, a pig, a cow, etc. Next to each image is a block of text that presents some facts about each species. In this case, alt="Cow:" could be appropriate. It's not important that it's an Aberdeen Angus; the picture represents bovine quadrupeds in general.
* In the third case, the image is used on a site about different breeds of cattle. Here it is used to illustrate what an Aberdeen Angus looks like, and how it is different from other breeds. The page comprises a number of images, each with a caption that identifies the breed, but no other textual information. In this case, the text equivalent should describe the particular attributes and traits that are specific to an Aberdeen Angus: the robust build, the massive chest, the relatively short legs, the buffalo-like hump behind the head, etc.
* In the fourth case, the image is used on a photographer's portfolio page. It's one image among several others, with very different motifs. This is one of the few cases where the alt attribute might actually include a description of the image itself, e.g., "A black Aberdeen Angus grazing in the sunshine with Ben Nevis in the background."
As we can see, the appropriate text equivalent depends on the context. Sometimes (often, actually) it should be empty, because the image doesn't convey any information that isn't available in the accompanying text. Some claim that such images should be background images specified via CSS, but there are many cases where that is impractical and where the image is really part of the content -- even though it doesn't convey any useful information to those who cannot see it.
For images that contain text, the text equivalent should of course replicate the text in the image. For things like pie charts, the text equivalent should convey information about the percentages -- the same information as the image conveys.
The alternate text shouldn't be too long. Some browsers don't word-wrap text equivalents, and they cannot be formatted in any way. If we need a longer text equivalent, we should put it somewhere else and link to it via the longdesc attribute.
Internet Explorer and old Netscape browsers display the alt attribute in a tool-tip when the user hovers the mouse pointer over the image. This constitutes an incorrect use of text equivalent data. We should use the title attribute for "tool-tip" information. To suppress the alternate text appearing in tool tips, we can use an empty title: title="".
34. What is the difference between class and id?
An id uniquely identifies a particular element in an HTML document. It's like a social security number, providing a unique handle for that element. Just as two people cannot have the same social security number, no two elements in a document can have the same id. ids must be unique within the page.
A class says that an element has some traits which it (possibly) shares with other elements. An element can belong to more than one class. An analogy could be professions: a person could be both a carpenter and a nurse, and there are many carpenters and many nurses. (They all have unique social security numbers, though.)
Both ids and classes are mainly used with CSS and/or JavaScript. In CSS, an id has higher specificity than a class, making it easy to specify special rules for a specific element. With JavaScript we can look up an element using its id (document.getElementById()).
We assign ids to page elements that can occur, at most, once per page, like a navigation menu, a footer, a sidebar, etc. We can also assign ids to specific elements that only occur once in the whole site, like a specific image, if we want to have certain CSS rules for it, or manipulate it with JavaScript.
We assign classes to elements that share some common traits, usually display properties via CSS rules.
ids and class names should be as "semantic" as possible. They should describe what something is, not what it looks like. Thus, id="menu" is much better than id="left"; especially if we redesign and move the menu to the right-hand side.
ids and class names are case sensitive, even in HTML. We shouldn't rely on case-sensitivity, though (i.e., we should not use names that differ only in case).
35. Why doesn't id="123" work?
Values for the id, name and class attributes must start with a letter (A-Z or a-z).
36. Why doesn't work?
There are two reasons in this case.
Attribute values that contain characters other than letters, digits and a few other characters must be enclosed in quotation marks (double or single). Any attribute value that needs to contain a space, for instance, must be quoted. The easiest and safest solution is to always quote attribute values. To include quotation marks in a quoted value, we have two options. We can either use the "other" quotation mark to enclose the value (alt='My "new" car', alt="Jane's car"), or use an entity or reference (alt="My "new" car", alt='Jane's car'). (Note that the ' entity cannot be used with HTML.)
The second reason is that there are spaces in the URI. These need to be encoded as shown here:
"%20" means "a character with code point 0x20". 0x20 is the code point for the space character. This applies to URIs only, not to attribute values in general.
37. How can I include an HTML page in another HTML page?
With a Strict DTD, there is only one valid option: the OBJECT element type:
Unfortunately, support for object is all but non-existent in Internet Explorer.
With a Transitional DTD, we can also use the iframe element type:
A much better approach is to handle inclusion on the server-side. Using server-side includes (SSI) is the simplest way to include a file into another, as long as they are from the same domain:
Note that this technique cannot be used to include a complete HTML document within another, though; it can be used only with fragments of HTML.
Other server-side technologies allow us to perform more advanced tasks. Your web server must support those technologies, of course. Often, shared servers with free hosting don't provide any such technologies -- not e
Tuesday, January 22, 2008
37 Steps to Perfect Markup
source: sitepoint.com
1. What is HTML?
HTML, or Hypertext Markup Language, is a markup language that's primarily used for Web documents. Any document that's written in a markup language is interspersed with tags that indicate the meanings of certain passages. Since version 2.0, HTML has been an application of a more generic markup language: SGML (Standard Generalized Markup Language).
HTML defines a number of element types. An element type assigns some semantic meaning to its content. For example, the em element type gives its content emphasis over the surrounding text. An element is a concrete instance of an element type. An element usually consists of a start tag (), some content, and an end tag ().
This HTML stuff is really, really nifty!
HTML allows some end tags (and even a few start tags) to be omitted. Don't confuse tags with elements; a bod y element will be present even if the tags are omitted. Certain element types must not have an end tag. One example is br, which signifies a line break.
Baa baa black sheep, have you any wool?
Yes sir, yes sir, three bags full
A start tag can contain attributes, comprising an attribute name, an equal sign (=), and an attribute value. For example, we can use the lang attribute to specify the language of an element's content.
Jean-Claude often exclaimed bon sang despite the fact that no-one understood him.
Attribute values must be quoted in some instances, so it's good practice always to quote all attribute values. Some boolean attributes are allowed to be minimised in HTML, which means the name and the equal sign are omitted (e.g. selected instead of selected="selected"). Some attributes are required for some element types, e.g., the alt attribute in an img element.
Beginners often use phrases like "alt tag", but this is incorrect nomenclature; alt is an attribute, not a tag. Tags are surrounded by <...>.
2. What are the different versions of HTML?
The first version of HTML (1989) didn't have a version number; it was just "HTML". The first "standardised" version of HTML, released by the Internet Engineering Task Force (IETF) in 1995, was called HTML 2.0.
Then the World Wide Web Consortium (W3C) was formed. It presented its first "standard" version in 1997: HTML 3.2. Its successor, HTML 4.0, came out in 1998, and was quickly replaced by HTML 4.01 in 1999. That is the latest and current version of HTML. The W3C has announced that it will not create further versions of HTML. HTML 4.01 is recommended for creating HTML documents.
However, the Web Hypertext Application Technology Working Group (WHATWG) are working on what is referred to as HTML5, hoping that it will eventually be accepted as a W3C recommendation.
3. What about XHTML?
A few months after HTML 4.01 became a final recommendation, W3C released XHTML 1.0. This was seen as the "next version of HTML," but that perception's not entirely correct. XHTML 1.0 is a "reformulation of HTML 4 as an application of XML 1.0", as the specification puts it. In other words, it's XML with a predefined set of element types and attributes (and semantics) that correspond to the elements types and attributes of HTML 4.01. It even comes in the same three flavours as HTML.
Many designers and developers embraced XHTML, as it was seen as the way forward. Few understood the profound differences between XHTML and HTML, as they looked so similar. The reality is that the most commonly used browser, Internet Explorer, does not support XHTML in any way, shape or form. More modern browsers like Opera, Firefox and Safari do support XHTML, but their market shares are too low for their support to have any significant impact when it comes to publicly accessible web sites.
By adhering to a number of guidelines put forth in the famous Appendix C of the XHTML 1.0 specification, it is possible to serve an XHTML document as HTML. This approach allows HTML-only browsers to be able to "handle" the document, but it is, for all intents and purposes, nothing more than HTML. We cannot use any of the features of XHTML when serving it this way, because we are not really using XHTML at all -- we're only pretending to.
4. Is HTML case-sensitive?
No, but XHTML is. In XHTML, all tags and attributes must be in lowercase. Traditionally, HTML element names and tags were written in uppercase, but with the advent of XHTML, this convention has slowly given way to the XHTML standard of lowercase element names.
5. What does the DOCTYPE declaration do?
The DOCTYPE declaration, which must precede any other markup in a document, usually looks something like this:
"http://www.w3.org/TR/html4/strict.dtd">
It specifies the element type of the document's root element (HTML), a public identifier and a system identifier.
The public identifier (-//W3C//DTD HTML 4.01//EN) shows who has issued the document type definition, or DTD, (W3C); the name of the DTD (DTD HTML 4.01); and the language in which the DTD is written (EN, for English). Note that it doesn't say anything about the language of the web page itself; it is the language of the DTD that is specified here.
The system identifier (http://www.w3.org/TR/html4/strict.dtd) is the URI (uniform resource identifier, or "web address") for the actual DTD.
The DOCTYPE declaration tells a validator (a program that checks the syntactic validity of a web page) against which DTD it should test the page for compliance. Browsers didn't used to care about the DOCTYPE declaration, but modern browsers use it to decide whether the page is "modern" (and presumably expect the behaviour detailed in the W3C HTML documentation) or old-school (and expect the browser to render the page with all the bugs and quirks exhibited by older browsers). A document's DOCTYPE affects the rendering mode used by Internet Explorer, Opera, Firefox (and other Mozilla-based browsers), Safari, and most other modern web browsers. A complete DOCTYPE declaration -- including the system identifier -- tells the browser that this is a modern document. If the system identifier is missing, or if there is no DOCTYPE declaration at all, browsers assume that this is an old document and render it in "quirks mode".
6. What is a DTD?
A DTD, or document type definition, specifies the element types and attributes that we can use in our web page. It also defines the rules of how we can use these elements together -- it's the specification for our markup language. The DTD can also declare the character entities we can use; more about those later.
A validator will test a web page for compliance with the DTD specified in the DOCTYPE declaration either explicitly, via the system identifier, or implicitly, using the public identifier. Browsers use non-validating parsers and do not actually read the DTD. They have built-in knowledge about the various element types, and usually a hard-coded list of character entities as well.
For HTML 4.01, which is the latest and greatest version, there are three different DTDs: Strict, Transitional and Frameset.
7. What is the difference between Strict, Transitional and Frameset DTDs?
The differences between these DTDs include the element types and attributes they declare, and how they allow or require element types to nest.
- The HTML 4.01 Strict DTD emphasises the separation of content from presentation and behaviour. This is the DTD that the W3C recommends for all new documents.
- The HTML 4.01 Transitional DTD is meant to be used transitionally when converting an old-school (pre-HTML4) document into modern markup. It isn't intended to be used to create new documents. It contains 11 presentational element types and a plethora of presentational attributes that are deprecated in the Strict DTD. The Transitional DTD is also often necessary for pages that reside within a frameset, because it declares the TARGET attribute required for opening links in another frame.
- The HTML 4.01 Frameset DTD is used for frameset pages. Frames are deprecated by the W3C. For modern web sites, using server-side scripting technologies is usually regarded as a far better solution.
8. Which DOCTYPE should I use?
If we are creating a new web page, the W3C recommends that we use HTML 4.01 Strict.
If we are trying to convert older HTML 2.0 or HTML 3.2 documents to the modern world, we can use HTML 4.01 Transitional until we have managed to transfer all presentational issues to CSS, and all behavioural issues to JavaScript.
9. Why should I validate my markup?
Why should we spell-check our text before publishing it on the web? Because mistakes and errors can confuse readers and detract from the important information. The same can be said for markup. Invalid markup can confuse browsers, search engines and other user agents. The result can be improper rendering, dysfunctional pages, pages that remain unindexed by the search engines, program crashes or the end of the universe as we know it!
If our page doesn't display the way we intended, we should always validate our markup before we start looking for other problems (or asking for help on SitePoint). With invalid markup, there are no guarantees.
Use the HTML validator at W3C to check your pages' compliance. Don't forget to include a DOCTYPE declaration, so the validator knows against which standards it should check your document.
HTML Tidy is a free tool that can help us tidy sloppy markup, format it nicely and make it easier to read.
10. Why does HTML allow sloppy coding?
It doesn't, but it recommends that user agents handle and try to recover markup errors.
It is sometimes alleged that HTML allows improperly nested elements like foo. That isn't true; the validator will complain about improperly nested tags because they don't constitute valid HTML. However, browsers will usually guess what the author meant, so the error may go undetected.
Some dislike that HTML allows the omission of certain (but not all!) end tags. That's not a problem for browsers, because valid markup can always be parsed unambiguously. In the early years it was very common to omit certain end tags, (e.g.
br and img, for which it is forbidden. 11. Why does the validator complain about my
embed has never been part of any HTML recommendation. It's a non-standard extension which, although supported by most browsers, is not part of HTML.
During the "browser wars" of the late 1990s, browser vendors like Microsoft and Netscape competed by adding lots of "cool" features to HTML to make it possible to style web pages. The problem with those additions was that they weren't standardised, and were mostly incompatible between browsers.
There are other elements that used to be quite common (marquee, anyone?), but which have never been included in an HTML recommendation. Don't use them if you can possibly avoid doing so.
A number of other attributes were very common in the 1990s, but have never been included in an official HTML recommendation. marginwidth is one example.
12. What does character encoding (charset) mean?
Computers can only deal with numbers. What we see on the screen as letters or images are transmitted over the Internet and around the various parts of your computer as numeric codes, which the computer sees as groups of binary digits (ones and zeros).
In order to make sense of these numbers, we need to define a minimum unit that's capable of conveying some sort of information. When we're dealing with text, this unit is called a character. This is a rather abstract concept. The character known as "uppercase A" has no defined visual appearance; it's more like "the idea of an A".
Next, we need to establish a set of such abstract characters that we will use. That's called a character set. A character set is the total set of abstract characters that we have at our disposal. For HTML, the standard character set is ISO 10646, which is virtually the same thing as Unicode. It is a set of tens of thousands of characters representing most of the written languages on the planet.
The visual appearance of a character is called a glyph. A certain set of glyphs is known as a font. The glyph for "uppercase A" will differ between fonts, but that doesn't change the underlying meaning of the abstract character.
Now, since computers only deal with numbers, we must have a way to represent each character with a numeric code. Each character in a character set has a code position, or code point. The code point is the numeric representation (index) of the character within the character set. Code points in Unicode are usually expressed in hexadecimal (e.g., 0x0041 for "uppercase A").
Finally, the encoding -- sometimes, unfortunately, also called a "character set" or "charset", though we'll stick with the correct term "character encoding" here -- is a mechanism for expressing those code points, usually with octets, which are groups of 8 binary digits (and thus are capable of representing numbers between 0 and 255, inclusive).
In the early days of computer communication, people used small character sets containing only the bare necessities for a specific language. The most well-known set is probably ASCII (ISO 646), which only contains 128 characters, 33 of which are unprintable "control codes". The ASCII character set has 128 code points numbered sequentially from 0 to 127. The encoding is a simple one-to-one: the codepoint for "uppercase A" is 65 (0x41), which is encoded as 65 (1000001 in binary).
ASCII isn't very useful outside the English-speaking world, because it contains only the letters A-Z, digits 0-9, and some basic punctuation. The International Organization for Standardization (ISO) issued a set of standards called ISO 8859, which augmented the ASCII character set with characters that needed for other languages. In the Western world, the most common set is ISO 8859-1, known as Latin-1. It contains characters needed to write most Western European languages. The ISO 8859 series are both character sets and character encodings. Each character set contains 256 characters, which can be encoded using 8 binary digits. They each used the ASCII character set as a subset, i.e., the first 128 code points are the same.
But even 256 characters was not enough to write some languages. Chinese, for instance, needs thousands of characters. Several mutually incompatible encodings for Chinese were devised, but there were still big problems for those who wanted to exchange information across linguistic and cultural barriers.
From this point, it would be easy to create a character encodings that used 16 or even 32 binary digits for each character. However, using a 32-bit encoding would result in most documents being four times larger than they needed to be.
The solution was a variable-length encoding called UTF-8. It uses between 8 and 48 bits to encode each code point, and it can address the entire Unicode (or ISO 10646) character set. The first 128 code points are encoded in 8 bits, and are identical to the corresponding code points in ASCII. Most Western European languages can be encoded with single octets, sprinkled with the occasional 16-bit character for letters with diacritical marks (e.g., Ä).
How does this affect us as authors of web documents? If we use characters whose code points are outside the ASCII range, the encoding becomes really crucial. Specify the wrong encoding, and the page will be difficult -- or even impossible -- to read.
So how do we go about specifying the encoding? The proper way to do it is to send this information in the Content-Type HTTP header:
Content-Type: text/html; charset=utf-8
The HTTP headers are sent by our web server, so we must tweak the server to change the encoding information. How we achieve that will depend on which web server we use. For Apache, it can be specified in the global configuration file (httpd.conf) or in local .htaccess files. But if we're using a shared host, we may not have sufficient privileges to tweak the configuration. In that case, we need a server-side scripting language to send our own HTTP header; here's an example for PHP:
header('Content-Type: text/html; charset=utf-8');
We can also specify the encoding using an HTTP equivalent in a META element:
content="text/html; charset=utf-8">
This meta element will be ignored if the real HTTP header contains encoding information. It can be useful anyway, though, because it will be used if a visitor saves our page to the hard drive and looks at it locally. In that situation, there's no web server to send HTTP headers, so the meta element will be used instead.
There is no default encoding for HTML, so we should always make sure to specify it.
A common encoding under Microsoft Windows is Windows-1252. It's very similar to ISO 8859-1, but there are differences. In ISO 8859-1, the range of code points between 0x80 and 0x9F is reserved for control characters. In Windows-1252, that range is instead used for a number of useful characters that are missing from the ISO encoding (e.g., typographically correct quotation marks). This is not an encoding that I would recommend for use on the Web, since it's Windows-specific. However, it is the default encoding in many text editors under Windows.
13. What is a BOM?
The BOM, or byte order mark, is used for some encodings that use more than 8 bits to encode code points (e.g. UTF-8 and UTF-16). Computer processors (CPUs) can employ two different schemes for storing large integer numbers: "big-endian" and "little-endian". The BOM comprises 16 bits, written at the very beginning of the file, which tell the browser which scheme is being used.
Unfortunately, many older browsers cannot handle this information, so they display these bits as character data. If you see a couple of strange characters at the top of a page, the reason is probably that the BOM isn't handled by the browser (or an incorrectly specified encoding).
The only resolution to this problem is to avoid using the BOM. Editors that can save a document as UTF-8 will usually allow us to choose whether or not to include the BOM.
14. What encoding should I declare?
It's very, very simple: we must specify the encoding that we used when saving our source file! If we save the file as ISO 8859-1, we must specify the encoding as iso-8859-1; if we save as UTF-8, we specify it as utf-8. The only problem here is that we may not always know what encoding our editor uses to save the file. Any editor worth its salt should give us the option to specify the encoding, though.
If we are writing in English, it doesn't matter all that much which encoding we choose, because we are mostly going to use characters that are encoded the same in most encodings. US-ASCII, ISO 8859-1, UTF-8 ... take your pick. For those of us who write code in other languages, the choice becomes more important. My native language -- Swedish -- uses three letters more than the English alphabet has to offer. Those are present in ISO 8859-1, so I can choose between that and UTF-8 encoding. Browser support for UTF-16 is poor, so it should be avoided on public web sites.
My recommendation is to use UTF-8 encoding wherever possible, without a BOM. It can natively represent any character in the Unicode character set.
Avoid Windows-1252 on public web pages, since it's a Windows-specific encoding. Use ISO 8859-1 instead (or ISO 8859-15, if you need the Euro sign).
15. How do I insert characters outside the encoding range?
What if we're using ISO 8859-1 encoding and wish to include a Euro sign in our content? There is no Euro sign in that character set, and hence no way to encode it, although it is present in ISO 10646 and can be used on a web page.
We have two choices: a named entity or a numeric reference.
The named entity for the Euro sign is €. Entities start with an ampersand (&) and end with a semicolon (;). In some circumstances we can get away with omitting the semicolon, but it is definitely good practice to always put it in. Entity names are case-sensitive.
A numeric reference can be either decimal (—) or hexadecimal (—), but it's generally safer to stick with decimal notation, because some old browsers can't handle the hexadecimal version. Note that the numeric value references the code point in ISO 10646; it has nothing to do with the encoding we've specified for our document.
References (in decimal) always work. Named entities may cause problems in older browsers, because some of them only support a subset of HTML entities.
16. Why do I need to write & instead of just &?
Certain characters have special meanings in HTML: < (less than), > (greater than), & (ampersand), " (quotation mark) and ' (apostrophe). In some circumstances, when we want to use these characters in normal text, we need to replace them with HTML entities.
The entities for the first four characters are as follows:
<(less than)>(greater than)&(ampersand)"(quotation mark)
XML defines an entity for the apostrophe ('), but HTML does not include this entity. An apostrophe can only be escaped using a numeric reference (').
Since the ampersand is used for these entities, it must nearly always be escaped, including occasions when it's used inside attribute values, such as the href attribute of links. Unfortunately, the ampersand is a very common argument separator in URIs, which means that it's quite common to encounter ampersands in URIs.
Most of the time in HTML, unescaped ampersands don't break anything (though XHTML is a different story). The error handling routines in browsers recover from the error and it all works. But if we should happen to have a query parameter whose name matches one of the predefined named entities in HTML ...
17. How should heading elements be used?
HTML heading element types are h1, h2, h3, h4, h5 and h6. The number denotes the structural level of the heading, which means we should treat headings as we did in those outlines we had to learn in school (and promptly forgot about right after graduation).
The top-level heading on a page must be an h1. It should describe what the page is about. Most pages will have one h1 heading, but very complex documents that deal with several disparate topics may need more than one.
h2 headings will mark up the next structural level. Any sub-levels under that will be h3, and so on. We can never skip a heading level as we move downward through the hierarchy. An h4 should not follow an h2; there should be an h3 in between. (The validator will not complain about this, but it is good practice.)
It's important to mark up headings with the Hn element types. Assistive technologies such as screen readers can make use of a proper heading hierarchy to present an outline of the document. If we use ..., they cannot.
to be continued
Monday, January 21, 2008
CSS Not([hacks])
Source digital-web.com
As any web developer worth his salt will know, browsers can differ in their interpretation of CSS rules and properties. One way of coping with this headache is to use various hacks; they might (in some cases) be invalid CSS, but they force browsers to read only certain parts of your CSS and render your page or web site as close to how you intended as possible. CSS hacks are one of the common ways to send specific instructions to different browsers, be it to solve min-width issues or box model interpretations.
This is basic progressive enhancement. When the next version of Internet Explorer arrives with (we hope) better CSS support, it will pick up on the rules targeting Firefox, Safari, and Opera, and it will display the progressively-enhanced page. And when this happens you won’t have to worry about updating your CSS files
But there is another way. I will demonstrate the possibilities of using CSS3 selectors as an alternative to hacks when targeting specific browsers. Hacks are an example of graceful degradation: you design for the most capable browser and then fix issues in legacy browsers. But what if we took the opposite approach and worked with progressive enhancement?
In this case, progressive enhancement involves writing the CSS so it works in all your target browsers, and then adding enhancements for those browsers that better support the CSS specification. You can think of it as the reverse of graceful degradation.
Let’s not mince words here: most of the problems stem from Internet Explorer’s (IE) rendering bugs. Consequently, many of the hacks relied on bugs in IE’s CSS parser—including its inability to correctly parse comments, leading underscores for properties or the box-model hack. The downside is that these hacks are specific to IE and can potentially break when a browser is upgraded.
#elem {
width: [IE width];
voice-family: "\"}\"";
voice-family:inherit;
width: [Other browser width];
}An example of the box-model hack: IE’s CSS parser incorrectly finishes the declaration block at the ‘}’ in the voice-family value, and fails to parse the last two declarations.
Wouldn’t it be better if we could continue to write CSS with statements that older browsers can’t understand, but are still valid? Using the child selector (‘>‘), for example, we can hide declaration blocks from IE6.
html>body p {
color: blue;
}An example of a child selector: all versions of IE up to and including IE6 couldn’t understand this rule, but IE7 does. You can use it to progressively enhance your designs. Newer browsers begin to gain the benefits stated in those rules without you having to constantly update your CSS.
This is a much better approach to take as it allows for progressive enhancement. As browsers become better at conforming to the CSS standard, the rules you already have in place begin to work. No need to wade through the old cruft of /* */ or _property looking for broken statements and updating the code if you write it well in the first place!
Using CSS3 for Fun and Profit
The easiest place to begin to look for valid CSS that some browsers understand and others don’t is the draft CSS3 specification. Portions of the specification are supported by Mozilla Firefox and Apple Safari—among others—but not IE.
Building a simple matrix of CSS statements and browsers, we can quickly see what features are and are not supported. Then we can offer some progressive enhancement: CSS rules that better conforming browsers support while worse or older browsers don’t.
Using the W3C CSS3 selector tests we can easily spot potential candidates for browser specific statements. I simply opened all the tests the W3C provides for CSS3 in 5 different browsers and looked for selectors that would not pass or fail unanimously. The table below shows a sample of the tests and their results.
| CSS/Browser | Opera 9.24 | Internet Explorer 6 | Internet Explorer 7 | Safari WebKit 3 | Mozilla Firefox 2 |
|---|---|---|---|---|---|
| NEGATED More than one class selector | Fail | Fail | Fail | Pass | Pass |
| :first-of-type pseudo-class | Fail | Fail | Fail | Pass | Fail |
| :last-child pseudo-class | Fail | Fail | Fail | Fail | Pass |
| :only-child pseudo-class | Fail | Fail | Fail | Fail | Pass |
| :target pseudo-class | Fail | Fail | Fail | Pass | Pass |
| :lang() pseudo-class | Pass | Fail | Fail | Pass | Pass |
| :root() psuedo-class | Fail | Fail | Fail | Pass | Pass |
A quick look at the list reveals that the not() selector is supported by Firefox and Safari but not by either IE (version 6 or 7) or Opera. The lang() selector is supported by Opera, Safari and Firefox, but not IE. Finally, using only-child or last-child, we can target just Firefox. With these selectors we can now create browser-specific CSS statements without having to resort to errors in CSS parsing between implementations.
So we have a CSS-only method for browser-specific styling that doesn’t resort to hacks. Instead of using comment hacks, the underscore hack or the box-model hack, you can write valid CSS and still achieve some browser specific styling: by first setting a default case and then applying the more specific statements to browsers that can understand.
Putting it all together
Let’s illustrate this with an example. Suppose we have an image we want to hide in IE but make visible in other browsers. First, the HTML code:
Second, we need to declare our base-case to hide the image in all browsers:
#gravatar img.photo {
display: none;
}This will hide all img elements with a class ‘photo’ that are descendants of the element with the id ‘gravatar’.
Having done that we need to then display the image for those browsers that have better CSS support.
#gravatar img.photo:not([border]) {
display: block;
}By adding the not() selector and checking for a border attribute, we can re-display this image for browsers that understand this statement. It specifies (take a deep breath) that all img elements with a class ‘photo’ that are descendants of the element with the id ‘gravatar’ and that do not have a border attribute should be displayed as a block element. Effectively, this makes the img element visible again. If we look at the browser matrix in the table above we see that only Firefox and Safari support this. We now have a way to specifically target just those browsers.
Using the not() trick will allow you to display the image (or anything else that takes your fancy) to a subset of browsers. Both IE6 and IE7 as well as Opera don’t understand this CSS statement, so in those browsers the image will remain hidden. But what if we want to display the image in Opera too, without affecting IE?
To accomplish this, we need look at the browser matrix and see which selectors will work in Opera, Firefox and Safari, but not the IEs. The :lang() pseudo-class looks like an ideal candidate; we can change the CSS statement to:
html:lang(en) #gravatar img.photo {
display: block;
}(Note for this to work you must include a lang="en" attribute on the html element.)
This is basic progressive enhancement. When the next version of Internet Explorer arrives with (we hope) better CSS support, it will pick up on the rules targeting Firefox, Safari, and Opera, and it will display the progressively-enhanced page. And when this happens you won’t have to worry about updating your CSS files: the information you added was never a hack in the first place. This is assuming that when IE8 supports the :lang() pseudo selector it will also be capable of displaying the image.
Using a pure CSS solution is always preferable to using hacks. Even Microsoft recommends avoiding hacks for IE, instead advocating the use of conditional comments. On the web, as in life, my mantra is “everything in moderation”. I have hopefully demonstrated to you that it is possible to write CSS for different browsers by using CSS3 selectors, therefore keeping your hackery to a minimum.
Thursday, January 17, 2008
WEB/INTERACTIVE DESIGN
| |||||
| Last issue’s theme, corporate community service, led me to look for a related site to review in this Best of Web issue. I found one that not only does a lot of good, but also offers a terrific user experience. The content, messaging, informational hierarchy, visual design, and interface all address donors’ and volunteers’ concerns beautifully. The first thing you see on the networkforgood.com home page is “donate now” in a big yellow button. That’s the point of the site, and since it’s so prominent, it’s likely to be the first thing visitors click on. It leads to a page that tells you how to use the site, lets you search for charities, and helps you figure out what level of giving is right for you. For non-clickers who may have doubts about the site, the home page answers key questions in a way that’s more “about you” than “about us.” Why is this site special? Because you can “give to your favorite charities in one place.” Is this organization trustworthy? The first box under the yellow button tells you that it’s easy, and that they’ll keep all your donation records for tax time, while the logos below assure you that Network for Good is backed by great companies. Is it OK to donate here? The second box says that 300 million others have already done so. “Learn more” buttons in each box link to testimonials and details on effectiveness, such as that 97 percent of your donation goes straight to charities. Another call-to-action box sits to the right. (Go on, just do it.)
 Clicking on the Volunteer Match icons at right leads you to a partnering organization’s site that describes the job you select and gives you tools to search for others. The menu bar across the top gives you other ways to find, manage, and record your donations and service efforts. Under “donate,” you can find charities, buy donations as gifts, store your favorite charities, calculate how much you should give, and so on. Under “volunteer,” you can look for opportunities, keep service records, join a youth network, and learn about effective volunteering. “Crisis relief” leads you to descriptions of disaster areas and their needs. “My profile” is your own private service and donation database. And finally, a pull-down menu connects you to special interest areas, such as Animals & Environment or Education & Research. Above all of this is a special link, “Are you a nonprofit?” that leads to a site with comprehensive information and services for managers of charities. This took several paragraphs to describe in words, but the visual design makes it look clear and simple. That’s partly because of the sun-and-blue-sky colors and generous white space, but mostly because of the unusual reading pattern the design imposes. Most sites organize information in choppy rows and columns. This one organizes it in a spiral—a natural page-scanning pattern. You start at that yellow button, swing down and to the left, move up through hot topics and search, and sweep across the menu. Compare this to a more typical charity site, justgive.com. The colors are harsh, the layout is rigid, the imagery is bleak, and the language is peremptory. It doesn’t tell you why you should use this site or address the all-important question, “What’s in it for me?”
 Youth Volunteer Network is a partner effort with Youth Noise— Network for Good does a lot of networking itself. Will the quality stay that high deeper into the site? From a donor or volunteer’s point of view, the hardest job is to select just one charity from the million or so doing good work in this country. Let’s see what happens when we click on Darfur in Hot Topics. The lead story is a brief, objective description of this tragedy in Sudan, without histrionics or guilt trips. Action items follow immediately. You can raise awareness among your own network by sending an “action e-card,” then decide whether you want to donate, volunteer, or learn more. The neat, clearly separated columns make the lists easy to navigate. When you click “donate,” you get the full story on the charity’s programs, executives, contact info, assets, and recent accomplishments. Click “volunteer,” and the organization’s own web page loads onto the Network for Good page. You don’t get a mess of pop-ups, but you will get everything you need to make an informed decision. If you aren’t ready to commit, you can add the charity to a list of favorites. Let’s try going into the site another way. Say you want to work with kids closer to home. Enter “youth” and your zip code in the home page’s search tool, and you immediately get a list of relevant organizations with links to descriptions of the organizations and the jobs they need help with. If you don’t see anything interesting, you can do an advanced search covering skills, partners, and the kinds of people you want to work with. Again, the layout is clean, open, and easy to use. The “short cuts” pull-down menu leads you to the same kind of information by way of an overview page. Here, while the information is dense, it helps you zero in on special interests and remains orderly. If you’re having trouble choosing, “This Week’s Features” at the upper right zeros in for you. The designers observed other niceties across the site, which are basic best practices in web design, but which some sites don’t seem to manage. They controlled the page size, and therefore the layout, by setting a plain gray flood plain—the area between the page and the browser frame. They frame every page with the appropriate identity elements. By appropriate, I mean the elements that are relevant to the page in question. For instance, the Donate overview page has the logo, menu bar, search tool, and features section, while the Gift Baskets page has just the logo and menu bar, and personal records pages have just the logo and a dark blue bar. You don’t need everything on every page, and you don’t get it. This kind of detail shows real respect for visitors. In the introduction, I said that what’s important about this site is not just the design, but the way it uses the best of what the web has to offer. Remember 1996, when all those irritatingly young, cocksure internet programmers and designers were telling us that the net was going to change the world? I thought they were nuts. They weren’t. The vast seas of information in its databases, linked across the world, and organized by intelligent visual and interface design, are making grassroots action one-click simple. This site is a prime example. It uses the power of the net efficiently and appropriately to bring people together in ways that make the world a little bit better every day. |
Tuesday, January 15, 2008
Interface design is security design
It is becoming popular to talk about dealing with people as a factor in security these days. The idea is that social factors contribute as much to security as technological factors. In other words, any security professional who only concerns himself with strictly technical decisions to secure a system, and ignores the social factors of security, is not doing his job.
It can be difficult sometimes to imagine how to account for social factors of security. In general, such factors boil down to matters like business culture and interface design.
A culture with a strong, positive emphasis on security helps people recognize the importance of following good security practices and adhering to policies. Fostering such a culture depends on keeping employees informed about security matters that affect them and that they in turn affect, establishing appropriate levels of trust, and keeping people aware of the importance of security at all times.
Interface design, in this case, refers to more than just the placement of buttons in GUI design. It refers to the way policies, technologies, and procedures are presented to the people who deal with your secure systems and each other. The easier and more natural you can make it feel for users to do the right thing for security, the more likely they are to do it.
What both of these general categories of social factors of security have in common is that they do not just mandate secure practice — they encourage it. When the individual is motivated internally to maintain good security, whether by a deep understanding of specific security procedures and the reasons for them or by secure procedures that seem more natural and intuitive than the alternative (or at least nearly as natural and intuitive), maintaining security is considerably more likely to be successful.
People often bemoan the trade-off between usability and security in software design, as though there is some natural law stating that for every incremental increase in the security of a system there is a matching incremental decrease in the usability of the system. This, however, is not the truism of software design that many people seem to think it is; rather, it is a truism of bad security design.
Often, such bad security design is a result of attempting to bolt security onto an already existing system that, previously, essentially benefited from no security design at all. The end result is not integrated security design, and bolted-on security features aren’t secure. A modern example is MS Windows Vista’s UAC, designed to allow users to log in with an uprivileged account for normal, day-to-day activities, but provide them with a means of performing administrative activities without having to log out of their unprivileged accounts first.
Stories of people growing so frustrated with UAC that they disable it and live with the security consequences of this are a dime a dozen. A Google search for the terms “uac” and “frustrating” should prove instructive for anyone who has not experienced UAC for him or her self. Believe it or not, though, UAC is an improvement. Before MS Windows Vista, one essentially had to log out of the unprivileged account then log in to the administrative account, do what needed to be done, then log out of the administrative account and log back in with the unprivileged account.
MS Windows XP introduced fast user switching, which alleviated some of the difficulty. It allowed the user to switch between accounts without having to shut down and, later, restart all applications used by a given account. Still, the basic inconvenience remained — exiting one user account and entering another, then reversing the process.
This could be especially problematic if you needed to access information or functionality that may not be very secure, such as Websites with information on how to achieve a given task; in other words, activities like Web browsing that are exactly the sort of thing you should do only with an unprivileged account. At that point, you must choose between copying all of the relevant information to some other medium before switching to the administrative account, switching back and forth between accounts constantly, and simply engaging in unsecured activities from the administrative account. The last choice, of course, directly counteracts the security purpose of separating user account privileges.
By contrast, Unix systems have had true privilege separation between accounts for decades. Security in this respect is integrated with the system, and does not suffer the same limitations. From within a login session for an unprivileged user account, one can open arbitrary applications as the root user (the Unix administrative account). These applications coexist within the same user interface environment with applications run by the unprivileged user account, as needed. This means that a browser running with the permissions of an unprivileged user account can exist side-by-side with a system configuration tool running with the permissions of the root user account.
This sort of difference in design is made easy by the fact that privilege separation is an integrated part of the system rather than a bolted-on afterthought, and the result is that users of the system find it much easier to use administrative accounts for a limited set of administrative activities and unprivileged accounts for everything else without compromising security.
That’s only one example of the difference between good and bad interface design in the context of security, but it is an example that should be familiar to most IT professionals. Keep it in mind the next time you design the interface for a security feature of your software, as a manifestation of the fact that interface design is often inseparable from security design.
Monday, January 14, 2008
Reality Check for Web Design
Source : wired.com
"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."
Tim Berners-Lee, inventor of the World Wide Web, recognized that universal access is a critical element of good design.
The Web's landscape has altered dramatically since its inception, when many websites completely ignored users with disabilities.
"Most project managers assumed that blind people could not use the Web anyway, so therefore they also could not use the specific website that was being developed," said Web usability guru Jakob Nielsen.
"We have now eradicated this misunderstanding, and most Internet managers do know that they have to care about users with disabilities."
Despite progress, websites today are still three times harder for users with disabilities to use than for other users.
"In most projects, accessibility has fairly low priority because project managers underestimate the number of people who are impacted by design problems," Nielsen said. "They think that they are just losing a handful of customers, whereas in fact they may be turning away millions of customers, especially among senior citizens, who constitute a big and rich group that's getting more and more active online."
Now, a new software product allows developers to check pages for compliance with usability guidelines as they code.
The software, "LIFT-Nielsen Norman Group Edition," or LIFT NN/g, works with Macromedia Dreamweaver (4.0 or MX) on both Windows and Macintosh.
LIFT NN/g checks to ensure that websites are compliant with the World Wide Web Consortium's accessibility guidelines and Section 508 guidelines.
"The new software basically makes it easier to be a Web designer and to remember the guidelines for users with disabilities," Nielsen said. "Instead of relying on having the designer remember every single guideline at every single step of developing the website, we are offloading the memory burden onto the computer, which is very good at staying alert and checking for a lot of details all the time without getting tired."
The Nielsen Norman Group created guidelines by conducting user tests and observing a range of users (including those who were blind or had poor vision or motor-skill challenges) interacting with a variety of websites.
The software alerts developers of any possible violations of these guidelines. A fix wizard automatically repairs broken tables, images, scripts, cascading menus and other glitches. A JavaScript Analyzer avoids common errors. A monitor checks work as it's completed, so mistakes are fixed before they are perpetuated on multiple Web pages.
Hundreds of pages can be processed in just a few minutes, saving hours that would otherwise be spent coding by hand.
"The main benefit is that the computer doesn't get tired; thus, it will check every design detail for every single guideline all the time," Nielsen said. "Also, the software has a simple link from any occurrence of a potential usability problem to the relevant research material that explains why it's an issue and what questions to consider when deciding whether to keep or fix the questionable design element.
"This is much faster than having to look up the answer in a book, and in fact it's a great example of the original promise of hypertext."
The software goes beyond merely focusing on accessibility to promote usability and improve the Web user experience for everyone.
"Technical accessibility is not enough to make a website easy to use," Nielsen said. "The real question is whether users can get what they want from a website in a reasonable amount of time and whether the visit is pleasant for them. Users with disabilities are humans and need easy and simple user interfaces just like anybody else."
"Making websites more accessible can go beyond the benefits to people with disabilities," agreed Doug Bowman, network design manager for Terra Lycos (Terra Lycos is Wired News' parent company). "Accessibility measures also make good business sense.
"The Web is just as much a public space as our downtown office buildings and suburban shopping malls. By not being aware of, or taking the time to implement, common Web accessibility measures and guidelines, we are -- as website producers -- essentially hiding the elevators, ramps, handrails and wide doors which welcome anyone into our virtual buildings and help them find their way or move from place to place."
But while the software automates many core usability and accessibility solutions, humans must ultimately decide whether a design has a usability problem.
"As with all usability, it is based on the need to create good human interaction, so it is important not to take the human out of the design process," said Jason Taylor, senior product manager for UsableNet.
The LIFT NN/g software works like Microsoft Word's grammar check, allowing designers to check fundamentals that are sometimes missed due to busy schedules and tight deadlines. But like grammar, usability doesn't always follow strict conventions.
"While it's helpful to know when you've gone outside those normal, recommended practices, automated software could misguide someone with less experience in Web accessibility if they follow every suggestion," Bowman said.
The cost of the software, available at UsableNet for $549, could be prohibitive for some small websites.
"I don't see smaller companies happily forking over another $550 for accessibility software when they really haven't yet been educated on the benefits of making their websites accessible," Bowman said.
What's more, some larger companies use other HTML editors besides Dreamweaver for designing and managing websites.
The LIFT NN/g software is just one of the evaluation, repair and transform tools that can be used in conjunction with more complex websites serving environments used by large websites.
Developers can also check the accessibility of their website free of charge using a tool commonly known as "bobby", which checks for compliance with the basic W3C standards.
"Large, dynamic database-driven sites often use complex scripts and serving environments to pull together content from multiple sources, then compile it into HTML," Bowman said. "Website design may begin in an editor like Dreamweaver. But the final HTML churned out by a content management system may leave out some of the accessibility-checked code from Dreamweaver."
Despite these drawbacks, software producers and designers agree that any improvement in accessibility for people with disabilities will also make it easier for other Internet users to navigate the Web.
"Over time, these tools become educational in nature," Bowman said. "Repeated reminders of what could be done can eventually become ingrained and lead to common practice."
Subscribe to:
Posts (Atom)
