Proposal: Support for String Interpolation and Templates in `ht-content`

[thoward]

Overview

Currently, the ht-content attribute only supports a simple comma-delimited fallback list (e.g., ht-content="page.title,site.title"). While effective for simple value replacement, it lacks the ability to combine multiple variables or wrap variables in decorative text (like pipes, dashes, or labels) at build time.

This proposal introduces Braced Interpolation for ht-content. This allows developers to treat the attribute value as a format string where multiple data sources can be injected into a single tag.

Specification

Syntax

1. Plain Mode (Legacy Support): If the attribute contains no braces (e.g., page.title), it behaves exactly as it does today (evaluates the fallback list and replaces the entire innerHTML).
2. Interpolation Mode: If the attribute contains curly braces { }, the string is treated as a template.
   • Content inside { } is treated as a standard HyperTemplates variable/fallback list.
   • Content outside { } is treated as literal text.

Behavior

• The parser identifies all braced expressions.
• Each expression is evaluated independently using the existing fallback logic.
• If a braced expression evaluates to an empty string (all variables in its list are missing), it renders as an empty string within the template.

Example Usage

1. Page Titles with Site Context

<!-- Input (where site.untitled_post is a constant string "Untitled Post" defined in site.yaml -->
<title ht-content="{page.title,site.untitled_post} | {site.title}">Placeholder</title>

<!-- Output (if page.title is "My Page" and site.title is "My Site") -->
<title>My Page | My Site</title>

<!-- Output (if page.title is empty, falls back to site.untitled_post for that braced expression) -->
<title>Untitled Post | My Site</title>

2. By line, with potentially missing post authors and default site author

<!-- Input -->
<span ht-content="By: {page.author,site.default_author}">By: Admin</span>

<!-- Output -->
<span>By: John Doe</span>

Benefits

• Flexibility: Allows complex string construction without adding extra HTML elements.
• Backwards Compatibility: Existing ht-content attributes continue to work without modification.
• Consistency: Uses the same comma-delimited fallback logic developers already understand.

Go Implementation Proposal

The parser will use a regular expression to find all {} blocks, evaluate the inner expression via the existing variable resolver, and rebuild the string.

Example: Go implementation

package main

import (
	"fmt"
	"regexp"
	"strings"
)

// Mock resolver for the existing variable logic
func resolveVariable(expression string) string {
	// This would be your existing logic that splits by comma
	// and looks up values in your data map.
	data := map[string]string{
		"page.title": "My Page Title",
		"site.title": "HyperTemplates Blog",
	}

	parts := strings.Split(expression, ",")
	for _, p := range parts {
		val := data[strings.TrimSpace(p)]
		if val != "" {
			return val
		}
	}
	return ""
}

// InterpolateContent handles the new braced logic
func InterpolateContent(attrValue string) string {
	// Regex to find everything inside { }
	re := regexp.MustCompile(`\{([^}]+)\}`)
	
	// If no braces are found, treat the whole string as a single expression (Legacy)
	if !re.MatchString(attrValue) {
		return resolveVariable(attrValue)
	}

	// Replace all {expression} with resolved values
	return re.ReplaceAllStringFunc(attrValue, func(match string) string {
		// Strip the braces to get the expression
		expression := match[1 : len(match)-1]
		return resolveVariable(expression)
	})
}

func main() {
	template := "{page.title,site.untitled} | {site.title}"
	result := InterpolateContent(template)
	fmt.Println(result) // Output: My Page Title | HyperTemplates Blog
}

[calebhailey]

Thanks for the proposal! This has been on my mind for a long time. It's definitely one of the bigger limitations of HyperTemplates at the moment. I just haven't decided if it's the good kind of limitation, or an unnecessary/unhelpful one.

Templating the <title> element is currently not possible in HyperTemplates because <title> elements "only [contain] text; HTML tags within the element, if any, are also treated as plain text." (MDN), so HyperTemplates normal templating tools won't work there. That means this proposal would add a new capability for templating the <title> element specifically - a very common use case! However, the second example you provided is already possible with HyperTemplates.

Here's the example you provided:

<!-- Input -->
<span ht-content="By: {page.author,site.default_author}">By: Admin</span>

<!-- Output -->
<span>By: John Doe</span>

Here's the same example that moves the ht-content attribute to a nested element:

<!-- Input -->
<span>By: <span ht-content="page.author,site.default_author">Admin</span></span>

<!-- Output -->
<span>By: <span>John Doe</span></span>

NOTE: wrapping the author's name in an HTML element provides a secondary benefit in that the author's name could be marked up using microformats. Semantic HTML for the win!

And another example using the ht-param attribute:

<!-- Input -->
<span>By: <param ht-param="page.author,site.default_author" default='Admin' /></span>

<!-- Output -->
<span>By: John Doe</span>

And another example using ht-param with a regular element (instead of the deprecated <param> void element):

<!-- Input -->
<span>By: <post-byline ht-param="page.author,site.default_author">Admin</post-byline></span>

<!-- Output -->
<span>By: John Doe</span>

I will give this proposal some thought as it directly addresses something very useful that is not possible with HT today. In the interim, I hope these examples are helpful! 😊

[thoward]

I would say the primary distinction here is the ability to composite multiple variables into a single string rather than using nested elements. It would also be great if there was a way to target not just the innerHTML element contents but also an element attribute, similar to how ht-attrs works now. not sure what that syntax would look like, but I could see something like a "More by this Author" link that would need to assemble a context specific string that ends up in an href like http://myblog.com/authors/thoward and would be assembled from a base URL template like http://myblog.com/authors/{page.author}.