Thông tin tài liệu
P1: FCH WY021-05 WY021-Holzshlag-v2 May 25, 2004 16:9 ࡗ 112 Part I: Tools, Planning, and Content ࡗ ࡗࡗ ࡗ Open-source based CMS software. The open-source community has a number of CMS solutions that are very good and far less costly than proprietary packages. However, as with almost all open-source software requiring server-side attention, the installation and implementation is best left to those experienced with open-source languages and methods. ࡗ CMS application service provider. In this case, instead of installing the CMS on your server, a provider offers the technology for you. Your job is to configure templates and permissions, allowing various individuals access to those content areas they will be managing. CMS provision of this nature can be a reasonable choice for many situations because of the low overhead, lower cost, and usually excellent support that goes with the service. ࡗ Custom CMS development. A good programmer can create a CMS from scratch or customize one from any number of open-source options for less money. The disadvantage of rolling your own CMS is that it takes a lot of time, and you will need to take into account that ongoing support will likely be required. Along with major CMS applications and services are smaller content-related tools that have emerged for the purposes of Weblogging. In the case of smaller sites, some of these tools—such as Movable Type—are excellent choices for content management. Tools of this nature are highly customizable (they are often open- source) and tend to be very affordable. Before jumping into a CMS, make sure you have a detailed process to evaluate the short- and long-term content requirements of a given project, submit a reasonable budget, and study the available options and how they might best serve you or your client needs. note To learn about open-source CMS, see www.cmsinfo.org. The site keeps details about a wide range of open-source CMS projects. For a complete guide to CMS news, analyses, reports, and other helpful information to assist you in making choices regarding content management, see CMS Watch at www.cmswatch.com/. Summary You should now have a very good idea of what challenges working with content on the Web can bring. Be confident that with good resources and a sensible ap- proach to the creation and management of content, you won’t have much trouble improving and streamlining the content aspect of your work. At this point in the book, you’vecome through the organization and strategy aspects of site development and design. Now it’s on to markup and style! The upcoming part contains chapters covering HTML, XHTML, CSS, and accessibility. P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 Part II HTML, XHTML, CSS, and Accessibility Chapter 6: Crafting Pages with HTML Chapter 7: Moving Ahead with XHTML Chapter 8: Style Tips for Type and Design Chapter 9: Laying Out Pages with CSS Chapter 10: Adding Accessibility Features 113 P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 114 P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 Chapter 6 Crafting Pages with HTML ࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗ Secrets in This Chapter #81: Create a Markup Style and Stick to It 118 #82: Understand Document Types and Language Versions 119 #83: Use DOCTYPEs 122 #84: HTML is Root 123 #85: Use <head> and <body> Appropriately 124 #86: Always Use <title> 125 #87: Manage Character Sets 125 #88: Author Documents Structurally 127 #89: Use Lists to Enhance Structure and Readability 128 #90: <em> and <strong> versus <i> and <b> 130 #91: Know your Document Tree 131 #92: Elements, Tags, and Attributes 133 #93: Intrinsic Events 134 #94: Special Characters 135 #95: Limit Color Names to Standard Colors 136 #96: Avoid the font Element 136 #97: Avoid the center Element 138 #98: Avoid All Deprecated, Obsolete, and Proprietary Elements and Attributes 138 #99: Use Elements as They Were Intended 139 #100: Restrict Use of Tables 140 #101: Restrict Use of Frames 141 #102: Validate, Validate, Validate! 141 ࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗࡗ P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 ࡗ 116 Part II: HTML, XHTML, CSS, and Accessibility ࡗ ࡗࡗ J ust the other day I was reading someone’s Weblog and he was thanking a pal for helping him unravel the “tangle” of the Hypertext Markup Language (HTML) tags that he’d gotten wrapped up in. He’d been using a visual editor to build his site. Not being very familiar with markup, he had the good sense to get someone to help him who was, or he wouldn’t have reached his goal of having a working Weblog for himself. What interested me about this fellow’s comment was how he viewed HTML—a tangle. HTML is a primary slice in the Web site creation pie. Is HTML Easy? The fact is that HTML is pretty easy to play around with and get some results from without having much experience with it. That’s not so much due to HTML itself. Rather, Web browsers are incredibly forgiving when it comes to errors in HTML. If they weren’t, the Web would never have become so thriving and multifaceted. As a result, people tend to think HTML is easy and don’t dig deeper into its features, nuances, rules, and limitations. HTML is a Markup Language HTML is not programming per se; some will argue it isn’t even code. What HTML is at core is a system of tags that are interpreted by a user agent such as a Web browser, a browser in a hand-held device such as a PDA, or an assistive device. A user agent’s job is to interpret and then render the language of the document being requested. note User agents can be as complex as the most contemporary Web browser created for today’s commercial computers, or as simple as required by wireless, Web-enabled devices such as mobile phones and pagers. As with any language, HTML has grammar. There are rules of structure and se- mantics. HTML has a distinct vocabulary, and complicated specifications define the many aspects of HTML as a formal language. But browser competition has often led to the emergence of elements and features related to a given browser. Some of these elements have in fact been introduced into the specifications (which are the documents that define “Web Standards”) and have been integrated into the language, but some have not been adopted. All working Web professionals should have some awareness of HTML as it is spec- ified rather than as most of us learned it—by viewing source, asking a colleague, and employing hacks and workarounds to get the various desired results. Face the Changes The by-our-bootstraps days of learning markup are gone. Awareness among the professional community has grown strong, in no small part due to the work of The Web Standards Project (WaSP), a grass-roots organization dedicated to promoting Web standards and resources for Web professionals. Figure 6-1 shows the WaSP site. note For news, resources, and reference materials about Web standards, visit the WaSP Web site at www.webstandards.org/. P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 ࡗ ࡗࡗࡗ Chapter 6: Crafting Pages with HTML 117 Figure 6-1: WaSP is a grass-roots volunteer organization advocating the use of Web standards. In addition, we now have very good CSS support in all modern browsers. This means we can clean up the hacks we used to lay out pages visually, remove extra- neous tags from our HTML, and write cleaner, clearer, more structured and less confusing documents, making HTML a lot easier to use—even for complex needs. What’s more, many product vendors, especially Macromedia, are becoming more interested in making sure their products allow users to create and maintain valid pages, which helps us all in the long run. So, if you’re still building your sites with nested tables, graphic shims, and sliced graphics, the time has definitely come to begin exploring the more sophisticated options available to you. Even if you are unable to drop those conventional prac- tices for contemporary, specification-driven ones, you can become more aware of the language requirements of an HTML document, how to keep it as structured as possible to assist with accessibility and portability across browsers and platforms, and how to write a conforming document even if you’re using practices that are being shelved in favor of more effective options. Document Conformance Document conformance in Web markup means that each page of HTML (or XHTML) you author conforms to the official W3C specification to which it is written. Author to the Specification This means each of your HTML pages will have markup within them that is part of this conformance. In the case of HTML, the language type you use is found within a DOCTYPE, a declaration at the top of the HTML document that declares what kind of document it is and which version of HTML the DOCTYPE in question P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 ࡗ 118 Part II: HTML, XHTML, CSS, and Accessibility ࡗ ࡗࡗ is referring to. You’ll learn about language versions shortly, but keep in mind that along with a DOCTYPE, you must make sure that all the tags and attributes you use are allowed within the language version that you are declaring. Validate the Document Conformance is checked by the process of validation, which is covered later in this chapter. Validation is the comparison of your document with the language you declared in your DOCTYPE, just to see if you’ve made any errors. Validators return a list of errors, which you can then correct. Once you validate the document without any errors whatsoever, it is considered a conforming document, which is also referred to as a compliant document. Conforming documents are easier to work with, particularly when more than one document author is involved, and the process of validation is an excellent means of not only eliminating errors, but also of learning more about the languages with which you are working as a result. ࡗࡗࡗ Secret #81: Create a Markup Style and Stick to It One of the biggest headaches in managing the code side of Web design is the variations that exist in how markup is formatted. I don’t mean how it will look on display, but how the code itself is formatted behind the scenes. Readers authoring their documents by hand have often developed their own formatting practices (see Figure 6-2 for an example), such as indenting tables and lists, by placing elements in uppercase and attributes in lowercase, and not quoting attributes. Add to this Figure 6-2: A look at my personal formatting habits within my favorite editor, Homesite. P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 ࡗ ࡗࡗࡗ Chapter 6: Crafting Pages with HTML 119 the discrepancies in Web publishing software (refer to Figure 6-3), and what you have is a big mess. Figure 6-3: Here’s an example of formatting in Dreamweaver MX 2004. Imagine working in a group environment where files are modified and updated by numerous content and document authors. If there is no consistency in the style of markup, chaos not only can, but most likely will, ensue. Even if you’re working on your own, disparities in how you format your HTML within the page can affect you. For example, perhaps you’dlike to perform a search and replace on a large number of documents, but the formatting is vastly different from one document to the other. Most software won’t recognize something that is formatted dramatically differently than the piece of markup you might be searching for, making the time required to fix or update those 100 pages far greater. So whether you’re working on a team or by yourself, making some decisions about how to properly format your markup can help save hours of frustration for all. Table 6-1 offers some ideas for better success with formatting HTML. ࡗࡗࡗ Secret #82: Understand Document Types and Language Versions Not all markup was created equally. When Tim Berners-Lee and his colleagues were cooking up the Web in their particle physics lab at The European Organi- zation for Nuclear Research (CERN) in Switzerland, the need for a very simple markup language for formatting text on-screen with the ability to have hyperlinks became obvious. P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 ࡗ 120 Part II: HTML, XHTML, CSS, and Accessibility ࡗ ࡗࡗ Table 6-1: HTML Formatting Strategies Action Benefit Example Indenting Table Cells For streamlined tables, some indentation is helpful when working with nested portions of the table. This provides white space and allows the person working on the markup to quickly find specific data or problems within the code itself <table> <tr> <td>content here</td> <tr> </table> Indenting List Items and Nested Lists As with nested table cells, indenting nested lists can be very helpful in troubleshooting and more effectively finding content that requires repair <ul> <li></li> <ul> <li></li> </ul> <li></li> <li></li> </ul> Managing Case HTML is not case sensitive. Prior to XHTML (See Chapter 7, “Moving Ahead with XHTML”), case in HTML was irrelevant, so you’d often get a total mishmash of case styles—even within the same document. XHTML is case sensitive, and I recommend all authors use lowercase at this time, even if they’re working in HTML. If an upgrade to XHTML is ever in the future of those documents, the process will be far easier and less time-consuming as a result In HTML you can have a variety of cases: <HTML LANG="EN"> <html lang="en"> <HTML lang="EN"> <HtMl LaNg="eN"> <htML laNG="eN"> All of these mean the same thing. When you advance to XHTML it changes. As a result, contemporary authoring is best kept to lowercase: <html lang="en"> For more information on case in XHTML, see Chapter 7 Managing Quotes The concerns regarding quotes around attribute values in HTML are similar to those for case. HTML is far less strict than XHTML in terms of quoting rules. While you can never go wrong in HTML quoting an attribute value, you can go wrong not quoting it. So, quote all attributes, even in HTML where the rules about quotes are fairly arbitrary In HTML, you could correctly write the following: <body bgcolor=black background="blackdot .gif"> It will likely work in the vast majority of browsers. However, think about the error margin that emerges here. You could add a start quote but forget the ending quote. A mistake of that nature can leave you in troubleshooting hell for hours. By quoting all attribute values, you reduce or even eliminate this kind of problem P1: FMK WY021-06 WY021-Holzshlag-v2 May 25, 2004 16:20 ࡗ ࡗࡗࡗ Chapter 6: Crafting Pages with HTML 121 Action Benefit Example Using Comments Comments are a gift from the programming forefathers and we should take care to use them effectively. Properly commenting particular areas within a document means you, or your colleagues, can find that area more quickly. You can also provide information about the content, directions to other authors or content specialists, and hide information from a browser that might be needed sometime in the future Add comments to the beginning of a section: <! begin meta data > As directions: <! content authors begin adding content here > To hide information for later use: <! <h2>Holiday Specials!</h2> > One important note here is to use comments but to do so where most needed. Over-commenting a site can be just as troublesome as having no comments available at all HTML in its infancy included very simple markup—at the time Berners-Lee was adding the spices to his stew, the Web did not serve up a graphical user inter- face (GUI). Therefore, the primary markings needed were related to simple struc- tural elements such as headings, paragraphs, line breaks, lists, and horizontal rules. Of course, the Web shot out of the hands of CERN researchers faster than you could say “it’s soup!” and suddenly the Web was everywhere. GUI interfaces began to emerge (Mosaic being the first in widespread use), and with a graphical means of displaying pages, new features were desired. Over the next few years, chaos ensued, and HTML became so mixed up that sites using no formal HTML are referred to as being written in “tag soup.” This became extremely problematic, as there was no consistency in workflow, browser support, and developer tools support. note The W3C creates specifications for three primary audiences: browser developers, Web developers, and software developers creating programs for Web design and development. To address the changing needs, the W3C broke HTML 4.0 up into three distinct types. Each of these varieties is governed by a separate Document Type Definition (DTD). A DTD is the list of elements, attributes, characters, colors, and related requirements for a given language, or in this case, language variety. The three DTDs for HTML 4 are as follows: ࡗ Strict. Strict versions of HTML call for a separation of structure and presentation. Few presentational attributes or elements are available in this version, such as font tags, alignment attributes, and so on. The idea is that strict versions are to be used with CSS. Strict DTDs do not allow for anything that is considered obsolete (no longer in use) or deprecated (still in use but moved aside to make way for a better method) in the language to be used. [...]... correct DOCTYPEs Chapter 6: Crafting Pages with HTML ࡗࡗࡗ ࡗ 123 Table 6-2: DOCTYPEs in HTML 4. 01 DTD DOCTYPE Strict Transitional Frameset ... declared in the document using a DOCTYPE declaration, which, as mentioned earlier, describes the language, version, and language type Using a DOCTYPE is required to have a document that conforms DOCTYPEs are placed at the very top of a document, above the opening tag Consider the following snippet, which is a DOCTYPE declaration for HTML 4. 01 Strict: ࡗࡗࡗ Chapter 6: Crafting Pages with HTML Creating a Conforming HTML Document Creating a Conforming HTML Document < /html> Save this listing to your local computer for use as a basic template for almost all HTML authoring . <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4. 01//EN” “www.w3.org/TR /html4 /strict.dtd”> Transitional <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4. 01 Transitional//EN” “www.w3.org/TR /html4 /loose.dtd”> Frameset. proper DOCTYPE declaration and the root element with its opening and closing tags. Listing 6-1: Building a document tree with a DOCTYPE and html as root <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML. <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4. 01 Frameset//EN” “www.w3.org/TR /html4 /frameset.dtd”> cross ref For more information about DOCTYPE switching, see Chapter 7. ࡗࡗࡗ Secret # 84: HTML
Ngày đăng: 14/08/2014, 11:21
Xem thêm: 250 html and web design secrets phần 4 doc, 250 html and web design secrets phần 4 doc
