Nick — as much as I love the music, I’d wish you drop it. And using iframes? I thought I was outdated … There is no need to load a new HTML document in an iframe. You can easily load just the content into a div tag without reloading the page. It sounds very much like you need a developer.

Frode,

The new site will have a play-pause button for the music, so visitors can kill it if they want.

Frameset is dead meat, which is what my site uses now, but iFrame is fully HTML5 A-OK. I chose to go with an iFrame because it will allow me to edit a smaller file when I update. Plus, the extra jQuery scripts for each new iFrame won't need to be loaded until (or unless) someone navigates to those pages.

Supported does not mean good practice, and this will in fact require you to edit a bigger file then my proposed method. Alas, this is not a discussion for a type forum :) PM me if you want help.

Supported does not equal good practice, and this will in fact require you to edit a bigger file then my proposed method. Alas, this is not a discussion for a type forum :) PM me if you want help.

If your main page will be the container for all other pages than yes.

If you're doing the right thing by killing the flash part, do the right thing and kill the iFrame and music.

"I chose to go with an iFrame because it will allow me to edit a smaller file when I update."

You could use AJAX calls for that if you wanted to.

A better option would be to use server-side includes to have every page include the repetitive elements.

If you want to stick with the iFrame, if the iFrame, itself, needs jQuery then, yes, that page within the iFrame needs to reference the same jQuery files as the other page.

Is your new website CMS based or hand-coded?

Darrel,

Thanks for reminding me about SSI: I haven't used it in about ten years, but—yes—it does help keep files tidier. The problem is, the site will have a main staging area that will swap out content, depending on the menu link clicked, and most of the content has a lot of overhead, in terms of images, text blocks, additional styles and scripts. The only real candidates for SSI would be the header and footer, which take up less than twenty lines of code.

What I want to end up with is an editable file similar to the XML file used to change images and text in my old site: I didn't have to wade through yards of code, and all the data categories had logical names. iFrame seems the most sensible solution.

And, FWIW, some people like the music (they write me and tell me so0, but I will put a kill button for the audio on the next version.

Dušan: The site is all hand-coded—all those years of using SGML (HTML’s grandaddy) marking up copy for dedicated phototypesetting came in handy. CMS and eCommerce will probably figure in to the next version.

Since I did our website recently (a couple of months ago), I'd like to share you my experience since I think you'll put a lot efforts in HTML website and in maybe a year, you'll decide to swap into CMS.

When we started, we had an HTML/CSS/JS based website that, at first, seemed easy to maintain. After each new font, I had to edit around 50% of existing pages to make possible for new font to conceptually follow the other fonts in website. It takes time, you'll always something forgot to do and you'll notice that after days/weeks/months and in one point you'll end up probably disappointed or just sick of it. And you'll always lack for something. Simple, it's not it, it's not good solution for longer run.

My advice is to go straight to CMS.
Make template, define all the pages/sections, prepare content, hire developer who will do it for you, pay what it costs and be happy for next a couple of years. If you use some stable CMS, that develops all the time, there's a good chance you might be able, for some next website layout change, to just do new template and keep same CMS, database....

It costs more, but it's more effective, more easier, more functional and more practical solution then HTML.

Cheers.

I get the feeling that dynamic generation of static pages is a lost art.

Dušan,

I appreciate the advice, and that’s where I will eventually wind up. For the present, I simply want a placeholder site that’s not Flash-based, so it isn’t invisible to some Mac users.

Also, keep in mind that your product line is relatively limited compared with mine, which now numbers of 600 families and more than 1,000 separate fonts. I'm in the process of slowly updating all of them and building a single, comprehensive database—both of which are necessary first steps before calling in the coders.

Thumbs up.

Hope to see your new website soon online.

Cheers