Support src attribute for image and style elements

[rowland]

Problem

LTML already uses src for <image>, but other content that naturally wants external file input still requires inline content. In particular, <style> currently expects the rule text to be embedded directly in the document. The legacy <rules> tag is still supported for compatibility, but <style> is now the preferred spelling.

We need src support for image and style elements so LTML can load external assets and external style declarations in a consistent way.

For <image>, this likely means formalizing the current src behavior as part of the broader design rather than leaving it as a one-off. For <style>, it means adding the ability to load rule text from a file path instead of forcing inline markup.

Goal

Support src as a first-class attribute for:

• <image>: external image assets, including existing JPEG/PNG/SVG behavior
• <style>: external CSS-like LTML rule declarations loaded from a file

The broader goal is consistency: elements that are naturally backed by external content should be able to reference that content through the same asset-loading conventions.

Proposed plan

1. Define common src semantics

Document and standardize how src is resolved:

• relative to the writer asset FS when configured
• otherwise relative to the working LTML file / current filesystem behavior
• with clear errors for missing or unreadable files

This should become explicit in ltml/SYNTAX.md rather than implicit behavior.

2. Keep <image src="..."> as the reference implementation

The existing image path is already the best precedent.

Tasks:

• review StdImage and the writer asset FS path resolution to make sure the semantics are stable and documented
• confirm JPEG, PNG, and SVG all remain supported through the same src contract
• add any missing tests if the current behavior is under-specified

3. Add src to <style>

Teach the Rules element to load rule declarations from an external text file when src is present.

Suggested behavior:

• <style src="styles.ltml.css" /> loads the file contents and parses them the same way inline rules are parsed today
• inline rule text and src should have defined precedence. My recommendation is:
  • allow either inline content or src
  • if both are present, either concatenate in document order or reject as ambiguous. I would lean toward concatenation only if there is a clear use case; otherwise erroring is simpler and safer.
• comments inside the external rules file should behave the same as inline rules if that is part of the current parsing contract
• if useful, the same src behavior can also apply when documents still use the legacy <rules> spelling

Implementation notes:

• extend ltml.Rules with a src field and SetAttrs handling
• add a file-loading step before or during scope.AddRules(rules)
• keep parse errors informative by naming the external file path in diagnostics

4. Reuse the existing asset-loading model where possible

Avoid inventing a separate path-resolution mechanism for styles.

If possible, <style src="..."> should use the same asset FS / path lookup approach as <image src="...">, so embedded documents behave consistently whether they are loading images or external style rules.

5. Add tests and docs

Tests should cover:

• <image src="..."> remains unchanged
• <style src="..."> loads rule text from the asset FS
• legacy <rules src="..."> behavior, if retained, matches <style>
• relative path handling works as expected
• missing-file errors are clear
• precedence behavior when both inline content and src are present

Docs should cover:

• src semantics for both elements
• at least one example using external styles
• note that <rules> remains a legacy compatibility alias if that stays supported

Open design questions

• Should <style> allow both inline content and src, or should that be rejected as ambiguous?
• Should legacy <rules> gain the same src behavior automatically, or should the feature be documented only on <style>?
• Should src be generalized further for other LTML tags later, or should we keep this narrowly scoped for now?
• Should external rules be cached per path within a document, or simply loaded once when parsed?

Workarounds today

• Keep using inline <style> blocks.
• Continue using legacy inline <rules> blocks where needed for older documents.
• Preprocess LTML files before rendering if external style files are needed.
• Continue using <image src="..."> as-is for external image assets.

Acceptance criteria

• Existing <image src="..."> behavior remains unchanged and documented.
• <style src="..."> can load and apply external rule declarations.
• If legacy <rules> remains supported, its src behavior is either equivalent to <style> or explicitly documented as unsupported.
• Asset FS / path resolution is consistent between images and style rules.
• Tests cover both success and failure cases.