Site design fundamentals

I am attempting to get the basic techniques of my personal site set up
correctly for future expansion, ease of design and alteration, and use
with a minimal CMS I am writing. Site is static HTML 4.01 Strict,
generated locally, and uploaded (command line ftp with auto generated
here documents) to the web server. I am trying to stick with facilities
already available on my computer (Macintosh), and not buying special
programs.

Site directories will have the same structure on the server as locally
and probably be:
Site
Boilerplate (DTD, headers, footers, site navigation, etc.)
CSS (site wide CSS)
images (images used by CSS as backgrounds, etc)
images (images
TopicA
TopicB
TopicC
...
TopicN
boilerplate (any special headers, footers and local navigation)
CSS (topic and individual page CSS)
images (all the graphics for that set of pages)
texts (all the main content text for TopicN)

CMS is just a series of Bash scripts. Web pages will be created by
patching together from boilerplate a DTD, a customised Title, Keywords
and Description metas for each file, more boilerplate header, a
customised stylesheet line, rest of the boilerplate header, then the
main page content from the texts directory, any additional page content,
boilerplate site and local navigation (customised to show current topic
and current file), and then the footer.

I am prototyping this as I go along, so I can more easily make changes
based on experience with what I can get to work. The CMS scripts just
use a very simple substitute for a make file, and there is one such file
in each Topic directory. Each line just lists the target HTML file
name, followed (in order) by the names of all the files needed to
assemble that target file. Thus boilerplate can come from any of the
boilerplate directories, and particular files can have special
treatment, say for local navigation, or for say a gallery of photos that
may be treated different to most of the site pages.

Now I am trying to work out how to best get the general HTML in each
page to work with style sheets.

I plan to have each web page call three style sheets. The first is the
site wide CSS file in the main directory. The second will be the topic
directory CSS file. The third will be the individual page CSS file.
The names of these files will be generated and inserted in the web page
automatically when they are created, based on the topic directory name
(so topica.css to topicn.css), and the actual file name (file1.css,
file2.css). In most cases, no actual file1.css or file2.css will exist,
as the page will get all the styles it needs from the main.css and the
topic.css style sheets.

Any comments on this approach would be appreciated.

--
http://www.ericlindsay.com

Eric Lindsay wrote:

Now I am trying to work out how to best get the general HTML in each
page to work with style sheets.

I plan to have each web page call three style sheets. The first is the
site wide CSS file in the main directory. The second will be the topic
directory CSS file. The third will be the individual page CSS file.
The names of these files will be generated and inserted in the web page
automatically when they are created, based on the topic directory name
(so topica.css to topicn.css), and the actual file name (file1.css,
file2.css). In most cases, no actual file1.css or file2.css will exist,
as the page will get all the styles it needs from the main.css and the
topic.css style sheets.

Any comments on this approach would be appreciated.

We use PHP to generate pages on the fly. One of the header functions

outputs style elements. Without any parameters to the function it outputs
just the main site CSS link (or @import), and a print CSS.
When a page has extra style(s), the filenames are added to the
function's parameter list and an additional @import is emitted for each
filename.

You seem to be creating a rather brittle structure for adding CSS files.
It works for what you have now but will you always create a site with such
a structure? If not, what you have now will not be easily reusable.

Another possibility here is using PHP. It does not have to be a
server-side runtime processor. The distribution includes an executable
that takes the PHP files and outputs HTML. You then upload the finished
product.

--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)

In article <xsOdndijbp6B1jrenZ2dnUVZ_s6dnZ2d (AT) giganews (DOT) com>,
Jim Moe <jmm-list.AXSPAMGN (AT) sohnen-moe (DOT) com> wrote:

I plan to have each web page call three style sheets.

We use PHP to generate pages on the fly. One of the header functions
outputs style elements. Without any parameters to the function it outputs
just the main site CSS link (or @import), and a print CSS.
When a page has extra style(s), the filenames are added to the
function's parameter list and an additional @import is emitted for each
filename.

That does seem more flexible. So as you see it, I should make the CMS
add links to any additional CSS files as the page is generated? Given I
have a flexible way of adding files to the main body, that seems
reasonable.

You seem to be creating a rather brittle structure for adding CSS files.
It works for what you have now but will you always create a site with such
a structure? If not, what you have now will not be easily reusable.

Yes, allowing only the three potential CSS files does seem brittle.
Just thinking online, I could set up the CMS to only include a topic
specific CSS files if it exists, and only include a file specific CSS
file if that exists (comparison would just be based on the directory and
file name). That means I don't have to edit the make file if I add a
file specific CSS file. That doesn't get me any further than my
original scheme, but it does eliminate failed searches for CSS files
that don't exist.

Next thing would be to include the names of any other extra CSS files in
the make file, so that these file names also get into the final html
file.

Another place I might organise automatic inclusion is when I do my
classes on the html and body elements of each file. For instance, if
all photo gallery or all product review pages in a directory include a
suitable class name like gallery or review, then I could check whether a
gallery or review CSS file exists. If so, I include it in the HTML file.

Another possibility here is using PHP. It does not have to be a
server-side runtime processor. The distribution includes an executable
that takes the PHP files and outputs HTML. You then upload the finished
product.

I didn't see any great advantages at the moment to PHP for prototyping a
static site. At least one of the sites I want to put this to use on
doesn't provide PHP access, so I wouldn't be moving that to dynamic
generation. Plus various Macintosh people are complaining Safari under
Tiger doesn't display .php, unless served as text/html from a web server
(the Bugzilla report says that will not be changed, so I assume doing so
would be a security issue under WebKit). Also since I am not familiar
with PHP, using it for prototyping would be harder for me. However I am
not doing anything very complicated in terms of processing. Most of the
problems are working out structures and how to treat pages. If speed or
ability of the language become a problem, I can change to PHP then.

Thank you for your suggestions. They have been a great help.

--
http://www.ericlindsay.com