Well, OK. I mean, technically, that's correct. Uhm... but, right, we know that in the real world things aren't always exactly to spec, like "http://bla.com/bla"; gets mapped to "http://bla.com/bla/"; (server fails the first time, then inserts the trailing slash) -- so, could there be some (hidden? in the user.js file or whatetever) pref to have Camino basically treat all text as HTML? Or at least, before concluding that it's *not* to be rendered, to do one more check and see if the content begins with "<html>"?
I mean, I consider Safari's behavior here to be (or, to me, feel) "right", from my perspective as the user (not the coder, who is, I think we can agree, technically, 'wrong' here -- but why should I suffer because of his/her little mistake?), and Camino's to feel "wrong" (even though it's following the letter of the law, exactly). I can always view source, to see what the source is, of something that's been rendered as HTML. But I can't do the opposite, and force Camino to view that 'text/plain' as if it were 'text/html' -- or can I? (is there a way?) That's my argument. In a case like this, I think it would be preferrable to have Camino do the user friendly thing, and basically, see that, OK, it's a plain text file, but let's do one more check, and - aha! there's a "<html>" beginning the file, so, OK, let's display it as HTML because that's what it was obviously intended to be. It's little nit-picky geeky stickler-for-the-rules letter-of-the-law not spirit-of-the-law things that, in this instance, define the difference between user-friendly (in this case, Safari), and user-not-friendly (in this case, Camino). Dumb. Stupid. Small. But, yet another little thing that piles up, combined with other little things. Let's *at least* make this a user-overridable behavior, or, preferrably, make the default behavior be, that it does one more check, and overrides based on actual content. Stepping back and looking at the larger scheme of things, if this is a Gecko thing, well. Then, I'd argue that here's a diff between "user friendly" and "standards compliant", i.e. a case where the *way* in which the standard is applied in the real world, is crucial, to realizing the intent. And one in which, we're doing it in the wrong way. Can Camino override this? Is there a mechanism, a pref in Gecko, that Camino can specify? Or has this never come up, was this flexibility never architected in? Enquiring minds want to know... > Aux environs du 30/11/03 � 15:37 -0800, sous le titre "[Camino] > Problem w/ ASP pages?", Ed Mechem prit sa plus belle plume pour > �crire les mots suivants: >>Camino fails to parse & display the HTML - it's basically just displaying >>source. (It renders fine in Safari, and I don't ever remember .asp >>pages having >>problems in Camino before). Quitting/restarting Camino doesn't fix >>the problem. >> >>Is anyone else seeing this behavior? > > The server says the page is text/plain, not text/html. So it's normal > that Camino displays it as text. > > GET /default.asp HTTP/1.1 > Host: jetsetrecords.com > > HTTP/1.1 200 OK > Date: Sun, 30 Nov 2003 23:46:55 GMT > Server: Apache/1.3.27 (Unix) mod_tsunami/2.0 mod_log_bytes/0.3 > FrontPage/5.0.2.2510 PHP/4.3.2 mod_ssl/2.8.14 OpenSSL/0.9.7b > Transfer-Encoding: chunked > Content-Type: text/plain > > [snip] > > Paul > -- > Philosophie de baignoire - consultations sur rendez-vous. > > NPDS/NewtonOS: http://newton.kallisys.net:8080/ > Apache/FreeBSD: http://www.kallisys.com/ > _______________________________________________ > Camino mailing list > [EMAIL PROTECTED] > http://mozdev.org/mailman/listinfo/camino -- Ed Mechem < mailto:[EMAIL PROTECTED] > _______________________________________________ Camino mailing list [EMAIL PROTECTED] http://mozdev.org/mailman/listinfo/camino
