Lists Home |
Date Index |
- From: firstname.lastname@example.org
- To: XMLDev list <email@example.com>
- Date: 08 Nov 99 18:00:40 -0500
Perhaps I'm coming at this from a different angle than you are, but in the current context
(Web development and standards), I must disagree with just about everything you say
> When you standardize, the benefits that you hope to achieve stem
> mainly from the network effect -- lower development costs and greater
> interoperability spring immediately to mind. These benefits are so
> powerful (and so tempting) that they often lead people to rush to
The Web is supposedly all about interoperability and platform independence. For either
of these to be possible, we have to have some way to ensure the following:
1. Web authors must be able to develop pages with some expectation that they can be
read...no matter what UA a given visitor is using. The number of UAs and platforms is
already so diverse that "test the page on everything" is impossible for the average author.
2. UA authors must be able to develop UAs with some expectation that they will
properly interpret Web pages...no matter what site a given user visits. The number of
web pages is up in the millions; "test the UA on everything" is flat-out impossible.
By setting a standard, both sides (theoretically) gain a huge advantage, and thus the third
side of the discussion - Joe Average, who uses a UA to visit pages - sees a benefit right
along with 'em. Web authors can code to the standard, UA authors can code to the
standard, and Joe Average can use a standard-compliant UA to visit standard-compliant
pages and see them at least roughly as intended. That's the goal, right?
The problem comes in when we see incomplete standards, incomplete implementations,
crude authoring hacks, and old UAs. For a prime example, take what I was working on
this weekend and some of last week. Way back in the HTML 3.0 proposal, a tag named
Q came along, to demarcate inline quotations. Q got accepted into the 3.2 spec, and
carried over into 4.0. Fine and dandy. From a rendering viewpoint, Q is extremely
simple to handle except where the CITE attribute is concerned: put quotes around the
contents, alternating as needed when one Q tag is nested inside another. Considering
how long this tag's been in the specs, this should be almost universal by now, right?
Wrong; the only currently-available browser I can find which handles Q properly is
Lynx, starting with version 2.6. Netscape and Microsoft have both utterly ignored this
part of the specs, making them noncompliant. (To be fair, the Gecko build I have
correctly handles Q - but as Gecko is still pre-alpha, I can't really count that.)
> On the other hand, standardization has many costs, of which the most
> obvious are the initial cost of implementing more than you need to
> (since standards are necessarily a superset of the needs of any
> specific set of users) and the risk of committing to an inappropriate
> solution prematurely and squashing real innovation.
And here I thought the whole reason for a standards ratification process and a
Consortium to oversee it was to address exactly those points. By the time a specification
gets to the status of a Recommendation, it has been hashed over much more thoroughly
than most federal laws; we can hardly consider this result a rash, premature conclusion.
> If a standard is successful, the network effect can more than
> compensate for the negatives, but most standards simply fail and leave
> the early implementors out of pocket. The problem is that,
> traditionally, standardization has solved existing problems: everyone
> had trains but they could not run on the same rail gauge, or there
> were many different phone companies but customers from one could not
> call customers from another another, or every public house used a
> different sized glass so it wasn't possible to compare prices.
And now, everyone has a browser but they can't view the same Web pages. To return
to that Q concern, I can solve it with some relatively easy server-side logic - but
compared to Joe Average Author, I'm the exception. Most authors don't have that tool
available, and many of those who do aren't willing to expend a great deal of effort in
tuning the code that closely. ("Serve a quotation mark entity to everybody except Lynx
and Gecko users, and serve the Q tags to everybody except old browsers - does that
work?" Yeah, that work...too *much* work.)
> Now that we're trying to standardize in *advance* of implementation,
> we run an enormous risk of messing up: our industry simply lacks any
> real, large-scale implementation experience to guide the process, so
> we're just publishing our own wild speculations and stamping them as
> W3C Recommendations or ISO standards or what-have-you.
Hey, we've seen the damage done by leaving innovation in the hands of the browser
authors - the Web still hasn't recovered from that fragmenting, and the current state of
affairs is at least partly due to people like myself crying out "Enough!"
> The solution is to standardize incrementally to minimize the risks,
> and to concentrate initially on the areas that will bring the most
> benefit for the least effort.
Keep in mind that once a UA is released, it never goes away - and people like me who
actually want to communicate instead of just writing "k00l pagezzzz" will have to keep
developing pages to accomodate it. "Fix it in the next release" may work inside a
company, but the general public is justifiably sick of it. Witness the general public's sour
reaction to Microsoft's "fix it next time out" attitude with Windows....
Rev. Robert L. Hood | http://rev-bob.gotc.com/
Get Off The Cross! | http://www.gotc.com/
Download NeoPlanet at http://www.neoplanet.com
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)