By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,771 Members | 1,669 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,771 IT Pros & Developers. It's quick & easy.

legality/practicality of nesting complete, valid HTML pages

P: n/a
Folks

Here's a skeleton, generic HTML page, call it "index.php". You'll see a bit
of php code in the middle:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>

<head>
...
</head>
<body>
....
<?php require("another_page.html"); ?>
...
</body>
</html>

If the contents of "another_page.html" is valid, it contains, at the outer
level, <html .... </html>. That means, when the page is served up, the
recipient browser will see something like this:

<html>
....
<html>
...
</html>
...
<html>

That is, completely nested -- though otherwise completely valid-- HTML
files. I've read that doing this is a BAD IDEA, but I can't find out why.
Sure, the HTML spec doesn't say you can do this, but I can't find any place
it says you can't.

OK, common sense says you shouldn't risk doing unusual things to browsers.
Yes, definitely.

Well, I've been nesting files like this for months, and I haven't noticed
anything going wrong on the client. But I'm looking a very narrow test
base: only FireFox on MacOS 10.4.x.

Question 1: Is nesting like this really a BAD IDEA?

You might guess that I have a deeper question. Yup! I've designed a site
that has a single template page, index.php, which dynamically fills in
content using php "require". I put individual chunks of content from .html
files, all of which are stand-alone valid -- starting with <htmland ending
with </html>. Bingo! Nested files.

Why do I make all the .html files stand-alone valid? Because Dreamweaver
(CS3) insists. I can't get functioning WYSIWYG, nor I can use site-wide
CSS otherwise. I need all that working to make the chunks right.

Question 2: Doesn't this issue come up all the time in DHTML site designs?

Question 3: Am I missing something incredibly obvious --or subtle and
magic-- that will fix this and/or teach me to relax about it?

TIA

Henry

remove 'zzz'

Nov 14 '08 #1
Share this Question
Share on Google+
17 Replies


P: n/a
On 2008-11-14, henry <he************@gmail.comwrote:
Folks

Here's a skeleton, generic HTML page, call it "index.php". You'll see a bit
of php code in the middle:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>

<head>
...
</head>
<body>
....
<?php require("another_page.html"); ?>
...
</body>
</html>

If the contents of "another_page.html" is valid, it contains, at the outer
level, <html .... </html>. That means, when the page is served up, the
recipient browser will see something like this:

<html>
....
<html>
...
</html>
...
<html>

That is, completely nested -- though otherwise completely valid-- HTML
files. I've read that doing this is a BAD IDEA, but I can't find out why.
Sure, the HTML spec doesn't say you can do this, but I can't find any place
it says you can't.
It's there in the DTD-- it says the HTML element must contain a HEAD and
a FRAMESET or else a HEAD and a BODY.
OK, common sense says you shouldn't risk doing unusual things to browsers.
Yes, definitely.

Well, I've been nesting files like this for months, and I haven't noticed
anything going wrong on the client. But I'm looking a very narrow test
base: only FireFox on MacOS 10.4.x.

Question 1: Is nesting like this really a BAD IDEA?
Yes. Many browsers know how to fix it so you get away with it, but have
you tested it exhaustively on all versions of IE?
You might guess that I have a deeper question. Yup! I've designed a site
that has a single template page, index.php, which dynamically fills in
content using php "require". I put individual chunks of content from .html
files, all of which are stand-alone valid -- starting with <htmland ending
with </html>. Bingo! Nested files.

Why do I make all the .html files stand-alone valid? Because Dreamweaver
(CS3) insists. I can't get functioning WYSIWYG, nor I can use site-wide
CSS otherwise. I need all that working to make the chunks right.
Ironic that its insistence on validity is what's causing you to
ultimately publish HTML that's invalid.
Question 2: Doesn't this issue come up all the time in DHTML site designs?

Question 3: Am I missing something incredibly obvious --or subtle and
magic-- that will fix this and/or teach me to relax about it?
Good questions. It sounds like it shouldn't be that difficult to make it
filter out <htmland </htmlwhen including a file, but I know
practically nothing about php. Alternatively stop using Dreamweaver and
leave the tags out of your fragments (perhaps automatically putting them
back in for the purposes of validating them).

But you really can't relax until you fix it. It's no good going to all
that trouble and then having invalid HTML at the end of it. You can't
blame the tools.
Nov 14 '08 #2

P: n/a

henry wrote:
>Sure, the HTML spec doesn't say you can do this, but I can't
find any place it says you can't.
Run it through the w3C validator. If the HTML specifications
which are contained in the DTD *really* don't say that you can't
do that, it will validate with no errors. If it throws one or
more errors, those are the places where you are doing things
that the HTML specifications specifically forbid.
--
Guy Macon
<http://www.GuyMacon.com/>

Nov 14 '08 #3

P: n/a
henry schreef:
Folks

Here's a skeleton, generic HTML page, call it "index.php". You'll see a bit
of php code in the middle:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>

<head>
...
</head>
<body>
....
<?php require("another_page.html"); ?>
...
</body>
</html>

If the contents of "another_page.html" is valid, it contains, at the outer
level, <html .... </html>. That means, when the page is served up, the
recipient browser will see something like this:

<html>
....
<html>
...
</html>
...
<html>

That is, completely nested -- though otherwise completely valid-- HTML
files. I've read that doing this is a BAD IDEA, but I can't find out why.
Sure, the HTML spec doesn't say you can do this, but I can't find any place
it says you can't.

OK, common sense says you shouldn't risk doing unusual things to browsers.
Yes, definitely.

Well, I've been nesting files like this for months, and I haven't noticed
anything going wrong on the client. But I'm looking a very narrow test
base: only FireFox on MacOS 10.4.x.

Question 1: Is nesting like this really a BAD IDEA?

You might guess that I have a deeper question. Yup! I've designed a site
that has a single template page, index.php, which dynamically fills in
content using php "require". I put individual chunks of content from .html
files, all of which are stand-alone valid -- starting with <htmland ending
with </html>. Bingo! Nested files.

Why do I make all the .html files stand-alone valid? Because Dreamweaver
(CS3) insists. I can't get functioning WYSIWYG, nor I can use site-wide
CSS otherwise. I need all that working to make the chunks right.

Question 2: Doesn't this issue come up all the time in DHTML site designs?

Question 3: Am I missing something incredibly obvious --or subtle and
magic-- that will fix this and/or teach me to relax about it?
I think you can simply use <objectfor this. But, as usual, do not
expect support from IE.

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
Nov 14 '08 #4

P: n/a
henry wrote:
Question 1: Is nesting like this really a BAD IDEA?
Yes. It creates invalid HTML.
You might guess that I have a deeper question. Yup! I've designed a
site that has a single template page, index.php, which dynamically
fills in content using php "require". I put individual chunks of
content from .html files, all of which are stand-alone valid --
starting with <htmland ending with </html>. Bingo! Nested files.

Why do I make all the .html files stand-alone valid? Because
Dreamweaver (CS3) insists. I can't get functioning WYSIWYG, nor I
can use site-wide CSS otherwise. I need all that working to make
the chunks right.
So don't use Dreamweaver. Or, if you do, strip out everything down to
the <bodytag and every from the </bodytag down after you have the
page template built.
Question 2: Doesn't this issue come up all the time in DHTML site
designs?
No. (Actually, DHTML is something different.) Dynamically generated web
pages are usually (for some definitions of usually) created in a way
that results in valid HTML.
Question 3: Am I missing something incredibly obvious --or subtle
and magic-- that will fix this and/or teach me to relax about it?
Yes.
Nov 14 '08 #5

P: n/a
Gazing into my crystal ball I observed henry <he************@gmail.com>
writing in news:C54256A4.35C32%he************@gmail.com:
Folks

Here's a skeleton, generic HTML page, call it "index.php". You'll see
a bit of php code in the middle:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>

<head>
...
</head>
<body>
....
<?php require("another_page.html"); ?>
...
</body>
</html>

If the contents of "another_page.html" is valid, it contains, at the
outer level, <html .... </html>. That means, when the page is served
up, the recipient browser will see something like this:

<html>
....
<html>
...
</html>
...
<html>

That is, completely nested -- though otherwise completely valid-- HTML
files. I've read that doing this is a BAD IDEA, but I can't find out
why. Sure, the HTML spec doesn't say you can do this, but I can't find
any place it says you can't.

OK, common sense says you shouldn't risk doing unusual things to
browsers. Yes, definitely.

Well, I've been nesting files like this for months, and I haven't
noticed anything going wrong on the client. But I'm looking a very
narrow test base: only FireFox on MacOS 10.4.x.

Question 1: Is nesting like this really a BAD IDEA?
Nesting is a bad idea in that some browsers may make corrections now,
but that may not be so in the future.
>
You might guess that I have a deeper question. Yup! I've designed a
site that has a single template page, index.php, which dynamically
fills in content using php "require". I put individual chunks of
content from .html files, all of which are stand-alone valid --
starting with <htmland ending with </html>. Bingo! Nested files.

Why do I make all the .html files stand-alone valid? Because
Dreamweaver (CS3) insists. I can't get functioning WYSIWYG, nor I
can use site-wide CSS otherwise. I need all that working to make the
chunks right.
This is one of those times that doing hand coding comes in really handy.
For my purposes the only page that needs to validate is the one finally
rendered in the browser.
>
Question 2: Doesn't this issue come up all the time in DHTML site
designs?

Question 3: Am I missing something incredibly obvious --or subtle and
magic-- that will fix this and/or teach me to relax about it?
You might want to think about a different type of template. Here's what
I use most of the time - I make one page that validates and looks the
way I want, then I split it up into its parts like:

<?php $thispage = "Title of page";
$thisurl = "actualurl.php";
include "linkrel_inc.php";
// what ever scripting needs to be done, querying db, etc
?>
</head>
<body>
<?php include "nav_inc.php"; ?>
<div id="content">
</div>
<?php include "footer_inc.php"; ?>

linkrel_inc.php itself has some includes - I have a file called
masterfunctions.php where I keep frequenly used functions. The
connection to the db is in this file, as well as an external stylesheet,
and external javascript. linkrel_inc.php has the doctype declaration,
and $thispage variable fills in the title element, and optionally the h1
element.

nav_inc.php optionally may include a header_inc.php, which marks up a
page header. This page also generates the navigation from an array.
$thisurl is used by the nav function to put class="thispage" on the link
whose href is $thisurl.

footer_inc.php makes the page footer and ends the HTML markup. It also
closes the connection to the db.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

Nov 14 '08 #6

P: n/a
henry <he************@gmail.comwrites:
Here's a skeleton, generic HTML page, call it "index.php". You'll see a bit
of php code in the middle:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>

<head>
...
</head>
<body>
....
<?php require("another_page.html"); ?>
...
</body>
</html>
<snip>
Why do I make all the .html files stand-alone valid? Because Dreamweaver
(CS3) insists. I can't get functioning WYSIWYG, nor I can use site-wide
CSS otherwise. I need all that working to make the chunks right.
You've had the "don't use Dreamweaver" suggestion, but I go the other
way. I am not a fan of DW, but I know people who are, and they claim
they can make templated sites just fine without any PHP being needed.
Now I don't use it so I can't say, but surely it has some way to apply
a consistent (and editable) template to your content? That must be
just about the most basic thing for site building tool (as opposed to
an HTML editor) like DW to be able to do. Now, of course, if it can't
do that I'll join the dump DW chorus.
Question 3: Am I missing something incredibly obvious --or subtle and
magic-- that will fix this and/or teach me to relax about it?
On fix is to write PHP to strip out the parts that are in common
between the template and the content pages. Essentially you write a
filter that includes only the content part. How easy of hard that is
will depend on exactly what you have in the ... parts above. This
will work but it feels like the wrong solution to a problem that
should simply be avoided.

--
Ben.
Nov 14 '08 #7

P: n/a
Folks:

Thanks to all for your suggestions.

I did a huge amount of searching and questioning and head-scratching....

Finally someone on a DW forum realized what I was really after, and told me
there is a feature in DW that provides it: "design-time style sheet".

This command marks a style-sheet link in a particular file to be effective
during the design process only. When the file is uploaded to the web
server, the style-sheet link is filtered out of the code. That's done by DW
on a file-by-file and link-by-link basis, not the most convenient when one
has hundreds of include files. With a little more searching I found a US$5
extension that applies this attribute to multiple files in various ways.

Whew!

Thanks,

Henry

remove 'zz'

Nov 16 '08 #8

P: n/a
On Thu, 13 Nov 2008 22:11:48 -0800, henry wrote:
<body>
....
<?php require("another_page.html"); ?>
...
</body>
I haven't tested this anywhere, but this is the behaviour required by the
standard:

You will get the contents of the included page's head elements that are
not empty and not allowed in the body as new anonymous blocks. In most
cases this will just be the contents of title.

Think of it like this: if another_page.html contains <title>foo</title>
this will be interpreted as if you had included a document containing
<div>foo</div>.

HTH
viza
Nov 19 '08 #9

P: n/a
viza wrote:
On Thu, 13 Nov 2008 22:11:48 -0800, henry wrote:
> <body>
....
<?php require("another_page.html"); ?>
...
</body>

I haven't tested this anywhere, but this is the behaviour required by the
standard:

You will get the contents of the included page's head elements that are
not empty and not allowed in the body as new anonymous blocks. In most
cases this will just be the contents of title.

Think of it like this: if another_page.html contains <title>foo</title>
this will be interpreted as if you had included a document containing
<div>foo</div>.
Not sure why folks have so much trouble this issue?

If you are doing includes by PHP or any other means then the included
files should *only* be html fragments, i.e., only the portion of markup
required to complete the document. Not complete HTML documents with head
& body elements...

So in the above example "another_page.html" should only contain
something like this:

<!-- File Start -->
<h1>Foo</hi>
<p>Some paragraph or other content...</p>
<!-- File End -->
If the include is *not* just a fragment but a *whole* document then you
should load the content into a buffer

PHP:

$buf = file_get_contents(another_page.html);

or via CURL

Then process the buffer to extract *only* the fragment that you need. If
you do not do this then of course your results will be invalid. It may
display "ok" because of error correction within browsers. But relying on
browsers' ability to parse junk is a very *bad* practice...

I remember in the old days with Netscape when viewing
'cut-n-paste'-wonder-sites having the pages truncated at the first
</bodyor crash when no </tablewas found!

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Nov 19 '08 #10

P: n/a
Jonathan N. Little wrote:
Not sure why folks have so much trouble this issue?
"Folks" aren't. The OP is. That is because he is using an HTML authoring
tool that only creates complete HTML pages. He has asked us not to
suggest he find another way to create HTML.
Nov 19 '08 #11

P: n/a
In article <gg**********@news.motzarella.org>,
Scott Bryce <sb****@scottbryce.comwrote:
Jonathan N. Little wrote:
Not sure why folks have so much trouble this issue?

"Folks" aren't. The OP is. That is because he is using an HTML authoring
tool that only creates complete HTML pages. He has asked us not to
suggest he find another way to create HTML.
IIRC that was DreamWeaver, which can be set up to create any number of
different types of pages. I have not had any trouble using it to create
html fragments - or even plain text files - but then I am not using PHP
either!
Nov 19 '08 #12

P: n/a
Scott Bryce wrote:
Jonathan N. Little wrote:
>Not sure why folks have so much trouble this issue?

"Folks" aren't. The OP is. That is because he is using an HTML authoring
tool that only creates complete HTML pages. He has asked us not to
suggest he find another way to create HTML.
My "Folks" was not explicitly referring to responders of this tread, but
more to the "Folks" that often post this question...

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Nov 19 '08 #13

P: n/a
Let's relax, OK?

I hope there's room for all methods and all tools on this group. We each
pick the tools that works best for us, and live with the disadvantages, OK?

If this is a group ONLY for people who use text editors to author sites,
then I'd really appreciate it if someone would point me to an equivalent
group for people who use all kinds of tools.

Maybe I should have mentioned that I stupidly volunteered to take over an
existing site of several hundred really, really badly written pages. (Do
they validate? ROFL.) Totally un-maintainable. It's a public-service
job, I'm not getting paid -- I'll even be paying for hosting myself in the
future-- but there seemed to be no choice, otherwise some valuable
information was going to get lost. I had no idea what I was getting into,
and didn't discover it until I started a site-wide renovation.

Back to the technical points:

So far, no one has disagreed with the scheme of an "index.php" file that
sets the site look but contains no content. Pure content is contained in
multiple separate HTML-only files that are included in "index.php" per some
computation. Right? (I wish someone would give me a good name for this
design. I'd also like to get an idea of how commonly-used it is, and if
there are some good alternatives that accomplish the same result.)

It seems we all agree that it is _at least_ a Very Good Idea for all pages
to pass W3C validation. If so, it is totally clear that the included
content files ("chunks") must NOT contain header or trailer material.

I think that's the end of the discussion for you brave and skilled authors
who choose do the job with only a text editor and an ftp utility. I really,
honestly, truly admire you. I fully understand the advantages of using such
tools.

For those of us who have good reasons to use higher-level tools, we get the
advantages of doing so, but we need to learn to live with the disadvantages.
In this specific case, the advantage is being able to apply a site-wide
style to many items in content pages by using a simple pull-down. The
disadvantage is that the develop-time content of the content chunk files
needs to be different from the load-time content.

DW offers one solution. I feel it is a bit fragile. It would be helpful
for me to hear about solutions offered by other high-level tools, if any.

Or, I would like to hear that this issue is avoidable by using a different
design, as long as the content chunks are in separate files.

One reply offered an alternative of reading the content chunks into a buffer
at page-load time, cleaning the leader and trailer material at that point.
(Is there a commonly-accepted name for this method?) Without ever having
tried it, that method seems simple, robust, and flexible. Thinking out loud:
Check the first non-whitespace string. If it is "<!DOCTYPE..." discard
everything up to and including the "<body>" tag, then search for "</body>"
and discard that and everything to the EOF. If the first string is
something different, assume the file contains a fragment of "bare" HTML and
use it unchanged. So, in practice, what are the potential difficulties of
this approach? Off the top of my head, I'm thinking ... buffer allocation.

In response to a point someone brought up: DW creates new documents with
default header and trailer material per user preference settings. There is
probably a way to create a truly blank, i.e. totally empty new document, but
I haven't found it yet. It's easy enough to empty a new document.

Thanks,

Henry

remove 'zzz'

Nov 19 '08 #14

P: n/a
henry wrote:
DW offers one solution. I feel it is a bit fragile.
My gut feeling is that if you can get past the feeling that this
solution is "fragile" you will be fine. Given that you want to work in
DW, it is the solution that is available to you. Use it, and don't be
afraid of it being fragile.
Nov 19 '08 #15

P: n/a
henry <he************@gmail.comwrites:
Let's relax, OK?
Everyone seems perfectly relaxed to me. If you think otherwise it
suggests you have limited Usenet experience!

<snip>
So far, no one has disagreed with the scheme of an "index.php" file that
sets the site look but contains no content. Pure content is contained in
multiple separate HTML-only files that are included in "index.php" per some
computation. Right? (I wish someone would give me a good name for this
design.
I doubt you'll find a name because I don't think it merits the term
"design". Content has been "included" into document templates decades
before the WWW came along.
I'd also like to get an idea of how commonly-used it is, and if
there are some good alternatives that accomplish the same result.)
It is very common indeed. The inclusion can be done by several
different mechanisms and it is often done off-line -- i.e. before the
page it uploaded using a template mechanism or macro processor.
It seems we all agree that it is _at least_ a Very Good Idea for all pages
to pass W3C validation. If so, it is totally clear that the included
content files ("chunks") must NOT contain header or trailer
material.
Well, I like my pages to validate, but it can be overrated from a
practical point of view. If you have existing content that works
exactly as you'd like I would probably have other things on my to do
list before making old pages validate.
I think that's the end of the discussion for you brave and skilled authors
who choose do the job with only a text editor and an ftp utility. I really,
honestly, truly admire you. I fully understand the advantages of using such
tools.

For those of us who have good reasons to use higher-level tools, we get the
advantages of doing so, but we need to learn to live with the
disadvantages.
In this specific case, the advantage is being able to apply a site-wide
style to many items in content pages by using a simple pull-down.
The high-level/low-level distinction is not a very useful one unless
you provide a definition of terms to haggle over. I use the tools I
use (rsync, sitecopy, wget, emacs, Perl, m4) because they make things
easier for me, not because they are some sort of puritan hair shirt
that make me admirable (but then I am not a professional web developer
so maybe I don't count). I have looked over the shoulders of people
using Dreamweaver and I wonder how they put up with it, but I image
they do exactly the same when they see me working. The oddity is that
your chosen tool is not, currently, making things easy for you.
The
disadvantage is that the develop-time content of the content chunk files
needs to be different from the load-time content.

DW offers one solution. I feel it is a bit fragile. It would be helpful
for me to hear about solutions offered by other high-level tools, if
any.
For small sites with content that changes only every now and then I
use a text template mechanism to do the "includes" before uploading
the finished HTML: edit the content, run a build command, run
sitecopy.

The trend for larger sites seems to be to move the content to an
online content management system. This main advantage is to put the
content back into the hands of the people who generate and maintain
it.
Or, I would like to hear that this issue is avoidable by using a different
design, as long as the content chunks are in separate files.

One reply offered an alternative of reading the content chunks into a buffer
at page-load time, cleaning the leader and trailer material at that point.
(Is there a commonly-accepted name for this method?)
That was me, I think, but the technique won't have a name.
Without ever having
tried it, that method seems simple, robust, and flexible. Thinking out loud:
Check the first non-whitespace string. If it is "<!DOCTYPE..." discard
everything up to and including the "<body>" tag, then search for "</body>"
and discard that and everything to the EOF. If the first string is
something different, assume the file contains a fragment of "bare" HTML and
use it unchanged. So, in practice, what are the potential difficulties of
this approach?
Some documents start with a XML prelude. Also, can you be sure that
all yours have a DOCTYPE at the top? If not you'd need to be a bit
more flexible.
Off the top of my head, I'm thinking ... buffer
allocation.
Not sure what you mean by that. PHP makes this sort of thing quite
easy. If you have a programming background, all you'd need is a PHP
reference manual. If not, you'd need to find a tame programmer.

--
Ben.
Nov 19 '08 #16

P: n/a
henry wrote:
Let's relax, OK?

I hope there's room for all methods and all tools on this group. We each
pick the tools that works best for us, and live with the disadvantages, OK?

If this is a group ONLY for people who use text editors to author sites,
then I'd really appreciate it if someone would point me to an equivalent
group for people who use all kinds of tools.
I think you missed the point. The tool is unimportant. But no tool is a
substitution for knowing what you are doing. Unfortunately some ( or
many) WYSIWYG editors either promote that "they can be a substitution
for knowing web design" or user mistakenly assume they are. You can make
valid code with almost any tool (well not really...MS Publisher is one
that comes to mind) but with many WYSIWYG editors it takes effort...and
maybe some hand tweaking.
>
Maybe I should have mentioned that I stupidly volunteered to take over an
existing site of several hundred really, really badly written pages. (Do
they validate? ROFL.) Totally un-maintainable. It's a public-service
job, I'm not getting paid -- I'll even be paying for hosting myself in the
future-- but there seemed to be no choice, otherwise some valuable
information was going to get lost. I had no idea what I was getting into,
and didn't discover it until I started a site-wide renovation.
Most time for such projects starting from scratch is
easier|faster|more-successful.

Back to the technical points:

So far, no one has disagreed with the scheme of an "index.php" file that
sets the site look but contains no content. Pure content is contained in
multiple separate HTML-only files that are included in "index.php" per some
computation. Right? (I wish someone would give me a good name for this
design.
Ah... a "template" with "server-side includes". If using PHP then PHP
includes. If SSI then SSI includes, etc.
I'd also like to get an idea of how commonly-used it is, and if
there are some good alternatives that accomplish the same result.)
http://www.google.com/search?hl=en&q...=Google+Search
php includes template web design tutorial - Google Search
>
It seems we all agree that it is _at least_ a Very Good Idea for all pages
to pass W3C validation. If so, it is totally clear that the included
content files ("chunks") must NOT contain header or trailer material.
If you mean extra HTML, HEAD, BODY, elements; then yes your includes
should only contain the fragment that you need to insert.
>
I think that's the end of the discussion for you brave and skilled authors
who choose do the job with only a text editor and an ftp utility. I really,
honestly, truly admire you. I fully understand the advantages of using such
tools.
If you use a WYSIWYG editor to make your "parts" for the include files
then you may have to cut and paste the relevant bits from WYSIWYG
development page (code view) and paste into Notepad or something to make
your includes.
>
For those of us who have good reasons to use higher-level tools, we get the
advantages of doing so, but we need to learn to live with the disadvantages.
You still have to know what you are doing...
In this specific case, the advantage is being able to apply a site-wide
style to many items in content pages by using a simple pull-down. The
disadvantage is that the develop-time content of the content chunk files
needs to be different from the load-time content.
If you are using includes, your most unimportant development tool will
be a development web server. You can not do server-side includes with
"file://" protocol.
>
DW offers one solution. I feel it is a bit fragile. It would be helpful
for me to hear about solutions offered by other high-level tools, if any.

Or, I would like to hear that this issue is avoidable by using a different
design, as long as the content chunks are in separate files.

One reply offered an alternative of reading the content chunks into a buffer
at page-load time, cleaning the leader and trailer material at that point.
(Is there a commonly-accepted name for this method?) Without ever having
tried it, that method seems simple, robust, and flexible. Thinking out loud:
Check the first non-whitespace string. If it is "<!DOCTYPE..." discard
everything up to and including the "<body>" tag, then search for "</body>"
and discard that and everything to the EOF.

Google "Regular Expressions"

BTW I was the one who suggested parsing the content. If you had properly
quoted your post others would know as well. So while you are at it:

Google "how to properly quote in Usenet"
If the first string is
something different, assume the file contains a fragment of "bare" HTML and
use it unchanged.
No, it may have some other info was well. Again RegExp is the tool. BUT
if you have access to all these pages then editing out the parts ahead
of time would be the BEST solution. Parsing is only done when you don't
have access to the source.
So, in practice, what are the potential difficulties of
this approach? Off the top of my head, I'm thinking ... buffer allocation.

In response to a point someone brought up: DW creates new documents with
default header and trailer material per user preference settings. There is
probably a way to create a truly blank, i.e. totally empty new document, but
I haven't found it yet.
Yes, it's called Notepad.

--
Take care,

Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Nov 19 '08 #17

P: n/a
Viza:

Thanks for your response to my post:

in article rD********************@newsfe29.ams2, viza at
to******@gm-il.com.obviouschange.invalid wrote on 11/19/08 6:44 AM:
On Thu, 13 Nov 2008 22:11:48 -0800, henry wrote:
> <body>
....
<?php require("another_page.html"); ?>
...
</body>

I haven't tested this anywhere, but this is the behaviour required by the
standard:

You will get the contents of the included page's head elements that are
not empty and not allowed in the body as new anonymous blocks. In most
cases this will just be the contents of title.

Think of it like this: if another_page.html contains <title>foo</title>
this will be interpreted as if you had included a document containing
<div>foo</div>.
Hmmm, that seems like another good reason to remove all header material from
the included file, as I am now firmly convinced.

Thanks!

Henry

>
HTH
viza
Nov 20 '08 #18

This discussion thread is closed

Replies have been disabled for this discussion.