 |
 Get the SOA Development Survival Guide
Get started understanding the benefits and tools needed for service-oriented architecture development. Includes whitepapers, Webcasts, and articles.
»
IBM Rational Systems Development Solution eKit
As systems increase in complexity, communication between systems and teams becomes more and more difficult. Read the "Model Driven Systems Development" whitepaper to see how to improve product quality. Also included are more whitepapers, customer examples, tutorials, informative Webcasts, and best practices for designing, building, and managing systems.
»
Webcast: Succeed with Asset-Based Development: Introducing Rational Asset Manager
Learn how IBM Rational Asset Manager enables organizations to identify, manage and govern the design, development and consumption of software assets, including services, as part of an SOA initiative. Learn about the key challenges of asset-based development and how IBM Rational Asset Manager can help provide the solutions.
»
Download: IBM Rational Rose Technical Developer
IBM Rational Rose Technical Developer is a robust Model-Driven Development (MDD) solution, expressly created to meet the challenges of complex systems development. Based on UML, Rational Rose Technical Developer provides a highly-automated and reliable solution to the unique problems of concurrency and distribution.
»
|
 |
|
|
|
|
|
HTML Standards Compliance - Why Bother ?
|
Most pages on the web don't comply with the W3C's HTML
specifications. In some cases this is because their authors
wanted to take advantage of proprietary extensions; but in
many other cases, the pages could easily have been made more
conformant without any problem. This article explains what the
issues are, and why you should and how you can, bring your
pages into compliance with the HTML standards.
|
The fundamental reason for HTML standards compliance
is to ensure that you use only those elements and structures that are
likely to be understood by the widest range of user agents.
It's like English - if I were to speak my parent's dialect
(East Anglian) most other English speakers would not understand
everything I say. Similarly, if you use proprietary dialects of HTML,
some user agents won't understand everything you write. There is
however, a
standard
for HTML which the browser makers say they
support, and
validation
points out the divergences in your HTML source.
By adhering to the standards you maximise the accessibility of your work
to the widest range of user agents, and therefore, users.
Some people take the view that checking their pages in the two major
browsers is validation enough. Close, but no cigar.. There are still
dialect variants even within a single make of browser, across the
different versions and platforms - let alone between the two. And why
neglect all the other user agents such as text-mode browsers, text to
speech synthesizers, search engine spiders and other robots, site
analysis tools, etc? Perhaps, because it's too much extra work? Maybe,
but most of the compliance errors I've seen are trivial to fix, e.g.
missing ALT attributes (not tags!) in IMG tags. Others might be harder
to understand and fix but practice overcomes this, and in the end your
"inner satisfaction" is in knowing that you've done a good professional
job that can be appreciated by all.
Sites often use a "browser sniffer" to detect which browser you're
using, and then serve you a page specifically optimized for your
browser. As the
WaSP says in their
mission statement
"Creating multiple versions of the same Web page because of
incompatibilities among browsers is wasteful and self-defeating
for Web developers and their clients. The alternative is to try to
resolve the incompatibilities by often complicated workarounds that
are costly for developers and their clients - at the cost of preventing
Web pages from being flexible enough to be used by emerging
television-based and PDA-based browsers."
HTML standards are designed to remain as backward-compatible as
possible while also attempting to be as forward-compatible as possible.
In particular, they are designed so that older conformant pages are not
too likely to break on newer browsers, and future conformant pages will
"gracefully degrade" on older browsers. Choosing to adhere to any
proprietary format, or none in particular, is very likely to cause a
site to look worse under older browsers, or future browsers, than if
the standards were followed. According to
W3C's
HTML 4.0
"Most people agree that HTML documents should work well across
different browsers and platforms. Achieving interoperability lowers
costs to content providers since they must develop only one version of a
document. If the effort is not made, there is much greater risk that the
Web will devolve into a proprietary world of incompatible formats,
ultimately reducing the Web's commercial potential for all participants.
Each version of HTML has attempted to reflect greater consensus among
industry players so that the investment made by content providers will
not be wasted and that their documents will not become unreadable in a
short period of time.
HTML has been developed with the vision that all manner of devices
should be able to use information on the Web: PCs with graphics displays
of varying resolution and color depths, cellular telephones, hand held
devices, devices for speech for output and input, computers with high or
low bandwidth, and so on."
The solution is for developers to adhere to the HTML standards, and for
the browser makers to support them fully before adding their
innovations. Let's examine the issues in a little more depth:-
- BroWWWsers
- Be Careful What You Wish For..
- HTML Checkers and Validators
BroWWWsers
"Standards":
At some point W3C apparently decided to relinquish any claims to be a
standards body, and to leave that function to other organisations such as
ISO. See for example
Information Technology -- Document Description and
Processing Languages -- HyperText Markup Language (HTML).
The issue is also a matter of semantics as well as history. If there is no
specification that can be strictly defined as an HTML 'standard' after v
2.0, there is nevertheless a strong need for some reference point more
up-to-date (with current practice) than v 2.0; and so common usage treats
the HTML 4.0 Recommendation as the ad-hoc standard until ISO or some other
acknowledged standards body rubber-stamps it..
|
