Re: [WSG] file extensions

[Michael Donnermeyer]

I agree...definitely not a clean URL and it would be a major headache.

Sam, OS X doesn't use file extensions in that manner.  They're there for compatibility's sake when in mixed environments.  The OS still figures out the type from the metadata in the file, it just requires extensions to ensure proper cross-platform sharing abilities.  Alot of us cringed when we saw the 10.1 policy on metadata...all because a certain unnamed competitor's OS is still stuck in the middle ages.


On Jun 16, 2004, at 01:42, Sam Walker wrote:

I would hardly say that /0/sa is a clean URL. I think semantic URLs (which actually give you useable information about the file you are looking at) are more important than saving a few bytes in the url. And this is not even going into all the compatibility headaches this would pose, mentioned by others. /images/SubHeaderAbout.gif is a much better URL, although ideally you would be able to do without the extension. Unfortunately, many of the platforms we rely on don't work that way – even OS X, the OS of choice for most designers, has reverted back to relying on extensions to determine filetype. So, for example, if the user wanted to save the image to disk, they wouldn't know how to open it.

-Sam Walker

Re: [WSG] file extensions

[Sam Walker]

On Jun 12, 2004, at 6:27 PM, Christopher Kennon wrote:

...
Interestingly, there really is little value to including file extensions such as gif, . jpg , .js, and so on.  The browser does not rely on these values to render a page; rather it uses the MIME type header in the response.  Knowing this, we might take: 

 

and shorten it to: 

 

If combined with file renaming, this might produce: 

 
...
However, the benefits of adding content negotiation far outweigh the costs.  Clean URLs improve both security and portability of your sites, and even allow for adaptive content delivery whereby you can send different image types or languages to users based upon their browser's capabilities or system preferences!  See "Towards Next Generation URLs" by the same authors for more information. 

I would hardly say that /0/sa is a clean URL. I think semantic URLs (which actually give you useable information about the file you are looking at) are more important than saving a few bytes in the url. And this is not even going into all the compatibility headaches this would pose, mentioned by others. /images/SubHeaderAbout.gif is a much better URL, although ideally you would be able to do without the extension. Unfortunately, many of the platforms we rely on don't work that way – even OS X, the OS of choice for most designers, has reverted back to relying on extensions to determine filetype. So, for example, if the user wanted to save the image to disk, they wouldn't know how to open it.

-Sam Walker

RE: [WSG] file extensions

[Kay Smoljak]

Michael Kear <[EMAIL PROTECTED]> said:
> But in a shared environment,  which is where the vast majority of sites
> actually are, all the users on a site would have to stop using .CFM
> extensions on their coldfusion pages if you were sending .cfm pages to PHP.

This can be done on a site by site basis. I'm moving one static site to
ColdFusion on IIS without changing filenames, and another has already been
moved to php without changing anything except the apache settings (both are
hostedx on shared hosting servers). Having said that, I can easily see from
recent personal experience that avoiding the need to change server settings
would be a good thing!


--
Kay Smoljak
http://developer.perthweb.com.au


*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[Mordechai Peller]

Marc Greenstock wrote:
that means the server has to scan the specified directory for all 
those files rather than retrieving the specific files.
The server has to scan the directory anyway in order to find the file 
matching the requested name. Server software isn't omniscient, scanning 
the directory is the only way it know where to find the file on the drive.

Secondly the article also referred to removing comments from 
javascript as if they were unnecessary garbage, but doesn't this 
contradict everything we have learned about good, clean code?
Not in this case. The article talked about having two copies of your 
code: one for working on and one for publishing. The code you work with 
should have all the comments and indentations good code should have, but 
your live copy should have all that removed.
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[Mordechai Peller]

Rev. Bob 'Bob' Crispen wrote:
Not even a good idea for Amazon.  If you stop putting "extensions" on 
file names,
There's an in between ground: the files have the extensions, but the 
URL's don't. As long as you don't have multiple images with the same 
name (which you wouldn't be able to do while san extension, anyway), 
there shouldn't be a problem. This way you have the flexibility with 
much less overhead.
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[Rev. Bob 'Bob' Crispen]

The voices are telling me that Peter Firminger said on 6/12/2004 7:48 PM:
Not a good idea for the average website. If you're running amazon.com then
there would be a reason to do it but for most of us maintenance would be an
issue.
Not even a good idea for Amazon.  If you stop putting "extensions" on 
file names, then your web server has to look inside the stream it's 
serving, read the "magic" header information, and figure out the MIME 
type from that.  E.g., "ff d8|de ff eo something something JFIF" means 
it's "image/jpeg", "#VRML V2.0 utf8" means it's "model/vrml".  If this 
seems like a roundabout way to do things, go with your feelings, Luke.

I used magic just for fun on a Sun 3-60 I used ages ago as a web server 
for my group at work and just as quickly took it off because it slowed 
even the tiny amount of traffic we were getting to a crawl.  Now I'm 
sure the relevant code in Apache is lots faster now, as are CPUs, but if 
you've got a site like Amazon, I'll bet you'd notice the difference.

Just to save a stamp, someone asked if such a thing is ever done in the 
wild.  The only example I've ever seen is w3.org.
--
Rev. Bob "Bob" Crispen
bob at crispen dot org
Ex Cathedra Weblog: http://blog.crispen.org/

Don't ask yourself what the world needs - ask yourself what makes you
come alive, and then go do it. Because what the world needs is people
who have come alive. -- Howard Thurman
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[Christopher Kennon]

Hi,
Thanks for the vigorous and spirited replies. I'll just use the trusted 
method of file extensions, as this excerpt was keeping me up at night. 
I was hoping I was not just blindly loyal to convention, unable to 
accept a needed change. After reading the replies to abandon file 
extensions is just dangerous.


"Say it clearly, and you make it beautiful no matter what."
 —Bruce Weigl
Chris
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
*

RE: [WSG] file extensions

[Michael Kear]

But in a shared environment,  which is where the vast majority of sites
actually are, all the users on a site would have to stop using .CFM
extensions on their coldfusion pages if you were sending .cfm pages to PHP.
That just isn't practical.  And it would PREVENT people moving their
coldfusion sites into that system without extensive re-writing. Not just
changing filenames, but also all cfincludes references, all custom tag
calls, CFC component calls etc.

Similarly the other way, if you configured the system to process .PHP files
through the cold fusion server.  Everyone would have to stop using .php
extensions for their php files, thus preventing anyone copying a .php site
into that system without re-writing it.

Most of the dynamic sites on the net are actually in shared hosting
environments, not on owned or dedicated servers.

I cant see the point in this standard.  It seems to offer a tiny advantage
for a vast cost, if all you want to do is get rid of .cfm extensions on file
names, and .gif and .jpg extensions on images.  

On the other hand if what you want to get rid of is the
?randID=12324587&clientID3212345 kind of thing, then dump PHP and go with
ColdFusion. It's a piece of cake. There's no need to pass variables from
page to page as a URL string unless you want to.  You can do it internally
using two methods - session variables or client variables.

But to get back to the standards aspect - I cant see the point in having
non-standard installations in a shared hosting environment just to meet this
W3C standard, which doesn't seem to provide any benefits apart from saving a
few bytes in bandwidth.


Cheers
Mike Kear

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of James Ellis
Sent: Sunday, 13 June 2004 9:58 PM
To: [EMAIL PROTECTED]
Subject: Re: [WSG] file extensions

Hi

The portability of URI's is an important point here: as discussed, if a 
web developer wants to move from X to Y server side language yet retain 
the URL stucture then this is the way to go, in Apache it's just a 
simple matter of telling it how to handle certain extension-less files.
That said, you should be able to set up a server to handle PHP scripts 
with .cfm extensions via the PHP interpreter and vice versa (as an example).

I wrote an article over at the Sydney PHP Group on doing this with 
Apache, shared hosting or otherwise, questions welcome offlist or post 
to that group.
http://sydney.ug.php.net/phpBB2/viewtopic.php?t=61

HTH

James


*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[Marc Greenstock]

James Ellis wrote:
Hi
The portability of URI's is an important point here: as discussed, if 
a web developer wants to move from X to Y server side language yet 
retain the URL stucture then this is the way to go, in Apache it's 
just a simple matter of telling it how to handle certain 
extension-less files.
That said, you should be able to set up a server to handle PHP scripts 
with .cfm extensions via the PHP interpreter and vice versa (as an 
example).

I wrote an article over at the Sydney PHP Group on doing this with 
Apache, shared hosting or otherwise, questions welcome offlist or post 
to that group.
http://sydney.ug.php.net/phpBB2/viewtopic.php?t=61

I agree, portability of URI's are important and an extension for an 
image is not doesn't necessarily qualify for an exclusion to this rule. 
I quite commonly render an image dynamically by setting the MIME type of 
a php file to the appropriate type and displaying the image I require. 
But I believe this is beyond the point with this article in question; 
The article suggests removing file extensions in the html document, eg 
the file logo.gif would be written in the html as . this has no relevance to portability of URI's 
because it is not a direct link. Doing that with a .html document may be 
relevant but definitely not images.

Apache has a module called mod_spell, it's not turned on by default but 
it helps when a site has been ported from an IIS server to apache. It 
solves the case sensitivity issue. The trouble is using the external 
modules can increase server load, a lot. Consider that you have 20 
images included on a page all with their extensions removed, that means 
the server has to scan the specified directory for all those files 
rather than retrieving the specific files. That can cause a huge 
overload on the server, especially if there are a lot of requests at any 
one time.

Secondly the article also referred to removing comments from javascript 
as if they were unnecessary garbage, but doesn't this contradict 
everything we have learned about good, clean code?  The purpose of 
comments is to remember what you did six months down the track when you 
need to do something to it. Removing comments will undoubtably clear a 
few bytes from a page download, but the result will be extremely mimimal.

*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[James Ellis]

Hi
The portability of URI's is an important point here: as discussed, if a 
web developer wants to move from X to Y server side language yet retain 
the URL stucture then this is the way to go, in Apache it's just a 
simple matter of telling it how to handle certain extension-less files.
That said, you should be able to set up a server to handle PHP scripts 
with .cfm extensions via the PHP interpreter and vice versa (as an example).

I wrote an article over at the Sydney PHP Group on doing this with 
Apache, shared hosting or otherwise, questions welcome offlist or post 
to that group.
http://sydney.ug.php.net/phpBB2/viewtopic.php?t=61

HTH
James
Anders Nawroth wrote:
Michael Kear wrote:
What’s the point of doing this? Saving 4 characters per image as a 
way of reducing bandwidth? Is there any other purpose?

*/
/*
There is another purpose.
See this W3C Note:

"Serve static content without file extension CM
The reason why one should serve static content without file extension 
is similar to the reason stated above : the content manager may, at 
some point, want to change the document format used to serve a 
resource, yet the resource would remain "equivalent". For example, 
switching from an image file format to an equivalent format, or 
switching from plain text to HTML...
File extensions should therefore be hidden for static content, using 
content-negotiation (see Guideline 7: Server-driven content 
negotiation.), proxying or URI mapping technologies."

*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
*

RE: [WSG] file extensions

[Michael Kear]

I can't think of a single site anywhere on the web that's not using file
extensions for the images on the site.  Does anyone know of one?

And in a shared hosting environment, where you have asp, asp.net, php, cfm,
html and shtml pages all residing and running simultaneously, I can't see
how it would work, in practical terms.  Yes, I know about content
negotiation - NOW - but IIS and Apache (the two most prominent web servers)
don't set up that way, few host administrators would know how to do this,
and all the development tools load their options and config files based on
the file extension. 

This would surely be the LEAST observed standard anywhere on the web
wouldn't it? 

Or have I been living in a different world?

As it happens, I tend to use non-specific urls myself where I can, but
because I want it easy to remember.  For example I'll have the url on my
bluegrass Australia site so that a section is in its own folder. Therefore
to access the magazine section the url is http://bluegrass.org.au/magazine/.
But it's not for any standards reason  - I had no idea until today that
standard existed. But simply for reasons that it's easier for people to
remember.   For the same reason we set our sites up so they don't need any
'www' (but work equally well with the 'www')

Cheers
Mike Kear
Windsor, NSW, Australia
AFP Webworks
http://afpwebworks.com



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Anders Nawroth
Sent: Sunday, 13 June 2004 7:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [WSG] file extensions


Michael Kear wrote:

> What's the point of doing this? Saving 4 characters per image as a way 
> of reducing bandwidth? Is there any other purpose?
>
> */
> /*
>
There is another purpose.

See this W3C Note:
<http://www.w3.org/TR/chips/#gl3>

[snip]


*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[Anders Nawroth]

Michael Kear wrote:
What’s the point of doing this? Saving 4 characters per image as a way 
of reducing bandwidth? Is there any other purpose?

*/
/*
There is another purpose.
See this W3C Note:

"Serve static content without file extension CM
The reason why one should serve static content without file extension is 
similar to the reason stated above : the content manager may, at some 
point, want to change the document format used to serve a resource, yet 
the resource would remain "equivalent". For example, switching from an 
image file format to an equivalent format, or switching from plain text 
to HTML...
File extensions should therefore be hidden for static content, using 
content-negotiation (see Guideline 7: Server-driven content 
negotiation.), proxying or URI mapping technologies."

/AndersN
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

Re: [WSG] file extensions

[Marc Greenstock]

Christopher Kennon wrote:
Hi,
Below is the url and excerpt from the passage in question. I've tried 
it and it works. The images are displayed, but someone looking over 
the code commented that it appeared that an image was used, but the 
extension was missing. Thus the question was inspired.

Chris
*/
http://www.sitepoint.com/article/effective-website-acceleration/2
/*
Sorry but what a load of crap, what are they trying to save here? Four 
bytes that that represent a file extension? Big whoop. The whole concept 
of cleaning up your links, using mod_rewrite/mod_spell/mod_regoation, 
removing comments from javascript??? so your page contains a few less 
bytes is frivolous let alone dangerous.

Marc
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

RE: [WSG] file extensions

[Michael Kear]

What’s the point of doing
this?  Saving 4 characters per image as a way of reducing bandwidth? 
Is there any other purpose? 

 

Cheers

Mike Kear

Windsor, NSW, Australia

AFP Webworks

http://afpwebworks.com



 

 











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Kennon
Sent: Sunday, 13 June 2004 9:28 AM
To: [EMAIL PROTECTED]
Subject: Re: [WSG] file extensions



 

Hi,

Below is the url and excerpt from the passage in question. I've tried it and it
works. The images are displayed, but someone looking over the code commented
that it appeared that an image was used, but the extension was missing. Thus
the question was inspired.

Chris


http://www.sitepoint.com/article/effective-website-acceleration/2

RE: [WSG] file extensions

[Peter Firminger]

Not a good idea for the average website. If you're running 
amazon.com then there would be a reason to do it but for most of us maintenance 
would be an issue.
 
P

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Christopher 
  KennonSent: Sunday, June 13, 2004 9:28 AMTo: 
  [EMAIL PROTECTED]Subject: Re: [WSG] file 
  extensions
  Hi,Below is the url and excerpt from the passage in 
  question. I've tried it and it works. The images are displayed, but someone 
  looking over the code commented that it appeared that an image was used, but 
  the extension was missing. Thus the question was inspired.Chrishttp://www.sitepoint.com/article/effective-website-acceleration/218. 
  Remove or reduce file extensions. Interestingly, 
  there really is little value to including file extensions such as .gif, . jpg , .js, and so on. The browser does not 
  rely on these values to render a page; rather it uses the MIME type header in 
  the response. Knowing this, we might take:  and 
  shorten it to:  If 
  combined with file renaming, this might produce:  Don't 
  be scared by how strange this technique looks; your actual file will still be 
  sA.gif. It's just the end user who won't see it that way! In order to take advantage of 
  this more advanced technique, however, you do need to make modifications to 
  your server. The main thing you will have to do is to enable something called 
  "content negotiation," which may be native to your server or require an 
  extension such as 
  mod_negotation for Apache or Port80's 
  pageXchanger for IIS. The downside to this is that it may cause a slight 
  performance hit on your server. However, the benefits of 
  adding content negotiation far outweigh the costs. Clean URLs improve both 
  security and portability of your sites, and even allow for adaptive content 
  delivery whereby you can send different image types or languages to users 
  based upon their browser's capabilities or system preferences! See 
"Towards Next Generation 
  URLs" by the same 
  authors for more information. Note: Extension-less URLs 
  will not hurt your search engine ranking. Port80 Software, as well as major 
  sites like the W3C, use this technique and have suffered no ill effects. On Saturday, June 12, 2004, at 03:34 
  PM, Jason Turnbull wrote:
  
Just finished article from a reputable web site, specializing 
  in bestpractices. They suggest omitting the file extensions .gif , 
  .jpg and.png from image files for bandwidth conservation. 
Chris, Whats the URL for this article. I'm finding it 
hard to grasp thereasoning, does it save on bandwidth as the images 
don't get 
displayed?:-)RegardsJason*The 
discussion list for http://webstandardsgroup.org/See 
http://webstandardsgroup.org/mail/guidelines.cfmfor some hints on 
posting to the list & getting 
help* 
  

Re: [WSG] file extensions

[Christopher Kennon]

Hi,

Below is the url and excerpt from the passage in question. I've tried it and it works. The images are displayed, but someone looking over the code commented that it appeared that an image was used, but the extension was missing. Thus the question was inspired.

Chris


http://www.sitepoint.com/article/effective-website-acceleration/2



18. Remove or reduce file extensions. 

Interestingly, there really is little value to including file extensions such as .gif, . jpg , .js, and so on.  The browser does not rely on these values to render a page; rather it uses the MIME type header in the response.  Knowing this, we might take: 

 

and shorten it to: 

 

If combined with file renaming, this might produce: 

 

Don't be scared by how strange this technique looks; your actual file will still be sA.gif.  It's just the end user who won't see it that way! 

In order to take advantage of this more advanced technique, however, you do need to make modifications to your server.  The main thing you will have to do is to enable something called "content negotiation," which may be native to your server or require an extension such as mod_negotation for Apache or Port80's pageXchanger for IIS.  The downside to this is that it may cause a slight performance hit on your server. 

However, the benefits of adding content negotiation far outweigh the costs.  Clean URLs improve both security and portability of your sites, and even allow for adaptive content delivery whereby you can send different image types or languages to users based upon their browser's capabilities or system preferences!  See "Towards Next Generation URLs" by the same authors for more information. 

Note: Extension-less URLs will not hurt your search engine ranking.  Port80 Software, as well as major sites like the W3C, use this technique and have suffered no ill effects. 


On Saturday, June 12, 2004, at 03:34 PM, Jason Turnbull wrote:

Just finished article from a reputable web site, specializing in best
practices.  They suggest omitting the file extensions .gif , .jpg and
.png from image files  for bandwidth conservation. 

Chris, Whats the URL for this article. I'm finding it hard to grasp the
reasoning, does it save on bandwidth as the images don't get displayed?
:-)

Regards
Jason


*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

RE: [WSG] file extensions

[Jason Turnbull]

> Just finished article from a reputable web site, specializing in best
> practices.  They suggest omitting the file extensions .gif , .jpg and
> .png from image files  for bandwidth conservation. 

Chris, Whats the URL for this article. I'm finding it hard to grasp the
reasoning, does it save on bandwidth as the images don't get displayed?
:-)

Regards
Jason


*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
* 

[WSG] file extensions

[Christopher Kennon]

Hi,
Just finished article from a reputable web site, specializing in best 
practices.  They suggest omitting the file extensions .gif , .jpg and 
.png from image files  for bandwidth conservation. I understand the 
theory, the mime-type is interpreted by the sever and the correct file 
is served to the user-agent. What  implications do omitting these 
commonly known extensions have on the work place and viewing source 
code?

Chris
*
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
*