Oh good heavens, Trevor. And you let me think you were a total newbie.
Yes, web development is a whole 'nuther ball of wax. HTML in itself is
incredibly complex, due to the history of it, and the HTTP transport
protocol. It started out simple, but not very strict, or very extensible. It
was an extension of SGML (Standard Graphic Markup Language). It was designed
originally to present pure text documents in a formatted manner, not a very
ambitious goal. It became popular in a very short time. And before you know
it, everyone wanted it to do more. So, people started extending it. And it
swiftly grew into a mangled, tangled mess of complex rules that were
followed to a different extent in one way or another by different browser
manufacturers.
Standards organizations like the W3C quickly attempted to gain control of
the situation and provide some kind of order that people could count on. But
HTML was fatally flawed from the start. After all, it was designed as a
markup language for *static* documents, and now people wanted it to do every
conceivable sort of computer trick available. As various software vendors
and the W3C worked together, and came up with ways of satisfying the public
appetite, the situation became both better and worse. JavaScript was added
to the mix fairly early on, but it depended on the Document Object Model,
which, while established fairly early on, was constantly being upgraded and
modified. We are now working with HTML 4.01.
Cascading Style Sheets (CSS) was an attempt to at least separate some of the
ever-expanding set of attributes and properties into some extensible set of
features that could be separated from the HTML markup, making it easier to
work with, extend, and modify. CSS is much more extensible than HTML. It
also provides the ability to apply layout and behavior styles across an
entire web site with a single set of code.
But it was the development of XML that will prove to be the ultimate
solution to the problem. After all, the "X" in XML stands for "eXtensible."
A new extension of SGML, XML is simple, but it is strict. While a <br> tag
if just as good as the more correct <br/> tag in HTML, it won't fly with
XML. The trade-off is in the simplicity of the rules. XML has very few,
perhaps a page or 2, whereas the rules for HTML have grown to the size of a
proverbial "Library of Congress." But while HTML is lax, complex, and
difficult to extend, XML is strict, simple, and easily extensible.
Let's say that someone wanted to add a new layout item to the HTML
specification. How about, for example, a slider control element? Well,
there's no <slider> tag in the HTML specification, and if a browser saw one,
it wouldn't know what to do with it. It would require an endless procession
of meetings, debates, RFCs, and various kinds of disputes about the nature
of the <slider> element before the W3C would incorporate it, and years
before all the browser manufacturers got around to accomodating it. Even
longer before they all treated it in the same way.
But with XML, a <slider> element doesn't have to be adopted, discussed, or
accomodated. There is no <slider> element in XML. There is no element of any
kind in XML, other than a root element, and a few others. Instead, there is
a DTD (Document Type Defintion) file (also XML) that describes it. Create an
XML element, define it in a DTD. Tell the client where to find the DTD. End
of story.
And XML can be much more than just markup. It is infinitely extensible, due
to its nature and design. As of this writing, I can think of a half-dozen
uses for it without even thinking too hard. It is in use now to store and
transmit data, at least dozens of different document types other then HTML,
to manipulate data, for cross-network programming (via SOAP, for example),
and is the UI code for the next generation of Windows (XAML).
Oh yes. And for the next generation of HTML, which is XHTML. No doubt, by
now you can see the possibilities of that.
If you ever decide to get into server-based web applications (ASP, ASP.Net,
etc), be ready for another set of issues. HTTP is stateless. State and
Session management in a server-based HTTP web application has presented
complexity for the developer since its inception with CGI. How *do* you
maintain state is a stateless environment? How do you keep track of which
client is which? How do you manage memory on the server? Now combine these
issues with the issues of HTML and browser compatibility, and you find
yourself never wanting to write another HTTP network application again, just
nice, relatively simple desktop apps and services. I know I do! But that's
not the future of things. And the future is where its at these days.
Let us know when you get some more pics up on the site! Australia has always
been one of my dream vacations, along with New Zealand and Hawaii. At least
I can look at the pictures for now!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
