In Razor syntax, @@ is documented as the way to escape a literal @ character in markup output.

Example (works as expected):

<p>@@hello</p>

This renders @hello in HTML output.

However, the same escape syntax does not work in component attribute values:

<Weather Value="@@currentCount" />

This results in a Razor compilation error, because the presence of @ switches the parser into C# expression mode, and @@currentCount is not a valid expression.

Observed Behavior

• @@ is recognized and processed in HTML content
• @@ is not recognized in component attribute values
• Component attributes do not appear to have an escape or literal-string mechanism equivalent to HTML markup

Expected / Questioned Behavior

From a user’s perspective, this is surprising:

<Weather Value="currentCount" />

is accepted and treated as a literal string, but:

<Weather Value="@@currentCount" />

is rejected, even though it could unambiguously mean the literal string "@currentCount".

This raises a few questions:

1. Is this behavior intentional by design, or a limitation of the current Razor compiler structure?
2. If intentional, is there documentation explaining why @@ escape applies only to markup output and not to component attribute values?
3. Would it be feasible (or desirable) to support literal escaping in component attributes for consistency, or is this explicitly out of scope?

Rationale

I understand that component attributes are expression-based and intentionally do not support mixed C# and markup content.

However, this scenario does not require mixed content — it only requires escaping a literal @.

The current behavior feels inconsistent because:

• @@ is part of Razor syntax
• Its validity depends on context in a way that is not clearly documented
• This can lead users to assume the feature is missing or incomplete rather than intentionally unsupported

Summary

This issue is not a request for string templating in component attributes, but a request for clarification (or reconsideration) of why Razor escape syntax behaves differently between:

• HTML markup
• Component attribute values

Even explicit documentation of this limitation would help reduce confusion.