Theme four-point-nine

giz · Yesterday 20:33:50

The default theme for 4.9 needed updating to reflect the new image generation system, so I thought I’d give it a go.

My approach is one-size-fits-all, and provides a range of sizes for the browser to choose from (it uses sizes="auto").

A bunch of template suggestions followed:

Pages and Forms

The default and archive pages are somewhat daunting or complex for newbies, so I simplified them by creating 2 new forms (misc/head.txp and misc/pagination.txp). This reduced the pages considerably, but there is still more that can be done eg. the <body> tag variants are a candidate for another form. Is <txp:if_author> et.al used enough to warrant so many lines throughout the default templates? I’d like to see a peppering of some of the more recent/useful tags and attributes e.g. <txp:yield />. Maybe we could treat default.txp as only-the-basics, with archive.txp as the page with bells and whistles?

I added an image capability to article_listing.txp, and made minor formatting changes throughout – typically using wraptag="foo" to replace surrounding tags where possible to reduce the line count, and moving html comments so that they are within a <txp:if_etc> tag so they display if required.

Style

The css in the four-point-nine install is compressed, making it difficult to edit. I’m recommending new styling which still presents the site as a wireframe, but allows the user to control aspects via css variables at the top of the file, or dig deeper to make changes to components etc. lower down.

jakob · Yesterday 21:54:25

Happy New Year Gary! You’re making a good start already! Just a brief answer for now as I’m short on time. I’ve only taken a quick look at your commits for now but I like your general approach. Things like excerpting css variables I think are a great idea. Users can then add own stylesheets in the presentations tab and set their own css variables or add extra css, potentially transforming the basic framework (4.9 adds some other ways of bringing in css from Textpattern’s styles panel as inline content). I see various other simplifications in your commits, and some more segmentation into forms, which I agree aids readability. Ditto wraptag to avoid if_conditionals.

A more general aspect: as informative as schema.org structured data can be, I find it clouds the readability of the demo theme, even to the point of causing roundabout constructions that would not be necessary if one didn’t have to cater for the extra attributes. I absolutely see its purpose for complex sites and markup patterns that html does not already cater for, or for types of site with particular content patterns (and then arguably the json-ld method could end up being more concise), but the demo theme is not that complex in terms of content and my personal feeling is that search machines aren’t going to have difficulties processing the demo site. In short, the principle is great, but how much extra search-machine clarity does it actually bring in this demo case? Maybe this is just a gripe of mine?

For example:

<p itemprop="image" itemscope itemtype="https://schema.org/ImageObject">
    <txp:variable name="img-tag" />
</p>

denotes that it is an image?! … which the img tag already does on its own. Also, is it still important to differentiate between images with and without a caption? MDN suggests not, expressly calling figure a figure with optional caption element and shows a Just an image example. The validator doesn’t seem to complain, either, if a figcaption is not included.

Might there also be a less nested way of handling the multiple if_… situations? I suppose it does demonstrate the conditional tags, but even with experience, I have to read it carefully to follow. Oleg showedan alternative pattern. If I have site that needs this more than once, I do the nesting dance once and define a page_context variable that can I use in the rest of the templates.

Overall nice ideas in there. I imagine the toned-down styling will be polarising, but I like it. Maybe some style variants would illustrate the potential of the css custom properties?

When I have more time, I’ll give it a proper tryout.

Bloke · Yesterday 22:29:57

Fab start! The default theme defintely needs some consolidation, and I love the idea of using CSS variables to show off the customisation opportunities. And yeah, auto thumbs…

Currently, sadly, the thumbnail tags need height="0" to prevent them automatically creating weirdly tall images (without CSS to tame them) but I’m hoping this can be addressed in a few weeks in a maintenance release 4.9.1 to also catch a few stray edge case bugs. Hopefully I can get my head round a way to retain the thumbnail tag’s broadly backwards-compatible nature (which it is now) but also less wordy (which it certainly isn’t now).

So if we can iterate this idea for the default theme, I’m all for including it in 4.9.1.

The microformats do seem over the top. Not just in our theme, but in general. schema.org is way way waaaay too prescriptive and, as Jools says, a lot of it is completely unnecessary if using descriptive HTML5 tags. I’d love to hack some of it out. Yes, keep the “BlogPosting” stuff perhaps because div and section tags need a little hinting. But definitely slim it down.

I would actually like to take this opportunity to showcase the tag processing order – although I’m not sure how intuitive it is in a default theme – to actually ditch the wordy inline microformats and use JSON-LD. There’s a whole discussion on it and the consensus seems to be that the JSON-LD structure can be built by peppering <txp:variable name="json-ld" add> containers (see Jools’ comment and my reply) throughout the template and then using <txp:variable[-1] name="json-ld" /> to output the entire structure in the <head> tag, utilising secondpass to add it after the variable has been constructed (even though it is output before them all in the source code). It’s clever and shows off how powerful the tag processor is, and also simplifies the template.

Thoughts on this welcome. But yes, definitely a fantastic step up. Thank you, Gary (and Happy New Year).

Textpattern CMS

Textpattern CMS support forum

#1 Yesterday 20:33:50