Subject: RE: [xsl] Mozilla 1.0 rc2 Problems From: "Brinkman, Theodore" <Theodore.Brinkman@xxxxxxxxxxxxxxxxxxxx> Date: Mon, 20 May 2002 12:50:58 -0400 |
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@xxxxxxxxxxx] Sent: Monday, May 20, 2002 12:06 PM To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: [xsl] Mozilla 1.0 rc2 Problems ----- Original Message ----- From: "Brinkman, Theodore" <Theodore.Brinkman@xxxxxxxxxxxxxxxxxxxx> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Mozilla 1.0 rc2 Problems, Michael Beddow | Thread | [xsl] new to XSl/variable usage, Rajesh . Jayabalan |
[xsl] [ANN] Ipedo Web Express 3.0, Chris Parkerson | Date | RE: [xsl] Second try: Search and re, Stuart Celarier |
Month |