My Very Strange Webhost, SBI! -- Opinions, Please

[Andy Dingley]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On 8 May, 21:54, Prisoner at War <prisoner_at_.. .@yahoo.comwrot e:

the image-swap itself is your basic <img
src="blah.png" onMouseOver="bl eh.gif" onMouseOut="bla h.png">.

For utter perversity, you _could_ do this: 8-)


<img id="hardway" src="rollover_n ormal.png"
onMouseOver="ro llover_hover.pn g" onMouseOut="rol lover_normal.pn g" >

With this JS:

<script type="text/javascript" >

function rollable_trap(e ) {
if (!e) var e = window.event;
var elmRolled = e.target;
switch (e.type) {
case 'mouseover':
elmRolled.src = elmRolled.getAt tribute( 'onMouseOver' );
break;
case 'mouseout':
elmRolled.src = elmRolled.getAt tribute( 'onMouseOut' );
break;
}
e.cancelBubble = true;
if (e.stopPropagat ion) e.stopPropagati on();
}


function onload_listenFo rRolloverEvents () {
var elmRollable = document.getEle mentById('hardw ay');
if (elmRollable) {
// Do it the crude way, rather than using addEventListene r()
// This avoids the error raised by the old URL value for "the
handler" being treated as a function
elmRollable.onm ouseover = rollable_trap;
elmRollable.onm ouseout = rollable_trap;
}
}


/* ****** ****** ****** ****** ****** ******
****** ****** */
// A listener list for the initial onload event
window.onloadLi steners = new Array();
window.addOnLoa dListener = function( listener ) {
window.onloadLi steners [window.onloadLi steners.length] = listener;
}
window.onload = function () {
for (var i in window.onloadLi steners) {
window.onloadLi steners [i] ();
}
}
// Add some listeners
window.addOnLoa dListener( onload_listenFo rRolloverEvents );
</script>

[Mark Goodge]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On Tue, 13 May 2008 15:11:58 -0400, Jonathan N. Little put finger to
keyboard and typed:

>Prisoner at War wrote:

>On May 12, 11:41 pm, "Jonathan N. Little" <lws4...@centra l.netwrote:

>>>
>>No, but you have to have your relative paths correct...

>>
>Look, look at this: http://ego-management.org/test.html -- look at the
>HTML/JavaScript.
>>
>Notice that my image-swap now works?
>>
>The **only** thing that's different now from when it didn't work is
>that the first src attribute in the <imgtag has an absolute file
>path name.
>>
>It's got nothing to do with whether my path names were correct -- they
>were; they just were in relative format, whereas due to a bug in their
>CMS they need the first one to be in absolute format when used as an
>image-swap.

>
>That make no sense at all. If you properly use a relative path to your
>Document Root (which on a webserver you have, but on a local file system
>you don't) is will work.

I think that the OP means "relative to the document root" when he says
"absolute" - that is, an absolute path as far as the browser is
concerned (starting with a "/"). In this context, "relative" is
usually taken to mean "relative to the current page URL". In this
context, the first and last of your examples are "absolute" to the
browser, as they will work from any page on his site no matter what
its location in the URL structure. The middle two, by contrast, will
only work if the page is in the document root itself:

http://www.ego-management.org/image-files/awww4.png

image-files/awww4.png
../image-files/awww4.png
/image-files/awww4.png

If that is the case then that also explains his problem. If you're
using an online CMS - particularly a javascript-based WYSIWYG CMS -
then you need to make your image paths absolute URLs (ie, relative to
the document root), as the relative path from the CMS is usually
different to the relative path from the public location of the page.
If you use a relative URL when creating pages in an online CMS, then
either the page will work in the CMS but not in the main site, or work
in the main site but not the CMS. And that's not a "bug" in the CMS,
it's a normal consequence of using one.

Mark
--
Miscellaneous remarks at http://Mark.Goodge.co.uk
"All this talk of getting old, it's getting me down my love"

[Prisoner at War]

Re: My Very Strange Webhost, SBI! -- Opinions, Please


LOL!!

That's actually rather similar to a "web-standards" version offered by
the book "DOM Scripting" (excellent book for beginners ready to get
"intermediate") , but yes, rather perverse in reality even though it
serves the otherwise worthy ideal of markup-styling-behavior
separation.

[Prisoner at War]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On May 14, 3:04 am, Chaddy2222 <spamlovermailb ox-
sicur...@yahoo. com.auwrote:

>
>
By not actually being valid code. Read about quirks vs standards mode
and gain a good understanding of it before doing anything. It can have
a large impact on how your pages work on the web.
For a start your page does not have a doctype, give it one and
validate your pages. DO NOT use XHTML

If I haven't mentioned it before to you (I did to somebody -- a
handful of somebodies now, but can't remember whomever exactly), let
me do so:

The original webpage had doctypes, etc., etc. This current one,
"test.html, " was designed to help tech support diagnose the issue by
removing the visual "clutter" of extraneous code that did not
highlight the problem (of a simple perfectly valid image-swap not
working).

Again, I don't know why you guys keep looking all over the place when
the problem is right in front of you: a simple and valid image-swap
does not work when hosted by their server. It's got nothing to do
with XHTML, etc.

I have set my editor to not use
it for all new sites that I develop. Google for the reasons why you
should not use it.

But XHTML is a W3C recommendation, is it not? Despite my disdain for
usenet rules like top-posting, sig-snipping, etc., I do believe in web
standards. Personally I prefer the laissez-faire ethos of good ol'
HTML, but I understand why for consistency's sake (that is,
consistency with the "semantics" of developing and future
technologies) XHTML might be preferred.

--
Regards Chad.http://freewebdesignonline.org
>
<snip>

[Prisoner at War]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On May 14, 7:59 am, Andy Dingley <ding...@codesm iths.comwrote:

>
>
So swap it back to being a relative filepath. Now that it's working, I
bet that it will _continue_ to work when you change this. That's
because this wasn't ever the problem at all.
>
Maybe you'll think it's "stereotypi ng" when I tell you that this is a
very common situation in user support. This is also why you always aim
to get a simple example _working_ first, then modify it gradually to
do what you need (whilst also keeping it working). Changing something
that's working is so much easier than fixing something that isn't
working.
>
I don't know why it didn't (past tense) work, but I doubt _VERY_ much
if it was to do with absolute paths. It just doesn't work that way.
Something else caused the problem, you didn't notice quite what it was
that fixed it, it just happened at the same time. Now switch the path
(and ONLY the path) back to being relative, and I bet it will still
keep on working.

Interesting proposition; I will, and will update my findings! Bear in
mind, though, that the absolute path reason is given by their own
"programmer s" (that's what tech support said), and I should think they
know what they're doing -- even if they won't explain further why and
how it works that way....

Welcome to user support. That's what it consists of day in, day out.
This is how cargo cults develop.

Eh? Sorry, I've read Marvin Harris' "Cows, Pigs, Wars, and Witches:
The Riddles of Culture" but I'm not sure I see the connection between
how cargo cults develop and the user support experience you're
alluding to....

No one is disputing that, merely that it could also be different
(relative path), yet still work.

Good grief, man!!

That's how it **started** out, with relative paths, as per standard
practice!

When that didn't work (on *their* end -- i.e., over the WWW from their
server), that's when I contacted tech support and was told, after two
weeks, that I had to use an absolute path for that first src
attribute!

Whereupon I came to usenet soliciting opinions concerning what seemed
even to my newbie self as a very strange situation.

I *know* relative path format is supposed to work...the issue for me
is whether this webhost, SBI, is just very strange, or whether all,
most, many, or some webhosts also have weird things about them, where
they require you to do things in a certain way (with SBI! you upload
through their widget, not just FTP whatever you want) -- even code/
markup a certain way (as in this image-swap case here)....

Ultimately, I'm quitting these folks (I still regret it a bit, as they
can be very educational, particularly about the business/marketing
side of things), but I need to know what to expect **of** a webhost,
what would be industry standards...SBI ! is all I know and though I
appreciate the hand-holding they provide I'm afraid I don't want to
deal with one nagging weirdness (like this image-swap that took two
weeks to resolve) after another (like not supporting .ani or .cur
files), with God-knows-how-many-more to come...so I need another
webhost.

But before I sign up again, I need to know what to expect, how
webhosts work...can I assume that anything I can create on my laptop I
can put up on a webhost's server and it'll run just as it does when
off my hard drive??

[Prisoner at War]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On May 14, 3:05 pm, Mark Goodge <use...@listmai l.good-stuff.co.uk>
wrote:

>
>
I think that the OP means "relative to the document root" when he says
"absolute" - that is, an absolute path as far as the browser is
concerned (starting with a "/").

Hey, I'm just taking my cue from SBI! tech support, which is just
passing along the message from their "programmer s" -- they're the ones
calling it an absolute file path name format. I've adopted the label
on the assumption that they know what they're talking about.

In this context, "relative" is
usually taken to mean "relative to the current page URL".

Yeah, it seems that "http://www.my-website.com" is the "root" and an
absolute path for a file would be "http://www.my-website.com/files/
file.doc" as opposed to "files/file.doc" -- which is relative format,
relative to the document calling for the file.

In this
context, the first and last of your examples are "absolute" to the
browser, as they will work from any page on his site no matter what
its location in the URL structure. The middle two, by contrast, will
only work if the page is in the document root itself:
>

http://www.ego-management.org/image-files/awww4.png

image-files/awww4.png
./image-files/awww4.png
/image-files/awww4.png

Sorry, can't follow along...all I know is that "absolute" is like
telling someone the full mailing address of a geographical location,
while "relative" is like telling someone "it's down the block on the
corner."

If that is the case then that also explains his problem. If you're
using an online CMS - particularly a javascript-based WYSIWYG CMS -
then you need to make your image paths absolute URLs (ie, relative to
the document root), as the relative path from the CMS is usually
different to the relative path from the public location of the page.

But why only the first src attribute; how come the other two can
remain relative, as I'd had them originally??

If you use a relative URL when creating pages in an online CMS, then
either the page will work in the CMS but not in the main site, or work
in the main site but not the CMS. And that's not a "bug" in the CMS,
it's a normal consequence of using one.

Seems to be a "bug" in the same way Y2K was a bug -- not accounting
for the way people actually do things. I don't know anything about
CMS (only found out about it in this thread!), but surely software
designed to manage content shouldn't require that content to deviate
from standard practices -- and relative path format is standard
practice for addressing a file that's in the same domain!

Mark
--
Miscellaneous remarks athttp://Mark.Goodge.co. uk
"All this talk of getting old, it's getting me down my love"

[Prisoner at War]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On May 13, 6:09 pm, Disco Octopus <di...@discooct opus.comwrote:

>
>
That is interesting. I have seen this before in some WYSIWYG inline
editors. Would they be using something called tiny_mce or something
like that? I think that there is a flag in the configuration of this
WYSIWYG editor that says to "resolve paths when saving content" or
"dont resolve paths". Just a guess and a thought from past experience
with these types of tools.

I don't know how SBI! runs its affairs, but someone else has also
noted that characteristic of content management software...so when I
get a new webhost, how do I make sure this kind of situation doesn't
arise again? What kind of per-sales question would I ask of them --
"can I use relative file path format?"?

[Mark Goodge]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On Wed, 14 May 2008 14:00:25 -0700 (PDT), Prisoner at War put finger
to keyboard and typed:

>On May 13, 6:09 pm, Disco Octopus <di...@discooct opus.comwrote:

>>
>>
>That is interesting. I have seen this before in some WYSIWYG inline
>editors. Would they be using something called tiny_mce or something
>like that? I think that there is a flag in the configuration of this
>WYSIWYG editor that says to "resolve paths when saving content" or
>"dont resolve paths". Just a guess and a thought from past experience
>with these types of tools.

>
>
>I don't know how SBI! runs its affairs, but someone else has also
>noted that characteristic of content management software...so when I
>get a new webhost, how do I make sure this kind of situation doesn't
>arise again? What kind of per-sales question would I ask of them --
>"can I use relative file path format?"?

Using relative URLs is often not a good idea anyway, as it means that
things will break if you move pages around. I use absolute URLs (ie,
file paths relative to the document root) as a matter of course - it's
no harder to type, and it avoids having to change things later.

If you're creating a website that's essentially static, though (ie,
not generated on the fly by means of server-side scripting taking
content from a database), then there's no real need for a CMS at all.
It's a lot easier to write the pages offline and upload them by ftp.

Mark
--
Pointless waffle (again) at http://mark.x.tc
"All I want is to find an easier way to get out of our little heads"

[Mark Goodge]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On Wed, 14 May 2008 13:46:14 -0700 (PDT), Prisoner at War put finger
to keyboard and typed:

>On May 14, 3:05 pm, Mark Goodge <use...@listmai l.good-stuff.co.uk>
>wrote:

>>
>In this
>context, the first and last of your examples are "absolute" to the
>browser, as they will work from any page on his site no matter what
>its location in the URL structure. The middle two, by contrast, will
>only work if the page is in the document root itself:
>>
>http://www.ego-management.org/image-files/awww4.png
>image-files/awww4.png
>./image-files/awww4.png
>/image-files/awww4.png

>
>Sorry, can't follow along...all I know is that "absolute" is like
>telling someone the full mailing address of a geographical location,
>while "relative" is like telling someone "it's down the block on the
>corner."

I think you need to read up on how HTML works. This is basic stuff,
and if you're having problems understanding what I've just written
then you're a lot further back in the class than you really ought to
be.

>If that is the case then that also explains his problem. If you're
>using an online CMS - particularly a javascript-based WYSIWYG CMS -
>then you need to make your image paths absolute URLs (ie, relative to
>the document root), as the relative path from the CMS is usually
>different to the relative path from the public location of the page.

>
>But why only the first src attribute; how come the other two can
>remain relative, as I'd had them originally??

Probably because the CMS can guess the correct relative URL for the
rollovers if at least one of them is absolute.

>If you use a relative URL when creating pages in an online CMS, then
>either the page will work in the CMS but not in the main site, or work
>in the main site but not the CMS. And that's not a "bug" in the CMS,
>it's a normal consequence of using one.

>
>Seems to be a "bug" in the same way Y2K was a bug -- not accounting
>for the way people actually do things.

It's not a bug, because it's how the web is supposed to work.

I don't know anything about
>CMS (only found out about it in this thread!), but surely software
>designed to manage content shouldn't require that content to deviate
>from standard practices -- and relative path format is standard
>practice for addressing a file that's in the same domain!

No, it isn't. Relative addressing is one way to do it for a file
that's in a fixed position relative to the page that references it.
But that's precisely what you don't have when you use a CMS - the page
being created in the CMS editor is in a different location to the
public version of the same page. So the relative address isn't fixed.
Absolute URLs, on the other hand, will work anywhere.

Mark
--
Stuff, some of it good, at http://www.good-stuff.co.uk
"Love is a precious thing, worth the pain and suffering"

[Prisoner at War]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On May 14, 5:15 pm, Mark Goodge <use...@listmai l.good-stuff.co.uk>
wrote:

>
>
I think you need to read up on how HTML works. This is basic stuff,
and if you're having problems understanding what I've just written
then you're a lot further back in the class than you really ought to
be.

I know HTML; what I didn't get was what you meant by what you said.
What's "absolute to the browser" mean?? What is a "document root"??

Probably because the CMS can guess the correct relative URL for the
rollovers if at least one of them is absolute.

Yes, of course; but if it's smart enough to put find the correct
relative URL for the remaining src attributes, why isn't it smart
enough to have found the first one when it was also in relative path
format? I mean, what's the CMS thinking?? It knows my website is
"http://www.my-website.com/" so why not just assume that any files
called for will be within that domain?? Why not just assume that
"image-files/image.gif" is just going to be appended after the URL???

It's not a bug, because it's how the web is supposed to work.

Huh? The web is supposed to work...how?? First src attributes in an
<imgtag are supposed to be in absolute path format, according to the
W3C??? That's what we're talking about here. Why a CMS should
require such an oddity is why it's a programming bug.

No, it isn't. Relative addressing is one way to do it for a file
that's in a fixed position relative to the page that references it.
But that's precisely what you don't have when you use a CMS - the page
being created in the CMS editor is in a different location to the
public version of the same page. So the relative address isn't fixed.

"The page being created in the CMS editor"...huh?? ? "In a different
location [than] the public version of the same page"...so my page is
uploaded to a CMS which then actually does something to it *and then*
puts it out onto the web???

I thought content management software only keeps tabs on stuff...not
actually work on 'em!!

Still, it seems bizarre that programmers couldn't have taken into
account how most src attributes in your typical <imgtag are written
(that is, in relative path names)...if it's valid HTML/CSS/whatever,
the CMS ought to work with it instead of requiring someone to work
around the CMS! Hence it is a bug in the manner of Y2K -- computers
should work for man, not the other way around.

Absolute URLs, on the other hand, will work anywhere.

Eh??? I'd read that *relative* file name paths are what are portable
and "will work anywhere," since their relation is always to one
another and not to some root that may change with webhosts or
directory re-organizations.. ..

Mark
--
Stuff, some of it good, athttp://www.good-stuff.co.uk
"Love is a precious thing, worth the pain and suffering"

[Chaddy2222]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On May 15, 6:19 am, Prisoner at War <prisoner_at_.. .@yahoo.comwrot e:

On May 14, 3:04 am, Chaddy2222 <spamlovermailb ox-
>
sicur...@yahoo. com.auwrote:
>

By not actually being valid code. Read about quirks vs standards mode
and gain a good understanding of it before doing anything. It can have
a large impact on how your pages work on the web.
For a start your page does not have a doctype, give it one and
validate your pages. DO NOT use XHTML

>
If I haven't mentioned it before to you (I did to somebody -- a
handful of somebodies now, but can't remember whomever exactly), let
me do so:
>
The original webpage had doctypes, etc., etc.  This current one,
"test.html, " was designed to help tech support diagnose the issue by
removing the visual "clutter" of extraneous code that did not
highlight the problem (of a simple perfectly valid image-swap not
working).
>
Again, I don't know why you guys keep looking all over the place when
the problem is right in front of you: a simple and valid image-swap
does not work when hosted by their server.  It's got nothing to do
with XHTML, etc.
>

I have set my editor to not use
it for all new sites that I develop. Google for the reasons why you
should not use it.

>
But XHTML is a W3C recommendation, is it not?  Despite my disdain for
usenet rules like top-posting, sig-snipping, etc., I do believe in web
standards.  Personally I prefer the laissez-faire ethos of good ol'
HTML, but I understand why for consistency's sake (that is,
consistency with the "semantics" of developing and future
technologies) XHTML might be preferred.
>
>
>

It's not supported by any version of Internet Explorer.

http://hixie.ch/advocacy/xhtml

--
Regards Chad. http://freewebdesignonline.org

[Andy Dingley]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On 14 May, 22:10, Mark Goodge <use...@listmai l.good-stuff.co.uk>
wrote:

Using relative URLs is often not a good idea anyway, as it means that
things will break if you move pages around. I use absolute URLs (ie,
file paths relative to the document root) as a matter of course - it's
no harder to type, and it avoids having to change things later.

Bollocks.

[Andy Dingley]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On 14 May, 21:19, Prisoner at War <prisoner_at_.. .@yahoo.comwrot e:

But XHTML is a W3C recommendation, is it not? Despite my disdain for
usenet rules like top-posting, sig-snipping, etc., I do believe in web
standards. Personally I prefer the laissez-faire ethos of good ol'
HTML, but I understand why for consistency's sake (that is,
consistency with the "semantics" of developing and future
technologies) XHTML might be preferred.

If you can write that paragraph, you don't even begin to understand
what XHTML is, let alone the question of whether to use it.

[Andy Dingley]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On 15 May, 03:29, Prisoner at War <prisoner_at_.. .@yahoo.comwrot e:

Using relative URLs is often not a good idea anyway, as it means that
things will break if you move pages around. I use absolute URLs (ie,
file paths relative to the document root) as a matter of course - it's
no harder to type, and it avoids having to change things later.

>
Hmm! I'd read that *absolute* paths are the ones which are not good
for "portabilit y," should the need ever arise.

It's not a simple one-off situation.

For your situation here, where the assets are "local" to the page,
then stick with relative paths and URLs. If you move these things,
they're likely to move en masse (and the relative relation stays the
same).

If you're referring to "site-wide" assets, then use a URL that refers
to the server root, but still avoid using the hostname. This URL
should ideally relate to some virtual location on the server, so that
it has a short, simple path fragment in the URL. e.g.

<img src="/assets/our-logo.gif" >

<link rel="stylesheet " type="text/css" src="/styles/site.css" >

It's quite possible that "site.css" actually lives in the directory /
app/apache0/vhost/AcmeCo/assets/May08-makeover/styles/
but the server config points the path fragment /styles/ straight to
it.


The problem starts when you have "shared" images that are used by a
number of pages. Do you treat these as "stable" site-wide assets, or
as mobile assets tied to a page? Your call, per job.


I'd also suggest ditching the "images" sub-directory too. It's a faff
to have to use it in the image paths on every page and it doesn't add
much. Certainly _don't_ think that a site needs one single directory
called "pages" and another called "images". You have file extensions
to describe this sort of format-based selection.

Instead structure your site to represent some logical presentation of
it, quite possibly one that can be mirrored directly into the URLs and
will then give the users a "sensible" conceptual structure by which to
navigate the site (this whole idea is more complicated than it looks
though, especially if you're using CMS). You ought to use plenty of
subdirectories to strucure things - splitting things up generally
works better than piling everything into one. At one extent, it's not
unreasonable to name every page index.htm, make _every_ page on the
site its own subdirectory. That way you never need a pagename in any
URL, you just use directory names alone and let the default document
mechanism handle the rest.

If you have fine-grained structure of directories, you don't need
"images" sub-directories to separate out the assets. Just place them
in the same directory as the HTML. Simpler.

[Prisoner at War]

Re: My Very Strange Webhost, SBI! -- Opinions, Please

On May 15, 2:13 am, Mark Goodge <use...@listmai l.good-stuff.co.uk>
wrote:

>
>
That's not generally true when referring to absolute URLs. It is true
when referring to absolute file paths, but that's a different thing
altogether - HTML and client-side scripting (such as Javascript)
*never* need absolute file paths. I suspect that you're being misled
by different usages of the word "absolute".

You deduce correctly: I've been talking about file paths all along,
but I see that you're referring to URLs...?? Yes, it's true that that
first src attribute is an URL

Then they're talking crap. Best to leave them, and find a webhost that
isn't trying to bamboozle you with false promises.

The interesting thing about them is that they never actually promise
anything, naturally enough...no, they suggest it, allowing you to
"fill in the blanks"...I must say, I've learned a lot about internet
marketing from them...sure, this is all "common knowledge" (even, in
some cases, "common sense") but as a newbie it was nice to have had it
all collected in one place, as it were...but time to be moving on,
you're right. I just figure a webhost should work around me, instead
of me around them....

Mark
--
Miscellaneous remarks athttp://Mark.Goodge.co. uk
"When your thoughts are too expensive to ever want to keep"