Thoughts on HTMLish Language Support

[MichaReiser]

The HTMLish languages include HTML and HTML-based template languages like: Vue templates, Angular templates, Grale templates, etc.

The goal of this discussion is to share design constraints and ideas.

Objective

Enable code reuse for lints and formatting for the different HTML languages. For example, implement the logic for accessibility lints once and use it for all HTMLish languages.

The objective is not to optimize binary size but enable code reuse.

Design considerations

HTMLish languages are not additive

What I mean by additive is that a language dialect like TypeScript or JSX adds additional syntax to a language:

• If you use TypeScript syntax in a JavaScript file, it becomes TypeScript.
• If you use JSX syntax, it becomes a JSX file
• If you use JSX and TypeScript, it becomes a TSX file

The same applies to JSON, JSON5, and JSON6: Using any JSON6-only syntax makes your whole file a JSON6 file.

That's because the "extension" dialects are supersets of the language they extend:

• JavaScript ⊆ TypeScript
• JavaScript ⊆ JSX, TypeScript ⊆ TSX, JSX ⊆ TSX (with a very few exceptions)
• JSON ⊆ JSON5 ⊆ JSON6

While it's true that you get an Angular template if you use any angular syntax in HTML, it doesn't work if you start mixing template dialects: What format does a file use if you use an Angular expression inside a Vue template? Vular, Angulue?

We'll run into the same problem with JavaScript if we add support for another JavaScript dialect, e.g., Flow. You could even argue that it's a situation we have today with SvelteJs, except that SvelteJs doesn't extend the JavaScript syntax but changes the language semantics.

Naming

HTML element and attribute names are not case insensitive but are case sensitive in Angular (at least when using TypeScript), JSX, and VueJS templates --- and potentially others.

Furthermore, some template languages support multiple syntaxes to assign an attribute value:

• attribute syntax <a href="./link">body<a>
• binding syntax: Vue.js <a v-bind:href="link">body</a>

That means it is necessary for some languages to check for static attributes and bindings when testing if an attribute is set.

JSX

JSX is defined as part of the JavaScript language but otherwise fits the bill of an HTML template language. Meaning reusing code for HTMLish lints rule for JSX is desired but doing so ultimately means that either:

• JSX must be extracted from JavaScript into the HTMLish language (unclear how this would work considering the tight coupling to the JS parser)
• The solution we seek must work across different syntax languages

Design Ideas

Single HTMLish language

Create a unified HTMLish grammar that unifies all different HTMLish dialects.

AnyHtmlishAttribute = VueBinding| AngualarBinding | HtmlAttribute | ... 

This does not mean that all dialects use the same parser. Language could either share the parser implementation, or each comes with its own.

This approach does not allow for code reuse between JSX and HTMLish

Unified HTMLish syntax

The idea is to have language-specific grammars with a unifying language on top.

AnyHtmlishRoot = AngularRoot | VueRoot | HtmlRoot | ... 
AnyHtmlishAttribute = AnyAngularAttribute | AnyVueAttribute | ...

This approach is very compelling at first but has two shortcomings

• The union nodes cannot implement AstNode because it's unclear what to use for the L: Language type parameter (the nodes are from many different languages)
• Much of our infrastructure is typed over L: Language.

HTMLish traits

Each HTMLish language has its own grammar and traits abstract the common operations used by the linter that allow iterating elements, finding attributes, testing attribute values, etc. Lints would then either be generic over the HTMLish trait implementation or a trait with methods to perform some language-specific operations.

This trait system may be supplemented by an HTMLish semantic model that allows fast queries for specific elements/attributes.

It's not entirely clear to me how this would work on the formatting side, but I could envision that the formatting of an Element is a trait that can then be implemented by language-specific formatters.