Here’s a trivia question for you: What was the name of the first Web browser? For many of you, Mosaic probably came to mind. While Mosaic is commonly thought of as the first Web browser, it was not. The first Web browser was invented by Tim Berners-Lee in 1989 and it was called WorldWideWeb.
WorldWideWeb was nothing like what comes to mind when we think of a Web browser today. It didn’t have the ability to render graphics. Even so, it was an extraordinary accomplishment and, as history can testify, it transformed the way we access information.
In 1993, NCSA Mosaic 1.0 was released, but it also lacked the ability to display images. That capability wasn’t made available until 1994, when Mosaic 2.0 was released.
Note
I can remember opening a Web page on Mosaic 2.0 and watching a picture unveil before my eyes. Perhaps “unveil” is a poor word choice because that image took about 15 minutes to download at 2400 baud.
In 1994, Netscape Communications released Netscape 1.0. A year later, Microsoft released Internet Explorer 1.0 and the race was on. By 1997, Microsoft had released Internet Explorer 4.0, which contained a solid implementation of the Document Object Model (DOM), allowing Web developers to begin using JavaScript to manipulate pages. In the meantime, Netscape had released version 3.0 and the Netscape 3.0 Gold Edition, which contained a WYSIWYG Web design tool called Netscape Composer. Add Microsoft’s FrontPage 97 (another WYSIWYG Web design tool available at the time) into the mix and the stage was set for a compatibility nightmare.
The concept of compatibility can be traced directly to the browser wars of the 1990s. As Netscape and Microsoft battled it out for browser superiority, Web developers became casualties of that war. Code that looked great in one browser looked entirely different on another browser. The design divergence wasn’t limited to Microsoft versus Netscape design decisions. Pages that looked great in one version of a particular browser might fall apart on a different version of the same browser.
As the war heated up, it became clear that Web designers would not get relief from browser developers. Instead, it was up to Web designers to “fix” the problem. Web development hacks began to pop up in forums frequented by designers. If you were a Web developer during this painful period, you no doubt remember how difficult it was to keep up with all the latest techniques.
A few years ago, I could have easily filled an entire book on compatibility issues. Fortunately, that is no longer the case. Today’s Web design tools and Web browsers are more standards-compliant. The hacks that Web designers used in the past are often no longer necessary. To avoid compatibility issues, today’s Web designer can focus on the standards and be fairly certain that his or her Web site will appear as expected for most people.
Note
Recent browsers and design tools are almost entirely standards-compliant, but there are still plenty of people using older browser versions. Keep that in mind when designing your Web site. See the “Should You Design for Older Browsers?” sidebar for my take on how to deal with this situation.
Expression Web has many features designed to help you create standards-compliant Web sites. The most important feature offered by Expression Web is its ability to create standards-compliant code automatically. Because of that, you are free to work on your Web site without worrying about what’s going on under the hood. However, what if you’re working on a site that was originally created in another application? Fortunately, Expression Web offers features to help you identify and correct inherited code problems as well.
Expression Web has a few different ways of notifying you when a code problem exists. Among these are the Status Bar, marking invalid code in Code View, and compatibility reports.
The Status Bar will display an icon (shown in Figure 20.1) when it finds incompatible code or a code error. For example, if an HTML table is missing the closing </table> tag, Expression Web will inform you that a code error has been detected. Other errors can be subtler, such as improperly closed tags in an XHTML-compliant document.
For more information on identifying and correcting code errors in Code View, see “Using Web Page Views”, p. 127 (Chapter 8). |
Tip
The icon indicating incompatible code will only appear when in Code View or Split View. The Code Error icon will appear in all views when a code error is present.
Note
XHTML is the latest standard in Web design. The current XHTML standard is almost identical to the HTML 4.01 standard with the addition of XML formatting and elements.
A full discussion of XHTML is beyond the scope of this book. For more information on XHTML, read Special Edition Using HTML and XHTML, available from Que Publishing.
To determine whether or not code problems exist, Expression Web uses several different methods to determine the formatting and layout rules applicable to the current page.
The doctype declaration is an optional statement that is contained within the first line of code in a Web page. It defines the rules that are applicable to the document. The following doctype specifies that a document should follow the XHTML 1.0 Transitional rules:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Tip
Most doctype declarations contain a URL to the definition file (.dtd file) that defines the rules for the document type. Expression Web does not read the definition file to determine the rules of the document, but your Web browser will often format the document differently if the URL is missing.
Expression Web displays the current doctype in the Status Bar, as shown in Figure 20.2.
If there is no doctype declaration in your document, Expression Web will use the schema of the document to determine whether or not code problems exist. The schema is defined in Expression Web and can target a standard (e.g., HTML 4.01 or XHTML 1.0) or a browser (e.g., Internet Explorer 3.02 or Internet Explorer 6.0).
Caution
Expression Web will not alter the code it creates based on doctype or schema settings. Specifying a doctype or setting a schema only affects the rules Expression Web uses to flag certain code as invalid or incompatible.
Needless to say, if you decide that you want to design your page to be compatible with an older schema such as the Internet Explorer 3.02 schema, you’re going to have a tough time. Much of the code Expression Web creates when you format page elements is CSS code, and older schemas will cause Expression Web to complain heavily about such code.
Another drawback to using older schemas is that Expression Web will continue to create code that uses CSS elements and other features that likely aren’t compatible with older schemas. If you insist on using older schemas, you should prepare yourself to do a fair amount of code editing and hand-coding to replace the code that Expression Web generates.
To alter the doctype and/or schema settings, select Tools, Page Editor Options, and click the Authoring tab. The doctype and schema can be set using the doctype and Secondary Schema dropdown, as shown in Figure 20.3. Note that you can also select the CSS schema in this dialog, but doing so only affects what is displayed in IntelliSense.
Note
If a doctype declaration is not added to your page even though one is selected in the Page Editor Options dialog, see “doctype Not Added to Page” in the “Troubleshooting” section of this chapter.
When Expression Web encounters invalid or incompatible code, it underlines the code in red. If you hover your mouse over the underlined code, a screen tip will inform you of the problem, as shown in Figure 20.4.
When Expression Web encounters a code error (such as mismatching tags), it highlights the offending code in yellow. Just as with underlined code, you can hover the mouse over the highlighted code for details of the problem.
Expression Web has three reporting options specifically designed to aid in locating problems with code:
Accessibility Reports—. Also called the Accessibility Checker, this report will locate any code problems affecting the accessibility of your Web site.
Compatibility Reports—. This report will analyze your Web page code and show problems with code that doesn’t comply with the standards you’ve specified.
CSS Reports—. This report will report on CSS usage and it will also show any problems with CSS code in your Web site.
Accessibility reports are covered in-depth in Chapter 19, and CSS reports are covered in-depth in Chapter 18. Therefore, we won’t go into any detail on the reports here.
To access compatibility reports, select Tools, Compatibility Reports to display the Compatibility Checker dialog, as shown in Figure 20.5. You’ll have the option of checking all pages, all open pages, selected pages, or the current page using the Check Where options. Pages can be checked against selected HTML/XHTML standards using the Check HTML/XHTML Compatibility With dropdown, and CSS code can be checked against a CSS standard specified in the Check CSS Compatibility With dropdown.
If you have a doctype declaration on your pages, you can check the Run Check Based on Doctype Declaration in Page if Available checkbox and the Compatibility Checker will check your pages based on the doctype. When you use this option, the setting in the Check HTML/XHTML Compatibility With dropdown is ignored if a doctype declaration is on your page.
It’s important to realize that checking the Run Check Based on Doctype Declaration in Page if Available checkbox does not automatically negate the setting in the Check HTML/XHTML Compatibility With dropdown. In fact, you may find yourself in a situation where you have inherited a Web site that contains some pages with a doctype declaration and some pages without one. In such cases, it’s often convenient to check against the doctype in the page when present, but check other pages against a particular standard in preparation for adding a doctype later. It’s in these types of situations that the flexibility of the Compatibility Checker is truly appreciated.
The results of the Compatibility Checker are disabled in the Compatibility pane, as shown in Figure 20.6. Each column in the Compatibility pane can be sorted by clicking on the column header. Double-clicking on an item in the list will take you to the code that is causing the problem so you can correct it. As you make corrections, you can use the buttons along the left edge of the Compatibility pane to refresh the results, rerun the compatibility reports, and navigate between compatibility errors. You can also generate an HTML report of all compatibility issues (shown in Figure 20.7) by clicking the Generate HTML Report button.
Note
If the results of the Compatibility Checker don’t match the code that Expression Web is highlighting as invalid in Code View, see “Code View Errors and Compatibility Checker Don’t Match” in the “Troubleshooting” section of this chapter.
By clicking on the small arrow at the right edge of a column in the Compatibility pane, the results can be filtered using either the dropdown menu that appears or by choosing Custom from the menu and entering filtering criteria in the Custom AutoFilter dialog, as shown in Figure 20.8. After a particular column has been filtered, the arrow at the right edge of that column will change to blue. To remove the filter you’ve applied, right-click on the column header and select Remove Filter, as shown in Figure 20.9.
I’ve selected a specific doctype in the Page Editor Options dialog, but when I check Code View, there isn’t a doctype on my page. Is this a bug?
It’s not a bug. The doctype that you select in the Doctype dropdown in the Page Editor Options dialog controls what gets added to new pages you create. It will not affect existing pages. If you want to add a doctype to an existing page, you must do it manually.
I see one problem in the Compatibility Checker, but in Code View, Expression Web is highlighting many errors that don’t show up in the Compatibility pane. What’s going on?
It’s likely that you are using a standard in the Compatibility Checker that does not match the standard chosen in the Page Editor Options dialog. You can avoid this kind of problem by always including a doctype declaration on your pages.
Web standards are like the weather in Texas—they change constantly and they rarely end up looking like anyone expects. For that reason, it’s best if you don’t rely solely on Expression Web’s compatibility features.
As standards-compliant tools become more common, it becomes more important for your Web sites to comply with standards. If you design Web sites for a living, you likely will encounter clients who will demand that their sites pass validation checkers.
There are plenty of validation tools available on the Internet. The most reliable is the W3C’s own Markup Validation Service located at http://validator.w3.org/. You can use the Markup Validation Service to validate a URL, upload a page for validation, or validate code that is pasted into a page.