Rebuilding on..

Well.. a lot of 'tidy up work' for 'Rebuild 22'..

CSS

CSS4 is a much more capable beast that I am used to, having probably had 'deep exposure' to CSS the last time about 10 years ago (CSS2?). My goal with this rebuild is to make it responsive (aka it looks good on everything from a phone screen through to a 20 inch monitor) and for the design to 'not suck too much' :-) And wherever possible to just get CSS to handle that. So far so good, SF_default.css achieves the basics and is less than a 100 lines, coming in at around 6kb

Pre-processing

So markdown is good, but not for everything. If for example you want to inject, or wrap, images in 'lightbox code' you're out of luck..

So I though about how this might work for a while.. The framework already had the ability to do content 'pre-processing' in the form of:

<!-- SF_command:something:somevalue -->

Essentially by using html comments (which is what <!-- --> are), in a very specific format, the framework can lift these (as many as you want) out of the content, and then provide whatever interpretation for what they contain. It was only ever implemented in this generic form where SF_command:something:somevalue got put into a global array SF_commands, indexed by 'something' containing the value 'somevalue'. This meant the framework doesn't have to do any interpretation here - it just lifts the comment out of the content, and stores what it contains as a generic operation. This happens very early in the frameworks load steps so these 'commands' can then be accessed pretty much throughout the entire of the frameworks processes.

So you're covered if you've got something simple you want to store to use later, say like a page date, e.g.

<!-- SF_Command:DateModified:10Sep2022 -->

But what about that 'lightbox image'? - you're going to need a url for the image, a caption, maybe a CSS class to position the thing on the page, the lightbox code itself is going to be a javascript function and you may want to 'pass arguments into' that function.. etc.

It's going to get ugly very quickly in the 'html comments' style of pre-processing.

The other thing which has been added to the framework for version 2 is 'front matter', or 'markdown page metadata', which again is a 'somefield: somevalue' kind of thing, which gets processed as simple yaml. You can have as many of these 'somefield's as you like, and again they are independently read in during pre-processing of the markdown content very early in the framework's steps. So in theory you could do:

url: /images/web500/someimage.jpg
caption: a dogs tale
cssstyle: figureclass
etc: etc
etc: etc

which will work fine if you have one image. But it's going to get very messy as soon as you have two.. What's more, are these things you really want to pre-process at global page load time? Probably not..

So, that's a very long introduction to shortcodes.

Shortcodes

Shortcodes are a basic abstraction used in static site generators, templating languages etc. Nothing new about them, you put them in the content, at the place where you want them to happen, and some functionality 'picks them out', interprets them, and replaces them with the html (+css+javascript) required to create the output you want.. i.e.

{{ type:lbimg; url:/images/web500/someimage.jpg; caption:a dogs tale; class:figureclass; etc:etc }}

So once you have the code to isolate the '{{ anything }}', you can then interpret what 'anything' means and replace the original '{{ anything }}' with the html output you want. It's simpler to say than it is to code, I can assure you, but it's certainly not rocket science, and at a high level generalises fairly well (which is always good in a coding sense, because one bit of code can handle many variations).

Shortcode processing, however, takes place during the page rendering process not as a pre-processing step. This is fine, it just means it has some limitations compared to global pre-processing of the page. For example, shortcodes can't be used to 'inject' things into the page headers, because the page header has already been rendered by the time the shortcode processing 'comes around'..

Ce le vie - so, shortcodes have been implemented. The initial test implementation is used to create javascript lightbox galleries using venobox. These allow for multiple images to be presented as both lower resolution 'on page', and full resolution images in a 'pop-up lightbox' display when the user clicks on them.

I'm sure the code for shortcodes needs to be generalised more, and for it to be possible for specific shortcode functionality to be isolated 'out of the framework'.. but it's working for now

enough for today..

Other posts on 'rebuild2022'