Features in IE7

[Philipp Lenssen]

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

--
Google Blogoscoped
http://blog.outer-court.com

[Kris]

In article <2j*************@uni-berlin.de>,
"Philipp Lenssen" <in**@outer-court.com> wrote:

I mean what more do we want but W3C standards etc.?

Security.

--
Kris
<kr*******@xs4all.netherlands> (nl)

[Brian]

Philipp Lenssen wrote:

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

HTTP standards. And default ("out of the box") accept headers that are
reasonable. At minimum, the content accept header should include
"text/html," no? And language accept headers should be more liberal. "Be
liberal in what you send" and all. But I don't know if this is relevant
for the IE7 project.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[David Dorward]

Kris wrote:

I mean what more do we want but W3C standards etc.?

Security.

Coffee making facilities

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Rijk van Geijtenbeek]

On Wed, 23 Jun 2004 19:45:56 GMT, Brian
<us*****@julietremblay.com.invalid> wrote:

Philipp Lenssen wrote:

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>
"If you have to ask..."
I mean what more do we want but W3C standards etc.?

HTTP standards.

There is an interesting item on this page, relating to the coming SP2 for
Windows XP:

http://msdn.microsoft.com/asp.net/us...p2websites.asp

<quote 1>
Q: Does your Web site contain files with file types that do not match
their Content-Type and/or file extension?

A: You should correct all of these mismatches. Both the Content-Type and
the file extension must match the type of the file for a download prompt
to appear. Be sure this is true for your Web pages as well. If the
Content-Type is plain/text, then they will not render as HTML.
</quote 1>

Never mind that it usually is text/plain of course :)

<quote 2>
General Tips
Make sure your Web site's Content-Type matches the file extension.

Exception: This change does not affect cases where a
"content-disposition=attachment" header is sent. In those cases, the file
name or extension suggested by the server is considered final and is not
changed based on Multipurpose Internet Mail Extensions (MIME) sniffing.
</quote 2>

--
Rijk van Geijtenbeek

The Web is a procrastination apparatus:
It can absorb as much time as is required to ensure that you
won't get any real work done. - J.Nielsen

[Brian]

Rijk van Geijtenbeek wrote:

http://msdn.microsoft.com/asp.net/us...p2websites.asp

<quote 1>
Both the Content-Type and the file extension must match the type of
the file for a download prompt to appear.
This is, of course, in definitive violation of the standard. File
extension is unrelated to the mime type of a web resource.
If the Content-Type is plain/text, then they will not render as
HTML.
</quote 1>

Never mind that it usually is text/plain of course :)
That too! It makes me wonder, do they have any technically competent
person to edit their faqs? "text/plain" is just plain embarassing.
<quote 2>
General Tips
Make sure your Web site's Content-Type matches the file extension.

The only sense I can make of this is server side -- the file extension
must trigger a content-type for the server to send. But the msdn page is
about the client ua, so, once again, any talk of file extension is silly
(uri's have no file extension), and in violation of the spec. I suppose
I should be happy to see any improvement in this area, but I'm not. The
answer is simple and clear; if MS does not implement it, I can only
assume they have goals other than building a web that works for everyone.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Peter Jenkins]

"Philipp Lenssen" <in**@outer-court.com> wrote in message

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>
I asked for W3C standard adherence - and GET RID OF THAT ACTIVEX SHITE!
Regards
Peter J

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

--
Google Blogoscoped
http://blog.outer-court.com

[Philipp Lenssen]

Peter Jenkins wrote:

"Philipp Lenssen" <in**@outer-court.com> wrote in message

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...nternetExplore
rFea tureRequests>

I asked for W3C standard adherence - and GET RID OF THAT ACTIVEX
SHITE! Regards
Peter J

That's still in. My text got removed. I put it back in.

"W3C compliancy wherever you go. CSS2, MIME types (including correctly
rendering XHTML content types, and not offering XHTML for download as
IE6 does at times). SVG built-in as an option. Full PNG support.

Additionally, it would be nice if a small frowning icon would show up
whenever the page does not validate according to a strict doctype --
hey, just make it an option until IE8.

Anyway, CSS compliancy is the biggest problem with IE6, so fix that
before all other things. Especially the lack of working selector syntax
needs a heavy update.

And some sort of RSS support would be nice as well. Just the chance to
have RSS feeds be added to some sort of RSS reader coming with IE7."

--
Google Blogoscoped
http://blog.outer-court.com

[DU]

Philipp Lenssen wrote:

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

Besides W3C standards and compliance, you ask?

- popup blocking
- tab browsing
- better cookie management
- better download manager
- full and entire veto power for the user over toolbars, chrome of
secondary windows and move, resize method calls; also all secondary
windows should be resizable at all times, without any setting or user
pref to check
- a feature which will report back to the user if a page uses valid
code, has markup and/or CSS errors: some sort of a Webpage Quality
indicator icon (smiley for valid page, frown when invalid) on the
statusbar (or somewhere else) which when click can report more info to
the user and give him more options among which one would be to validate
the page with the W3C validator.
W3C HTML 4.01 specs recommend browsers to notify users about
markup/syntax errors in pages:
"We also recommend that user agents provide support for notifying the
user of
such errors."
http://www.w3.org/TR/html401/appendix/notes.html#h-B.1
- drop entirely support for "javascript:" pseudo-protocol links
- redo entirely the javascript debugger
- implement a system, a structure by which people could report MSIE
browser bugs so that the product could be improved on a continous basis:
Microsoft shouldn't be working on the product intermittently, every 3 years

DU

[Philipp Lenssen]

DU wrote:

- drop entirely support for "javascript:" pseudo-protocol links

Agreed to you other points, but could you explain this one?
I suppose you want to disallow
<a href="javascript:bla()">Bla</a>

--
Google Blogoscoped
http://blog.outer-court.com

[Shawn K. Quinn]

DU wrote:

- full and entire veto power for the user over toolbars, chrome of
secondary windows and move, resize method calls; also all secondary
windows should be resizable at all times, without any setting or user
pref to check
I agree with this, though some of it could be made possible via something
like Privoxy.

Until I realized Konqueror's crashing was caused by it, I used to "x out"
the nonstandard chrome properties in libkhtml.so with every reinstall of
Konqueror. Somehow the script now changes the size of the file by one byte
where it did not before.
- drop entirely support for "javascript:" pseudo-protocol links
Agreed, I'm surprised anything else actually supports these turdlets.
- implement a system, a structure by which people could report MSIE
browser bugs so that the product could be improved on a continous basis:
Microsoft shouldn't be working on the product intermittently, every 3
years

This has to come along with a willingness by Microsoft to improve and
maintain their IE product on a continuous basis, and that only comes when
another browser effectively competes with Microsoft's offering.

Another one, assuming this excuse for a browser will be with us much longer:

- the ability to override idiotic font-size properties specified in px, pt,
in, or cm units. (Even assuming px units are actually implemented as per
the CSS standard and not just taken to mean "one screen pixel, period")

--
Shawn K. Quinn

[Philipp Lenssen]

Shawn K. Quinn wrote:

- the ability to override idiotic font-size properties specified in
px, pt, in, or cm units. (Even assuming px units are actually
implemented as per the CSS standard and not just taken to mean "one
screen pixel, period")

As you may know you can already override font-sizes in IExplorer.
However that will get rid of all font-sizing, not just idiotic ones.

--
Google Blogoscoped
http://blog.outer-court.com

[Andrew Urquhart]

*Philipp Lenssen* wrote:

*DU* wrote:

- drop entirely support for "javascript:" pseudo-protocol links

Agreed to you other points, but could you explain this one?
I suppose you want to disallow
<a href="javascript:bla()">Bla</a>

http://jibbering.com/faq/#FAQ4_24
--
Andrew Urquhart
- FAQ: www.htmlhelp.org/faq/html/
- Archive: www.tinyurl.com/2zw7m (Google Groups)
- My reply address is invalid, use: www.andrewu.co.uk/contact/

[Harlan Messinger]

"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:2j*************@uni-berlin.de...

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

Ability to specify independently the default font to use for serif,
sans-serif, and monospace.

[Harlan Messinger]

"Andrew Urquhart" <us**************************@spam.invalid> wrote in
message news:kIUCc.23$wk3.20@newsfe6-win...

*Philipp Lenssen* wrote:

*DU* wrote:

- drop entirely support for "javascript:" pseudo-protocol links

Agreed to you other points, but could you explain this one?
I suppose you want to disallow
<a href="javascript:bla()">Bla</a>

http://jibbering.com/faq/#FAQ4_24

What is the meaning of the sentence, "It was designed to be a method that a
javascript function could return the new page e.g. javascript:"<p>Hello</p>"
"?

[C A Upsdell]

"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:2k*************@uni-berlin.de...

"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:2j*************@uni-berlin.de...

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

To use the Gecko engine, and to help fund Mozilla.org?

[Andrew Urquhart]

*Harlan Messinger* wrote:

"Andrew Urquhart" <us**************************@spam.invalid> wrote in
message news:kIUCc.23$wk3.20@newsfe6-win...

*Philipp Lenssen* wrote:

*DU* wrote:
- drop entirely support for "javascript:" pseudo-protocol links

Agreed to you other points, but could you explain this one?
I suppose you want to disallow
<a href="javascript:bla()">Bla</a>

http://jibbering.com/faq/#FAQ4_24

What is the meaning of the sentence, "It was designed to be a method
that a javascript function could return the new page e.g.
javascript:"<p>Hello</p>" "?

I've not seen a specification, but the 'javascript:' pseudo-protocol
AFAIK was designed to return a document. It's universally abused for
such things as 'javascript:DoSomething()' where function DoSomething()
usually modifies the presentation of the current document through DHTML
effects or fires a pop-up window. However, there are a few problems with
this:

1. Since the browser expects a new document as a result of using the
pseudo protocol, once triggered the browser usually cancels further
processing of the current page and prepares for the new document. This
is why some browsers appear to stall or stop loading images and other
external objects when such a pseudo-protocol link is activated, the
browser is waiting for a new document it never gets. It's a problem
regularly queried in news:comp.lang.javascript

2. Attributes such as 'onclick' and 'onkeypress' etc. exist for the
purpose of invoking script methods such as DoSomething() - that's what
they're designed for and they are superior to the pseudo-protocol. When
such attributes are used then those browsers that don't support
javascript, or have it disabled, can simply decline to process those
attributes. However, when the pseudo protocol is used, non-javascript
aware browsers are then forced to deal with ordinary hyperlinks that
aren't real links and which don't 'do anything' in those browsers. Such
pseudo-protocol hyperlinks become an obstacle to navigation - this is
particularly important to users with special needs and special needs
software and/or legacy systems. So, to use the pseudo protocol with its
ability to cause browsing problems when there are properly designed
alternatives that don't cause such problems is rather thoughtless. This
is particularly evident when the page author prevents people from
viewing a page via a normal hyperlink because he or she demands that the
user view the new page in a new window (a window usually permanently
restricted in size, without the familiar browser controls to go forward,
back, stop or print and has the problem of breaking up the flow of
browsing). By using the pseudo-protocol for a pop-up only those users
with javascript can get access to the page.
--
Andrew Urquhart
- FAQ: www.htmlhelp.org/faq/html/
- Archive: www.tinyurl.com/2zw7m (Google Groups)
- My reply address is invalid, use: www.andrewu.co.uk/contact/

[Harlan Messinger]

"Andrew Urquhart" <us**************************@spam.invalid> wrote in
message news:5eZCc.24$kf2.22@newsfe3-gui...

*Harlan Messinger* wrote:

"Andrew Urquhart" <us**************************@spam.invalid> wrote in
message news:kIUCc.23$wk3.20@newsfe6-win...

*Philipp Lenssen* wrote:
*DU* wrote:
> - drop entirely support for "javascript:" pseudo-protocol links

Agreed to you other points, but could you explain this one?
I suppose you want to disallow
<a href="javascript:bla()">Bla</a>

http://jibbering.com/faq/#FAQ4_24
What is the meaning of the sentence, "It was designed to be a method
that a javascript function could return the new page e.g.
javascript:"<p>Hello</p>" "?

I've not seen a specification, but the 'javascript:' pseudo-protocol
AFAIK was designed to return a document.

How would it do that? By "return" do you mean 'request"? What does

href="javascript:\"<p>Hello</p>\""

mean, and does that have anything to do with returning a document?
It's universally abused for
such things as 'javascript:DoSomething()' where function DoSomething()
usually modifies the presentation of the current document through DHTML
effects or fires a pop-up window. However, there are a few problems with
this:

1. Since the browser expects a new document as a result of using the
pseudo protocol, once triggered the browser usually cancels further
processing of the current page and prepares for the new document. This
is why some browsers appear to stall or stop loading images and other
external objects when such a pseudo-protocol link is activated, the
browser is waiting for a new document it never gets. It's a problem
regularly queried in news:comp.lang.javascript

2. Attributes such as 'onclick' and 'onkeypress' etc. exist for the
purpose of invoking script methods such as DoSomething() - that's what
they're designed for and they are superior to the pseudo-protocol. When
such attributes are used then those browsers that don't support
javascript, or have it disabled, can simply decline to process those
attributes. However, when the pseudo protocol is used, non-javascript
aware browsers are then forced to deal with ordinary hyperlinks that
aren't real links and which don't 'do anything' in those browsers. Such
pseudo-protocol hyperlinks become an obstacle to navigation - this is
particularly important to users with special needs and special needs
software and/or legacy systems. So, to use the pseudo protocol with its
ability to cause browsing problems when there are properly designed
alternatives that don't cause such problems is rather thoughtless. This
is particularly evident when the page author prevents people from
viewing a page via a normal hyperlink because he or she demands that the
user view the new page in a new window (a window usually permanently
restricted in size, without the familiar browser controls to go forward,
back, stop or print and has the problem of breaking up the flow of
browsing). By using the pseudo-protocol for a pop-up only those users
with javascript can get access to the page.
--
Andrew Urquhart
- FAQ: www.htmlhelp.org/faq/html/
- Archive: www.tinyurl.com/2zw7m (Google Groups)
- My reply address is invalid, use: www.andrewu.co.uk/contact/

[Andrew Urquhart]

*Harlan Messinger* wrote:

*Andrew Urquhart* wrote:

*Harlan Messinger* wrote:

*Andrew Urquhart* wrote:
http://jibbering.com/faq/#FAQ4_24

What is the meaning of the sentence, "It was designed to be a method
that a javascript function could return the new page e.g.
javascript:"<p>Hello</p>" "?

I've not seen a specification, but the 'javascript:' pseudo-protocol
AFAIK was designed to return a document.

How would it do that? By "return" do you mean 'request"? What does

href="javascript:\"<p>Hello</p>\""

mean, and does that have anything to do with returning a document?

'Replace' is more accurate. The current document would be replaced in
its entirety by the result of the pseudo-protocol execution. Here's an
example:

....
<script type="text/javascript">
function DoSomething() {
var objDoc = new Array();
var i = 0;

objDoc[i++] = "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0
Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">";
objDoc[i++] = "<html xmlns=\"http://www.w3.org/1999/xhtml\"
xml:lang=\"en\" lang=\"en\" dir=\"ltr\">";
objDoc[i++] = "<head>";
objDoc[i++] = "<title>Pseudo Protocol Example</title>";
objDoc[i++] = "</head>"
objDoc[i++] = "<body>";
objDoc[i++] = "<h1>Pseudo Protocol Example</h1>";
objDoc[i++] = "<p>This content has replaced the original document
tree</p>";
objDoc[i++] = "</body>";
objDoc[i++] = "</html>";
return objDoc.join("\r\n");
}
</script>
<div>
<a href="javascript:DoSomething();">Test</a>
</div>
....
--
Andrew Urquhart
- FAQ: www.htmlhelp.org/faq/html/
- Archive: www.tinyurl.com/2zw7m (Google Groups)
- My reply address is invalid, use: www.andrewu.co.uk/contact/

[Jim Ley]

On Thu, 24 Jun 2004 00:30:48 GMT, Brian
<us*****@julietremblay.com.invalid> wrote:

Rijk van Geijtenbeek wrote:

http://msdn.microsoft.com/asp.net/us...p2websites.asp

<quote 1>
Both the Content-Type and the file extension must match the type of
the file for a download prompt to appear.

This is, of course, in definitive violation of the standard. File
extension is unrelated to the mime type of a web resource.

This is great news, Mozilla FireFox decides to break their MIME
handling to make it non-conformant, and IE then changes to be
conformant, making Mozilla look very silly IMO.

Hopefully the Mozilla folk will start following the standard too, if
IE can, Mozilla must be able to surely.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[DU]

Philipp Lenssen wrote:

DU wrote:

- drop entirely support for "javascript:" pseudo-protocol links

Agreed to you other points, but could you explain this one?
I suppose you want to disallow
<a href="javascript:bla()">Bla</a>

Good question.

1- "(...)Links that don't behave as expected undermine users'
understanding of their own system. A link should be a simple hypertext
reference that replaces the current page with new content. Users hate
unwarranted pop-up windows. When they want the destination to appear in
a new page, they can use their browser's "open in new window" command --
assuming, of course, that the **_ link is not a piece of code that
interferes with the browser’s standard behavior._**
Users deserve to control their own destiny. Computers that behave
consistently empower people by letting them use their own tools and
wield them accurately."
Top Ten Web-Design Mistakes of 2002
6. JavaScript in Links
http://www.useit.com/alertbox/20021223.html

2- Here's the results I get while testing "javascript:" pseudo-protocol
links with Mozilla:

http://bugzilla.mozilla.org/attachme...49&action=view

What you don't see is that the context menu Link property info is always
wrong in Mozilla. Everything, except a left mouse button click on
"javascript: pseudo-protocol links", fails in Mozilla (and in other
browsers as well). "javascript:" pseudo-protocol links fails in text
browsers, fails in js support disabled browsers, fails as it mislead
browsers, fails as it confuses users, etc.

3- http://www.panix.com/~aahz/javascript.html#remove

4- http://jibbering.com/faq/#FAQ4_24

5- "javascript:" pseudo-protocol links also defeats numerous DOM methods
based scripts as the href value is not relying on a valid scheme to
begin with.

DU

[DU]

Shawn K. Quinn wrote:

DU wrote:

- full and entire veto power for the user over toolbars, chrome of
secondary windows and move, resize method calls; also all secondary
windows should be resizable at all times, without any setting or user
pref to check

I agree with this, though some of it could be made possible via something
like Privoxy.

proxomitron also does that. But why not embed good sense into the
browser. Opera 7.x is the only browser which will always , per default,
ignore "resizable=no" in the 3rd argument of window.open() calls. I filed

Bug 177838: Make all popup windows resizable, ignoring resizable=no
http://bugzilla.mozilla.org/show_bug.cgi?id=177838

at bugzilla on this and overall I got support but there is another bug

Bug 101509: Pref to disable resizable=no
http://bugzilla.mozilla.org/show_bug.cgi?id=101509

which makes it an user pref (based on UI setting) rather.

Note that even Microsoft knows very well that granting more power to
scripters and web authors in these areas is often, very often
counter-usability and anti-accessibility and stupidly irritating.
"
'Earlier versions of Internet Explorer ignored the resizable=no feature
and allowed you to resize the new window.'
http://support.microsoft.com/default...b;en-us;211068

So, MSIE 5.01 and previous were always ignoring resizable=no.
"

Until I realized Konqueror's crashing was caused by it, I used to "x out"
the nonstandard chrome properties in libkhtml.so with every reinstall of
Konqueror. Somehow the script now changes the size of the file by one byte
where it did not before.

- drop entirely support for "javascript:" pseudo-protocol links

Agreed, I'm surprised anything else actually supports these turdlets.

- implement a system, a structure by which people could report MSIE
browser bugs so that the product could be improved on a continous basis:
Microsoft shouldn't be working on the product intermittently, every 3
years

This has to come along with a willingness by Microsoft to improve and
maintain their IE product on a continuous basis, and that only comes when
another browser effectively competes with Microsoft's offering.

Another one, assuming this excuse for a browser will be with us much longer:

- the ability to override idiotic font-size properties specified in px, pt,
in, or cm units. (Even assuming px units are actually implemented as per
the CSS standard and not just taken to mean "one screen pixel, period")

Agreed. In the webpage about submitting suggestions, enhancement
requests, features, ideas, I wrote this:

"5- Make text size scalable, even if the web author chose absolute
length units instead of relative units for CSS font-size. This is a
well-known accessibility burden for MSIE and its users."

I like very much Mozilla's feature which set a floor, minimum value for
font-size and this floor value will override whatever css font-size
author declarations.

DU

[DU]

Philipp Lenssen wrote:

Shawn K. Quinn wrote:

- the ability to override idiotic font-size properties specified in
px, pt, in, or cm units. (Even assuming px units are actually
implemented as per the CSS standard and not just taken to mean "one
screen pixel, period")

As you may know you can already override font-sizes in IExplorer.
However that will get rid of all font-sizing, not just idiotic ones.

You can if you use an user stylesheet. You can not otherwise increase
font size if the author chose absolute font units.
W3C Quality Assurance tip for Webmasters:
Care With Font Size: Recommended practices
http://www.w3.org/QA/Tips/font-size#goodpractice

"Here are a few basic rules that one should follow in order to create
Web pages that are easy (enough) to read, using CSS's font properties.

* Do not specify the font-size in pt, or other absolute length
units. They render inconsistently across platforms and can't be resized
by the User Agent (e.g browser).
"

DU

[BC]

"C A Upsdell" <cupsdell0311XXX@-@[e-mail]> wrote in message news:<n6*****************@news01.bloor.is.net.cabl e.rogers.com>...

"Harlan Messinger" <h.*********@comcast.net> wrote in message
news:2k*************@uni-berlin.de...

"Philipp Lenssen" <in**@outer-court.com> wrote in message
news:2j*************@uni-berlin.de...

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

To use the Gecko engine, and to help fund Mozilla.org?

Some way to completely remove it. 'Nuff said.

-BC

[Daniel R. Tobias]

"Andrew Urquhart" <us**************************@spam.invalid> wrote in message news:<gj*************@newsfe2-gui.server.ntli.net>...

'Replace' is more accurate. The current document would be replaced in
its entirety by the result of the pseudo-protocol execution. Here's an
example:

...
<a href="javascript:DoSomething();">Test</a>
...

I just tried that example code (including all the function code that I
snipped here for brevity) in Mozilla, and it did nothing. I don't
think there's any way to get the "javascript:" pseudoprotocol to
return a new page as you claim was its original intention.

--
Dan

[Jim Ley]

On 26 Jun 2004 13:44:18 -0700, da*@tobias.name (Daniel R. Tobias)
wrote:

"Andrew Urquhart" <us**************************@spam.invalid> wrote in message news:<gj*************@newsfe2-gui.server.ntli.net>...

'Replace' is more accurate. The current document would be replaced in
its entirety by the result of the pseudo-protocol execution. Here's an
example:

...
<a href="javascript:DoSomething();">Test</a>
...

I just tried that example code (including all the function code that I
snipped here for brevity) in Mozilla, and it did nothing. I don't
think there's any way to get the "javascript:" pseudoprotocol to
return a new page as you claim was its original intention.

included at (with fixed linebreaking)

http://jibbering.com/2004/6/javascript.html

and it works for me everywhere similarly.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Brian]

Jim Ley wrote:

Mozilla FireFox decides to break their MIME handling to make it
non-conformant,
And Opera, as configured "out of the box." Though, in both cases, I
think it may only break MIME handling for text/css.
and IE then changes to be conformant, making Mozilla look very
silly IMO.
Not yet. Did you misunderstand the thread? This is a wish list, not a
list of features that already exist.
Hopefully the Mozilla folk will start following the standard too,
That'd be nice.
if IE can,
It hasn't yet shown it can. But then you knew that, didn't you?
Mozilla must be able to surely.

They did it once, they can do it again.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Jim Ley]

On Sun, 27 Jun 2004 01:31:23 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

And Opera, as configured "out of the box." Though, in both cases, I
think it may only break MIME handling for text/css.

text/plain too.

and IE then changes to be conformant, making Mozilla look very
silly IMO.

Not yet. Did you misunderstand the thread? This is a wish list, not a
list of features that already exist.

No correct mime handling is in Windows XP SP2 as the cited urls above,
this is distinct from any IE7 wish lists.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Alan J. Flavell]

On Sun, 27 Jun 2004, Jim Ley wrote:

No [,] correct mime handling is in Windows XP SP2
Well, it comes with a long-winded description. It's a move in the
right general direction, but I'm not convinced that what's described
there is fully compatible with RFC2616.

The description seems hopelessly muddled about the distinction between
the open interworking protocols (HTTP, MIME etc.) and the internal
workings of Windows (filename extensions, Windows shell associations,
ProgIDs etc.).
as the cited urls above,

http://www.microsoft.com/technet/pro...on133121120120
says:

Web developers must change their Web servers to host files, using
^^^^
consistent headers and file name extensions.
^^^^^^^^^^^^^^^^^^^^

But HTTP is completely agnostic about "file name extensions": they
play no direct part in the HTTP transaction. So this seem to be yet
another attempt to impose a proprietary flavour of web, even if the
parts which tighten-up on MIME handling are a long-awaited
improvement.

[Brian]

Jim Ley wrote:

Brian wrote:

And Opera, as configured "out of the box." Though, in both cases,
I think it may only break MIME handling for text/css.

text/plain too.

Sorry for not being clearer while abbreviating my reply. What I meant
was that Moz and Opera only change text/plain to text/css, apparently
catering to broken web servers.

I just ran a test, configuring my server to send .html files as
text/plain. Lynx 2.8.3, Firefox 0.8 and Opera 7.5 all displayed plain
text, with no rendering, for urls that corresponded to an .html file.
Only IE 6/WinXP broke the rfc, displaying such urls rendered as HTML
documents. Mind you, I have not upgraded to the latest service pack,
and, given how long upgrades take on dialup, I probably won't anytime
soon. Thus, I cannot test Microsoft's claims.

Aside: I know of no browser which changes text/css to anything else.

This is a wish list, not a list of features that already exist.

No correct mime handling is in Windows XP SP2 as the cited urls
above

Rubbish. How does a file extension relate to a url on the client end?

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Jim Ley]

On Sun, 27 Jun 2004 08:38:30 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

Jim Ley wrote:

Brian wrote:

And Opera, as configured "out of the box." Though, in both cases,
I think it may only break MIME handling for text/css.
text/plain too.

Sorry for not being clearer while abbreviating my reply. What I meant
was that Moz and Opera only change text/plain to text/css, apparently
catering to broken web servers.

Only they do the same with changing text/plain to various streaming
media types (I also don't agree Apache defaulting unknown files to
text/plain is particularly a bug in apache, it's just a poorly chosen
default which is different.)
I just ran a test, configuring my server to send .html files as
text/plain. Lynx 2.8.3, Firefox 0.8 and Opera 7.5 all displayed plain
text, with no rendering, for urls that corresponded to an .html file.
Only IE 6/WinXP broke the rfc, displaying such urls rendered as HTML
documents. Mind you, I have not upgraded to the latest service pack,
and, given how long upgrades take on dialup, I probably won't anytime
soon. Thus, I cannot test Microsoft's claims.

Aside: I know of no browser which changes text/css to anything else.

This is a wish list, not a list of features that already exist.

No correct mime handling is in Windows XP SP2 as the cited urls
above

Rubbish. How does a file extension relate to a url on the client end?

I don't understand what you're saying now? What particular part is
rubbish? you've just said you've not tested XP SP2 so don't know.

The matching content-type to extension does actually seem logical to
me for downloading files (it's not rendering, the quote about file
extensions is to do with when downloading files) . In windows when set
up an extension you can associate a mime-type with it, so all the
download prohibition is saying is that windows users will need to do
this, this I think is sensible way to ensure the uneducated are
downloading what they think they are (not downloading something of
type text/plain but has an extension of .bat which once saved locally
will result in different actions when clicked on.)

Remember virus propogation is mostly being done by users.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Brian]

Jim Ley wrote:

Brian wrote:

Jim Ley wrote:
What I meant was that Moz and Opera only change text/plain to
text/css, apparently catering to broken web servers.
Only they do the same with changing text/plain to various streaming
media types

<sigh> That's seems far worse than text/plain -> text/css. At some
point, I should try to run tests for different browsers here, but I
don't have time right now.
(I also don't agree Apache defaulting unknown files to text/plain
is particularly a bug in apache,
Is there anything in http protocols which says what should happen? I
sort of thought that text/plain would be the default if one were chosen.
it's just a poorly chosen default which is different.)
Apache can be configured to use a different default, of course. BTW,
I'm curious: what would you choose as default?

I have not upgraded to the latest service pack, and, given how
long upgrades take on dialup, I probably won't anytime soon.
Thus, I cannot test Microsoft's claims.

correct mime handling is in Windows XP SP2 as the cited urls
above

Rubbish. How does a file extension relate to a url on the client
end?

I don't understand what you're saying now? What particular part is
rubbish? you've just said you've not tested XP SP2 so don't know.

True, I'm relying on (a literal interpretation of) the msdn link
provided earlier in the thread, in particular the part about file
extensions, which should play no role in content type on the client end.
The matching content-type to extension does actually seem logical
to me for downloading files (it's not rendering, the quote about
file extensions is to do with when downloading files) .
Which is it? Does IE Win sp2 follow the rfc or not?

In any case, the content-type should be definitive, whether the
content-type is markup or binary. If you feel otherwise, then your
complaint is not that Firefox (and Opera; you singled out Firefox
while letting Opera off the hook) do *not* break the protocol.
In windows when set up an extension you can associate a mime-type
with it
What extension? On the server? How do you reliably read the extension
of a file on a server via a url?
all the download prohibition is saying is that windows users will
need to do this, this I think is sensible way to ensure the
uneducated are downloading what they think they are (not
downloading something of type text/plain but has an extension of
.bat which once saved locally will result in different actions when
clicked on.)

It seems more sensible for a Windows browser to add a sensible
extension based on the content-type, not determine the content-type
based on what it thinks the file extension is.

You seem to have read more into the MS announcement than I did. I
cannot say that you were wrong to do so, but I understood the note
about content-type as being directed at web server admins, not at
surfers. I tried to find the page again to reread it, but I cannot
find it anymore.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Dave Patton]

"Philipp Lenssen" <in**@outer-court.com> wrote in news:2jtplkF15vje7U2@uni-
berlin.de:

There's this page requesting people to add their wishes for IE7.
<http://channel9.msdn.com/wiki/defaul...netExplorerFea
tureRequests>

"If you have to ask..."
I mean what more do we want but W3C standards etc.?

To have IE be a standalone application, not
"part of the operating system", and coincident
with that, have, at a minimum, both IE and Mozilla
offered as installation choices with MS Windows.

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/

[Jim Ley]

On Sun, 27 Jun 2004 11:45:46 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

Jim Ley wrote:

it's just a poorly chosen default which is different.)
Apache can be configured to use a different default, of course. BTW,
I'm curious: what would you choose as default?

I woulnd't choose one, leave out the content-type header (then
sniffing the content is allowed as per http RFC's)

The matching content-type to extension does actually seem logical
to me for downloading files (it's not rendering, the quote about
file extensions is to do with when downloading files) .

Which is it? Does IE Win sp2 follow the rfc or not?

Choosing if to offer a download link, or prevent downloading is not
against the RFC (since it's not actually acting on the mime-type other
than as it's described, it's just preventing the user from saving it)
So I would say it's not against the RFC, since it trusts the
mime-type, it just doesn' offer the user the opportunity to save it.
At least that's my reading. (text/html for example isn't going to
require a .html or .htm extension, nothing would work, so it's clearly
only about downloaded mime-types not rendered ones)
It seems more sensible for a Windows browser to add a sensible
extension based on the content-type, not determine the content-type
based on what it thinks the file extension is.

To me, that would make more sense yes. However it seems that this is
being used the same way Mozilla stopped showing ALT on tooltips, as a
way to encourage authors from doing something they think is right.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Alan J. Flavell]

On Sun, 27 Jun 2004, Brian wrote:

(I also don't agree Apache defaulting unknown files to text/plain
is particularly a bug in apache,
Is there anything in http protocols which says what should happen?

No, I don't believe so. The applicable specs for HTTP >= 1.0 say that
the server SHOULD (not "MUST") supply an appropriate content-type.
So it's arguable that if the server genuinely does not know what type
is appropriate, it could omit the content-type header; however, I
don't know any servers which do that, and frankly I wouldn't know how
to dissuade Apache from supplying one.

RFC2616 then goes on to say that

If and only if the media type is not given by a Content-Type field,
the recipient MAY attempt to guess the media type via inspection of
its content and/or the name extension(s) of the URI used to
identify the resource. If the media type remains unknown, the
recipient SHOULD treat it as type "application/octet-stream".

However, it doesn't seem to go into any further details about what
kind of action they had in mind for "treating it as" octet-stream.

In earlier times, we seem to have pretty much taken it for granted
that the only sensible move in response to octet-stream would be to
propose saving the content to file. But in the original NCSA HTTPD
(unix-based), where filename extensions had no particular meaning to
the OS, there would be all kinds of eclectically-named files like
readme.1st and HOWTO.INSTALL and I don't know what else, and people
soon got fed up of being asked to download these to file before they
could read them. Hence the sloppy default of text/plain seems to have
caught-on, instead of application/octet-stream, and this has persisted
in Apache also.

More recently, however, software from you-know-who has taken to
treating application/octet-stream as "client may guess". The
propriety of that in terms of RFC2616 is rather dubious, to my mind;
but its implications in terms of practical security have surely by now
become evident even to those who weren't able to work it out for
themselves beforehand.
Apache can be configured to use a different default, of course.
Indeed, but there's no i-havent/a-clue content-type: every explicit
content type "means" something; except for octet-stream, which says no
more than "this is a lump of bytes with no particular structure or
semantics", with the implication that recipient should have been told,
"out-of-band", what it's supposed to be good for.

I personally favour made-up content types as being more appropriate
for content which has no registered content type. Regular recipients
of such made-up types could then configure their browser according to
their preferences (e.g to feed one particular type to a custom
application, while saving another particular type to file, and so on):
this works even for MSIE, in the situations where I have tried it.

Caveat: content-types which are handled by browser plugins rather than
by helper applications are harder to deal with; I rate that as a
shortcoming of the client implementation, rather than anything wrong
with the interworking specification.
True, I'm relying on (a literal interpretation of) the msdn link
provided earlier in the thread, in particular the part about file
extensions, which should play no role in content type on the client end.
Right
Which is it? Does IE Win sp2 follow the rfc or not?
I'm also interested in the answer to that. Either MS's page is
misleading, or the implementation must be B.A.D ("broken as
designed").
In any case, the content-type should be definitive, whether the
content-type is markup or binary. If you feel otherwise, then your
complaint is not that Firefox (and Opera; you singled out Firefox
while letting Opera off the hook) do *not* break the protocol.
In defence of the minority browsers, even though I deplore what they
did, I think it's fair to say that they were left with little
alternative in the face of widespread server misconfiguration which in
turn could only be explained by MS's misbehaviour. Now that MS are
cleaning-up their act, then presumably the broken servers[1] will be
cleaning up, and the minority browsers can also cut back on
workarounds for broken servers.
It seems more sensible for a Windows browser to add a sensible
extension based on the content-type,
Absolutely.

I've got a script called something.cgi which, when called with the
first set of parameters, delivers the text/html HTML page containing
<img src="something.cgi?..." ...>. Then, when the browser actions
this <img src=...> tag, the same script is called with a different
parameter, which tells the script to return the image/jpeg. In both
cases the filename extension is .cgi

So what kind of sow's ear is IE going to make of that, based on MS's
description of what they're doing in SP2? At the moment, I don't
know.
You seem to have read more into the MS announcement than I did. I
cannot say that you were wrong to do so, but I understood the note
about content-type as being directed at web server admins,
That's how I read it, too.
I tried to find the page again to reread it, but I cannot
find it anymore.

http://www.microsoft.com/technet/pro...on133121120120

all the best

[1] except for the one which reportedly told their customer that they
"did not support CSS, and had no plans to do so in the future".
(sheesh)

[Jim Ley]

On Sun, 27 Jun 2004 17:55:07 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

I've got a script called something.cgi which, when called with the
first set of parameters, delivers the text/html HTML page containing
<img src="something.cgi?..." ...>. Then, when the browser actions
this <img src=...> tag, the same script is called with a different
parameter, which tells the script to return the image/jpeg. In both
cases the filename extension is .cgi

So what kind of sow's ear is IE going to make of that, based on MS's
description of what they're doing in SP2? At the moment, I don't
know.
I would suggest from the documentation that it would continue working,
the "must match" behaviour is clearly only relevent to downloading of
files.

Unfortunately though after installing XP SP2 RC2I do get the
MIME-SNIFFING etc. registry keys, but mime-sniffing of text/plain into
HTML still seems to happen, so the behaviour is nothing like what is
documented there. unless the RC doesn't actually match the
documentation, and this is only scheduled for the release. but at the
moment it's still completely knackered!

You seem to have read more into the MS announcement than I did. I
cannot say that you were wrong to do so, but I understood the note
about content-type as being directed at web server admins,

That's how I read it, too.

Er, Me too, I think the I failed to explain my point clearly
previously.
http://www.microsoft.com/technet/pro...on133121120120

Yep, I can't see any of the behaviour described here in the current
publically available Release Candidate.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Alan J. Flavell]

OK, I have just read your message-id
40***************@news.individual.net , but as I had already
prepared this f'up, I think it's still fairly relevant, with just a
couple of adjustments...
On Sun, 27 Jun 2004, Jim Ley wrote:

Choosing if to offer a download link, or prevent downloading is not
against the RFC (since it's not actually acting on the mime-type other
than as it's described, it's just preventing the user from saving it)
MS says this:

___
/

When files are served to the client, Internet Explorer uses the
following pieces of information to decide how to handle the file:

.. File name extension and the corresponding ProgID for the registered
handler of that file name extension.

.. Content-Type from the HTTP header (MIME type) and the corresponding
ProgID for the registered handler of that Content or MIME type.

.. Content-Disposition from the HTTP header.

.. Results of the MIME sniff.

In Windows XP Service Pack 2, Internet Explorer requires that all
file-type information that is provided by Web servers is consistent.

\___

I don't see anything which says that this "enforcement" is restricted
to saving to file, as opposed to rendering.
So I would say it's not against the RFC, since it trusts the
mime-type, it just doesn' offer the user the opportunity to save it.
At least that's my reading.
Could you perhaps focus us more closely onto which bit you're reading?
There's a great expanse of verbiage in there, and it's far from clear
to me just which bits you're relying on. And, as you say that tests
with a Release Candidate were not showing the behaviour described,
we really have very little to go on at the moment, have we?

When it says:

Web servers that do not include the correct Content-Type header with
their files and that use non-standard file name extensions for HTML
pages now have their pages rendered as plain text rather than HTML.

- I'm confused as to which kind of boolean "and" we are dealing with
here. In what was quoted earlier, MS said that "Web developers /must/
.... use consistent filename extensions" (which is completely wrong in
HTTP terms); or is it now trying to say that "non-standard"[1] file
name extensions for HTML files will be just fine so long as the
content type is text/html ? (except that maybe the recipient will be
prevented from saving the HTML to a file??? What fun!!)

[1] According to HTTP specifications there is no such thing as a
"standard" for filename extensions!
(text/html for example isn't going to require a .html or .htm
extension,

I can see some logic in what you're claiming - but this still seems to
be an open question, based on what MS have published.

I already quoted this bit:

Web developers must change their Web servers to host files, using
^^^^
consistent headers and file name extensions.
^^^^^^^^^^^^^^^^^^^^

But later, I found this bit:

You should configure Web servers to use the correct Content-Type
headers. You can also name the files with the appropriate file name
^^^
extension for the application that should handle the file.
Those two versions of the litany seem to me to contradict each other.
One says the [information provider] "must" use consistent file name
extensions, whereas the other implies that they don't *have* to choose
a particular filename extension.

It's all rather confusing.

[Jim Ley]

On Sun, 27 Jun 2004 18:52:00 +0100, "Alan J. Flavell"
<fl*****@ph.gla.ac.uk> wrote:

MS says this:

___
/

When files are served to the client, Internet Explorer uses the
following pieces of information to decide how to handle the file:

. File name extension and the corresponding ProgID for the registered
handler of that file name extension.
In IE speak AIUI, these are only relevant to non internally handled
mime-types, so the above isn't relevant other than on download
(potentially to pass to other handlers just as windows media, or Real
etc.), this is what leaves me disregarding these lines for native
handled stuff, and feeling happy that the behaviour makes sense.

At least I was until I failed to get anything to actually work once I
installed it, now I know not what to think.
Those two versions of the litany seem to me to contradict each other.
One says the [information provider] "must" use consistent file name
extensions, whereas the other implies that they don't *have* to choose
a particular filename extension.

Yep, perhaps my biases on how it logically worked. I think the
general problem was I mostly reading the mime type sniff section,
whereas others were reading the mime-type-enforcement section. I
believe the 2nd is about internally handled stuff and the first about
externally handled stuff, but that is likely my biases rather than
anything else.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Philipp Lenssen]

DU wrote:

Philipp Lenssen wrote:

As you may know you can already override font-sizes in IExplorer.
However that will get rid of all font-sizing, not just idiotic ones.

You can if you use an user stylesheet. You can not otherwise increase
font size if the author chose absolute font units.

Yes you can, and I often do (witout a hand-written user stylesheet).
Open the Internet Explorer accessibility options, there is an "Ignore
font sizes" check box.

--
Google Blogoscoped
http://blog.outer-court.com

[Philipp Lenssen]

DU wrote:

1- "(...)Links that don't behave as expected undermine users'
understanding of their own system. A link should be a simple
hypertext reference that replaces the current page with new content.
Users hate unwarranted pop-up windows.

These are all valid points for authors not to use JavaScript links. but
the question remainds why this feature should be disabled in IE7. Is
the browser responsible for accessibility? (I'm actually wondering
myself right now...)

--
Google Blogoscoped
http://blog.outer-court.com

[Tim]

On Sun, 27 Jun 2004 18:52:00 +0100,
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> posted:

One says the [information provider] "must" use consistent file name
extensions, whereas the other implies that they don't *have* to choose
a particular filename extension.

I can see the sense in telling people to name their files appropriately for
their server's configuration, considering that most servers seem to decide
MIME types by the filenames. But that's as far as I'd go along with that
idea.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Alan J. Flavell]

On Mon, 28 Jun 2004, Tim wrote:

I can see the sense in telling people to name their files
appropriately for their server's configuration,
Well of course; but that's none of IE's business.
considering that most servers seem to decide
MIME types by the filenames.

Again, that's none of IE's business.

And how do you square that with *.cgi, *.php, *.asp etc. etc., which
could be returning all kinds of different content-types?

I can only repeat that whoever wrote that note for MS seems incapable
of discerning the proper borderline between the interworking protocols
on the one hand, and the internals of their own software on the other
hand.

(Of course it -could- turn out that the note does not really describe
what the implementation does, either. But we'll have to cross that
bridge when we come to it.)

[DU]

Philipp Lenssen wrote:

DU wrote:

Philipp Lenssen wrote:

As you may know you can already override font-sizes in IExplorer.
However that will get rid of all font-sizing, not just idiotic ones.

You can if you use an user stylesheet. You can not otherwise increase
font size if the author chose absolute font units.

Yes you can, and I often do (witout a hand-written user stylesheet).
Open the Internet Explorer accessibility options, there is an "Ignore
font sizes" check box.

Yes, you're right! This info is greatly appreciated. Best regards :)

DU

[DU]

Philipp Lenssen wrote:

DU wrote:

1- "(...)Links that don't behave as expected undermine users'
understanding of their own system. A link should be a simple
hypertext reference that replaces the current page with new content.
Users hate unwarranted pop-up windows.

These are all valid points for authors not to use JavaScript links. but
the question remainds why this feature should be disabled in IE7. Is
the browser responsible for accessibility? (I'm actually wondering
myself right now...)

"javascript:" pseudo-protocol never was a valid protocol to begin with:
it's not listed as a valid protocol anywhere. Historically, it was just
a way for browsers to access the javascript engine/debugger from the
locationbar to test for a command, to verify.

IE browsers also support "javascript:" about anywhere:
<link rel="stylesheet" href="javascript:functionName();" ...>
<frame src="javascript:functionName();" ...>

Browsers have a greater share of responsibility regarding accessibility.
They should not support coding practices that disable user commands,
user prefs, user settings, degrade the usability and accessibility of
pages. When the workaround is known, possible, easy to use (here,
javascript can be replaced by coding the onclick event attribute for
links), then browsers should follow W3C standards and ietf protocols.

DU

[Tim]

On Mon, 28 Jun 2004, Tim wrote:

I can see the sense in telling people to name their files
appropriately for their server's configuration,

"Alan J. Flavell" <fl*****@ph.gla.ac.uk> posted:

Well of course; but that's none of IE's business.
I don't disagree.
considering that most servers seem to decide
MIME types by the filenames.

Again, that's none of IE's business.

And how do you square that with *.cgi, *.php, *.asp etc. etc., which
could be returning all kinds of different content-types?
Those are recognised as something that the server identifies as some type
of a file (a script for it to run). The idea isn't that different; the
name is being used to work out what it is, but it doesn't have to be used
to determine the end result. But in this case, it's just the server using
the filename for itself, not the next thing to get the data (the web
browser), which can't do the same trick with .cgi files.

I often have that argument with people who complain their browser doesn't
display some page from a site until they add PHP to their browser's
internal MIME determination process. They'll fix two problems, and create
five more. Though I suppose it's a fair bet that it's going to be some
form of HTML from a PHP or ASP script, it's not an absolute expectation,
and I've seen CGI used to generate all manner of different file types.

Of course I realise that the servers don't have to use the filenames. They
can make assumptions to expect certain filetypes in certain places (scripts
in /cgi-bin/, PNGs in /icons/, etc.), if that's what the SysAdmin wants, or
to snoop into the file. It's just a case of authoring to suit the
environment of that server, and telling authors to name all HTML files as
..html files, for instance, simplifies server administration.
I can only repeat that whoever wrote that note for MS seems incapable
of discerning the proper borderline between the interworking protocols
on the one hand, and the internals of their own software on the other
hand.

I do wonder if the people at Microsoft are completely thick. How many
years of stupid MS software behaviour does it take before they realise how
stupid their software's behaviour is? And how many years of other people's
software doing MIME correctly, long before MS waded into the game, does it
take before they can see that?

I've just had similar arguments with an author of a web browser on a
mailing list. I almost get the impression that they're deliberately
avoiding reading the specs that established (ages ago) how these things
work, and are just pottering about seeing what works with a few limited
test cases.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Jim Ley]

On Sun, 27 Jun 2004 17:21:46 GMT, ji*@jibbering.com (Jim Ley) wrote:

On Sun, 27 Jun 2004 17:55:07 +0100, "Alan J. Flavell" Unfortunately though after installing XP SP2 RC2I do get the
MIME-SNIFFING etc. registry keys, but mime-sniffing of text/plain into
HTML still seems to happen, so the behaviour is nothing like what is
documented there. unless the RC doesn't actually match the
documentation, and this is only scheduled for the release. but at the
moment it's still completely knackered!

Using it some more...

And it looks somewhat different... Using it on sourceforge download
page, directly clicking on the link, and it offers it for download
fine.

however the meta-refresh to the tar.gz served as application/x-gzip
file gets blocked - you are of course offered the opportunity to
download it.

I don't know what this means against the described behaviour.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/