*Without* using JavaScript or other active client-side scripting,
server-side includes or frames, is there a way to include a standard
header on all pages within a site? The design goal is to have the
header links and title graphic on every page kept in some single
place, so that a change to the header data doesn't require changing
every single html file on the site. (The sites in question are my
personal sites - see signature).
In other words, I want a way to do this in regular (non-framed) non-
active HTML and CSS only. It seems like there ought to be a way to do
it with CSS, but I really can't work it out.
Thanks for any pointers...
--
Lewin A.R.W. Edwards
Projects - http://www.zws.com/
Personal - http://www.larwe.com/
> *Without* using JavaScript or other active client-side scripting,
> server-side includes or frames, is there a way to include a standard
> header on all pages within a site?
> In other words, I want a way to do this in regular (non-framed) non-
> active HTML and CSS only. It seems like there ought to be a way to do
> it with CSS, but I really can't work it out.
Why would you think there ought to be a way to do it in CSS? CSS is
about making things pretty, not supplying content.
--
dorayme
> > In other words, I want a way to do this in regular (non-framed) non-
> > active HTML and CSS only. It seems like there ought to be a way to do
> > it with CSS, but I really can't work it out.
>
> Why would you think there ought to be a way to do it in CSS? CSS is
> about making things pretty, not supplying content.
Perhaps mainly because I'm not a CSS expert - if you look at my sites
you'll see they are 90% text (=content) and *very* little sugar. It
just seemed to me that there should be a way to do it. But I'm happy
to accept that CSS doesn't contain an answer - do you have a
suggestion for something that does?
I don't want to use active scripting because I personally tend to run
with it disabled. And I CERTAINLY won't use Java or plugin nonsense
like Flash!
I don't want to use frames because historically they have caused me
problems with content not being indexed properly by search engines.
I don't want to use SSIs because they severely impact performance on
my provider.
That didn't seem to leave much else in the way of technologies. If I
have to choose a single evil I guess it would be frames. I'd like to
hear of an alternative though.
> On Sep 20, 9:22 pm, dorayme <doraymeRidT...@optusnet.com.au> wrote:
>
>> > In other words, I want a way to do this in regular (non-framed) non-
>> > active HTML and CSS only. It seems like there ought to be a way to do
>> > it with CSS, but I really can't work it out.
>>
>> Why would you think there ought to be a way to do it in CSS? CSS is
>> about making things pretty, not supplying content.
>
> Perhaps mainly because I'm not a CSS expert - if you look at my sites
> you'll see they are 90% text (=content) and *very* little sugar. It
> just seemed to me that there should be a way to do it. But I'm happy
> to accept that CSS doesn't contain an answer - do you have a
> suggestion for something that does?
>
> I don't want to use active scripting because I personally tend to run
> with it disabled. And I CERTAINLY won't use Java or plugin nonsense
> like Flash!
> I don't want to use frames because historically they have caused me
> problems with content not being indexed properly by search engines.
> I don't want to use SSIs because they severely impact performance on
> my provider.
That's odd.
> That didn't seem to leave much else in the way of technologies. If I
> have to choose a single evil I guess it would be frames. I'd like to
> hear of an alternative though.
The usual method it to include some sort of build step when making the
site. There are literally dozens of options from WYSIWYG site editing
software to using a macro processor and something like make.
If you don't know what these last two are, then they are probably not
right for you. They may be one day, but there is more to learn that
way. Unfortunately I don't know much about the former. You may get
some actual recommendations for others...
--
Ben.
Absolutely. Look up "server-side includes" and possibly some server-side
programming technology such as PHP, ASP.NET, Perl, etc.
> The usual method it to include some sort of build step when making the
> site. There are literally dozens of options from WYSIWYG site editing
> software to using a macro processor and something like make.
Hmm... I didn't include that in the list because it's not the design
goal - I don't want to have to re-upload every single HTML file. I
don't know if it's my hosting provider (Verve) or something else, but
I frequently get dropped/stalled connections.
I'm kinda surprised that this is really the "usual" method though. It
seems like a really common requirement, it astounds me that there is
no elegant solution.
At the moment I'm using the free version of Visual Web Developer
(inside VirtualBox on my MacBook - it's the best free WYSIWYG CSS-
supporting HTML editor I can find). I'm not sure if it supports this
feature. I don't "do" the traditional text processing languages like
perl, but I guess it would be a simple matter to write a C program
that recursively descends the tree, looks for some magic tokens like
<!--##headerbegin##--> <!##--headerend##--> and replaces whatever's in
between with my generic site header. I was hoping to be able to have a
"news of the week" or "news of the day" item in this header, i.e.
relatively frequent updates without rewriting everything.
> > *Without* using JavaScript or other active client-side scripting,
> > server-side includes or frames, is there a way to include a standard
>
>
> Absolutely. Look up "server-side includes" and possibly some server-side
> programming technology such as PHP, ASP.NET, Perl, etc.
You missed the part where I explicitly stated that I did not want to
use server-side includes. They cause a big performance penalty on my
hosting provider. A minor point is that they also make it harder for
me to migrate the site around different servers. The less technology I
use in my site, the less proprietary/provider-specific infrastructure
I'm relying on.
Look up pre-processors.
--
Berg
> On Sep 20, 9:22 pm, dorayme <doraymeRidT...@optusnet.com.au> wrote:
>
> > > In other words, I want a way to do this in regular (non-framed) non-
> > > active HTML and CSS only. It seems like there ought to be a way to do
> > > it with CSS, but I really can't work it out.
> >
> > Why would you think there ought to be a way to do it in CSS? CSS is
> > about making things pretty, not supplying content.
>
> Perhaps mainly because I'm not a CSS expert
No, it is *not* because of this. It is because of a basic
misunderstanding about the role of CSS. CSS is to make things pretty, it
has nothing at all in principle to do with content or meaning. There are
some CSS provisions to add a bit of this and that by way of content but
it is an oddity and unsuited to your purpose.
> - if you look at my sites
> you'll see they are 90% text (=content) and *very* little sugar. It
> just seemed to me that there should be a way to do it. But I'm happy
> to accept that CSS doesn't contain an answer - do you have a
> suggestion for something that does?
>
Yes, two.
1. For small sites of a few pages, say 5 to 20, don't mess about with
"includes", more bother than is worth it unless you are real pro and it
is like water off a duck's back. Just learn about how to insert text
globally in a good text editor using Find & Replace. No doubt, along
will be coming advice to get a preprocessor, but don't bother if you
have a text editor to find and replace over all the files in a folder
(*You* do something once, and *it* does something 20 times). When you
update to the server, you still do one thing, namely drag a group of 20
from your PC to the server window in your FTP program.
I am conscious of telling you to do what you have expressly said you do
not want to do. But I press on insensitively anyway...
2. Use a server side include. Here is a snippet from one of my website
HTML docs as it appears on my computer:
<?php include
($_SERVER['DOCUMENT_ROOT'].'/somedomain/includes/banner.inc'); ?>
And in the folder "includes" on the server, I have, amongst other
things, a file with banner material markup called banner.inc
There are other ways to have includes, not using PHP.
But one way or another, you have to learn how to do this and also have a
server that does not mess about and provides for such things. Even many
free servers will give you these things these days.
> I don't want to use active scripting because I personally tend to run
> with it disabled. And I CERTAINLY won't use Java or plugin nonsense
> like Flash!
> I don't want to use frames because historically they have caused me
> problems with content not being indexed properly by search engines.
> I don't want to use SSIs because they severely impact performance on
> my provider.
>
> That didn't seem to leave much else in the way of technologies. If I
> have to choose a single evil I guess it would be frames. I'd like to
> hear of an alternative though.
You could reconsider Frames and try to mitigate all the evil powers that
ray out from this poor child of a much maligned technology. Read and
take some but not too much heart from:
<http://www.markparnell.com.au/articles/frames.php>
--
dorayme
Just btw, now I see this reply to another poster, in my last post, the
construction you saw in my example php include was for the express
purpose of portability, at least on all Unix type servers, both my home
one and the most popular public ones. (Window's servers are a bit of a
nuisance and you need different path instructions. But just try to avoid
such servers if you can).
Sounds to me like you might need to get a different host or (for a small
fee) I could ask my dark sunglass team of men to pay them a little visit
and advise them not to be giving you so much trouble.
--
dorayme
You will need some form of server side process to do this. If you don't
want to use SSI, you could use a scripting language, such as Perl or
PHP, etc., to assemble each page before it is delivered. Perl has a very
simple yet robust templating module just for this purpose. I would not
be surprised if PHP did as well. I don't know if the load on the server
would be any less than with SSI.
http://search.cpan.org/~samtregar/HTML-Template-2.9/Template.pm
zwsd...@gmail.com wrote:
>I've been looking for references for some weeks now, but haven't found
>an answer to the following question. I'd love some help on this:
>
>*Without* using JavaScript or other active client-side scripting,
>server-side includes or frames, is there a way to include a standard
>header on all pages within a site? The design goal is to have the
>header links and title graphic on every page kept in some single
>place, so that a change to the header data doesn't require changing
>every single html file on the site. (The sites in question are my
>personal sites - see signature).
>
>In other words, I want a way to do this in regular (non-framed) non-
>active HTML and CSS only. It seems like there ought to be a way to do
>it with CSS, but I really can't work it out.
Get a text editor that can search and replace large blocks
of text in multiple files. It takes me about 15 seconds
more to I can change the header in a thousand webpages
instead of just one.
BTW, what do you have against server-side includes?
--
Guy Macon
<http://www.GuyMacon.com/>
zwsd...@gmail.com wrote:
>
>Ben Bacarisse wrote:
>
>> The usual method it to include some sort of build step when making the
>> site. There are literally dozens of options from WYSIWYG site editing
>> software to using a macro processor and something like make.
>
>Hmm... I didn't include that in the list because it's not the design
>goal - I don't want to have to re-upload every single HTML file. I
>don't know if it's my hosting provider (Verve) or something else, but
>I frequently get dropped/stalled connections.
So? A good FTP client will keep plugging away at it until
all the files have been replaced.
>I'm kinda surprised that this is really the "usual" method though. It
>seems like a really common requirement, it astounds me that there is
>no elegant solution.
There is an elegant solution. SSI. You rejected it because of
performance issues, but it is still an elegant solution.
Is there any chance that your server admins are afraid of huge
resource-hogging build-it-on-the-fly SSI but would have no real
problem with a simple common-header SSI? Those really don't
use that many resources, and actually *reduce* some kinds of
resource use (less disk bandwidth, for example).
>I don't "do" the traditional text processing languages like
>perl, but I guess it would be a simple matter to write a C program
>that recursively descends the tree, looks for some magic tokens like
><!--##headerbegin##--> <!##--headerend##--> and replaces whatever's in
>between with my generic site header.
Easy enough in C or pretty much any other language except BEST.
zwsd...@gmail.com wrote:
>I don't want to use SSIs because they severely impact performance on
>my provider.
And they let you use CSS? I wouldn't be surprised if processing
your CSS results in more use of server resources than a simple
header-replace SSI would.
> I've been looking for references for some weeks now, but haven't found
> an answer to the following question.
In the good old times, people would just have looked at a FAQ and got the
correct answer in a few seconds. But time has passed by, the FAQs are
covered with dust, and their defenders have gone away...
> *Without* using JavaScript or other active client-side scripting,
> server-side includes or frames, is there a way to include a standard
> header on all pages within a site?
You exclude here everything except preprocessing.
> In other words, I want a way to do this in regular (non-framed) non-
> active HTML and CSS only.
This seems to exclude preprocessing too, since it's definitely not HTML (and
CSS has nothing to do with the issue really). So you are asking "how to do
include without using any of the mechanisms for it?"
Well, to be honest, although the dusty old FAQs said - and the HTML
specifications implicitly say - that there is no include mechanism in HTML,
beyond the fake inclusion via frames, iframe, or object, there _is_. The
only problem is that no browser implements it.
Since the very beginning of HTML as "officially" defined, it has had an
inclusion mechanism by virtue of being an SGML application, later an XML
application. For fun, here is how you could do it "modern HTML", i.e. XHTML:
?xml version="1.0" standalone="no" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ENTITY headers SYSTEM
"http://www.cs.tut.fi/~jkorpela/test/headers.xhtml">
]>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >
<head>
<title>Inclusion demo</title>
</head>
<body>
&headers;
<h1>Inclusion demo</h1>
<p>Hello world!</p>
</body>
</html>
(And you could do quite the same thing in pre-XHTML HTML as well.)
But you will see that web browsers won't grok it. They will fail in
different ways. What comes closest perhaps is, somewhat surprising, Internet
Explorer in the situation where you serve this document as plain XML,
application/xml. It will render the document as XML source but after
properly processing the inclusion; and you could always use a style sheet to
have it rendered in some real way.
To be very honest, modern HTML specifications require a specific DOCTYPE
declaration to be used, so they exclude this feature. But you could always
use HTML 2.0, which has no such restriction! :-) And then you could ask some
students to write a browser that supports HTML 2.0 - the first one in the
world that does that! - and try and find a make the world use that browser
or other HTML 2.0 conformant browsers.
So it's time to wake up and state that there ain't no include in HTML as
implemented in the so-called real world. You need to use _some_ mechanism
external to HTML.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
> 1. For small sites of a few pages, say 5 to 20, don't mess about with
Which these aren't. One of my sites has over 600 HTML files.
> 2. Use a server side include. Here is a snippet from one of my website
This isn't in the solution space, I'm afraid. I did make that clear at
the start.
> You could reconsider Frames and try to mitigate all the evil powers that
> <http://www.markparnell.com.au/articles/frames.php>
That's an interesting link, though it didn't tell me anything new, or
what I want to know. The bit I find particularly ironic is that right
down the bottom of that page is apparently an exact answer to my
question: "One of the major reasons that many developers use frames is
that they can include a single navigation file on multiple pages. Here
are some alternative ways of achieving the same goal." Unfortunately,
when I click the link I get to a parked domain offering links to web
design, premature ejaculation, and masturbation.
Having said all this, talking about frames again has made me think a
bit more and leads me to believe that the "right" answer is possibly
an IFRAME as it appears to be more bot-friendly than a normal frameset.
> >I don't want to use SSIs because they severely impact performance on
> >my provider.
>
> And they let you use CSS? I wouldn't be surprised if processing
> your CSS results in more use of server resources than a simple
> header-replace SSI would.
What does CSS do on the server side? My understanding is that they're
rendered entirely at the client end. The HTML file references the
stylesheet, and the browser loads it. No server-side processing.
> Having said all this, talking about frames again has made me think a
> bit more and leads me to believe that the "right" answer is possibly
> an IFRAME as it appears to be more bot-friendly than a normal
> frameset.
If you have started thinking that IFRAME is the solution, it's time to
re-think the problem.
No amount of reduction in site management work (like moving from manually
maintained headers to iframed header file) could ever justify all the
problems you create by using IFRAME.
How often do you intend to change the common header? Monthly? Weekly? Well,
in that case, you should design the site in a new way that does not require
such frequencies of changes there. Design something that lasts a couple of
years. (And when it will need modifications, you will probably want, or be
forced to do, a complete redesign anyway.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
> > bit more and leads me to believe that the "right" answer is possibly
> > an IFRAME as it appears to be more bot-friendly than a normal
>
> If you have started thinking that IFRAME is the solution, it's time to
> re-think the problem.
I did some googling on problems with IFRAMEs, and I can't see any show-
stoppers, care to explain why it is a problem? As near as I can work
out it is exactly the kind of client-side #include feature I want;
though not 100% bot-friendly I can work around this by having a (not-
intended-for-users-to-click) link to the IFRAME src page at the bottom
of the body content.
> How often do you intend to change the common header? Monthly? Weekly? Well,
The idea is to put a "new this week" type of link there, for example a
thumbnail picture of progress on one of my projects.
> How often do you intend to change the common header? Monthly? Weekly? Well,
> in that case, you should design the site in a new way that does not require
> such frequencies of changes there. Design something that lasts a couple of
> years. (And when it will need modifications, you will probably want, or be
> forced to do, a complete redesign anyway.)
I cannot speak for the OP, but a navigation bar linking to other articles
could be something that changes monthly, is wanted to appear with the
lastest contents on each page, and shall be updated at only one place.
Nowadays, this is done with a CMS but when one has not so many pages (say,
about 30) the labour of configuring a CMS and updating its software might
exceed the labour saved by it. -- This is not a new requirement and SSI
is exactly tailored to such needs: simple enough to be used without
learning, and still doing something useful if not more is needed.
Excluding SSI and all other solutions that might help renders the question
somewhat academic.
BTW, I am not sure CSS cannot be tricked to do the job somehow. But even
if possible, that would be an extremely bad solution: Web pages must not
depend on CSS, only their appearance may.
--
Helmut Richter
> Get a text editor that can search and replace large blocks
> of text in multiple files. It takes me about 15 seconds
> more to I can change the header in a thousand webpages
> instead of just one.
This leaves me with the problem of reliably uploading a thousand HTML
files every time I change one byte of the header. It also means the
"last updated on" date shown in search engines is nonsense.
Maybe my difficulties with the former are an ftp client issue, but I
doubt it as I've used a couple.
> BTW, what do you have against server-side includes?
They cause a perceptible page load time hit on my provider, and at one
time (maybe still, buried in the FAQs somewhere) the provider
explicitly advised against using server-side processing "just" to
serve up a standardized banner on every page of the site. IIRC they
recommended including a javascript file that does a bunch of
document.write()s to generate the menu text, and invoking the
appropriate function inside the HTML file. Not an elegant or indeed
workable solution!
Right now I don't want to change providers because apart from this one
issue they're a good service at a good price.
> On Sep 20, 9:45 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> The usual method it to include some sort of build step when making the
>> site. There are literally dozens of options from WYSIWYG site editing
>> software to using a macro processor and something like make.
>
> Hmm... I didn't include that in the list because it's not the design
> goal - I don't want to have to re-upload every single HTML file.
That does not follow unless you change the common parts. A good build
systems just uploads the parts that change.
> I
> don't know if it's my hosting provider (Verve) or something else, but
> I frequently get dropped/stalled connections.
You also say that SSI imposes a large cost on your hosting provider.
If the upload problems are also their fault, you should change
provider (for me, just one of these would be enough).
> I'm kinda surprised that this is really the "usual" method though. It
> seems like a really common requirement, it astounds me that there is
> no elegant solution.
What is inelegant about a good build system?
> At the moment I'm using the free version of Visual Web Developer
> (inside VirtualBox on my MacBook - it's the best free WYSIWYG CSS-
> supporting HTML editor I can find). I'm not sure if it supports this
> feature. I don't "do" the traditional text processing languages like
> perl, but I guess it would be a simple matter to write a C program
> that recursively descends the tree, looks for some magic tokens like
> <!--##headerbegin##--> <!##--headerend##--> and replaces whatever's in
> between with my generic site header.
Your perfect time to learn Perl (or at least one use of it)! Perl has
a template tool that can do exactly this (and, of course, much more),
ttree, which processes a tree of template files.
> I was hoping to be able to have a
> "news of the week" or "news of the day" item in this header, i.e.
> relatively frequent updates without rewriting everything.
I don't see why "everything" needs to be re-written. A build system
will change just those files that need to be changed and no others. A
good remote update program will upload only those files that have
changed. For small sites this is a good solution. An update involves
typing:
ttree -s source
sitecopy --update name
(or in a couple of cases "make" rather than "ttree").
--
Ben.
> On Sep 21, 7:27 am, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
<snip>
>> How often do you intend to change the common header? Monthly? Weekly? Well,
>
> The idea is to put a "new this week" type of link there, for example a
> thumbnail picture of progress on one of my projects.
Do you think that putting such a link in the common header will mean
that common header changes weekly? If so, you need to re-think how
your links are written.
--
Ben.
> > Hmm... I didn't include that in the list because it's not the design
> > goal - I don't want to have to re-upload every single HTML file.
>
> That does not follow unless you change the common parts. A good build
> systems just uploads the parts that change.
Which in this case would be every .html file on the entire site,
because as you'll see if you visit those sites, they all have exactly
the same header (currently implemented with tables).
Roughly once every year I grit my teeth and rewrite every single file
on the site. I am getting to this point right now, but not looking
forward to it.
> > don't know if it's my hosting provider (Verve) or something else, but
> > I frequently get dropped/stalled connections.
>
> You also say that SSI imposes a large cost on your hosting provider.
> If the upload problems are also their fault, you should change
> provider (for me, just one of these would be enough).
I'm really not sure where the problem lies with ftp sessions. It might
partly be the fault of my cable provider; I have pretty crappy
upstream data rates. (At home I run an Apache server to collect data
from some embedded devices, using dyndns to keep it visible - larwe
dot ath dot cx - you can poke it and see it is really slow because it
relies on the same upstream connection).
Currently I pay $15/month for 1Gb space, 5Gb/month transfers,
unlimited subdomains and addon domains and various other features.
Last time my wife and I tried a different provider, it was a disaster
- on paper it looked like a good deal but it went up and down every
other week, no support, etc. So we are leery about experiments with
other providers :)
> What is inelegant about a good build system?
A system that has to re-upload every file looks pretty inelegant to
me.
> Your perfect time to learn Perl (or at least one use of it)! Perl has
yeah - I knew someone would suggest this :) perl is just one of those
languages, like APL, which looks daunting to an asm/C/C++/[rarely]
Java guy. I'm an embedded systems developer, not an app-level person.
It's much less work to me to hack up a quick one-page C program to do
the one function I need than it would be to learn perl. I realize this
would be different if I intended to add CGI to the site, but since I
have no intention of *ever* running any scripts on the server side,
there doesn't seem to be any compelling reason to learn perl.
> > I was hoping to be able to have a
> > "news of the week" or "news of the day" item in this header, i.e.
>
> I don't see why "everything" needs to be re-written. A build system
> will change just those files that need to be changed and no others. A
What I don't see is why you don't appreciate that this is every
single .html on my site. Counting all three sites I administer, this
is just over 1100 files.
> > The idea is to put a "new this week" type of link there, for example a
> > thumbnail picture of progress on one of my projects.
>
> Do you think that putting such a link in the common header will mean
> that common header changes weekly? If so, you need to re-think how
> your links are written.
<frustration> What am I not making clear here? Look at www.zws.com,
specifically the logo and links above the cyan separator bar. I intend
to move all that logo/link material into this "unified header scheme",
and I also intend to add some "news of the day/week/month/whatever"
link(s) as well, for example a link to whatever article I have
published most recently, special pricing on one of my books, a once-in-
a-lifetime opportunity to buy one of my used socks on eBay, whatever.
The point being that no matter where people enter the site, they will
see in the header a link to whatever I think is of most interest
today. That could update every couple of days in the worst case. I
don't want to upload every single HTML file every time this happens -
life's too short. I already mentioned the other technical constraints
I'm trying to apply to select a technology for this function.
> On Sep 21, 1:46 am, Guy Macon <http://www.GuyMacon.com/> wrote:
<snip>
>> BTW, what do you have against server-side includes?
>
> They cause a perceptible page load time hit on my provider, and at one
> time (maybe still, buried in the FAQs somewhere) the provider
> explicitly advised against using server-side processing "just" to
> serve up a standardized banner on every page of the site. IIRC they
> recommended including a javascript file that does a bunch of
> document.write()s to generate the menu text, and invoking the
> appropriate function inside the HTML file.
Fortunately you have done the decent thing an named them (else where)
so we all know another name to avoid. Thanks for that.
However I am baffled and don't want to malign them without more
detailed knowledge. If you mean vervehosting.com, their cheapest
package includes PHP and the knowledge base of the site tells you how
to turn SSI on for all files as if it were the most normal thing in
the world. They don't seem to discourage it at all. Maybe that is
only in the "client area". A link would help, because on the surface
they look quite good.
--
Ben.
> Sounds to me like you might need to get a different host or (for a small
> fee) I could ask my dark sunglass team of men to pay them a little visit
> and advise them not to be giving you so much trouble.
Heh. I think it is not malicious so much as the fact that I'm not
paying (nor willing to pay) for premium services - so my pages are
hosted on a virtual server without much horsepower.
If your links have to change every day or so then, of course, so would
every built page. Most sites can get away with links that don't
change even though the content does. If you can't (or don't want to)
do that then you would, indeed, have to do lots of uploads.
If you want lots of very specific and ever changing links, then this
does not really fit the model of a common header. I'd be inclined to
have one link that never changes ("what's new") and have that page
include the link to your socks on ebay. This is one example or what I
meant by rethinking how your links works.
--
Ben.
Nothing more than an SSI.
> My understanding is that they're
> rendered entirely at the client end.
The same is true for an SSI.
> The HTML file references the
> stylesheet, and the browser loads it. No server-side processing.
With an SSI, you don't have an http request. The "processing"
performance impact is marginal. I don't know why you're mentioning it
at all. The syntax is simple an not proprietary/provider-specific.
It's far better than an object/iframe or anything else that requires
an http request.
> I did some googling on problems with IFRAMEs, and I can't see any
> show- stoppers, care to explain why it is a problem?
I guess people who understand the problems don't care about writing about
them much. Checking my dusty piles of pages, I found
http://www.cs.tut.fi/~jkorpela/html/iframe.html
which is fairly old but might contain some observations that are still
relevant.
Just a point I have probably not addressed there: You should use the same
character encoding in the iframed document as in the containing document.
This is due to errors in popular browsers: they cannot handle a mixture.
This is not an obstacle as such, just something to take care of - and
strikingly often ignored.
If you start implementing the idea of an iframed header part, you will
encounter some nasty formatting problems. For example, would you set the
height of iframe in pixels, or how? If it contains both text and images,
you're in trouble: you should use the em unit for sizing text boxes and px
unit for images, and you can't combine them in a value of a property in CSS
(still less in HTML, of course).
> As near as I can
> work out it is exactly the kind of client-side #include feature I
> want;
No, it is logically quite different - it creates a subwindow where an
external document is displayed independently, instead of really _including_
its content in the document's content flow.
> The idea is to put a "new this week" type of link there, for example a
> thumbnail picture of progress on one of my projects.
Well then I don't really see why you want to create a problem, instead of
using a page template that has an element for such a link, say
<div class="new">
<a href="new.html"><img src="new.jpg" alt="New this week" width="200"
height="100"></a>
</div>
(properly styled of course)
and you just change the content of the image new.jpg and the page new.html.
If you want to include text as well (or a more suitable alt="..." text),
then you are in the area where you should really use some of the different
non-HTML techniques for inclusion, e.g. some of those mentioned in this
discussion. For example, SSI has some efficiency impact, but it is hardly
noticeable unless you have a _very, very_ popular site.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
> them much. Checking my dusty piles of pages, I foundhttp://www.cs.tut.fi/~jkorpela/html/iframe.html
> which is fairly old but might contain some observations that are still
> relevant.
Grr. I built a test layout based on iframes, and it looks fairly nice,
but of course breaks at narrow window sizes because there is no neat
way to auto-size an iframe to the height of the content within it. I
don't know if I can live with it or not. My current layout breaks at
small sizes too, but not as badly - at least everything still remains
accessible. Anything that scrolls outside visibility inside a fixed-
size iframe with no scrollbars might as well not be there.
So I start to take another look at SSIs and I now remember the other
reason I don't like them - I can't preview them without slowly
uploading them to my server. What a pain. This particular need - as
shown by Google searches - is not unique.
My situation is not common headers, which indeed I handle by
preprocessing, but common *page content* in two different sites with
different structures.
Here's a sample URL:
http://oakroadsystems.com/math/tiskurt.htm
The actual content (inside the IFRAME) is at my college's Web site:
http://www.tc3.edu/instruct/sbrown/ti83/skurt.htm
There may be a better way to accomplish what I'm trying to do, which
is to make the content available through my Web site and through the
College Web site, without duplicate uploading all the content. (There
are several dozen instructional pages like this, and the average page
is updates maybe two or three times a year.) Suggestions?
Notce that just above the IFRAME I do give a link for busting out of
the frame.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
So install Apache server on your local machine. Test locally, then
upload when it looks right.
> <frustration> What am I not making clear here?
What you are not making perfectly clear, given what has been said to
you, is what *good reason* you have not to use includes. The reasons you
have given are not good.
"Doctor, my head hurts when I bang it against the wall"
"So, don't bang it against the wall"
"This isn't in the solution space, I'm afraid. I did make that clear at
the start of this consultation"
--
dorayme
> So I start to take another look at SSIs and I now remember the other
> reason I don't like them - I can't preview them without slowly
> uploading them to my server.
You can preview them by running a home server. Get a Mac and do yourself
a favour, comes with a server, you just tick a box and its on.
The other thing, if you upload an include to your server, unless it is
absolutely massive and you are on dialup, it should be very very quick
not slow.
Are you on earth?
--
dorayme
Or keep the computer you have and install Apache which will install on
whatever OS you have...nc
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
You're joking, right? If it were a free service, they'd have every right
to discourage, or even ban, server side processing. This should be
unacceptable for paid service.
> Right now I don't want to change providers because apart from this one
> issue they're a good service at a good price.
It may be that they were a good service for you at one time, but you do
yourself no favors by staying with a service that doesn't give you the
functionality (SSI or other server side process) that you really need at
this point.
Bite the bullet and get a better hosting service.
--
Berg
> dorayme wrote:
> > In article
> > <04f9d2b7-c9b3-4981...@d77g2000hsb.googlegroups.com>,
> > zwsd...@gmail.com wrote:
> >
> >> So I start to take another look at SSIs and I now remember the other
> >> reason I don't like them - I can't preview them without slowly
> >> uploading them to my server.
> >
> > You can preview them by running a home server. Get a Mac and do yourself
> > a favour, comes with a server, you just tick a box and its on.
>
> Or keep the computer you have and install Apache which will install on
> whatever OS you have...nc
Or don't bother with either and get broadband, a good external host, a
good FTP program and see the results.
--
dorayme
I would always advise one test their site on a local development server
before going live, even personal websites can be wonderful spam relays
with sloppy coding.
Oh on the broadband thing, is there some extraterrestrial mind-control
thing you can to to "adjust" the minds of TPTB in the phone and cable
companies here to get some broadband here?
> dorayme wrote:
> > Or don't bother with either and get broadband, a good external host, a
> > good FTP program and see the results.
> >
>
> I would always advise one test their site on a local development server
> before going live, even personal websites can be wonderful spam relays
> with sloppy coding.
>
I suppose. But I bet most people would not know what coding that does
not let in spammers from coding that can looks like. You can advise all
you like. But, me, not being from earth has an earthy feeling and I say,
don't worry too much, just do your tests in a test folder on the
external site, even password protect it if you like. And stop worrying
so much.
> Oh on the broadband thing, is there some extraterrestrial mind-control
> thing you can to to "adjust" the minds of TPTB in the phone and cable
> companies here to get some broadband here?
My mind control system is so poor where you are concerned that when I
gave you valuable tips ages ago on how to get more work given your
considerable talents, so you could afford satellite (or even to move
your whole family to New York and be done), you never said a single
thing.
I think you like being far off in the middle of somewhere, you just
don't like the dialup. I forget where that is, I know you have denied it
is in Texas and I know it is not in Finland or Iceland but somewhere in
America.
Which is OK. See The Family Man where Nicholas Cage tries to persuade
his wife to move to New York and what her instincts were.
--
dorayme
Brain fart. You are entirely correct. I was thinking .htaccess
and for some stupid reason wrote about CSS. My apologies. Sorry
about that.
(Note to self: next time, smoke crack *after* posting to Usenet.)
--
Guy Macon
<http://www.GuyMacon.com/>
The Game of Why Don't You / Yes But
In the game of WDYYB, someone asks ask for suggestions from a group,
but as each suggestion is made, he responds with a reason why it
won't work. Advanced players start the discussion by excluding the
more popular answers so as to reach the payoff sooner.
"Why Don't You, Yes But" can proceed indefinitely, with any number
of players in the answerer role until everyone becomes exhausted
and can think of no other solutions.
In some cases, the payoff comes when the questioner brings out his
own pet idea and proclaims it as only workable solution -- often
accompanied by reasons why anyone who points out a flaw in his
solution is wrong.
A variation of this is justify a claim that no solution exists;
once he has justified his problem as being insoluble he can avoid
the hard work of implementing a solution.
In other cases, the payoff comes from the questioner building up
his self-importance by supposedly showing the inadequacy of the
group. He has just "proved" that all who try to help are no
smarter, no more capable, no way superior to the needy one.
In any case, the questioner has already decided what the answer
is before asking the question.
> > reason I don't like them - I can't preview them without slowly
> > uploading them to my server.
>
> You can preview them by running a home server. Get a Mac and do yourself
> a favour, comes with a server, you just tick a box and its on.
This message is brought to you by my 2.16GHz Core 2 Duo MacBook.
Though I do have an Apache server running on a Linux box (it runs my
svn server and acts as the home-base backend for some experimental
embedded devices I have out in the field). If I develop something on
that server, though, will it be just "drag and drop" when I move it to
the environment on my hosting provider? I don't get that impression;
all the FAQs I read talk about all kinds of hardcoded paths and
environment-specific stuff.
This is what I mean when I say I don't like doing stuff that relies on
proprietary infrastructure.
> Are you on earth?
Yes, however I'm on Earthlink cable (resold TWC) in NYC.
> On Sep 21, 7:14 pm, dorayme <doraymeRidT...@optusnet.com.au> wrote:
>
> > > reason I don't like them - I can't preview them without slowly
> > > uploading them to my server.
> >
> > You can preview them by running a home server. Get a Mac and do yourself
> > a favour, comes with a server, you just tick a box and its on.
>
> This message is brought to you by my 2.16GHz Core 2 Duo MacBook.
>
Right. Then are you running Mac OS X? Go into Sys Prefs/Sharing and tick
Personal Web Sharing. You can then see your internal URL address at the
bottom of the pane.
Make up an index.html file or modify any that is already there in your
Sites folder. Don't mess with this folder for a while, just keep all
your website files in there. In this index.html make yourself a menu
that targets your site(s). For example, your present project that has
600 pages, make a link to its index page.
> Though I do have an Apache server running on a Linux box
on *a* Linux box? We talking a different machine now?
> (it runs my
> svn server and acts as the home-base backend for some experimental
> embedded devices I have out in the field). If I develop something on
> that server, though, will it be just "drag and drop" when I move it to
> the environment on my hosting provider? I don't get that impression;
> all the FAQs I read talk about all kinds of hardcoded paths and
> environment-specific stuff.
>
> This is what I mean when I say I don't like doing stuff that relies on
> proprietary infrastructure.
>
I gave you an example of one of my own includes earlier and I chose it
because of its essential portability. I have the same line in my site
whether it is via my own server or on an external one (all bets are off
with a commercial Windows server though. I operate on a couple of these
and I also use php and includes but it is more complicated and gives me
more of a headache)
Give me an example url of a simple set of two or three pages with a menu
(for example) that is repeated on the three pages. I will put it an
external server that you can access and I will deck it out with an
include and walk you through it. Jonathan Little will correct me all the
way for greater perfection and you will be the great beneficiary. But I
won't do it if there is a single CSS or HTML error in anything. Your
choice.
> > Are you on earth?
>
> Yes, however I'm on Earthlink cable (resold TWC) in NYC.
You are in NYC and on cable and you experience slow? I am on ADSL, I am
at the bottom of the earth, and frankly, the speed makes me dizzy.
Sometimes I cut my broadband connection and use dialup to relax and
drink with...
--
dorayme
> I've been looking for references for some weeks now, but haven't found
> an answer to the following question. I'd love some help on this:
> *Without* using JavaScript or other active client-side scripting,
> server-side includes or frames, is there a way to include a standard
> header on all pages within a site? The design goal is to have the
> header links and title graphic on every page kept in some single
> place, so that a change to the header data doesn't require changing
> every single html file on the site. (The sites in question are my
> personal sites - see signature).
Okay, this has been kicked around for quite a while. You don't want to do
this client-side (insofar as that might be possible), you don't want to do
it with any of the server-side tools available. The only real alternative
is to change the pages. And this is a real alternative.
Preprocessors do not have to run on a server. You can automate the whole
process with your choice of make utilities, so that nothing gets changed
that does not have to be changed and nothing gets upload that has not been
changed. This might be a daunting task via dial-up if you want dozens of
new graphics on thousands of pages, each of which was many 100k or so. But
for changing one or two graphics and a few lines of text on a few hundred
pages most of which are under 10k it is very practical (and of course with
broadband or with shell access to your server it would be trivial).
--
Lars Eighner <http://larseighner.com/> use...@larseighner.com
Dynamic linking error: Your mistake is now everywhere.
> Though I do have an Apache server running on a Linux box (it runs my
> svn server and acts as the home-base backend for some experimental
> embedded devices I have out in the field). If I develop something on
> that server, though, will it be just "drag and drop" when I move it to
> the environment on my hosting provider? I don't get that impression;
> all the FAQs I read talk about all kinds of hardcoded paths and
> environment-specific stuff.
>
Sure! If you use server side scripting like PHP your can have your site
adjust for whatever environment it is running in. I always setup a
config file that my main script using to get values for local vs live
site values. Test for the server name to tell which environment your are
in so the if
if( $_SERVER['SERVER_NAME']=='www.example.com' ) {
//we are live use live site values
}
else {
// we are on local development server
// I use a local TLD like 'www.example.lan'
// use local development server values
}
> This is what I mean when I say I don't like doing stuff that relies on
> proprietary infrastructure.
So then if I move my hosting, like I am doing currently I just edit
*one* config file and I am done!
Hell, nobody else does.
--
Blinky
Killing all posts from Google Groups
The Usenet Improvement Project: http://improve-usenet.org
Need a new news feed? http://blinkynet.net/comp/newfeed.html
May I used that on a page at Blinkynet, in my Usenet section? You
would be credited.
dorayme wrote:
>(all bets are off with a commercial Windows server though.
>I operate on a couple of these and I also use php and
>includes but it is more complicated and gives me more
>of a headache)
Are you sure you mean "Windows server" (Operating System is
Microsoft Windows, Web server could be Apache, IIS, or other)
or did you actually mean to specify a Microsoft IIS Server?
>I am at the bottom of the earth,
Not so. The Arctic Ocean is at the bottom of the earth.
On my wall I have a map made in Australia that clearly
shows this. :)
--
___ |\
__| . \_| \
/ \
/' .\
\ . |
Perth --> \. _. /
|__---' \_._/
http://linuxmafia.com/~rick/afw/#perth
Lars Eighner wrote:
>Preprocessors do not have to run on a server. You can automate the whole
>process with your choice of make utilities, so that nothing gets changed
>that does not have to be changed and nothing gets upload that has not been
>changed. This might be a daunting task via dial-up if you want dozens of
>new graphics on thousands of pages, each of which was many 100k or so. But
>for changing one or two graphics and a few lines of text on a few hundred
>pages most of which are under 10k it is very practical (and of course with
>broadband or with shell access to your server it would be trivial).
It's not so bad on dialup either. A good FTP client will keep plugging
away at the job no matter how many errors or disconnections it sees
until it gets the job done. Running it at night avoids slowing down
your other online activity, and is a good policy when updating websites
anyway.
No problem at all. If convenient, please include a link to
<http://www.GuyMacon.com/>, but I don't insist on that.
The words above are mine, but the basic idea came from
Eric Berne (See <http://en.wikipedia.org/wiki/Eric_Berne>
and <http://www.ericberne.com/>), and I wouldn't mind at all
if he got sole credit.
You wrote what I'm quoting; most of our thoughts are built upon the
foundations of others.
That said, do you have a problem with your faithful editor (me! <g>)
changing the name to, simply, "Yes-But"? It's catchier, and the "Why
Don't You" is explained in the text.
http://blinkynet.net/comp/yesbut.html
Blinky the Shark wrote:
>That said, do you have a problem with your faithful editor (me! <g>)
>changing the name to, simply, "Yes-But"? It's catchier, and the "Why
>Don't You" is explained in the text.
No problem at all.
> dorayme wrote:
>
> >(all bets are off with a commercial Windows server though.
> >I operate on a couple of these and I also use php and
> >includes but it is more complicated and gives me more
> >of a headache)
>
> Are you sure you mean "Windows server" (Operating System is
> Microsoft Windows, Web server could be Apache, IIS, or other)
> or did you actually mean to specify a Microsoft IIS Server?
>
Yes, I meant the very latter. Thanks for clearing this up. (But on my
own PC (as well as my Mac) I have Apache servers.
> >I am at the bottom of the earth,
>
> Not so. The Arctic Ocean is at the bottom of the earth.
> On my wall I have a map made in Australia that clearly
> shows this. :)
This is actually a serious matter, you try hanging on to a globe when
you are even *roughly* towards the bottom of it. Why do you think rf,
Chaddy and I are a bit volatile. We face danger at all times, that's why.
--
dorayme
> What you are not making perfectly clear, given what has been said to
> you, is what *good reason* you have not to use includes. The reasons you
>
> "Doctor, my head hurts when I bang it against the wall"
If you want to use this analogy - which is fine - consider me as
someone with strong religious beliefs who doesn't want any part of
COTS medicine. I want the toadstools and grasshopper saliva cure, not
aspirin. Thus far it seems the IFRAME meets this description.
> > Though I do have an Apache server running on a Linux box
>
> on *a* Linux box? We talking a different machine now?
Yes. I do essentially all of my work on three machines:
- MacBook running OSX 10.4 for all my email, office productivity, web
development. It has VirtualBox running both Windows and Linux for
various embedded development toolchains. I spend 90% of my time on
this machine.
- a tablet PC running XP Tablet used for taking notes and occasionally
for running JTAG tools that positively cannot work inside VirtualBox
on the Mac.
- an x86 desktop PC running Ubuntu, with a large (3TB) RAID array.
This is a backend server for those devices I mentioned earlier, and it
also holds my SVN repository.
> Give me an example url of a simple set of two or three pages with a menu
> (for example) that is repeated on the three pages. I will put it an
FWIW my IFRAME test - NOT fully debugged - is at http://www.larwe.com/test/
but it doesn't yet meet your criteria.
> > > Are you on earth?
>
> > Yes, however I'm on Earthlink cable (resold TWC) in NYC.
>
> You are in NYC and on cable and you experience slow? I am on ADSL, I am
> at the bottom of the earth, and frankly, the speed makes me dizzy.
Yep. I actually migrated from Melbourne to New York the best part of
ten years ago, back in the days when pay TV was a new thing not
available in all neighborhoods.
I'm well aware of it, having been on both sides of the net (?
goalposts? ring? home plate?).
I asked for a solution that's as low-tech as possible because hi tech
breaks. I don't /like/ most of the solutions that have been posited so
far, but I'm trying out two of them to determine how disruptive
they'll be. As for my pet answer, well, I don't like it very much
either. All conceivable solutions will break under certain
circumstances; I've got to make a judgement as to which will be least
disruptive to me.
The real, most efficient, and effective solution is includes, be they
SSI, PHP, ASP.net, CF whatever... Break pages in to logical common
components and assemble server-side. Anything less will be limited,
cumbersome, inefficient or a combination of all three. Since you already
have a local development *nix server then I would say PHP includes would
be your best bet. The local server will show you your composite content
during development and maintenance and then you will only have to edit
and upload content that changes *once*.
See the note at the foot of:
http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME
which links to
http://www.w3.org/TR/html401/struct/objects.html#embedded-documents
I don't know if this does what you want, or how well different
browsers will handle it, but it does appear to be an alternative
to iframe, scripting, or server-side includes.
(I'd be interested to know if anyone has actually tried this
for, for example, a navigation menu. I will try it when I have
time, but that won't be for a while :( )
>
>
>
> Blinky the Shark wrote:
>
>>That said, do you have a problem with your faithful editor (me! <g>)
>>changing the name to, simply, "Yes-But"? It's catchier, and the "Why
>>Don't You" is explained in the text.
>
> No problem at all.
Thanks. I'll link to it now from my Usenet index page.
The "self-taught" part of your rez was quite a surprise.
> See the note at the foot of:http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME
I think from a cursory read this is my IFRAME solution, which works
though others here have deprecated it.
There are no real subpages here, but my test implementation is at
http://www.larwe.com/test/ - it works, but breaks when the browser
width is too narrow. Also, my particular demo page has a transparent
PNG, which Internet Explorer won't handle - it looks OK in Firefox/
Safari/etc but I guess I have to fix that issue.
Mac, linux what is the difference? "Drag and drop", "Plug and Pray"
what else du you want? Are you on crack too?
> when I move it to
> the environment on my hosting provider? I don't get that impression;
> all the FAQs I read talk about all kinds of hardcoded paths and
> environment-specific stuff.
>
> This is what I mean when I say I don't like doing stuff that relies on
> proprietary infrastructure.
What are you talking about. Proprietary infrastructure?
Your pages have to be served by an web server. On every webserver you
can use SSI. An simple SSI can look like this:
<!--#include virtual="header.html"-->
This file called 'header.html' just have to lay on your folder under
the document root. That don't depended on an proprietary
infrastructur. That's the same if the document root is on an Mac,
Linux or Window server, and if you're using IIS, Apache or whatever.
> > Are you on earth?
>
> Yes, however I'm on Earthlink cable (resold TWC) in NYC.
I don't know if that is an excuse.
> On Sep 22, 12:10 pm, David Stone <no.em...@domain.invalid> wrote:
>
>> See the note at the foot of:http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME
>
> I think from a cursory read this is my IFRAME solution, which works
> though others here have deprecated it.
You did not "see the note at the foot" (David Stone gave the direct
link as well).
--
Ben.
Not as bad as iframes. But then, all "hi tech" seems to break at your
end.
> > I don't /like/ most of the solutions that have been posited so
> > far, but I'm trying out two of them to determine how disruptive
> > they'll be. As for my pet answer, well, I don't like it very much
> > either. All conceivable solutions will break under certain
> > circumstances; I've got to make a judgement as to which will be least
> > disruptive to me.
I wonder what your conclusion would be.
> See the note at the foot of:http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME
>
> which links tohttp://www.w3.org/TR/html401/struct/objects.html#embedded-documents
>
> I don't know if this does what you want, or how well different
> browsers will handle it, but it does appear to be an alternative
> to iframe, scripting, or server-side includes.
They renders more or less the same.
> (I'd be interested to know if anyone has actually tried this
> for, for example, a navigation menu. I will try it when I have
> time, but that won't be for a while :( )
If you have an formula like those on Stan Browns page,
http://www.tc3.edu/instruct/sbrown/ti83/skurt.htm
, you could use xhtml and present it with MathML:
<object data="math.xhtml" type="application/xhtml+xml" style="height:
5em; width: 100%; overflow: auto"
<img src="math.gif" alt="..." longdesc="description.html">
</object>
You could do the same with figures in SVG.
No browsers seems to support intrinsic dimensions (anymore) for
embedded html/xhtml documents.
You can take a look some testcases at:
http://joliclic.free.fr/html/object-tag/en/
> On 22 Sep, 18:10, David Stone <no.em...@domain.invalid> wrote:
[snip]
> > See the note at the foot
> > of:http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME
> >
> > which links
> > tohttp://www.w3.org/TR/html401/struct/objects.html#embedded-documents
> >
> > I don't know if this does what you want, or how well different
> > browsers will handle it, but it does appear to be an alternative
> > to iframe, scripting, or server-side includes.
>
> They renders more or less the same.
[snip]
> You can take a look some testcases at:
> http://joliclic.free.fr/html/object-tag/en/
Interesting. May I suggest that you add the links for the specific
test cases into each section? That way, readers don't have to scroll
all the way to the bottom of the page if they are only interested in
embedding, say, a flash object.
One potential problem appears to be that the NoScript plugin (which
I leave on by default) didn't load the "resultObject" until I
allowed this. Presumably, this indicates that others have abused this
technique in the past, much like frames and iframes. I wonder if
other "security" software or settings would cause similar problems?
Sorry, what I wrote about embedded html/xhtml documents wasn't related
to those testcases.
The main rendering problem is that browsers don't support intrinsic
dimensions for embedded document like:
<object data="math.xhtml" type="application/xhtml+xml"
style="height: auto; width: auto"
<img src="math.gif" alt="..." longdesc="description.html">
</object>
Browsers that don't support "application/xhtml+xml" are using the
alternate content.
> That way, readers don't have to scroll
> all the way to the bottom of the page if they are only interested in
> embedding, say, a flash object.
Hm, those testcases isn't mine. With flash objects, I don't think
problems with intrinsic dimensions applies in the same degree. I
haven't used flash, but it seems that they always comes with
dimensions fixed in pixels.
> One potential problem appears to be that the NoScript plugin (which
> I leave on by default) didn't load the "resultObject" until I
> allowed this.
Isn't that a good thing? Then you can run flash only from domains you
trust.
> Presumably, this indicates that others have abused this
> technique in the past, much like frames and iframes.
No, what do flash got do with frames and iframes? It might indicate
that others has abused flash. AFAIK the object element don't allow
scripting between the parent document and the "entirely independent"
embedded document in the object element.
<http://www.w3.org/TR/html401/struct/objects.html#embedded-documents>
> I wonder if
> other "security" software or settings would cause similar problems?
It might.
> On 23 Sep, 14:10, David Stone <no.em...@domain.invalid> wrote:
> > [snip]
> > > You can take a look some testcases at:
> > >http://joliclic.free.fr/html/object-tag/en/
[snip]
>
> > One potential problem appears to be that the NoScript plugin (which
> > I leave on by default) didn't load the "resultObject" until I
> > allowed this.
>
> Isn't that a good thing? Then you can run flash only from domains you
> trust.
>
> > Presumably, this indicates that others have abused this
> > technique in the past, much like frames and iframes.
>
> No, what do flash got do with frames and iframes? It might indicate
> that others has abused flash. AFAIK the object element don't allow
> scripting between the parent document and the "entirely independent"
> embedded document in the object element.
> <http://www.w3.org/TR/html401/struct/objects.html#embedded-documents>
If you view the source of the test case pages linked from the
joliclic.free.fr page referenced above, you'll see that the very
first object is text/html, which is blocked even though it is NOT
a flash object. Here's an explicit link showing the problem:
http://joliclic.free.fr/html/object-tag/en/object-text.html#html
I suspect a prior security problem stemming from html pages embedded
using the object tag prompted the NoScript authors to block such
things by default; if other security packages/plugins do the same thing,
this would undermine using the object tag as an alternative to scripting
and SSIs as a way of handling common content.
> I suspect a prior security problem stemming from html pages embedded
> using the object tag prompted the NoScript authors to block such
> things by default;
Who knows what an unsigned add-on might do. It's ridicules. An static
html page served as 'text/html' or 'application/xhtml+xml' page isn't
a security problem. At least you should be able to see the alternate
content.
> if other security packages/plugins do the same thing,
Why would they do that. An static html page from the same domain isn't
a security problem. They might let you disable iframes, or third party
objects, but that's another question. Again, you should be able to see
the alternate content.
> this would undermine using the object tag
Well, some vendors would like to do that.
> as an alternative to scripting
And scripting is more secure than an static html page? And the
'NoScript' add-on is just plain fun?
> and SSIs as a way of handling common content.
Well, server side scripting is a way to handle alternate content like
html vs xhtml. Just serve e.g. MathML or SVG to browsers that handles
'application/xhtml+xml' and a bitmap picture with alt text to other
browsers. With simple CSS like 'display: block' and 'display: hidden',
you can serve unreadable xhtml to an html parser, without reducing the
experience for people with disabilities.
Yes, I use m4 and make for this sort of thing.
robert
> *Without* using JavaScript or other active client-side scripting,
> server-side includes or frames, is there a way to include a standard
> header on all pages within a site? The design goal is to have the
For what it's worth, I've concluded that the answer to this question
is "yes, but all the methods have significant downsides." I am using
SSI. TheFAQ from my provider was stale information.
>Sun, 21 Sep 2008 14:27:28 +0300 from Jukka K. Korpela
><jkor...@cs.tut.fi>:
>> No amount of reduction in site management work (like moving from manually
>> maintained headers to iframed header file) could ever justify all the
>> problems you create by using IFRAME.
>
>My situation is not common headers, which indeed I handle by
>preprocessing, but common *page content* in two different sites with
>different structures.
>
>Here's a sample URL:
>http://oakroadsystems.com/math/tiskurt.htm
>
>The actual content (inside the IFRAME) is at my college's Web site:
>http://www.tc3.edu/instruct/sbrown/ti83/skurt.htm
>
>There may be a better way to accomplish what I'm trying to do, which
>is to make the content available through my Web site and through the
>College Web site, without duplicate uploading all the content. (There
>are several dozen instructional pages like this, and the average page
>is updates maybe two or three times a year.) Suggestions?
>
>Notce that just above the IFRAME I do give a link for busting out of
>the frame.
Personally, I think it's a good application for an IFRAME.
I suppose IFRAME's can overused/abused like everything else. The only
problem I've come across with IFRAMES is that search engines don't
seem to follow any links contained within the frame.
Rob
RobC wrote:
>I suppose IFRAME's can overused/abused like everything else. The only
>problem I've come across with IFRAMES is that search engines don't
>seem to follow any links contained within the frame.
Try creating shortcuts with different frames selected.