5 ms·

Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's ev

by jabart 3y ago

Irony is that javascript handlers on elements were frowned upon in 90s/00s because of separate of concerns that HTML should be HTML and JS should attach it's events in a separate file. Now all of these libraries have an onclick that mirrors those original JS event handlers in the same html with no separation!

samwillis 3y ago
Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style https://github.com/samwillis/x-style
- endofreach 3y ago
  Or, tailwindcss…
  - efskap 3y ago
    Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.
  - samwillis 3y ago
    Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes. Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better. It's an experiment, seeing where it leads.
ximm 3y ago
If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives https://www.w3.org/TR/CSP2/#directives
- thrownaway561 3y ago
  I'll never understand CSP not allowing onclick handlers. Having all your javascript in a separate file makes it very hard to diagnose and understand what is causing the event on the element.
  - WorldMaker 3y ago
    onclick and other in-HTML handlers have some unsafe eval-like behavior for old compatibility reasons (with ES1 and the old web/old DOM) and I feel like the CSP designers were overly-cautious of XSS exploits via DOM manipulation that are hard to do in practice, but still in theory a major security concern. I wonder if there were a better way to opt-in to "use strict" (and maybe even ESM friendliness) in onclick handlers if that would have fewer CSP concerns. I doubt there are any current proposals to build such tools for HTML, though.

by jabart 3y ago

samwillis 3y ago

Only thing missing is inlining your css styles on each element, only a mad man would try that though... [cough]... https://github.com/samwillis/x-style https://github.com/samwillis/x-style

endofreach 3y ago
Or, tailwindcss…
- efskap 3y ago
  Did you even click the link? The "Why?" section explains the problem with tailwind and the code sample shows it's doing a different thing, closer to htmx.
- samwillis 3y ago
  Tailwind is awesome and gets so much right. However, it requires a build step using local dev tools, and it has a complete DSL that reimplements most of css as classes. Utility classes for uniform padding, spacing, border, colours etc at brilliant. But my suggestion with x-style is that placing the actual css on an element may be better. It's an experiment, seeing where it leads.

ximm 3y ago

If implemented incorrectly, these onclick handlers are a security hazard, because they prevent you from using a strict content security policy. https://www.w3.org/TR/CSP2/#directives https://www.w3.org/TR/CSP2/#directives

thrownaway561 3y ago
I'll never understand CSP not allowing onclick handlers. Having all your javascript in a separate file makes it very hard to diagnose and understand what is causing the event on the element.
- WorldMaker 3y ago
  onclick and other in-HTML handlers have some unsafe eval-like behavior for old compatibility reasons (with ES1 and the old web/old DOM) and I feel like the CSP designers were overly-cautious of XSS exploits via DOM manipulation that are hard to do in practice, but still in theory a major security concern. I wonder if there were a better way to opt-in to "use strict" (and maybe even ESM friendliness) in onclick handlers if that would have fewer CSP concerns. I doubt there are any current proposals to build such tools for HTML, though.