January 01, 2002
URL:http://drdobbs.com/xhtml-in-the-real-world-part-ii/184412351

In last week's excerpt, I examined how HTML's original logic had been stretched and pummeled into something far, far from a markup language. In our efforts to build an innovative and exciting visual Web, we've turned it into a de-facto language of design.

This week, I delve a bit deeper into the challenges, and offer up some simple yet strong suggestions as to how we can all approach markup more effectively.

Difficulties Across Platforms and Browsers

So, the demand for better visual sites altered HTML as a language. And, as a result, the bane of the Web designer's existence has become trying to figure out ways to make HTML work as a tool of design across platforms.

What we create for the Windows environment is always going to be somewhat different from what is created for the Mac environment, or Linux environment, and so on.

Platform-wise, there is little we can control as designers because hardware and software issues influence the way that user agent software—in most instances the Web browser—read our documents.

But to make our sites as cross-platform, cross-browser compliant, we have to work extra hard. Imagine if browser developers adhered to certain standards with the way they wrote their software and the way that software in turn displayed our code? Our lives would be made much more simple. But browser developers have had their own agenda, and it's done very little to help us. As a result, Web designers in contemporary times typically have to:

• Test their work on numerous platforms.
• Test their work in numerous browsers types.
• Use legacy as well as current browsers in testing.
• Rely on authoritative charts and materials to compare and contrast what works and what doesn't work in a given platform/browser environment.
• Learn stress management techniques to cope with the extra long hours spent trying to make a great design be interoperable.

My bottom line here is that it's simply not enough to make the author completely responsible for code compliance! Browser manufacturers have as much—if not more—responsibility when it comes to both the messes of the past and the fixes of the future.

(Note: A coalition of Web developers and Web users make up the Web Standards Project, which exists to call browser developers on the floor and demand they pay attention to standards. You can visit the Web Standards Project at www.webstandards.org.

Poor Habits Extending to Software

One of the most frustrating issues surrounding HTML is how the bad habits and non-standard methods of its evolutionary being have traveled into HTML editors. This is especially disconcerting in today's Web production environment, where many authors and designers are being asked to use specific editors (especially visual editors) to do a job. And, given the wealth of collaborative tools and production environments that exist in visual editors, it makes sense in many cases to do this.

It becomes imperative that people understand the limitations of the software products being used. What's more, knowing the standard methods of code can totally empower you as an individual to troubleshoot problem code, refine code and reduce code overhead, and bring generated code up to standards.

Some of the major concerns in primary visual editors that I'm concerned about are defined in the table below.

In Figure 1 I created a very simple design and then laid it out using each of these programs: The first shows my results in Adobe GoLive; the second shows it in Macromedia Dreamweaver; and the third in Microsoft FrontPage.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.