Nuemark: add reliable explicit [block ...] attribute-only blocks #38

Summary

Nuemark needs a reliable, explicit attribute-only block form:

[block data-name="example"]
  Content

The built-in block renderer already exists, and paragraph-only probes can render through it. However, named [block ...] is not currently a safe authoring form because named tags use Nuemark's YAML-body heuristic. YAML-looking Markdown bodies are converted to tag data, block.blocks is omitted, and the block renderer crashes when it attempts to render undefined.

This issue formalizes the explicit form, fixes that parser/renderer mismatch, and hardens its attribute behavior before Project Clarity migrates existing dot-form wrappers.

Reproduction

This works because the nested body does not look like YAML:

[block data-x="one"]
  Hello

This fails:

[block data-x="one"]
  - Item

The list-first body produces a tag shaped like:

{
  name: "block",
  attr: { "data-x": "one", class: "" },
  data: {},
  has_data: true
  // no blocks
}

Rendering then fails in renderBlocks() because blocks is undefined. Prose beginning with a YAML-looking key, such as Note: text, has the same parsing hazard.

The anonymous form does not fail:

[. data-x="one"]
  - Item

Its parsed tag name is null, so it bypasses named-tag YAML detection and the body is parsed as Markdown blocks.

Provenance

• block() was introduced by extracting the anonymous-block rendering path.
• Dispatch uses tag.name || 'block', so the explicit name happens to reach the same handler.
• Existing regression tests cover anonymous [.class] blocks, including list content.
• There is no named [block ...] authoring test or public documentation.
• A prior fix intentionally limited YAML-body detection to tags with a truthy name so anonymous list blocks remain Markdown. The explicit name re-enters that YAML path.

This means the handler is intentional, but the named authoring surface is not yet established as a complete contract.

Required work

1. Make explicit block bodies reliably Markdown

Define block as a structural Markdown wrapper whose nested body is always parsed as Markdown, even when it begins with:

• a list item such as - Item;
• YAML-looking prose such as Note: text;
• headings, separators, nested tags, or other sectionized content.

A likely implementation is to exclude the built-in block name from named-tag YAML-body detection. An equivalent block-specific parsing route is also acceptable.

Do not solve the crash only by defaulting missing blocks to an empty array; that would silently discard author content.

2. Add explicit-form regression coverage

Cover at least:

• paragraph content;
• list-first content;
• Key: value content;
• nested/sectionized Markdown content;
• class/ID shorthand combined with data-*;
• parity with anonymous [.class] rendering;
• no regression for built-in/custom tags that intentionally accept YAML data.

3. Define quoted custom-data value semantics

The current inline value parser coerces quoted values before attribute rendering. As a result:

• data-state="0" is omitted;
• data-state="false" is omitted;
• data-state="true" becomes a bare boolean-style attribute.

For quoted data-* attributes, preserve literal string values unless a different rule is intentionally chosen and documented. Retain intentional coercion for unquoted tag data where compatible.

4. Avoid an empty internal class value

Parsing an attribute-only tag currently retains an internal class: "" value. It does not appear in rendered output, but absent classes should be omitted from the parsed representation. Add a focused parser assertion.

Acceptance criteria

• Named [block ...] is an intentional, tested attribute-only Markdown wrapper.
• Its body cannot be diverted into tag YAML merely because the content begins with a list or Key: value.
• All supported Markdown body shapes render without crashes or silent content loss.
• Quoted data-* values have defined, tested string/boolean/number semantics.
• Attribute-only blocks do not acquire an internal empty class.
• Existing anonymous-block behavior and YAML-data behavior for other built-in/custom tags remain compatible.

Documentation and migration boundary

The legacy public documentation should not be patched during Project Clarity M6. The M8 rewrite will document the explicit form only after its final behavior is source-verified.

The Direct Work site currently has 17 permissive [. data-*] forms. Their migration is gated on this fix and is not part of this issue.