Errors

MX prefers a compile error over silently dropping or misinterpreting a construct. This page catalogs the errors you’re most likely to run into and why each one exists.

A stateful tag under strict

If the project (or a <let>/<effect>/etc. author) opted into the strict policy, using <let>, <effect>, <lifecycle>, <script>, a client block, or <id> on a host with no reactive target is a compile error naming the construct. The input-shadowing check below is not one of these six — it applies regardless of strict. See Stateful tags.

<await> on the html target

The html target compiles to a plain (input) => string function with no notion of a pending value, so <await> is always an error there — this isn’t a strict-only restriction, since there’s no way to render a promise to a string synchronously.

<try> with <@placeholder> on the html target

A <try> with only <@catch> compiles to an ordinary try/catch. Adding <@placeholder> needs a second render pass (show a placeholder, then swap in the real content once it resolves) that the html target’s single-pass string output can’t do.

A binding named input

<const/input=42/>

is rejected — it would shadow the parameter every compiled template function already has (function (input) { ... }), silently making the real input unreachable. This applies to <let>/<const> at the top level of a template.

A tag param named input is fine:

<for|input| of=items>
  <p>${input.name}</p>
</for>

because a tag param opens a genuinely nested scope, the same way an ordinary JavaScript function parameter can legally shadow an outer variable.

An attribute tag colliding with a prop

<Card children="x">
  <@children>y</@children>
</Card>

is rejected: <@children> would silently overwrite the children prop (or an explicit attribute of the same name), and MX treats that as an error rather than “last writer wins.” See Attribute tags and tag params for the full table.

Attribute-tag errors

These are the diagnostics introduced by the AttrTag contract. Names such as head, row, and Card are substituted from the source; the wording shown is the compiler’s wording, not a summary.

Declaration and call shape

Reading and rendering the value

Reading the callee’s Input

An unresolved import is a warning because the call can still use the syntactic fallback: couldn't read `<Card>`'s Input (`@app/Card` not resolvable); attribute-tag shape inferred from this call. Supply the tool’s synchronous resolveImport hook for aliases.

Astro and Angular projection limits

The projection hosts reject shapes they cannot carry instead of dropping data.

Angular additionally reports @mxlang/angular can't read projected content `header` as a value; render it with <${input.header.content}/> for conditions, property reads, and pass-throughs. Calling projected content with arguments reports `input.header(…)` passes arguments to content, which Angular's content projection cannot express: `<ng-content>` places the caller's nodes and cannot pass them values. Declare the block as a `<define>` and pass it as an input the component renders with `ngTemplateOutlet`.

The complete value shapes and legal render idioms are in the AttrTag guide.

class:foo and style:foo

<div class:active=isActive></div>

isn’t MX-specific syntax to avoid — it isn’t Marko syntax at all. Marko’s own parser rejects it before any host ever sees the template, with a fix-it suggesting the object form instead:

<div class={active: isActive}></div>

There’s no MX behavior to document here because no .mx file using the colon-modifier form compiles in the first place.

An ambiguous > in an attribute value

A > preceded by whitespace ends the tag, so a comparison written bare in an attribute value splits the tag in a way you did not intend:

<if=count > 9><p>double digits</p></if>

fails with Ambiguous “>” in attribute. Wrap the expression in parentheses:

<if=(count > 9)><p>double digits</p></if>

The same applies to any attribute value, not only <if>. <, and a > with no space before it, are unambiguous and need no parentheses.