[suggestion] Raw/unescaped strings in `view!` macro

[kyrias]

Currently all strings passed to the view! macro are escaped, meaning that using things like HTML entity references or in-line CSS using & becomes kind of a hassle since you need to use something like Unescaped::new_unchecked("§"). It would be neat if the view! macro had some way of passing in unescaped strings directly for this kind of use-case. Maybe even using actual raw string syntax?

[pikaju]

Hm, the reason topcoat makes it so difficult right now is because unescaped strings could be very dangerous. What specifically are you annoyed by, the amount of typing you have to do for Unescaped::new_unchecked? You could create a function like:

fn raw(s: impl Into<String>) -> Unescaped<String> {
    Unescaped::new_unchecked(s.into())
}

and then write (raw("unescaped content")). Would that solve your problem?

[kyrias]

I do think it makes sense overall, yeah. I'm slightly annoyed by the amount of typing, but it's mainly that the resulting formatting after running topcoat fmt that easily ends up very... disagreeable, let's say. It does seem a bit strange to me to worry too much about unescaped string literals in the view! macro though, and it seems to me like having raw string literals actually be passed through as-is would makes sense.

To be fair, for the HTML entity reference use-case it would probably make a lot of sense to just have an EntityReference enum which would correctly render them, even if only to ensure that you only use valid ones. But I also have inline style blocks where it's causing an issue with nested CSS rules which use &, and splitting that into multiple strings with only some parts being passed to another function leads to kind of weird/difficult to read formatting. On the other hand that's kind of the case anyway since I'm using the font! macro and constructing the font-family using the Font::family method, so I guess that's probably not the most important thing.

(Maybe I should also see if it'd be feasible to implement an equivalent of view! for CSS styles which could then make both of these non-issues. And could potentially then also integrate with the assets system to not have them be in-line styles blocks at all, hmm.)

[fredrikroos]

I think there is a case for style! and script! macros with their own escaping rules and to help editors with highlighting and formatting.

[pikaju]

@fredrikroos I agree, though I think we should wait a bit with adding this to topcoat. There are some more issues to address before that

[pikaju]

@kyrias could you give an example of what your code looks like and how it could be improved?