Joe Pea
Joe Pea
> would produce what you're seeing, because that is precisely what lit-html does – setting the string as innerHTML to a template element. That's not something people are actually doing...
> the only use for this would be for setting values of type `string`. We can't assume or deduce any other type for the value. Lit Element could just run...
Another way to think about it is that we shouldn't give CSS authors a solution to this problem only _**in JavaScript**_, but also _**in CSS**_.
@romainmenke I saw you downvoted. What do you disagree with? What are better alternatives?
I found a workaround: The config in the OP did not work. Additionally this did not work, causing build errors in the presence of type-only `declare` fields elsewhere in the...
Note, the PR template states to link to an issue that is in the Backlog (I can't do that).
A workaround for mobile is to simply fallback to a simpler mobile-friendly editor on mobile, and use Monaco only on desktops. See https://github.com/microsoft/monaco-editor/issues/246#issuecomment-805418018 for more ideas on how.
Actually I just tested, and autocompletion will work as long as the app already imports the default `html` somewhere first. So this change is not needed for that. This does...
Yay! Nice you got something going on this @mrginglymus!
Manual test results have been added for Lit, Lume, Solid.js, Pota, Vue, Svelte, React, with more on the way.