Add support for interpolated attribute values in HTML / HTML-like template tags without quotation marks
bensmithett opened this issue · 7 comments
👋 thanks for the excellent package!
Is it possible to support htm syntax?
Expected:
Current (html syntax)
It's almost there, but not sure if there's much you can do about this - is it just delegating to sublime's HTML syntax?
Current (js syntax)
It's supported in VSCode via the lit-html extension, so is there potential to similarly support both here?
Thanks 🙂
For most template tag language modes, yes, we just delegate to existing definitions. But iirc, HTML may be one of the exceptional cases where we’re baking in a customized version, so this may be addressable.
The problem you’re running into appears to specifically be about attribute quotation marks. When we get past the interpolated segment, we’re still expecting opening quotation marks for an HTML attribute. The nature of the problem can be seen more clearly if we add quotation marks after — it resumes correctly, then:
A bit tangential, but maybe interesting: You mentioned that the lit-html extension for VSCode handles their absence okay. That surprised me slightly since lit-html discourages omitting the quotation marks, normally included because lit-html templates get parsed as real HTML by the browser. It’s a bit of a footgun in that context to omit them (it’s often fine, but may lead to avoidable surprises), so I haven’t noticed the issue myself as a lit-html user:
I will take a look at whether we’re baking in our own HTML def here or not and see if this is fixable from there.
I missed the second item in your screenshot on the first read, the use of interpolated segments in place of tag names. That’s a bit trickier since the assumption we need to make is weaker. That is, attr=${} is a strong signal because we know the sequence must begin with an attribute value (even if it’s the empty string), and we couldn’t possibly be expected to recover if someone did things like attr=${"'foo'>"} or attr="${ 'foo"' }. In contrast, <${x} is a fairly good indicator of a tag start, but there are many other possible continuations there in HTML, some of which even leave the < as chardata. I’ll look into it though.
@bensmithett It turned out solving for both cases was possible without the kind of ‘correctness’ concessions I thought would be necessary. I’m gonna wait for a sign off on the PR from Blake since he knows the tagged template stuff much better than I do, but I think it’s likely gonna work.
BTW, for html you can omit the /* syntax: html */ now if the name of the tag is html.
@bathos amazing, thanks!
it is possible - i can do some black magic and have the embedded HTML syntax explicitly allow interpolated elements to act as unquoted attribute values. This opens up pandora's box a tiny bit since we would also want to consider all embedded contexts that should recover from interpolated elements, but i definitely see the value in making this work for markup languages. We wouldn't try to recover from the situations @bathos describes but we can at least cover all the cases you would want to interpolate a word, tag attribute or value.
Update just saw the two prev posts and the PR. Will check it out now.
Fixed in v2.1.2. Interpolation now supports tag names, attribute names, attribute values, and text node values.