This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Mozilla 1.0 rc2 Problems


I'd be more inclined to think that insisting that a file is type 'x' when
the server says it is type 'y' is more picky.

If you're talking about font encoding schemes (UTF-8 vs. iso-whatever vs.
???), then we're not talking about mime-types.  There the problem is that
most servers aren't configured to send different headers in that regard at
all, because most servers deal with only one encoding.  No amount of
assuming a file is a certain type based on it's extension will ever fix
that.

IE may currently have a better encoding-guessing algorithm than Mozilla, but
I've had better luck with getting the correct characters displayed on
foreign sites with Moz than with IE.  It may just be that I visit different
sites than you.  (That's not to say I can actually *read* the site when it
is displayed in Japanese, but that's my fault not the browser's.)

However, that has nothing to do with a site sending me file.doc (mime-type:
text/xml) and having IE try to open it in MS Word because on my system the
.doc extension is registered as being a Word file.  (God forbid it should
ever mean anything different.)  I've run into more applications than I care
to count that save text configuration or export files as filename.pdf.  The
Adobe PDF format specifies a leading series of bytes to identify the file
type, so why does IE insist on sending filename.pdf (without those leading
bytes) to Acrobat Reader when the server said it was 'ContentType:
text/text'?

	- Theo

-----Original Message-----
From: Michael Beddow [mailto:mbnospam@mbeddow.net]
Sent: Monday, May 20, 2002 12:06 PM
To: xsl-list@lists.mulberrytech.com
Subject: Re: [xsl] Mozilla 1.0 rc2 Problems


----- Original Message -----
From: "Brinkman, Theodore" <Theodore.Brinkman@standardregister.com>
Sent: Monday, May 20, 2002 2:51 PM
Subject: RE: [xsl] Mozilla 1.0 rc2 Problems


> Technically, Moz isn't any pickier about mime-types than IE.  It simply
> listens to what the server says the mime-type is (like it *should*)

[...]

Er, that's what I take picky to mean. Unless the server Does the Right
Thing, Moz won't play. Correctly and justificably picky, maybe, but picky
all the same. The real-world problem here is getting server admins to fix
their mime-types, especially for xslt. People who can't change their host
server, or get its admin to see sense, have a problem. IE's undoubtably
problematic reliance on the extension means that the site author can solve,
or at least mask, the problem without sysadmin intervention and so get the
pages rendered client side.

There's a similar pragmatic issue in IE's much-maligned encoding-detection
heuristics. Sure, a browser ought to trust the encoding declared in the
server header and or the meta-tag (as again, Moz correctly does) but it's a
depressing fact that a number of, e.g. Russian or Japanese sites declare the
wrong encoding in their pages (especially when they offer parallel pages in
different encodings). Result: Moz with all the right attitudes, shows
garbage until the savvy user intervenes, IE, by arguably dubious means,
shows what the site authors intended straight off. HTML is an incurably
messy area.

Michael
---------------------------------------------------------
Michael Beddow   http://www.mbeddow.net/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]