Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/htmlx-org/HTMLx
One Template to rule them all
https://github.com/htmlx-org/HTMLx
Last synced: about 2 months ago
JSON representation
One Template to rule them all
- Host: GitHub
- URL: https://github.com/htmlx-org/HTMLx
- Owner: htmlx-org
- Created: 2018-04-30T14:31:52.000Z (over 6 years ago)
- Default Branch: master
- Last Pushed: 2020-01-23T15:32:21.000Z (over 4 years ago)
- Last Synced: 2024-06-03T04:38:05.024Z (4 months ago)
- Size: 5.86 KB
- Stars: 575
- Watchers: 23
- Forks: 8
- Open Issues: 13
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- awesome - HTMLx - One Template to rule them all (Others)
README
# HTMLx
One Template to rule them all,
One Template to find them;
One Template to bring them all
and in the darkness bind() them
— [Jason Miller](https://twitter.com/_developit/status/990943081066217472)
## Background
UI frameworks built around JSX — React, Preact, Inferno, Nerv and many others — have benefited from a shared set of tools for syntax highlighting, autocomplete, linting and so on.
Other frameworks, which use a template syntax built atop HTML — Svelte, Vue, Ractive, Glimmer etc — have historically been fragmented, meaning those tools need to be reinvented many times.
This (**work-in-progress**) document proposes a common language designed to meet the needs of all those frameworks. It is smaller in scope than the [unity component specification](https://github.com/TheLarkInn/unity-component-specification), as it is only concerned with template syntax and has no opinions about behaviour.
## Motivation and goals
A shared language would allow different frameworks to collaborate on tooling. It would also reduce friction for new users, who would no longer have to learn a new syntax for each new framework.
One key advantage of 'HTML-plus' languages is that you don't actually *need* tooling in order to be productive — most editors give you out-of-the-box support for things like syntax highlighting (though imperfect, as JavaScript expressions are treated as strings) and auto-closing tags. Tools like Emmet work with no additional setup. HTMLx should retain that benefit.
## Syntax
### Tags
A lowercase tag, like `
`, denotes a regular HTML element. A capitalised tag, such as ``, indicates a *component*.
A framework might define its own special elements — these are namespaced with the framework's name. For example, Svelte provides a `` element for declaratively adding event listeners to `window`.
### Attributes
By default, attributes work exactly like their HTML counterparts:
```html
can't touch this
```
As in HTML, values may be unquoted:
```html
```
Attribute values can contain JavaScript expressions:
```html
page {p}
```
Or they can *be* JavaScript expressions:
```html
...
```
An expression might include characters that would cause syntax highlighting to fail in regular HTML, in which case quoting the value is permitted. The quotes do not affect how the value is parsed:
```html
...
```
It's often necessary to pass a property to an element or component directly, so a shorthand is permitted — these two are equivalent:
```html
...
...
```
*Spread attributes* allow many attributes or properties to be passed to an element or component at once:
```html
```
An element or component can have multiple spread attributes, interspersed with regular ones.
### Text expressions
Text can also contain JavaScript expressions:
```html
Hello {name}!
{a} + {b} = {a + b}.
```
### HTML expressions
In a text expression, characters like `<` and `>` are escaped. An expression can inject HTML with `{@html expression}`:
```html
{post.title}
{@html post.content}
```
Whether or not `post.content` is sanitized is up to the framework, rather than a concern of HTMLx.
### Control flow
Content that is conditionally rendered can be wrapped in an `{#if condition}` block, where `condition` is any valid JavaScript expression:
```html
{#if answer === 42}
what was the question?
{/if}
```
Additional conditions can be added with `{:else if condition}`, optionally ending in an `{:else}` clause:
```html
{#if porridge.temperature > 100}
too hot!
{:else if 80 > porridge.temperature}
too cold!
{:else}
just right!
{/if}
```
Iterating over lists of values can be done with an `{#each list as item}` block, where `list` is any valid JavaScript expression and `item` is a valid JavaScript identifier, or a destructuring pattern.
```html
Cats of YouTube
{#each cats as cat}
- {cat.name}
{/each}
```
An `#each` block can also specify an *index*, equivalent to the second argument in an `array.map(...)` callback:
```html
{#each items as item, i}
{i}: {item.name}
{/each}
```
It can also specify a *key expression* in parentheses — again, any valid JavaScript expression — which is typically used for list diffing when items are added or removed from the middle of the list:
```html
{#each items as item (item.id)}
{item.name}
{/each}
```
An `#each` block can also have an `{:else}` clause, which is rendered if the list is empty:
```html
{#each shoppingCart as item}
{item.name}
{:else}
Your shopping cart is empty!
{/each}
```
*TODO: Svelte also has `await` blocks — does this section need more flexibility?*
### Directives
A framework may support *directives* on elements and components for declaratively adding event listeners, transitions and so on. The general form is `type:name={value}` — the `:` character distinguishes directives from attributes.
For example, a `click` event listener could be added with an `on:click` directive:
```html
click me!
```
As with attributes, the value can be quoted, and the quotes will not affect how the directive value is parsed:
```html
```
### script/style
An HTMLx string could include `` and `<style>` tags. The contents of these tags must *not* be interpolated, but must instead be preserved as typed.
What happens to the contents of those tags is up to the framework.