OnClick / Style ... Forced erroring

[Perusae]

OnClick / Style ... Forced erroring

[a-h]

I think you may have written this while being frustrated, since it's not particularly constructive. If you have a team of developers using templ, perhaps you could have put together a more detailed proposal of how to improve script and CSS handling?

Go's built-in html/template forces you to use the type template.JS to identify safe JavaScript strings. If you use a standard string for a JS attribute, you don't get a compile error, you get a silent failure at runtime. Copy the output of this program into a HTML file, and you'll see what I'm talking about: https://go.dev/play/p/G_ts4C2g7nl

One of the goals of templ is to bring errors up early. Compile time errors are better than runtime errors, and are a lot better than silently not doing what you might reasonably expect.

Putting that aside, I think that what you're asking for is a way to bypass the XSS protection for script and style attributes, in much the same way as there's a SafeURL type that lets developers bypass URL sanitization for URLs in templ.

So, something like this would work:

templ Button(onclick templ.JS, style templ.Style, title string, text string) {
  <button class="button" type="button" onclick={ onclick } style={ style } title={ title }>{ text }</button>
}

For scripts, the generator would need to be updated so that the generated code supports the use of both templ.ComponentScript and templ.JS, and a new templ.JS string type added.

For style attributes, a similar update could be done to generate custom code that expects a templ.Style type, or else, it sanitizes the CSS.

I think this is very do-able.

[Perusae]

Let me put it in simple terms...

Right now, your making another class to fix a issue what needs to be a very basic compile time flag.

templ generate --nostylecheck --nojschecks ...

The manual right now is already loaded with too much custom behavior in dealing with CSS/... what is linked a lot to to bypass checks.

I understand that you prefer to have a strict amount of checking, but we have been writing way more methods to bypass Templ restrictions then we like. O, and that compile change a while back where you altered all the generated variable names was SO MUCH FUN, as it broke a lot of code that relied on injection to do bypasses.

When we see more and more features like proxy, live compiling etc... Great but again your add features that are done easily by existing tooling, where there are 100's of live compile / file watch programs. So instead of just adding a section to the manual, your doing the typical recreate existing features.

A stupid example of why people need to stick to the basics: A few weeks ago, we got fed up with a HTTP Client that we used, because it kept encoding images into base64, so if you pulled data, it created a base64 encode, base64 decode... You can imagine the fun when your handling 1000's of images.

Why did this exist even? Because the author kept adding features to his client, that he considered useful like json decoding directly as a output and that created issues as he coded it in such a way, that he was unable to simply export the body reader.

We ended up forking it and stripping out all that json, and other unneeded code, returned it to a bare client, and directly feed into io.copy, and the difference in performance (and memory utilization) was amazing. If we needed json? Wel, just take the reader and directly feed it into our json module. Less was better! But now the developer was on the hook for maintaining the whole json part, and so much other features. Instead of focusing on the core ... And we need to deal with a fork, so if a change happens to the base functionality, well, now we are forced to check again and again. Everybody loses in the end.

Right now, Templ is starting to tinker on this line, of trying to add more and more features that do not belong into it, or that are designed around a specific philosophy. Great to see JS, or CSS templ included but you know what is even better? Just a basic JS or CSS file in your html header, that only needs to be rendered one time. I know, old fashion design. Bonus, it has no issues unlike templ generated css/js because those CSS/JS never get evaluated if we send html snippets from server to client (for darn good reasons of security!).

So excuse my ranting. But i deal with the team members when they get into roadblocks (as it was my choice originally to use templ). Right now, we moving away from templ and are in the process of writing our own template generator, that is heavily inspired by templ but that just does the basics. And if we need more, like live reloading, ... Trust me when i say this: KISS ... stick to it, make some of those feature external or simply document them as such but we are seeing Templ go in a direction for a while, that is going to put so much stress on you as a developer to keep maintain it, and then like so many project it gets abandoned when you burn out.

Anyway, i am closing this issue... We are already moving to our own solution. I thanks you for reading this rant and i hope a bit of self reflection is in order. And my advice: Do not add every feature that people want / ask / cry about, do not make a project around your own development platform, ... Your just going to frustrate more people over time. Been way too darn long in this business to know how most projects end up, especially with one or small teams.

Good luck to you sir...

[iloveicedgreentea]

I am also running into this issue... I am using daisyui with a modal and need to simply write the following string

modal-%s.showModal()", entity.ID but I cannot do this

cannot use fmt.Sprintf("modal-%s.showModal()", entity.ID) (value of type string) as templ.ComponentScript value in variable declaration

Edit: I figured it out

script openModal(modal string) {
	document.getElementById('modal_' + modal).showModal();
}

script closeModal(modal string) {
	document.getElementById('modal_' + modal).close();
}

Pass these into onclick. It makes sense after the fact, but figuring this out was not obvious to me personally. Not that difficult to do but it could have been explained better in the docs