Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Reusing HTML without rewriting it
I have a site hosted through GitHub and I'm using footers for special links and it also serves as my main navigation bar for now. I find it a little frustrating to manually copy-paste the footer's contents and I could end up having footers different from one site to another with me missing a page or two to edit.
I'm aware of scripting languages, so that may be the way for me to continue, but with my lack of understanding of those languages, what can I do to automatically output something on every page of a site?
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
Use static site generator to manage your footer on multiple pages. GitHub supports Jekyll, by this you can create templates for common elements like footers.
1 comment thread
Use a static site generator. There are other possibilities, but they seem more complicated or worse for your use case.
A static site generator takes in source data in some combination of markup formats (commonly including raw HTML and Markdown) and generates complete HTML pages from that. A key feature of these tools is support for templates which can capture the common structure of related types of pages. These tools usually offer additional features, e.g. they may be able to generate navigation bars, tables of contents, and RSS/Atom feeds.
There are two basic ways to go about this. First, you can choose your own static site generator, run it locally, and simply commit the resulting generated HTML to GitHub. This is exactly what I do for my GitHub Pages hosted site using Hakyll as the static site generator. The benefit of this approach is that you don't need any special support from your hosting provider - so if you decide to host your site somewhere else, you just need to upload the generated HTML somewhere else.
The second way, which is probably better in your situation, is to use the static site generator built in to GitHub Pages. In particular, GitHub Pages supports Jekyll, a popular Ruby-based static site generator. For your specific purpose, you'd probably want to use the layouts and/or includes feature. This way, you don't need to set up Jekyll yourself (though you will probably want to), and the history of your GitHub repository will reflect the actual meaningful changes you make and not a bunch of generated noise.
1 comment thread
I agree with other answers that a static site generator is the best approach. This is something that the original designers of HTML left as an open problem. The problem has now been "solved" by third party tools, and there's not yet a good alternative to HTML. Static site generators are those tools.
HTML does not support includes, so indeed in vanilla HTML you are expected to duplicate the content on each page.
In theory, you can make the common content a separate page, and display it in a frame. This would have several drawbacks, one of them being that you can't have the footer be slightly different on each page (like highlighting the current page).
You could author your documents in some other format (that supports includes), and then compile them. Python's Jinja library can do this, as can Pandoc, and many others. However, you would be reinventing the wheel, since static site generators are already a mature implementation of this idea.
These days many sites generate the HTML both client and server side. The server (for example, Python Flask) can calculate each part of the page dynamically when serving each visitor, then compose them together. On the client side, Javascript can further modify the HTML. Sometimes the server just sends over data packets (like JSON) instead of HTML, and it gets rendered into HTML by client side JS. This is a popular approach in commercial frontends, but likely not worth the effort for you unless you want to make a webapp.
0 comment threads
1 comment thread