Closed jstarry closed 3 years ago
I actually like the strictness of not allowing string literals and keeping a separation between the DOM structure created and the "contents". Has this feature been requested lots?
@mdtusz it hasn't, just wanted to document the request. It will likely be marked as won't fix
I like the strictness and singular way to do things as they stand, but I do sometimes find it frustrating to not be able to copy+paste HTML from some external site (like some CSS framework guide showing how to use their classes) and instead have to meticulously wrap every bit of text in {"
and "}
to appease the html! macro.
I don't think its too much of a problem if its implemented or not.
I think it's important that html!
accepts pretty much any valid HTML. Allowing plain text is probably the most obvious thing, but there are other examples too. I could imagine making the following legal:
html! {
<ul>
<li>List item
<li>Another list item
</ul>
}
(yes, that is valid HTML5)
Also, I think yew should recognize tags that HTML5 specifies to be self-closing (to make <meta>
and <input>
be equal to <meta />
and <input />
.
Maybe I should just implement this in a new proc macro crate :thinking:
While html!
outputs html, the input isn't html and is a lot closer to jsx and other html-likes. I think it's probably prudent to keep it strict. It can be slightly annoying to have to remember and fix closing tags, but it is in line with "the rust way" of keeping things correct.
If the desire is to be able to have pure input html, perhaps a raw_html!
macro could be useful?
Just my $.02, but sticking as closely as possible to JSX syntax is probably a very good thing given the broad adoption of the syntax... which means literal text should be allowed, and non-xml input would not be allowed.
Along the same lines would be empty tag (fragment) support, in case you need it (such as for a dictionary list item).
html! {
<>
<dt>{term}</dt>
<dd>{definition}</dd>
</>
}
Another minor detail I've recalled about this topic is that I believe that syn is much faster at parsing quote-delimited strings instead of arbitrary text tokens. I think it would be prudent to benchmark compile times before such a change would be merged because there might be the possibility of drastically slowing down compile times.
I hadn't considered JSX. If it's also much more strict than HTML, that's a reason to be a little stricter as well.
syn is much faster at parsing quote-delimited strings instead of arbitrary text tokens
I hadn't previously considered how html!
input is parsed. I wonder why it would be that much slower. Personally I've always heard that compiling syn
takes much more time than its actual parsing.
@tracker1 fyi fragments like
<>
<span>{"Yay!"}</span>
<span>{"Yew!"}</span>
</>
already work!
Closing this in favor of #1758
Description
Yew's
html!{}
macro deviates from JSX by not allowing text literals.Proposed Syntax:
Current Syntax