Use Dreamweaver 8 to get "web standards"

Dreamweaver|web|web Standard

　　A total of 8 articles in this series, starting with the popular web standards, describes how to build a compliant web with Dreamweaver 8来, as the original author of this article is on the Build Your OWN standards compliant Website Using Dreamweaver 8 (This article is a charge), so I made a proper deletion of the content, the order is consistent with the original text, but the length will be adjusted, hereby inform. The level of translation is limited, please understand.

If you are reading this article, you are likely to have some interest in Web standards and are curious about the application of standards in sites built with DW (Dreamweaver).

You may have some knowledge of WS (WEB standards abbreviation), but you don't know how to write compatible code with DW. Or you're a DW user, you want to comply with WS, use CSS more extensively, and you can make more approachable documents. Regardless of your type, this article will give you the answer you want: tell you how to use DW to handle WS.

　　Definition of WEB standards

For the WS we care about throughout this article, let's take a moment to make clear what we're talking about:

WS is a specification that guides the Web development language and is developed by the consortium. These specifications include a variety of languages, such as HTML, XHTML, and CSS, as well as other relevant languages, such as MathML, used to represent equations in mathematics that might be useful when you have this particular need. The consortium has also issued a "Web content Affinity Guide" (Web contents Accessibility GUIDELINES--WCAG)--Promoting accessibility of Web pages (via WAI)

　　Hint: get these specifications directly

You can read these specifications on the website of the world's Web site, although they are sometimes difficult to read:

　　HTML 4.01

　　XHTML 1.0

　　CSS 1

　　CSS 2.1

　　WCAG 1.0

In this article, we will use the XHTML1.0, CSS1 and 2.1, WCAG 1.0, and other specifications and recommendations, but you must be pleased to know that we do not have to read too much of the document.

　　Who needs WS?

You may have only one vague concept: WS is a good thing, but many sites-including many well-known sites-do not comply with WS, and they do seem to manage well. So why do we try to comply with WS? Does this have any real benefit? Who needs WS? Who needs to pay attention to the norms and recommendations of the consortium?

　　Web Developers and designers

The first category of people who need to focus on WS is us: Web site developers and designers. Is it worthwhile for us to spend time learning how to use WS development?

Neat tags make bugs faster to fix.

If you validate your pages through the Web, at least you will learn that nonstandard markup is not the cause of the errors you've encountered. Sometimes, verifying a page and fixing a process that has found errors can clear the display of problems that are caused by the absence of a tag (element) or by a tag (tag) spelling error.

Even if validating your document does not fix these problems, at least you will know that these problems exist in the canonical document. Now that you know the problem is not a mistake, you can start to focus on other issues, such as CSS handling differences in different browsers.

The need to comply with accessibility is easy

If you write a canonical XHTML tag, you can guarantee that the document is semantically correct, and you can separate the content from the presentation, and you'll be able to put a lot of work on the accessibility issues listed in many WCAG1.0. It is also important to recognize that accessibility is not only designed for people with disabilities. A good affinity site can be accessed by many different devices, such as mobile phones and PDAs, who do not have the power to deal with scattered, non-standard tags.

Forward compatible

If you only consider the performance of your newly developed pages in the current few browsers, how can you guarantee that it will behave in a new browser in the future? The new browser may make your page look bad, and you'll have to struggle to find and fix those annoying problems.

Compliance with WS does not completely eradicate the problem; However, standard compatibility reduces the risk of your design failure, and today's browser software companies are also starting to support standards. They may have accidentally explained some of the specifications, and they cannot support it at all. If the worst happens and a new browser has a strange effect on your standardized web site, it's much easier to fix it than to fix an incompatible site. If you encounter a problem, it will also affect other standard compatible sites. Community intelligence in the Web communities will point this out and write articles to solve the problem. So, collectively, it's easier to fix the BUG in a compatible document than to fix it in an incompatible document.

More Convenient refactoring

Have you ever had to detach text from a site and refactor it? And everything has to start from scratch. Have you ever seen labels that are cluttered with font tags and tiny table cells that make us start from scratch? I only know I've seen it, it's a long process, and a lot of time and money have been burned down by the reconfiguration of this site.

Separating the content and performance of the document will make you realize the beauty of standardized compatibility: This means that the next time someone wants to refactor the site, they don't have to take a copy out of the Web document. The text in all the sites will be marked with semantic (X) HTML, and all the performance information-which the webmaster wants to change-will be stored in an easily replaceable CSS file.

Some customers will not wait for it to be refactored until they start asking you to make some changes, and they'll just wait until the mammoth fossil pit is over and ask you to say, "Move the left column to the right." "For a standardized, compatible site, all pages are controlled by CSS, and you can easily move the markup in the page without having to think in many pages that are structured in a complex form." This makes it easier to change the layout of the page.

The separation of structures from performance can also make it easier to add new elements, like a high contrast, small-picture version of a site that may be more appealing to some visitors. When you can easily change the style sheet, why create a separate plain text version of the page?

　　Browser software company

The software company of the browser began to focus on WS. In the past, browser software companies added proprietary tags and attributes to their basic language. But now, as never before, they've all started to conform to standards, and some of the newest browsers are already certain that they're trying to display them in accordance with the (X) HTML and CSS defined in the specification.

In the foreseeable future, browsers will be able to display most of the nonstandard tags, code, because if they do not, thousands of irregular sites will not be able to display the normal-then the public will probably start to blame the browser, rather than blaming the Web designer. However, other devices (those that do not have the power to handle the desktop) will be more reliant on the standardized compatibility of the code they are experiencing.

　　Authoring Tools Software Vendors

Authoring Tool software Vendors--Macromedia, for example--made dreamweaver--and, like web designers, started to comply with WS, for example, as more and more of their customers demanded that these authoring tools be able to output spec tags. These visual development environments do not have a good reputation because they generate confusing, non-standard markup; however, the latest major visual development environments cite standardized compatibility and accessibility elements, which have become a major selling point. Software vendors must listen and respond to market demands.

　　Web User

The users of our web site also benefit from our adoption of WS, even if they don't realize it! Perhaps they are unconsciously using sites developed specifically for today's popular browsers. If these users switch to other browsers, they may find that the online experience is no longer enjoyable, as the proprietary tags are not accepted by the new browser. A standardized and compatible site is well represented in different browsers, both in the existing and in the future browsers alike.

In addition, a site that complies with accessibility recommendations is also an affinity for those who find it undesirable to browse the Web. The WEB should provide more convenient shopping, reading, and search conditions for those with visual impairment or other disabilities. They should not be able to browse because of a site with proprietary tags or other exclusive (browser) technologies.

Using the WS

How can we make sure that WS is used properly? How do we comply with standards?

First, we should follow the rules. This means that we should use only the elements and attributes defined in those specifications, avoiding the proprietary properties of a browser, such as IE's marquee tag and Netscape's Blink label. Also, do not use elements that appear in the earlier specification (such as HTML3.2) and elements that are removed by subsequent specifications.

To create a canonical XHTML document

In this article, we will use XHTML, so we will all follow the recommendations of the XHTML 1.0 of the Consortium [the recommendation (recommendation) is what the specification (specification) means] according to the consortium. XHTML is basically the latest version of HTML, designed to replace HTML as a markup language. Although it is an HTML variant of XML, XHTML is almost exactly the same as HTML, and there are subtle differences in the XHTML and semantics that we'll discuss later.

You can generate an XHTML document (File > New ...) by creating a new Document dialog box in Dreamweaver. Make sure that the base page is selected in the Category list, and then select HTML from the list of basic pages, as shown in Figure 2.1, "Creating a new XHTML document in Dreamweaver." You can then select any item from the Drop-down list of the document type.

Figure 2.1: Creating a new XHTML document in Dreamweaver

Figure 2.2: Displaying the new XHTML document in the Code view

Click "Create" to generate a new document. By clicking the Code button at the top of the document window and going to Code view, you can see exactly what code is included in a simple XHTML document. As shown in Figure 2.2, "display the new XHTML document in Code View"

The first row of the document shows the following

　　<! DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 transitional//en" "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd ">

This is called a document type declaration, or DOCTYPE. As the name suggests, DOCTYPE declares what your document is--which (X) HTML specification you are complying with. In this example, we followed the XHTML 1.0 transitional, which is the default setting for DW 8. The transitional section will tell us some additional information about the XHTML version. XHTML1.0 has three "flavors": Strict, Transitional, and Frameset. DW uses the transitional type by default, and if you want to insert a frame into a document, that's Frameset.

The XHTML Strict is the strictest XHTML format, which presumably you can guess. A Strict document type looks like this:

"Http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" >

If you are using Strict DOCTYPE, you cannot use any of the elements (tags) or attributes that are declared disapproved of in your document, nor can you use frames. Elements that declare disapproval will be removed in a future XHTML version. Many of these elements are used to control the appearance of the page, which can be completely replaced by CSS. The biggest difference between Strict and transitional is that when you use Strict DOCTYPE, the attributes and elements that you think can be used as performance are greatly limited.

Note: Use Strict DOCTYPE in the DW

DW is not very strict in complying with standards. If you use Strict DOCTYPE, pay special attention to verifying your document and correcting the nonstandard attributes. Basically, it's easy to replace them with CSS.

Frameset DOCTYPE supports the use of the framework, which is automatically used by DW if you insert a frame into the document. The frames page is at least as good as the other two pages, and there is no limit to the document type of the related pages. The code for Frameset DOCTYPE is as follows:

"Http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd" >

HTML 4.01 also provides the three "flavors" of document types--transitional, Strict and frameset--their operations are exactly the same as the XHTML Doctypes mentioned above. If you use any of these types, you must specify them in HTML (not XHTML) documents. We'll delve into the differences between HTML and XHTML in the sections that follow to create the site.

Original:Dreamweaver 8 does standards! by Rachel Andrew

Compiling:x5