HTML Templating requires unquoted attributes

HTML supports unquoted attributes, we use a template language that uses unquoted attributes for templating and requires template attributes to NOT have templates. It would be ideal to support an option to not surround attributes with quotes.

Alternatively, having a “sub” HTML syntax like is done with Vue would work as well. We’d prefer to avoid forking the entire HTML plugin just to change this single format if possible.

Prettier 1.15.3 Playground link

--parser html

Input:

<div>
  <p id={VALUE}>Hello</p>
</div>

Output:

<div><p id="{VALUE}">Hello</p></div>

Expected behavior: The attribute should not be surrounded by quotes.

<div><p id={VALUE}>Hello</p></div>

[ikatyang]

@diervo I know it’s a bit confusing but what I meant --parser here is actually a printer since we do not have --printer at this point so we simply use --parser as a hint for printers to output something different from the default one, the parser we actually used should be same as the one used by HTML. (The sub-language parsing is happened in the printer.)

Regarding plugins, our current architecture does not support injecting some printer logics to other plugin, so I suggested to put it in the HTML plugin for now (https://github.com/prettier/prettier/issues/5627#issuecomment-451657206), and I hope we could address this issue in v2 so that you can easily write a plugin for it without forking the entire repo.

[diervo]

@ikatyang For the record, the grammar we use in LightningWebComponents is a subset of HTML, and we very purposely did that to be compliant with all parsers.

I’m a little bit concerned or unhappy that you guys want us to do a plugin rather that making it part of the default parser since by design we really tried to avoid going that route and have to do forks on things.

I worked on that part of the spec defining parser errors and doing some disambiguation. If you look at the syntax specification: https://www.w3.org/TR/2017/WD-html52-20170228/syntax.html#attribute-value-unquoted-state As long as you don’t use spaces or any quote or unicode that produce a parse error, it is valid HTML, and all the browsers actually honor this and do the correct parsing according to the spec.

We are fine if we have to do the plugin, but I would love for you guys to reconsider given that we are fundamentally spec compliant.