Re: .html and nothing else

On 02.10.00 at 07:56, Shane P. McCarron <shane@aptest.com> wrote:

>Well - you can take me out and execute me if you want.

I think I'll visciously and with extreme prejudice *not* buy you a beer the
next time I'm in your neck of the woods! :-)


NOTE: "Taking the [vendor|standards body|developer|program|etc.] out
       back and executing [him|her|it]" is used as a technical term.
       No grievous bodily harm intended. :-)


>It was mostly my idea.

I _will_ curse you to the ninth generation every time I have to deal with
XHTML 1.x though! :-(


>XHTML 1.0 is a transitional standard.  It permits people to author in
>XML and be backward compatible.

Sure, but then it prevents them from being forwards compatible. The proper
way to handle this would have been to explicitly label XHTML as a XML
document type and then let WebMonkey and it's ilk suggest ways to fool
browsers into thinking it's SGML (e.g. using text/html). By specifying
text/html as the only Content-Type for XHTML -- explictly deprecating the
*/xml types -- you've made XHTML worse then worthless (IMO, of course!).

XHTML as text/html is a hack to fool SGML-based agents into accepting it.
It should *never* have made it into the specifications document -- not even
as a footnote -- and making it the only sanctioned content type is outright
destructive. If you'd specified text/xml (or whatever), the next rev of the
browsers would have added default mappings to take care of the problem.
Instead you've crippled implementations for the forseeable future.


That XHTML 1.0 is mostly worthless anyway is completely different matter.


>Without that, no one would use XHTML because there are no browsers that
>can interpret text/xml correctly (there weren't then, there aren't now).

And so we've yet again let implementation deficiencies dictate standards.
Why was it so important to have people author in XHTML when no browser
supported it yet? Why couldn't you have made a technically sound standard
and let the vendors worry about when to implement it? AFAICT, XHTML 1.0
offers no significant benefits over HTML 4.0, but it provides plenty of
hassles for authors, not to mention user agent implementors.

By the time XHTML 2.0 is out, you'll have had to add a FONT element to the
base language because vendors don't want to tell their users they have to
actually do some work themselves to implement one. To be "backwards
compatible" with XHTML 1.x. Not to mention the fact that you'd still need
to take 1.x into account so you'll never have a clean XML implementation,
but rather need to make allowances for the kinda-XML-but-really-SGML that
is XHTML 1.x.


>XHTML 1.1 also does not address this issue.  XHTML 2.0 is the
>specification that is targeted to finish the transition.  We hope that
>by that time browsers will actually know how to deal with text/xml,

They probably would if you'd given them any kind of incentive to do so.
There is none right now because the old cruddy HTML engines deal well
enough with XHTML-nee-HTML. When we get to XHTML 2.0, there will be three
types of documents supported by browsers: HTML, XHTML, and some limited
form of XML. Then we get to start all over again complaining about bugs in
the XML implementations and lacks of features; while authors everywhere use
HTML or XHTML to create visually stunning and completely unstructured
documents. Thanks a lot! :-(




-- 
Editor's note: in the last update, we noted that Larry Wall would "vomment"
on existing RFCs. Some took that to be a cross between "vomit" and "comment."
We are unsure of whether it was a subconscious slip or a typographical error.
We are also unsure of whether or not to regret the error.

Received on Monday, 2 October 2000 10:25:56 UTC