Re: [w3c/webcomponents] [templates] If HTML Template Instantiation proposal is adopted, consider a HTML-native syntax (#695)

Regarding the case sensitivity question, we ran into that hiccup while developing our prototype parser. The first implementation literally used DOM parsing to parse the new elements (as `HTMLUnknownElement`s) , so we made a design decision to require all variable names passed down in the model to be case insensitive to match HTML.

When we dropped the DOM parser approach to parsing templates (for performance reasons), we added case sensitivity as a feature, as it is common in other templating systems. Notably, even in the original pure DOM implementation, the case sensitivity only applied to variable names rather than their contents, because in practice most (all?) DOM implementations preserve case on attribute values.

Another problem with our prototype syntax is that it does violate at least one rule of HTML grammar: attributes can only be present once per element. Here's some problematic syntax we support, that HTML does not:

```html
<if blah='something' or blah='somethingElse' or blah='stillSomethingElse'>
  <p>blah is one of those three things</p>
</if>
```

The above example violates the rules of HTML by allowing the `blah` attribute to be present three times and the `or` attribute to be present twice.

My thinking though is if a HTML-inspired syntax ever got adopted as a standard, it might be prudent to make the templating tags exceptions to the case sensitivity rule and the rule requiring an attribute to appear only once per element, since the templating tags are of a fundamentally different character than just marking up data since they are programmatic in nature by offering some features of true programming languages like flow control which would be entirely new to HTML.

Granted, that same logic is sometimes used to support the argument that templating systems should *not* just be extensions of HTML, but in fact be entirely distinct languages that are easily recognizable as templating languages and not merely the marking up of data semantically. If that design principle wins the day, then I would argue that the templating systems that make the most sense are the ones that are literally just JavaScript syntax moved to the templating layer (e.g. ejs).

The main thing I fear is an entirely new syntax and grammar getting standardized on just for templating. It seems to me that both the existing languages of HTML (my preference) and JavaScript are suitable for doing HTML templating inside of `<template>` elements. It would be a shame if we standardized on a whole new language when either of those should be sufficient.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/695#issuecomment-341757905