Hi there.

New user, so thank you in advance for any assistance that you may be able to give me.

I am in the process of creating a website. I've used (copy/pasted) some code for an overlay menu - which works perfectly. However, I would like to add a submenu to some of the categories. I've checked on the W3C site and performed a loose search on how to do this, but I'm unable to find any hints/tips that tell you how to add submenus to an overlay - only a normal navigation menu.

The site is theadventurers.agency

and here's the code before I customised it.

...THE HTML...

...AND THE CSS...

My knowledge of html and css was once "quite" good, but as with everything, without constant practice, one's memory wavers, so I've forgotten most of what I've ever learned, so please bear this in mind when assisting.

Once again, thank you in advance.

Best Wishes,

Chris.

Hi!


It depends on how the menu is written in the first place. Some accomodate submenus, others don't, so perhaps the easiest would be to find one that already supports it.

I'm not sure what an "overlay" menu is exactly, is it any different from the traditional CSS/JS-driven dropdown menus that open in front of the ordinary page content (the ones usually made with UL lists --I don't mean form SELECT menus)? There are lots of examples of the latter on the web, just make sure that they work properly with touch screens as well (where hovering is not possible, like with a mouse).

Yes, probably. I think it would be possible to rewrite it, but to what avail? To start with the HTML needs to be rewritten so the menu is list based. Now it's just a bunch of links. You can't have one link inside another, but you can have a new list inside a LI. So you can't get sub menus into it as it is now. Just as well to start over.

There are, or at least there used to be, tutorials on how to build a menu from scratch.

This one is still around. Not exactly tutorials, but he explains what's going on a little anyway.
http://www.cssplay.co.uk/menus/

Hmm. Never heard them called "overlays" before, since basically what you have here is a "modal dialog".

There are a number of issues with your markup and style to be "corrected" before you worry about "submenus", but really my approach is to treat each and every submenu as another modal dialog. The old "drop down" or "expanding" was always garbage accessibility and as such is something I stopped doing and advocating 15 years ago.

That said, if you insist on shoe-horning more menus into that menu, you could use the modern details/summary tags to expand and contract them inside the existing modal.

https://developer.mozilla.org/en-US/docs/We...Element/details

New elements and capabilities often undoes what was once bad practice and makes it viable. Even better, without resorting to JavaScript.

Now, as to those problems I mentioned, the biggest is your lack of basic HTML semantics. Don't take this as being harsh, I'm not trying to be mean. There is no "hostile tone" implied here, I'm just listing off facts. You said yourself you're behind on good practices and there's been a LOT of changes in what's "acceptable" or "good"... As @pandy mentioned a full rewrite might be in order just to bring you up to date.

A laundry list of the issues:

1)This seems to be a section of navigation, where's your NAV tag?

2) This seems to be a list of choices, where's your UL/LI? Just tossing anchors into that DIV does nothing but make a run-on sentence on screen readers, braille readers, and even search.

3) If all the anchors inside one container are getting the same class, why are you putting classes on any of them? That's SELECTOR's job.

4) You've put the H1 after the menu, when it should when possible be the first content-bearing element in your markup.

5) It is highly unlikely that "Open Menu" is THE heading that describes everything on the site, aka what H1 is supposed to mean. Remember, H1..H6 do not mean "fonts in different weights and sizes", they mark the start of sections and subsections. H1 is THE (singular) headING(singular) that labels all content on the page and/or site (thus it should probably be the site title). H2 marks the start of a major subsection of the page with the first indicating the main content if you don't use MAIN. H3 marks the start of a subsection of the H2 preceding it, H4 marks the start of a subsection of the H3 before it. Care to guess what H5 and H6 mean?. Even HR means a paragraph level change in topic, not "draw a line across the screen". This is why you don't just jump straight from H1 to H5, or start a page with a H3, or pair H1+H2 for title and tagline. No matter how often you see others doing it that way, it's wrong and tells non-visual UA users where to stick it. Thus your HR doing CSS border's job doesn't make any sense either.

This is the biggest "mental hurdle" to try and jump when writing HTML, the notion that it should say what things are, structurally and grammatically, and NOT what you want things to look like. If you choose any of your HTML tags based on their default appearance or use classes and ID's for same, you have not been taught or failed to grasp the most basic purpose and rules of HTML. And why CSS is separate from it!

6) That pesky double-scrollbar bug arises at smaller display sizes.

7) Good scripting should hook markup and/or insert scripting only DOM elements. Thus the script you're using has accessibility woes.

8) If you use the (relatively) new (If 14 years can be called "new") :target attribute you don't need JavaScript

9) Do NOT use pixels for layout. They are static in size and tells a lot of users to sod off. Anyone telling you to use PX for font-size, heights, widths, paddings, margins, or even media queries is talking out their backside. They're called EM and REM, use 'em!

10) We don't care about IE anymore you can drop the X-UA-Compatible (not that you should EVER have needed it in thr first place)

11) Where's your media target? Don't waste time sending screen media layout to all devices. Put a media="screen" on your stylesheet <link>. I've said it for 25 years, if you see <link rel="stylesheet" without a media="" of the appropriate target, or a media="all", you're looking at code written by people who never learned the basics of what CSS even is, or worse learned from same. And yes, I realize that means 99.99% of all ocde ever written with those gormless "frameworks"

12) Do NOT use style="" in all but the smallest of corner cases. that's putting presentation in the markup (where it ahs no business being) and missing a caching opportunity. With crazy Goog penalizing sites search results for a lack of speed, you do every good practice and that includes NOT saying what you want things to look like in your HTML. I extend said practice to classes, which is why I think HTML/CSS frameworks like bootcrap and failwind are pure stupid.

13) Quality scripting should be written so it can be loaded right before </body> and not at the top. Likewise using onevent attributes is a bad practice, and as I said this isn't even something I'd script unless it were to add keyboard navigation enhancement.

14) your fist in the face font-sizes are just as bad for usability and accessibility as going too small.

15) Do not use target="_blank" to shove new windows/tabs down the users gullet. It's garbage on modal, and if a desktop/laptop user wants that behavior they can middle-click or ctrl-click. It was left out of HTML 4 Strict for a reason, and it's kind of dumb on the W3C's part that it's back in HTML 5.

16) Don't underscore things that aren't anchors. The <u> tag really needs to go away, particularly when it's redundant in meaning to STRONG

17) This is 2023, you can pretty much stop worrying about anything more than woff and woff2.

18) some of your fonts are 404.

So let's try fixing all that. I know that's a lot to take in, and some of it may conflict with what you learned if you were taken in by drivel peddlers like W3Schools. There's a reason I point people at MDN. Again that's not on you or insulting you, that's just the result of an industry where a LOT of alleged "educators" are blindly parroting lies as fact.

Gimme... 20-30 minutes and I'll belt out a rewrite of your home page, implement a few of the things on your wish list, and then over the next couple days I'll document it piece by piece so you can learn how "modern" solutions work, bringing you up to date on things you may have missed.

So much of what you want is so simple now. Didn't used to be. Take the "sticky header" on your to-do list.

header { position:sticky; top:0; }

DONE.

Same as I mentioned for the menu, apart from keyboard enhancement that's not even JavaScripts' job anymore... which to be frank is freaking awesome!

This post has been edited by Jason Knight: Jan 28 2023, 04:13 PM

And here we go. Live demo of a rewrite here:

https://cutcodedown.com/for_others/minWinte...s/template.html

The directory:

https://cutcodedown.com/for_others/minWinter/adventurers/

is wide open for access to the gooey bits and pieces, and I threw a .rar of it in there so you an grab the whole thing easy-peasy.

I'm out the door for dinner with a lady friend, but later if insomnia sets in or tomorrow I'll explain why I made the changes I did, then break down the HTML and CSS section by section so you can understand the how/what/why/where of it.

Of course, waiting on her to be ready, so I added the JavaScript enhancement to make it so that focused modals don't let you focus pages or other modals under them, the escape key can close a modal dialog, and the history doesn't get as filled up with hashes as it tries to do history.back instead of location.hash = "#" when possible.

Make as much work as possible without JavaScript first, then enhance.

I cant' thank you all enough for your responses above. I knew I'd come to the right place

Jason, to coin a phrase - you Sir, are a steely-eyed missile man! I do hope your dinner went well.

Thank you also for the re-write, since it was something that I didn't expect - and looks absolutely gorgeous, by the way.

I'll be changing my homepage imminently.

Yes, it's been a long time since I tried to do anything like this and when comparing your code to mine, it seems that I have a lot of catching up to do, so I'll be looking forward to the explanations over the next few days, as they will help a lot - and I'm sure that they'll also give rise to some more questions.

In fact, I should explain that my process went something like this, in this instance.

Check an old hard-drive, find and install Serif WebPlus X7.
Realise that I no longer have the serial number, can no longer get one and therefore, can't use it anymore.
Swear.
Download OpenElement, but realise that it no longer works.
Swear.
Throw myself in at the deep end and download Dreamweaver, signing up for their trial.
Ask myself if I actually know what the hell I'm doing. Answer - no.
Swear excessively.
Swear again when I then discover that my week's trial has run out whilst I'm trying to teach myself Dreamweaver - and I've forgotten to cancel the trial because DW is way out of my league.
Spend an hour on the phone saying "No I don't want to continue my subscription to Dreamweaver. Please cancel it."
Swear some more.
Rule out using Wordpress because I don't want to have a site that looks like everyone elses.
Open W3C after deciding that I'm better off learning how to code the pages from scratch.
Open Notepad++ (seemingly the only thing that I have got right so far...)
Read through some " How To's" following those to the best of my ability and find a code snippet for something called an overlay menu, which I've never heard of before, but looks good and seems to fit the style of the website that I want to create.
Hash together a few HTML pages and a CSS page.
Discover that it's ok doing that as long as you know a) what you're doing, b) how you've arrived at the end result and c) what everything means and does behind the scenes - which I sort of do, but not entirely.
Come here and ask for help.

What I "should" have done...

Come here and ask for help...

And so - in conclusion, your honour, I will no doubt have some further questions for you, but I'll make them as short and sweet as I can. I see on your website that you have pagination implemented, so that'll be another one off of the wishlist. That will probably make the scroll indicator redundant too, so a double strike - triple, in fact, since I no longer have to bother with menus closing and opening.

Should I start a new topic for each, since we've cleared up the overlay menu question now?

Either way. Thank you all very much for the assistance.

Glad I found you.

Best wishes,

Chris.

I've missed that element completely, looks very useful.

I think we can continue here. Keep it together and you'll probably have less questions as I document what I did. All I've given you so far is code. It helps to explain the code.

In fact as a rule of thumb I say if you can't -- or don't -- write documentation for what you've written for code, you shouldn't be coding. It's an extra step, it's extra work, but it saves you so many headaches in the long term.

And what you said about missing the "details" element? There's a lot of new tags the past 12 years that are easy to miss if you started out before that.

Your struggles with the various "easy" editors is common because they try to be WYSIWYGS... but the truth is what YOU see is rarely what anyone else gets. Different screen widths, resolutions, font metrics. The same problem as PSD jockeys or the folks using and calling themselves "designers". It's a task complexity mismatch that leads to "false simplicity".

They LOOK easy, but in lowering the bar of access they make it harder to actually get the job done. Much less done right. It is thus tools like Dreamweaver are and always have been money-making scams, HTML/CSS frameworks like Bootstrap and Tailwind are even bigger scams, and they prey on beginners and alleged experts alike through propaganda, ignorance, and just plain wishful thinking.

I've got the HTML docs like 90% written. I'll post that up and then get to work on explaining the CSS. I used to do rewrites and posts like this three or four times a week between contracts to keep my skills sharp, but with the rise of toxic positivity and "wah wah, you said you don't like something" pedantry -- all of which seems to exist to perpetuate echo chambers for the snake oil peddlers -- even suggesting something is wrong and/or actually trying to teach people something just results in moderators swinging the banhammer.

Laugh is this took me longer to document than it did to write the code.

Let's begin with the markup. Our first section:



I always condense my DOCTYPE through HEAD opening to a single line, and you'll see I do the same with </head><body> and </body></html>. This is just a gentle "reminder" that these tags must appear in this order, and to not do something stupid like paste other code between them.

I also like to group my HEAD contents by type and function with whitespace between them. It's just easier to read.

Mostly you know what's here, it's kind of what you had. I just added a description meta for SEO reasons and to make Google Lighthouse zip its lip.

The next section you might not be familiar with:


Preload links do two things, they prioritize the load order of these files, and hangs the render until all the files are loaded. I just recently wrote about this on Medium:

https://medium.com/codex/http-parallelism-p...my-ec043ed0733e

Generally you should limit your preloads to 6 to 8 files, and I like to put things like a large background image and fonts first so as to reduce FOUC (flash of unstyled content).

Note, I ran that background through a png optimizer reducing the file size by a factor of around five. Those fonts are a bit heavy and if I weren't travelling outside ASCII7, I'd delete the extra characters from them to try and get the size down... though as is the load times are under half a second and I got it to a Lighthouse score of 100 so...

I like to put style last to hange the render until the browser knows what it's rendering. This lowers -- sometimes eliminates -- a pesky issue called "cumulative layout shift" which can get you penalized by search on mobile. It's a whole different ballgame these days with the micromanagement.

Then the stylesheet:

Nothing fancy, but notice I mention what media target it's for in the filename, and specify that it's for screen media. Again, I have a medium article about this:

https://medium.com/codex/media-the-html-att...se-30766bf14beb

... and as I mentioned previously, if you see a <link rel="stylesheet"> without a media target, you're looking at code by people who have no business teaching you to make websites.

Next are the favicons. I generated some simple ones of the letter "A" in the various formats you "need" now. You do NOT need the specific PNG for android because I made the .ico contain all the relevant values from 16x16 to 128x128. Anything needs larger than that it should be using the SVG.



Guess what else I wrote about on Medium?

https://medium.com/codex/this-two-dozen-fav...ol-ba611467784e

Though I forgot about apple-touch-icon on that one. Note that favicon.ico and apple-touch-icon.svg should be named EXACTLY that and should be in the root of your site / document, as some UA's will look for them there irregardless of what your <link> tags say.

Now, just a note about "title". There are SO many garbage ways people put them together in total ignorance of how it works and what it's for. When possible the format should be:



The part in [] being optional and usually omitted on the homepage. Don't say "- homepage", leave it out. Only add information like that -- FIRST not last -- for subpages. This is because when tabs get narrow it's more useful to see the page name than it is the site name. You'll notice most forum and CMS software out of the box follows this format.

Thus:



Now, moving on to the document body, we start out with two DIV, an anchor, and a HEADER.



The outer scrollfix DIV is there as a scroll container to exist in parallel / under our modal dialogs. This avoids the "double scrollbar" but if we lett HTML or BODY handle scrolling. #fauxBody I put in there for things like background images, and as a columnar flex container so we can make the footer remain at the bottom of the page when the content is too short.

Header provides accessibility and an easy hook to tell the browser where to stick it... By that I mean position:sticky so it doesn't scroll. Humor, deadpan mode. Because it is sticky we can't just id="top" on the header, so we need another element to be the "top" of the page for a "back to top" link to point at.

Be thankful smooth scrolling back to top is now just "scroll-behavior:smooth" instead of having to screw around with JavaScript like it's still 2002.

Note that the site title is the H1. That's kind of H1's job. In my previous post see all that stuff I said about numbered headings? Headings act as navigable 'landings" for non-visual user-agents. Braille readers, screen readers, TTY, even search. Their order is important and to that end I rewrote and created headers where/as appropriate. Learning header orders and import is one of the most important parts of content generation if you care at all about accessibility and usability.

The W3C HTML validation service even offers a heading summary, as does the "web developer toolbar"

https://chrispederick.com/work/web-developer/

I highly recommend adding that tool, it lets you test so many conditions. It works best in FF, but has a Chrome version. Though real-world you should be testing in every currently relevant browser engine you can get!

I took a screencap of your existing page and its document order:
https://cutcodedown.com/for_others/minWinte...ineOriginal.png

Again is "MENU" really a major navigational element that everything else is a subsection of? You have the welcome text also as a H1 so you have TWO document roots? Is the entire warning actually a heading, what's it a heading OF / FOR? Is "New Users Start Here" really a subsection of that warning? Are the update status and personal notes really subsections of "New Users start here"? Of course not.

That's why I rewrote your content into sections and headings. Thus my rewrites outline:
https://cutcodedown.com/for_others/minWinte...lineRewrite.png

Is far more useful when not navigating visually via mouse or touch. aka what HTML is actually for, device neutral delivery of content to everyone. Not just the magically privileged with perfect sight sitting at a high resolution graphical desktop.

Now in that header we have:


I used the span as you did to remove the extra text, though I made it more generic in that it's basically a skip-to link, allowing the menu to behave as a modal without unique width detection code. I don't know if you planned on having the menu show when the screen was big enough or not, I assumed not which simplifies things greatly.

The mad excellent part of this approach to modal dialogs is that it's all just hash link driven. It doesn't NEED scripting to open or close them, we just use scripting to add more useful behavior atop already working code. This means we can actually put <a href="#mainMenu"> anywhere on the page to open the menu. Or href="#" anywhere in the modal to close it. Better still because without CSS they're just normal SECTION of the page, they remain completely accessible. They are literally just another SECTION we can hash link to.

Next up we open MAIN, give MAIN a heading, and then create a subSECTION.



The use of STRONG is NOT because I want it bold, but because as a warning that text should receive "more emphasis" -- again what STRONG MEANS.

I put the paragraph after the section with emphasis on it, because it's not part of the warning section. It's transitive text.

Also notice my closing comment. When closing tags several lines later I like to know which section or div is being closed. I put the comment before it because old UA's and like every other release of Firefox loses their minds if a comment ends up between positioned elements. Placing the comment before the closing tag eliminates the possibility of that bug. It's also more useful reading left to right to see WHAT is being closed first. It's just a good practice I highly recommend.

The next section I broke into two ARTICLE (subsections)


Nothing too fancy, the two article seem like proper subsections, so we end up down at H4 depth

Also see that link to the menu that actually opens it? Yeah, that's cool.

As before the 'thank you' text isn't part of either article so it goes after, though in this case it's clearly part of the section.

Your updates status I turned into a table because it's obviously tabular data. The rows have headings, the columns have headings...



I tossed in some TIME tags to show how those work. All your times would/should probably have those on them. Also notice I used the word for the month so "US vs. the World" confusion doesn't end up in the mix.

When the data is inherently tabular with semantic relationships, TABLE is the correct tag no matter how many gullible fools who know jack scream "Don't even use tables". That's not what "don't use tables for layout" meant!

Tracking Policy is also an easy section.



Since your to-do list is a list -- ordered at that -- we have a tag for that.



Note I used DEL to mark the ones I implemented.

Again much like the tabular data, use the correct semantics or you're telling large swaths of users to "Degeneration X" it. And I'm not down with that...

Closing out MAIN we have a FOOTER tag for your footer.



The span in the #backToTop link is there to create a flyout on mouse-over, and to isolate the scripting off fallback text.

Also It's © or Copyright, don't use both. "Copyright Copyright" is kind of silly. Also legally at the international level -- and by US and EU law -- you no longer need to list the years.

Ok, that's your page, now what about the main menu? We want that as a modal dialog, accessible scripting off, and to be able to link to other menus.



The closing links are "hidden" since non-screen user-agents won't care about them. There is no reason print, speech, braille, or even search should care about the state of a modal, much less closing them. To such UA these should just be normal sections of the page. They also get text hidden by a span for screen so that should a garbage screen reader actually try reading screen, it has something to read. Also gets you 100% Accessibility score in Google Lighthouse.

I use NAV as the outer container becuase this is a navigation section. It gets a H2 as a landing, and a menu is a list of choices, so UL/LI it is. Notice how the last two link to the #contact and #subMenu modals.



Same idea for the second menu, not significantly different apart from the anchor back to the main menu.

The contact form:


Being a form uses the FORM tag as the outer container. Again a H2 to mark that it's a major subsection, and a simple contact form. This way you don't need a separate page for such a small bit of code, resulting in cleaner access than forcing a "pageload for nothing".

Finally at the end I load the script and close out the markup.



Loading a script at the end of the markup before </body> means that the entire static DOM is built, so if we want to manipulate things before DOMContentLoaded or Widnow.onload, we can do so. In fact the number of times I have "needed" to trap those two events the past decade can be counted on one hand. It also loads "faster" though preloading it has much the same impact.

... and that's the markup.

I'll get to documenting the CSS when I get a chance.

Oh, and before we get into the CSS I want to talk the stylistic changes. I switched to a much smaller font set in EM/REM using dynamic fonts "clamped" between two extremes. The PX fonts you had were not good from a usability perspective.

Choosing font size is actually easy if you follow some simple guidelines. Don't use PX, use EM or REM instead. Don't go below 0.875 default rem (14px for normal users). (you can change REM by changing it on the HTML tag, so care must be taken there). For flow text 1rem is usually the ideal, resulting in 16px normal, 20px "large / 7+ medium / 8514 / 120 dpi / 125% / pick a huffing name already", 24px "7+ large", or even the 32px I have my 4k media center set to with the ten foot interface. You can then "tweak" based on screen size using the new "clamp" property. Thus why in the CSS I have this:



This changes REM based on the default REM. "clamp" means that it's based on the middle number, cannot go below the first number, and cannot go above the last number. Using 2.5% of the vertical width or 4% of the height -- whichever is smaller -- as the basis results in dynamically scaled fonts within those limits based on screen size. From there if everything is declared in EM or REM it will scale to those values. On top of using whatever the user has chosen as their default size. This prevents many users like myself from having to dive for the zoom.

I've been using 20px or larger default font size since Windows 3.0 as I actually owed an AT with a 8514 adapter.

Anyone telling you to do anything relating to font size, section widths, paddings, media queries, and so forth in PX doesn't have the first clue what they're talking about.

And it's why the only time you'll find PX in my code is for larger raster images I don't want to get pixelated by being stretched, or for "maximum size" box-shadow since the limit on size in most browsers is 256px. (offset + blur + push combined). To that end it's why so many dev's now use webfonts for icons, or when using raster images deploy a "double resolution" image so that when scaling occurs it is always "shrink". And with browsers leveraging the GPU for anisotropic filtering shrinking images looks really good nowadays. Enlarging is still "garbage in, garbage out"

I reduced the amount of "all caps" because that too can be an accessibility headache. It's ok for one or two words, or for EMphasis or "more emphasis" when you don't have access to the correct tags such as in a forums, typing on a real typewriter, or on something crippled like twitter. Or even for adding emphasis to "more emphasis" such as "WARNING!"

It's not ok for major flow content.

Similar for the adjustments I made to the colour palette as I aimed for accessibility first. I spent the past decade and some change working as an accessibility and efficiency consultant, so that's where a LOT, no, a LOT! of my efforts go.

Oh, and I really hate that cyan mucking up the beautiful amber.

Same goes for organizing the tabular data. It's funny a good number of folks scream "tables aren't accessible" because they've never bothered coding them properly. You use tables when the rows and columns are semantically related via headings. Headings have SCOPE, which is to say a direction in the table by which they apply -- ROW and COL.

MOST of the time if you see <b> tags inside a TD for a heading, or TH without scope, or a lack of at least THEAD and TBODY, you're looking at people writing tables who don't understand how they work.

I also wrote about this on Medium:
https://medium.com/codex/ffs-would-you-clow...ly-48801df59833

As I said in the HTML writeup, a lot of people magically turned "don't use tables for layout" -- a completely valid statement -- into "don't ever use tables" -- so much 100% grade A farm fresh prairie pies that it dwarfs Biff Tannen's '48 Ford Super De Luxe.

That happens a LOT in HTML where people will take a statement completely out of context and blanket apply it to everything. Just look at the confusion around B/I/EM/STRONG for proof of that nonsense.

And it's even crazier the "men and horses, hoops and garters, lastly through a hogshead of real fire" people will jump over and through to support such false statements. From manufacturing nonsensical claims about how 'slow" tables are, to claims of being "non-semantic" and "inaccessible" that are more about their own ignorance than having anything to do with fact.

The speed claim always made me laugh. IF a 386/40 with 8 megs of RAM running IE 4 could handle it on dialup, it's time to sierra tango foxtrot uniform about the "speed" of a table in the age of 50-100x the clock speeds, 5-8x the IPC, and a thousand times the RAM and bandwidth.

Such claims coming from people who get taken for a ride by the likes of W3Schools or blindly trust and copy everything off of Stack Overflow. That's not on those so bamboozled, it's on the predatory scammers who run these places.

There's a reason I point people at MDN. Or used to point people here to WDG's HTML 4 reference when 4 was still relevant. Which is funny, I've used that reference as an exemplar of "doing it right" since around 2001, never knew this place had a forums until a month or two ago.

Related to the font sizes is the change of the menu to a conventional modal. It was too much of a "fist in the face" with the menu items taking up the entire screen. Not a big deal when it fit mobile, but on a 4k desktop it was a bit much.

I'm not 100% wild about the choice of a serif font for the flow text (paragraphs and the like). For the larger headings such fonts are fine, but the more complex the font the less usable it is at "normal" sizes. I would consider switching that out for something more conventional like "lato", "droid sans" or "poppins". Sans fonts might look boring, but they're legible.

One of the most important lessons of design? The best design is actually one the user DOESN'T notice... because it they notice stuff like that it means it's probably interfering with what they came to the site to do -- access the content!

When consulting I oft end up screaming "CONTENT" in people's faces the way a drill instructor would the word "TEAMWORK!" quoting R. Lee Ermey verbatim over how I didn't realize they stacked **** that high.

But as I keep saying, web development education could learn a good deal from the military. That was a joke.

Oh, before I get into the CSS I also want to explain why I made the directory structure the way I did.

I'm a firm believer that if you have to "../" in your code you're doing something wrong. It's why for static sites I put ALL my HTML files in the root, and for dynamic sites I'm a firm believer in "one index to rule them all" -- which is where every request is rooted through a central index.php or similar. (depending on language used).

This way you never have to worry about absolute links (the full URI) or up-tree "../". This improves 'portability' -- the ability to have both local and server copies without it needing to care about where it is. You can move it to any directory on a server or local filesystem and it doesn't care because everything is "down-tree" pointing relative links.

It also plays well with how when you load resources from CSS they are loaded relative to the location of the CSS files. Thus if you have a the CSS in /template images the CSS needs can go in /template/images and fonts go in /template/fonts, keeping them separate from a "root' /images containing actual content.

Good practice? If it's part of the template and not content, it doesn't go in the markup. So why not have a directory structure that mirrors this? Even better if you want to implement different templates and skins, you can keep the template files separate from each-other by creating something like /template/default and /template/theme2 with their own /template/default/images and /template/theme2/images.

Basically I try to organize thus:

/ -- root, contains all user-callable HTML as well as favicons since UA's assume your favicon.ico and apple-touch-icon.png will be there regardless of what you set in your HTML.

/downloads -- files the user can grab.

/images -- content images. Not part of the site template(s)

/scripts -- all content scripting

/template -- the CSS and any template generation files.

/template/fonts -- webfonts

/template/images -- template images, not content

/template/scripts -- scripts specific to the template, not the content.

You don't have to follow my pattern, but develop a clear consistent pattern. Organization skills are as important to sane and rational design as any other factor. Much like with the tab formatting of code, it's consistency across your entire project that matters more than the details.

Christmas on a cracker, is this guy ever going to shut up? Ouch, that was painfully self-aware.

This post has been edited by Jason Knight: Jan 29 2023, 12:31 PM

Thank you again for the work that you've put into the above.

When I first saw the explanations above, I have to admit that I was a bit daunted by it, but after reading and re-reading it, it's beginning to make more and more sense.

I've started at the foundations and I'm working my way up from there, so I have a quick question about directories.

You've mentioned that you prefer to put all of your .html files into the root directory.

Does it matter how many are in there? I mean, is there a limit that shouldn't really be exceeded?

I'm likely to have many thousands of .html pages over the next few years and I'm just wondering if that amount is going to slow things down in the future, if they are all in one directory.

It's a lot to take in, just keep hammering away at it. It's not actually THAT complex, there's just a lot of it.



At around 20 or 30 pages is when I'd give serious consideration to adding some form of content management, even if it's just "poor man's CMS" of routing all requests to a single index.php and glueing the requested parts together.

I'm actually writing a medium article about that which should go up in a week or so. I usually have four or five articles being written at once. Block sets in I work on another one.


Yeah that's definitely where I'd be using PHP as glue. I'm actually working on a different simpler way of handling that.

Oh and sorry I've not gotten to doing the CSS writeup yet. It's on my to-do list.

I don't think it matters to the server, but thousands of pages in the same directory might be hard to overview for yourself, so for that reason alone you might use multiple directories. Here's an old but still good page on organizing a website: https://webtips.dan.info/subdir.html

You may also want to come up with a practical naming scheme for all the future HTML files. If you'd use obscure filenames (say for brevity) it may become very hard to find a particular page in the directory listing once the number of pages grows. It's also best to avoid spaces in filenames, at least Google seems to prefer words in a URL to be separated by hyphens: https://developers.google.com/search/docs/c...g/url-structure

If the pages share any common content (like headers, footers or nav menus) it will soon become very tedious to edit all of them if necessary. For that reason it might be a good idea to use some kind of server-side includes (like Jason mentioned above), where you'd use a single, global file for all the pages' headers, footers and menus, respectively; the content of these global files are then inserted seamlessly into the web page on the server (by e.g. PHP's include expression) before being sent to the site visitor's browser. Whenever you need to make changes in the header, footer or menu you then only need to edit a single file, not thousands (a bit similar to using an external CSS or javascript file, except that it's done on the server, not by the browser).

It's also possible (but much more advanced) to store each page's unique content in a database; and generate each web page using a single HTML template, which is populated by content pulled from the database. That's how this forum works; all forum post content etc is stored in the database, and the same web page (index.php) is filled with a different forum post/thread depending on the query string parameters (the part after the "?" in the URL).

My apologies. Perhaps I should have mentioned the amount of pages beforehand - and also done a little more planning into how the site was going to run - before I made my initial post.

In the past week, I've managed to become quite conversant with the information that's been posted above, but now, with the mention of a CMS, and I can understand the benefits of using one, I'm not sure exactly how to continue.

This also leads me to another question. Would I be able to style a CMS to make it look at least something like the existing site that I already have?

If it helps, I have access to setups for Joomla, Drupal and SilverStripe, but I have no idea what I'd be doing with any of them.

(No worries, Jason - I'm just looking forward to reading it once you manage to write it up.)

This post has been edited by Midwinter: Feb 4 2023, 02:45 PM

Just an update...

Having now spent a good few hours/days trying and testing 8 different CMS's, I've found all of them unsuitable for a variety of reasons.

The main issue is that I just can't get "that look" that I've been after - so I've decided to continue with the above code, in the hope that I can hire someone at a later date to either design something that works, or come up with a workaround to the "large amount of pages" issue that I will probably have by then.

Any suggestions, hints/tips, or pitfall avoidance notifications would be very gratefully received at this point.

In the meantime, I'd like to once again say a big thank you to all of you, for all of your help and I look forward to asking some more questions along the way.

Also - still looking forward to reading your CSS tutorial, Jason, even though I think I've managed to work out most of it, to be honest - and you're right, it's not that hard after all, really.

Perhaps some kind of Blog script could be used? Otherwise I wouldn't recommend a CMS, since you already know how to write HTML yourself. A CMS mostly makes sense if you want to let other people edit the content, and you want to limit how much they're allowed to change the HTML in the process. Possibly a CMS could also be useful if you want to edit content yourself, but from any PC, mobile phone etc (e.g. when travelling, and you don't have access to your FTP program, text editor, etc).

A custom-made CMS would also be expensive to create, and would limit you to whatever HTML structure it was created to work with.

Instead of a CMS I'd just use global PHP inclusion files for the header, footer and nav menu; in my experience it's a very simple and practical solution.

Hi Christian.

Thank you for the response.

A blog script is a possibility depending on the configuration limitations.

I like the idea of the global PHP inclusion but I have absolutely no experience of PHP whatsoever, beyond changing the version on my server.

Do you have any suggestions into where I might find a working example at all, please - or should I be looking into learning the complete language?

It very simple, just add something like:


in the HTML files at the location where you want the snippet of say menu HTML to be included. Also the HTML files by deafult need the extension ".php" instead of ".html" for the server to run PHP code in them. (You can also make PHP run in files with ".html" extensions, by using a .htaccess directive --your webhost's support should provide specific details. Unfortunately the exact value of this directive may need to be changed every time the server's PHP version is updated.)

The file to be included ("menu.txt" in the example above) can have any file path, name or extension you want, as long as it matches the include directive. Note that the file must only contain the HTML snippet you want included; not an entire web page, like you do with iframes.

Your browser must of course load the web pages from a server for PHP to run, unlike static HTML files it doesn't work directly from your local file system. If you want to run PHP on your local PC you can install a server package such as XAMPP on it: https://en.wikipedia.org/wiki/XAMPP