Re: [WSG] Content negotiated links: why so bad?

2007-03-02 Thread TuteC

That's what I do, and it's really swift of doing, even though you
never saw an htaccess file.
I use it, there are some disadvantages on server load but in my
projects, I don't care. Well, it works as expected.
Best regards,
Eugenio Costa.

On 3/1/07, Adrian Lynch <[EMAIL PROTECTED]> wrote:


Or just use mod_rewrite to rewrite the URL's from nice clean URL's
into the crusty querystrings on the fly. If you are familiar with
mod_rewrite it would take 15 minutes, otherwise might take an hour or
so to work out what you need but you wouldn't need to even touch
the backend.

A



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Content negotiated links: why so bad?

2007-03-01 Thread Adrian Lynch

On 01/03/2007, at 11:36 AM, Kenny Graham wrote:

The webmaster I'm talking to is responsible for URLs that end like  
this

 *.cfm?doc_id=n ... and thinks it's perfectly acceptable


. Beyond that, any way to get rid of the ?doc_id=n and
such at the ends of the URLs would require an entire rewriting of the
backend, or maybe even getting rid of the backend all together and
writing every page as static html.  Which likely isn't worth it just
to get easier URLs.


Or just use mod_rewrite to rewrite the URL's from nice clean URL's  
into the crusty querystrings on the fly. If you are familiar with  
mod_rewrite it would take 15 minutes, otherwise might take an hour or  
so to work out what you need but you wouldn't need to even touch  
the backend.


A


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Content negotiated links: why so bad?

2007-03-01 Thread Kenny Graham

The webmaster I'm talking to is responsible for URLs that end like this
 *.cfm?doc_id=n ... and thinks it's perfectly acceptable


In that case, the webmaster is making dynamically generated pages.
URLs that end like that are necessary, because they're used to pass
variables to the page.  The other option is to use "post" to pass the
variables, which could cause annoyance when refreshing or using
back/forward.  Beyond that, any way to get rid of the ?doc_id=n and
such at the ends of the URLs would require an entire rewriting of the
backend, or maybe even getting rid of the backend all together and
writing every page as static html.  Which likely isn't worth it just
to get easier URLs.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Content negotiated links: why so bad?

2007-02-28 Thread Ben Buchanan

organisation). I have a penchant for short, usable URLs that don't show file
names, and would like to link to "/mydept/training/" rather than
"/mydept/training.htm".


Sounds a lot like you'll get resistance, although I agree that not
showing extensions has some benefits.

I'd shoot for a middle of the road - make sure that all index pages
are documented/distrubuted without the "index.html" and try to avoid
promoting anything other than an index :)

More of a social hack than a technical solution, but sometimes policy
requires it.

cheers,

Ben

--
--- 
--- The future has arrived; it's just not
--- evenly distributed. - William Gibson


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



Re: [WSG] Content negotiated links: why so bad?

2007-02-28 Thread libwebdev

I appreciate your comments, Breton, thank you.

At 11:19 AM 1/03/2007 +1100, Breton Slivka wrote:


Given the structure of the  site, I am not sure that
there is any great advantage to be gained.'


what special qualities of the site's structure is he talking about here?


No special qualities. It's very simple. /dept/ contains all *.htm files
including the site index, with css/javascript/images/otherstuff in their own
/dirs/. Pretty basic. Maybe that's his point: little advantage.


is seamless multiple language support, and seamless multiple browser

support into the

future important to the company? Are clean, easy to remember URL's

important?

Nope, to easy URLs (forgive me, I don't understand the relationship between
MultiViews and language/browser support).
The webmaster I'm talking to is responsible for URLs that end like this
 *.cfm?doc_id=n ... and thinks it's perfectly acceptable (just one of
the many many reasons I'm glad our dept's website is NOT in the
organisation's CMS). In fact, I think he quite likes them, and certainly
doesn't seem to think usable URLs are an issue in any way at all.


what percentage of your target audience would be able to take real

advantage of this change?

Probably a very small one. However, the last usability study I did on my
site (the webmaster hasn't done one of those, has he, nah, course not), a
couple of users actually mentioned how they preferred my dept's style of URL
to the organisation's. I was just trying to make it even better. I think
/dept/training/ just looks way cooler and more professional than
/dept/training.htm

Perhaps I'll just let this one go; there are sure to be bigger issues down
the track more worth my time. *sigh*

thanks again though, i really did want to understand more about his
response.

lib.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Content negotiated links: why so bad?

2007-02-28 Thread Breton Slivka


On 01/03/2007, at 9:31 AM, libwebdev wrote:


Hi folks,

I followed a recent thread here on how people manage their links,  
and I made a request to our organisation's webmaster to allow  
MultiViews for my department's website (which I manage, and which  
is part of a large public organisation). I have a penchant for  
short, usable URLs that don't show file names, and would like to  
link to "/mydept/training/" rather than "/mydept/training.htm".


His response:


My main concern would be with how content-negotiated links get  
handled by search engines (both Google and Thunderstone).


Google sends the http accept header with text/html as its preference.  
Apache will serve whatever content best matches that. Thunderstone  
sends whatever accept header you set it to send, so the consequences  
of that are up to you and how you set it.



There is also a potential issue if there is more than one page in a  
folder that satisfies the content criteria.
Then the one the user agent prefers (indicated by it accept header)  
gets sent.  This concern is uselessly ambiguous, though. What kind of  
situation is he imagining, exactly?



Additionally, even if we were to allow MultiViews, it is essential  
that the URL in any links within the pages still be the correct  
full one.


How does he define "correct" ? Any one of the possible content types  
is correct depending on what user agent is requesting the page. If an  
XML browser requests a page which contains "full" links to html  
documents, this would be incorrect.



Given the structure of the  site, I am not sure that  
there is any great advantage to be gained.




what special qualities of the site's structure is he talking about here?




I'm not sure I fully understand his concerns, and wondered if  
someone could enlighten me as to why he is reluctant to do this,  
why it would be A Bad Thing when it seems pretty innocuous to me.


is seamless multiple language support, and seamless multiple browser  
support into the future important to the company? Are clean, easy to  
remember URL's important? What are the actual drawbacks? I've read  
carefully though his "concerns" and he doesn't seem to specifically  
state any.  So, it seems to me that while he said he has concerns,  
what he listed as concerns are rather strange constructed mythologies  
designed to appear like concerns, but which are not.





Or perhaps I should just get over it, use *.htm everywhere, and  
move on to more important issues. .. ?


lib.



You could. To play devil's advocate here, what percentage of your  
target audience would be able to take real advantage of this change?  
Is that percentage worth the trouble of arguing with him, and is it  
worth the trouble of implementing the change?




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***



[WSG] Content negotiated links: why so bad?

2007-02-28 Thread libwebdev

Hi folks,

I followed a recent thread here on how people manage their links, and I made
a request to our organisation's webmaster to allow MultiViews for my
department's website (which I manage, and which is part of a large public
organisation). I have a penchant for short, usable URLs that don't show file
names, and would like to link to "/mydept/training/" rather than
"/mydept/training.htm".

His response:


My main concern would be with how content-negotiated links get handled by
search engines (both Google and Thunderstone). There is also a potential
issue if there is more than one page in a folder that satisfies the content
criteria. Additionally, even if we were to allow MultiViews, it is essential
that the URL in any links within the pages still be the correct full one.

Given the structure of the  site, I am not sure that there is
any great advantage to be gained.


I'm not sure I fully understand his concerns, and wondered if someone could
enlighten me as to why he is reluctant to do this, why it would be A Bad
Thing when it seems pretty innocuous to me.

Or perhaps I should just get over it, use *.htm everywhere, and move on to
more important issues. .. ?

lib.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***