Syntactic/dynamic tag/attribute extensions

[kirillsemyonkin]

Unsupported Attributes

Systems like HTMX require attributes using a colon in their name, for example hx-on:click or hx-on::before-request. Currently Yew does not support the colon/namespace syntax, even though HTML spec allows it (is - a valid attribute name? what about :?).

Main concern with supporting it directly via a set of idents and colon-puncts may be the way Rust macros handle spaces (this link is suggested by stylist documentation - once start and end or such stabilize, it would be possible to figure out the whitespaces from token lengths and positions). If Yew were to support boolean attributes as they are defined in the spec (like abc- abc=123 should be interpreted as abc-="abc-" abc=123, but in Rust with ignoring spaces it would become abc-abc=123), some ambiguity may appear, but Yew for the better or the worse, does not.

Additionally, Yew uses ~ for HTML/JS (doc is a little unclear on what it exactly it does) properties, which supposedly is valid HTML as per spec mentioned above, which would clash with extending Yew syntax to all characters.

Proposed Syntaxes

• Simply support colons just like dashes: a:b-c:d. More characters should be allowed if Yew were to follow the HTML spec, but every single new character (@, ~, etc) to be added would have to be vetted.
• Add a dynamic attribute syntax: {"attribute"}={"value"}, but also "attribute"="value". Having quotes in attribute names is banned per HTML spec, so it should be fine to use in Yew.
  • Should key and ref be handled in any way if the attribute is dynamic? What about direct "key" and "ref"? (does current Yew support ~key and ~ref to be properties instead of built-in keywords?)
  • Should dynamic attributes be also forced/allowed to use @ (e.g. @{"attribute"}={"value"})?
  • Should attribute name be sanitized before being passed to Browser APIs like set_attribute? (does current Yew sanitize dynamic tag names, for example whitespaces?)
• Remove @ from the dynamic tag syntax. It seems unnecessary, as <{"dynamic-tag"} ... > (but also <"dynamic-tag" ... >) would suffice.
  • What would be the closing tag? For example, a constant </{}> or having to repeat the dynamic tag (but then it would have to be checked in runtime). yew-alt-html supports </> for all tags.

[its-the-shrimp]

Simply support colons just like dashes: a:b-c:d.

What would be the use case for allowing colons in attribute names?

Add a dynamic attribute syntax: {"attribute"}={"value"}, but also "attribute"="value"

This is a wonderful idea, especially for the edge cases of actually needing some unusual characters in attribute names.

Should key and ref be handled in any way if the attribute is dynamic?

If one of intended use cases of these is an escape hatch from the limitations of the syntax of html!, then it should be a good escape hatch and not carry over the restrictions, I believe Yew should do absolutely nothing with dynamic attributes and pass them as it receives them.

Remove @ from the dynamic tag syntax. It seems unnecessary, as <{"dynamic-tag"} ... > would suffice.

<@{x}></@> is pretty much equivalent to <{x}></{}>, even in terms of the length of the syntax: both strings are 10 characters long, and I can't see where would one need a @ in a tag/attribute name, so I believe there'd be no benefit in adding another breaking change to Yew.

Should dynamic attributes be also forced/allowed to use @ (e.g. @{"attribute"}={"value"})?

As far as I understand, @ is required in dynamic tag names for easier association of <@{x}> with </@>, purely an aesthetic choice; for dynamic attributes that question would be irrelevant.

[kirillsemyonkin]

@schvv31n

What would be the use case for allowing colons in attribute names?

The very top of my text mentions HTMX. Some people in Discord suggested that they wanted to be able to SSR HTMX using Yew, and this would be one (if not the only one) step necessary. Other cases may be attributes related to SVG, MathML, and many other places where XML namespaces may be used.

I can't see where would one need a @ in a tag/attribute name

This is for HTML spec parity (but I am actually not sure if its allowed in actual browsers), making @ to actually be able to be used in tag/attribute names.

there'd be no benefit in adding another breaking change to Yew

First of all, it does not have to be breaking - both variants could be allowed (or repurposed - for example, <@ComplexComponent<K, V>> to be able to close it with </@>). To me, the {x} is looks more pleasing (concise and consistent) than @{x}, which uses a character that in Rust is used for variable bindings, and adds another thing to remember (@{} does dynamic tags, ${} does stylist interpolation, #{} is what SCSS uses, and {} is what everything else uses - we have !{}, &{}, *{}, etc to spare!). Alternatively, if character count is your optimization metric, rather than consistency, </> could be taken from my project I mentioned in the post.

The feature itself is not used as extensively to be worried about breaking everything, unlike recent changes like ..._with(deps, ... (which honestly is not the fairest comparison since latter is actually a useful change).

[kirillsemyonkin]

for the edge cases of actually needing some unusual characters

Other use-case may be, you know, dynamic attribute names:

let hidden = false;
html! { <div { if hidden { "hidden" } else { "visible" } }="" /> }