7:35 p.m.
I have tidied up one of my websites to make better use of CSS, and now
intend to add some new pages to it. Of course I want to keep it
Netsurf-friendly.
The <head> section of each article includes the usual link to my
stylesheet, which (in Linux filepath syntax) might be
2018.css or
../2018.css or
../../2018.css etc
depending how many branches back it roosts on the directory tree.
Advice from Linuxland tells me that simply prefixing a "/" with no
dots before it makes the link "absolute" (to the root of the website)
rather than relative to the page where we are when writing the link.
IT would be quite handy&welcome to use this trick rather than having
to adjust the links for stylesheet, page background and top-of-page
graphic if I relocate a page in the directory structure. This indeed
works when viewing my page online.
However, when developing the page in the local copy of my site rather
than online, the "absolute" version of the link looks for the *root
directory of my own RiscOS drive* rather than the root of the website.
If I make a copy of the stylesheet as $.2018/css Netsurf is happy.
Is there a way around this? Is there some setting I would need to
make in Netsurf to define what I mean by "/" as root? (Presumably
there is such a setting in my ISP's software, for I am not being taken
to the root of their drive!)
Excuse me if this is a dumb question, but I haven't been here before.
http://glastonburyconservation.org.uk if anybody wants to have a look.
--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscos-swshow.co.uk Feb 24
8:07 p.m.
On 19/02/18 10:35, Jim Nagel wrote:
[snip]
Is there a way around this?
Use a webserver to serve the root directory of the web
site you're developing, and point your browser at
http://localhost/
I believe WebJames can do this on RISC OS.
Cheers,
--
Michael Drake http://www.codethink.co.uk/
12:46 a.m.
Michael Drake wrote on 19 Feb:
Use a webserver to serve the root directory of the web
site you're developing, and point your browser at
http://localhost/ I believe WebJames can do this on RISC OS.
Thanks. I've now got Webjames successfully serving local pages, and
obeying those "absolute" links -- /logo.gif and /paper.jpg (the
background pattern) which appear on every page of the site.
I have also discovered that simply putting favicon.ico in the root
directory causes that icon to appear beside the URL automagically:
absolutely no extra code at all is required in the HTML.
One problem still has me scratching my head:
- Netsurf displays the pages served up via Webjames perfectly,
except that it is NOT obeying the stylesheet (which is /2018.css )
even though the Webjames log records a GET success for the CSS file
just as it did for the logo and paper and favicon.
- Yet when Netsurf fetches the identical page from my ISP's server,
it DOES obey the CSS.
Same problem for pages farther out the directory tree. All pages now
specify /2018.css in handy "absolute" shortform.
--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscos-swshow.co.uk Feb 24
12:49 a.m.
On Mon, Feb 19, 2018 at 03:46:41PM +0000, Jim Nagel wrote:
- Netsurf displays the pages served up via Webjames perfectly,
except that it is NOT obeying the stylesheet (which is /2018.css )
even though the Webjames log records a GET success for the CSS file
just as it did for the logo and paper and favicon.
- Yet when Netsurf fetches the identical page from my ISP's server,
it DOES obey the CSS.
Complete guess: is your CSS source file set to the CSS type, or plain
text type? I'm not sure how NetSurf reacts to CSS files served with an
appropriate Content-Type header.
B.
12:57 a.m.
In article <20180219154920.GJ3127(a)platypus.pepperfish.net>, Rob Kendrick
<rjek(a)netsurf-browser.org> wrote:
On Mon, Feb 19, 2018 at 03:46:41PM +0000, Jim Nagel wrote:
> - Netsurf displays the pages served up via Webjames perfectly,
> except that it is NOT obeying the stylesheet (which is /2018.css )
> even though the Webjames log records a GET success for the CSS file
> just as it did for the logo and paper and favicon. - Yet when Netsurf
> fetches the identical page from my ISP's server, it DOES obey the
> CSS.
Complete guess: is your CSS source file set to the CSS type, or
plain
text type? I'm not sure how NetSurf reacts to CSS files served with an
appropriate Content-Type header.
Also, are you fetching your CSS with a suffix of ?v=1 or something?
Browsers are notorious for not fetching CSS files if they think they
don't need a new one, even if it's changed. Putting a fake variable on
the end seems to force a fetch.
--
Tim Hill
timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk
11:18 p.m.
Rob Kendrick wrote on 19 Feb:
On Mon, Feb 19, 2018 at 03:46:41PM +0000, Jim Nagel wrote:
> - Netsurf displays the pages served up via Webjames perfectly,
> except that it is NOT obeying the stylesheet (which is /2018.css )
> even though the Webjames log records a GET success for the CSS file
> just as it did for the logo and paper and favicon.
> - Yet when Netsurf fetches the identical page from my ISP's server,
> it DOES obey the CSS.
Complete guess: is your CSS source file set to the CSS type, or
plain
text type? I'm not sure how NetSurf reacts to CSS files served with an
appropriate Content-Type header.
Thanks, Rob. Sorry for delayed response. (I think I covered the
point elsewhere in the thread, though.)
Yes, the source file was called !2018.css but its RiscOS filetype was
still text. I changed the filetype to CSS and Netsurf is now happy.
I can't quite get my head around this (not that it matters, since
things are working now):
- The distant server (probably running on Linux) does not care about
RiscOS filetypes and Netsurf correctly displays pages from there when
my !2018.css has RiscOS filetype as text
- The local development server (Webjames) does a successful GET of
!2018.css whatever its RiscOS filetype, but Netsurf does not display
pages correctly when !2018.css is Ro-filetyped as text, and *does*
display them correctly when !2018.css Ro-filetype is changed to CSS.
--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscos-swshow.co.uk Feb 24
12:26 a.m.
On Fri, Feb 23, 2018 at 02:18:18PM +0000, Jim Nagel wrote:
- The distant server (probably running on Linux) does not care about
RiscOS filetypes and Netsurf correctly displays pages from there when
my !2018.css has RiscOS filetype as text
That's because it will be using the file extension to decide what
content type to tell the browser, where WebJames uses the RISC OS
metadata.
- The local development server (Webjames) does a successful GET of
!2018.css whatever its RiscOS filetype, but Netsurf does not display
pages correctly when !2018.css is Ro-filetyped as text, and *does*
display them correctly when !2018.css Ro-filetype is changed to CSS.
See above.
B.
1:58 a.m.
On 19/02/18 15:46, Jim Nagel wrote:
- NetSurf displays the pages served up via WebJames perfectly,
except that it is NOT obeying the stylesheet
I guess WebJames is not serving the
CSS file with the "text/css"
MIME type.
I think there's a mimemap file that lives somewhere in !Boot, which
may need updated with an entry for CSS.
WebJames may ship with an example mimemap for this.
Cheers,
--
Michael Drake http://www.codethink.co.uk/
2:38 a.m.
Michael Drake wrote on 19 Feb:
On 19/02/18 15:46, Jim Nagel wrote:
> - NetSurf displays the pages served up via WebJames perfectly,
> except that it is NOT obeying the stylesheet
I guess WebJames is not serving the CSS file with the
"text/css" MIME
type. I think there's a mimemap file that lives somewhere in !Boot,
which may need updated with an entry for CSS. WebJames may ship with
an example mimemap for this.
Ah, thanks again, Michael! Found the required Mimemap syntax for a
CSS entry in the "Solved problems" section of the Webjames helpfile.
However, I then found I *already* have that entry in my Mimemap!
Then a closer look: I found that the file 2018/css had RiscOS
filetype Text. Changed filetype to CSS (&f79), relaunched Webjames --
and now everything is fine!
(Begs the question: why does RiscOS actually bother having a specific
filetype for a CSS file? It's only text. Doubleclicking it only
loads it into a text editor. Nothing else in RiscOS except the
browser, as far as I know, has any use for a CSS file. The HTML page
invokes the file as "xxx.css" and explicitly declares it as a
stylesheet. The distant host doesn't care about RiscOS filetypes.
What was the mechanism that made the filetype matter in this case?
Academic, I guess, now that it's working!)
--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscos-swshow.co.uk Feb 24
3:05 a.m.
In article <f4f7e9cc56.jim(a)6.abbeypress.net>,
Jim Nagel <netsurf(a)abbeypress.co.uk> wrote:
why does RiscOS actually bother having a specific filetype for a CSS
file? It's only text. Doubleclicking it only loads it into a text
editor.
Many files are just plain text, but the filetype is helpful in that an icon
can be assigned, helping to spot the required file visually by type rather
than looking for obscure file extensions or looking at contents.
It's how RISC OS does it, and I like it that way!
John
PS and yes, it is actually RISC OS, not RiscOS with its pseudo camel-case.
Editor should have spotted that one!
--
| John Williams
| johnrw(a)ukgateway.net
3:48 a.m.
In article <56ccec687fJohnRW(a)ukgateway.net>, John Williams
<JohnRW(a)ukgateway.net> wrote:
[Snip]
PS and yes, it is actually RISC OS, not RiscOS with its pseudo
camel-case. Editor should have spotted that one!
The confusion of Risc<half space>PC and RISC OS is not a new phenomenon
just as WebJames is often called Webjames.
How about "doubleclicking" Vs double-clicking?
None of the meaning is lost in what was written and while I too like to
get things OCD-right, I think we can leave enforcement to trademark
owners!
Where's that old spelling I used to use in these cases. Oh yes!
The new Welsh operating system, rhisck/oH.eSs
3:21 a.m.
In article <f4f7e9cc56.jim(a)6.abbeypress.net>, Jim Nagel
<netsurf(a)abbeypress.co.uk> wrote:
[Snipped]
(Begs the question: why does RiscOS actually bother having a
specific
filetype for a CSS file?
You don't need to give your HTML or CSS files an extension with WebJames.
It seems to use the filetype to create the MIME data.
Conversely, files with no .ext on an Apache server seem to be treated as
text and sent to the browser. I rely on this with
http://timil.com/riscos/mimemap/mimemap
These are identical (ancient) files:
Apache (no .ext)
http://timil.com/links and
WebJames (no .ext but correct HTML RISC OS filetype)
http://dev.timil.com/timil.com/links
--
Tim Hill
timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk
8:12 p.m.
On Mon, Feb 19, 2018 at 10:35:22 +0000, Jim Nagel wrote:
Is there a way around this? Is there some setting I would need to
make in Netsurf to define what I mean by "/" as root? (Presumably
there is such a setting in my ISP's software, for I am not being taken
to the root of their drive!)
The best way is if you can run a local web server and serve up the content
similarly to how it'd be served in production. A common web development tactic
is to run up a simple server and visit http://localhost/ or
http://localhost:8000/ or similar, having it serve the site "normally" from
there.
If you have a Linux system available you could store the content on there,
and if everything is basic static content then you can serve a site trivially
by:
cd /path/to/website/base
python -m SimpleHTTPServer
it'll tell you what port it's on, and you can visit http://linuxbox:someport/
If you're stuck developing the site on RiscOS, then consider using a RAM disc
or similar because then your site would be a $ on the FS.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
12:34 a.m.
On 19 Feb 2018 Jim Nagel wrote:
Is there a way around this? Is there some setting I would need to
make in Netsurf to define what I mean by "/" as root? (Presumably
there is such a setting in my ISP's software, for I am not being taken
to the root of their drive!)
I have the same problem. I'm running WebJames with its root directory
as the directory containing my web sites. That means that "/" on the
local site takes me back to the top level and not the root of the site
I want.
Therefore all my links are relative if possible and links are explicit
i.e. the index file is /index.html rather than /. The only places
where relative links don't work are in error and acknowledgement pages
which could be invoked from different levels of the hierarchy. These
are addressed relative to the root i.e. /something and I put up with
them not working on the local sites.
The other exceptions are in mouseover stuff for drop-down menus where
they're not going to work in NetSurf anyway, and in data files for
scripts for the same reason. For html forms I use absolute addresses.
I'm afraid that's just a workaround rather than a solution. I don't
think your ISP's software comes into it unless your ISP is also your
hosting company. Normally your web site will be loaded into
public_html on the server and your ftp parameters should reflect this,
so public_html is your root directory. I suppose you could push the
site down a level to match your local setup and then have redirects
for any links that go to the top level by default but I haven't tried
this.
--
Richard Porter http://www.minijem.plus.com/
t: @westernexplorer mailto:ricp@minijem.plus.com
I don't want a "user experience" - I just want stuff that works.
12:49 a.m.
Richard Porter wrote on 19 Feb:
... I don't think your ISP's software comes into it unless
your ISP is
also your hosting company.
Sorry: I used the wrong term. I did mean the hosting company.
--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscos-swshow.co.uk Feb 24
1:09 a.m.
In article <92f5dfcc56.jim(a)6.abbeypress.net>, Jim Nagel
<netsurf(a)abbeypress.co.uk> wrote:
Richard Porter wrote on 19 Feb:
> ... I don't think your ISP's software comes into it unless your ISP
> is also your hosting company.
Sorry: I used the wrong term. I did mean the hosting company.
No, you didn't. Hosting is an internet service provided by an ISP, a
"Hosting ISP". It may not provide (your) Internet Access, which is just
ONE of the things an ISP may do. One of them. Some ISPs do not provide
internet connections at all; perhaps only email.
ISP should not be seen as synonymous with an "Access provider ISP".
I have seen the press making this mistake all the time. Amazing how it
has now become received wisdom.
Even Wikipedia gets this right.
--
Tim Hill
timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk
6:14 p.m.
New subject: Re Wikipedia (OT)
Tim Hill wrote on 19 Feb:
Even Wikipedia gets this right.
If it didn't, then of course it would now, because you surely have
signed up for an account as one of the crowd-sourced and peer-reviewed
editors and you would have contributed the required correction.
--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscos-swshow.co.uk Feb 24
1:24 a.m.
Richard Porter wrote on 19 Feb:
I have the same problem. I'm running WebJames with its root
directory
as the directory containing my web sites. That means that "/" on the
local site takes me back to the top level and not the root of the site
I want.
Eureka! I tried setting a system variable in
Choices.Webjames.Attributes, on the DocumentRoot line and Webjames
happily served it. So in that attributes file I now have
DocumentRoot <webjames-thissite$dir>
and in the root directory of each of my sites I now have an obeyfile
called !!hey-Webjames (the plings to put it at the top) containing
set webjames-thissite$dir <obey$dir>
filer_run SSD.$.Network.Servers.!Webjames
(your pathname might differ)
Put a copy of the identical obeyfile into the root of each site.
So when I want to point Webjames at a single specific local site,
simply doubleclick !!hey-Webjames in that site's root directory.
In Netsurf's URL bar type just "localhost" and Webjames serves it.
(Webjames doesn't seem to mind the apparently repeated filer_run line
when it has already been running for a previous site.)
--
Jim Nagel www.archivemag.co.uk
|| See you at the show? www.riscos-swshow.co.uk Feb 24
10:11 p.m.
[Email copy of news posting to comp.sys.acorn.misc]
Posted in Netsurf users, as it follows up a question and in c.s.a.misc
because it's not NetSurf specific. Please reply in Usenet.
In article <6c94decc56.ricp(a)user.minijem.plus.com>, Richard Porter
<ricp(a)minijem.plus.com> wrote:
On 19 Feb 2018 Jim Nagel wrote:
> Is there a way around this? Is there some setting I would need
to
> make in Netsurf to define what I mean by "/" as root? (Presumably
> there is such a setting in my ISP's software, for I am not being
> taken to the root of their drive!)
I have the same problem. I'm running WebJames with its root
directory
as the directory containing my web sites. That means that "/" on the
local site takes me back to the top level and not the root of the site
I want.
I was just having a similar problem to Jim's original and have a solution
wrt setting the BASE tag depending on server, local or distant. The same
technique could of course be applied to just the style sheet location, or
whatever. It uses PHP but don't let that put you off.
Let's imagine the URL of the distant server you upload to is
http://domain.tld/
and your local WebJames copy is here
http://localhost/domain/
First of all, save this fragment of php as file 'pathname/php' and/or
'pathname.php' in both locations:
<?php
$pathname = dirname(__FILE__);
print("Pathname = $pathname");
?>
Then run it from your browser:
http://domain.tld/pathname.php
and
http://localhost/domain/pathname.php
You will see something like
Pathname = /ISPname/users/8/4/s112113/htdocs
and
Pathname = /Sunfish::Web_Sites.$/domain
(Or, at least, that's what I see: my WebJames serves sites stored on a
NAS accessed with Sunfish)
Once you know a string to differentiate the location of where your file
is running, this would then work in the HEAD of your index.php file, or
whatever, in place of the BASE tag:
<?php
$pathname = dirname(__FILE__);
if ( substr($pathname,1,7) == "ISPname" ) {
$base = "http://domain.tld/";
} else {
$base ="http://localhost/domain/";
}
print("<base href=\"$base\">\n");
?>
If your WebJames server has an external URL, use that in place of
localhost, obviously.
HTH
(Replies in c.s.a.misc please; this is OT for NetSurf-Users.)
--
Tim Hill
timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk
12:40 a.m.
In article <9f33c3cc56.jim(a)6.abbeypress.net>, Jim Nagel
<netsurf(a)abbeypress.co.uk> wrote:
[Snip]
2018.css or ../2018.css or ../../2018.css etc
[Snip]
Is there a way around this?
[Snip]
I'm going to run away and hide after writing this:
1. Apart from files in the root, link them all with ../ and copy the css
file into every directory except the last in each branch using an obey
file which you keep in the root so you can update them if you make a
change to the master. Yeah, okay, those people screaming at the back,
maybe not if you have hundreds of directories, or
2. Re-organise - flatten - your site so that this isn't a problem, or
3. Learn PHP. ;-) This can read the current directory of the script/page
that's running and depending on the host it finds, sets either
"[nothing]" or "/[extra path]" as the value of a path which prefixes
"/Style.css?v=1"
A copy of the script:
http://timil.com/riscos/_to-do/css_slash.txt
Output of the script from my servers:
Distant:
http://timil.com/riscos/_to-do/css_slash.php
Local:
http://87.127.161.109/timil.com/riscos/_to-do/css_slash.php
You'll need to change the value of the first variable to the first eight
letters of the string returned as "current path" from your local server
and also the second variable, which is the name of the local folder
containing you web site, assuming it's in your server's root. You can see
timil.com is kept locally in a folder with the same name as its proper
site's URL.
Then replace your CSS sheet <link...> with everything between <head> and
</head> in the script on every page, and, oh, you'll also have to change
the name of your files from <name>/htm to <name>/php and make sure your
provider supports PHP and also that you're running a server with PHP
(such as WebJames+PHP).
There. No changes to servers required. ;-)
--
Tim Hill
timil.com : tjrh.eu : butterwick.eu : blue-bike.uk : youngtheatre.co.uk
2033
days inactive
2046
days old
netsurf-users@netsurf-browser.org
19 comments
7 participants
participants (7)
-
Daniel Silverstone -
Jim Nagel -
John Williams -
Michael Drake -
Richard Porter -
Rob Kendrick -
Tim Hill