Closed markknol closed 5 years ago
Given that we'll have this inline XML syntax, I don't think this is necessary.
I think it still makes sense to have, for safe escaping, localisation and probably for some template engines that don't rely on xml related syntax.
Question about the inline markup syntax as proposed: Will the syntax (without macros doing stuff with it) compile to strings? The proposal says it is going to trow a Unprocessed inline markup
, is that true? Or will it sometimes return actual Xml?
In any case, sometimes it's just easier to write:
myElement.innerHTML = `<button onclick="alert('Hi!')">Press me</button>`;
.. compared to this: (below wild guess how the alternative would look with the inline markup syntax (??) ).
myElement.innerHTML = new Xml(<button onclick="alert('Hi!')">Press me</button>).toString();
Also since HTML5 isn't valid XML, if you want to write something like <video autoplay></video>
xml isnt even usable. Or will we have a special markup processor for html?
We discussed this and decided to reject this. There are already enough ways to delimit your strings, and the inline not-XML proposal is going to help with that further.
Too bad, thanks for looking into it. Hope the not-XML will help here indeed!
Support backticks
`
in Haxe, which also support String Interpolation.Rendered version