OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   re: Re: XHTML 1.0 returned to HTML WG

[ Lists Home | Date Index | Thread Index ]
  • From: rev-bob@gotc.com
  • To: "xml" <xml-dev@ic.ac.uk>
  • Date: 04 Nov 99 05:32:37 -0500

> > Depends on what you mean by that; I see the dangerous potential there
> > of descending into the same morass we currently have with HTML, where
> > we theoretically go by the DTD,
> 
> I never thought that HTML <!DOCTYPE ...> declarations were ever
> usable for any purpose other than content providers to validate, in
> order to work on more browsers.  How could they be?  I think that
> HotJava once tried to validate -- and gave up quickly because so
> many sites _only_ produce illegal HTML.

Conversely, I always found !DOCTYPE-based validation to be useless in the context of 
making pages work on more browsers.  Sometimes, you have to know when to go 
outside of the spec - especially when you consider all the browser-specific junk 
introduced in the 2.x/3.x browsers, the backstepping done between HTML 3.2 and 4.0 
regarding presentation tags, etc.  It's all well and good to say "use CSS for presentation" 
in theory, but the reality is that there are still a lot of old browsers out there that don't 
know CSS from CQD.  (Last time I checked, my XML pages checked out as XHTML 
compliant and my HTML pages *almost* check out.  There's one element on every 
HTML page that isn't spec-legal, and it's there for old browser support.  C'est la vie.)

That's why I'm looking forward to widespread adoption of an XML/XHTML spec - it's 
a fresh start.  No browser that is XHTML-compliant should require "old browser tricks" 
- it's a new platform, and because time has gone by, the bottom level of that platform 
can be a great deal higher than the bottom level of the HTML platform.  This is a good 
thing.  With HTML, you have to use tables for some types of layout, because they work 
on a wide variety of browsers.  Yes, CSS is a better option in theory, but the real 
installed UA base doesn't support it.  It's starting to, but it ain't there yet.  With 
X(HT)ML, you know that any browser capable of parsing the pages can handle CSS - 
so you don't have to use the workarounds.  However (to return to the original point), if 
some tangible form of control doesn't exist on what tags are accepted and how DTD 
interaction works, it won't be long before we're back at the drawing board, wondering 
where we went wrong.

It's the difference between theory and reality.  If the theory of XML and its X-siblings 
can be realized, the reality of instant support for new specs just might be in our grasp.  
That's one hell of a big IF, though.

> >	 but in actuality, it's anybody's guess what browserisms a random
> > user agent will support.  Witness the spotty support CSS1 and CSS2 have,
> > not to mention HTML4 itself.
> 
> Namespaces are for distinguishing an XHTML "table" from furniture, not
> for nuancing IE4/Mac table browserisms (bugs) from NN4.61/Linux ones.

You miss my point; I was contrasting the theory of a valid HTML DTD which should 
work on any HTML browser with the reality of incomplete support and assorted 
browserisms.  I was not by any stretch trying to equate namespaces with browserisms.

> > why should we expect that the UAs we will have for XML will do any better?
> 
> Better in what respect -- being less buggy?  Two things come to mind:

Better in terms of support.  Better meaning "if the spec defines it, the UA will understand 
it".  Better meaning that the developer can actually go by the spec, instead of having to 
keep an armada of browsers on hand to ensure that everything works as it should.  
Better meaning that the theory of the spec actually aligns somewhat with the reality of 
the UAs.  Clear enough?

>   -  One is that so many developers understand the damage that comes from
>      HTML standards being so thoroughly ignored ... which wasn't widely
>      understood as the damage was being created.  XML has "draconian"
>      error handling (no display if it's not well formed!), which is a
>      big step forward (though it only goes so far).

That's something I really like about XML - although, as noted, it only goes so far.

>      This means that users are already demanding (and getting) better
>      standards conformance.  It doesn't come easy to many vendors since
>      an "Open" playing field doesn't provide customer lockin.

Translation: "Netscape and Microsoft like to add their own proprietary tags."  Perhaps 
with the advent of XML, they'll realize that the better path to dominance is in enhancing 
the usability features that Joe Average actually notices, instead of trying to fragment the 
Web by bribing developers into using proprietary tags.

Take a look at the NeoPlanet browser for a minute.  It's a shell.  By using the IE libraries 
to do the rendering work, they're free to concentrate on the interface - *and it works*.  
If their Gecko plugin was more stable (which I blame on the alpha status of the Gecko 
code), I'd make NeoPlanet my default browser in an instant - because I can switch 
rendering engines without losing user interface features, mailboxes, or anything else.  
One user, one shell, multiple engines - that's what I call customer lockin.  At least, for 
this customer....

>   -  Another is that now we're seeing more alternatives, including some
>      significant Open Source componentry (not just Mozilla).

Hey, as long as I can get data on more UAs, more power to 'em.  The only reason I 
don't provide more granular support now is that I just don't have the data.  ("How's that 
look on Opera?"  "I dunno.  I don't get many Opera hits, so the registration cost isn't 
worth it.  I'll treat it as base-level and see what happens.")

>      This means that vendors in the XML space won't be able to get away
>      with as much.  (Watch out for the tactics some will take to cope...
>      some bits of XML will get needlessly complex, as entry barriers for
>      the newer vendors and perhaps as homes for more "browserisms".)

Some bits of anything will always be needlessly complex.  That's part of what makes it 
fun, sometimes.  :)

> Surely there are other reasons, too -- like not giving in to despair!  ;-)

As those of you who've visited my site probably know by now, I don't give in to despair; 
I retrofit it as rage and use it as fuel.  (And I know some of you have been by; I saw the 
spike in the logs.  For those using Netscape who had problems Wednesday, the stray 
greater-than symbol has been eradicated and the pages work again.)



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


*---------------------------------------------------------*
       E-Mail Delivery By VEI Internet Mail Services
   http://www.veiinternet.com - $14.95 Unlimited Internet

       Visit The New VEI Stores Open For Christmas:
       VEI DVD Store - http://vei.vstoredvds.com/
       VEI Book Store - http://veibooks.vstorebooks.com/
*---------------------------------------------------------*

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS