Re: [WICG/webcomponents] Proposal: Custom attributes for all elements, enhancements for more complex use cases (Issue #1029)

@bahrus I don't want anyone to abandon the behaviors-or-similar idea. With the behaviors-as-children idea, if the parser could be changed, then my idea would be an alternative for the main issue: lack of support for the `is=""` attribute.

<details><summary>As for the JSX stuff, </summary>

Solid.js is using existing JSX syntax, it did not change any syntax (the stuff it does with curly braces is valid JSX (inside the curlies is just JavaScript)), and remains compatible with tooling like TypeScript, etc. JSX itself does not have any runtime specification, it is only a syntax specification, and frameworks like React, Solid, etc, can create any runtime output they want when they compile JSX to JS. Maybe if we want to have the best effect, we can propose something for HTML instead of JSX, and then every markup language including JSX would likely want to make space for it if possible.

Currently, the easiest way to get support with existing tools (f.e. TypeScript+JSX) is with elements, not currently with behaviors-or-similar.

</details>

I agree that behaviors-or-similar can be totally useful, especially when type checking is not in play. Is it easier to introduce behaviors-or-similar, or to update parsing? (seems like the former is)

---

Is it possible to propose new syntax for HTML?

```html
<table>
 <tr
    #my-behavior(foo="asdf" bar="blah")
    class="row"
    #other-behavior-without-attributes
  ></tr>
</table>
```

This is currently valid HTML, so not necessarily *new*, but people don't generally write attributes like that, so a subset of HTML could potentially be reserved for a new feature?

For non-parser-blocked scenarios (f.e. "foster parenting"), syntax could allow it as a child-parent association in the markup:

```html
<div>
   <p class="row">
    <!-- these behaviors apply to the <p> -->
    <#my-behavior foo="asdf" bar="blah" />
    <#other-behavior-without-attributes />
  </p>
</div>
```

In that last example, although the markup looks as though behaviors are children, the instances would not appear in `childNodes` or `children`, etc. They would only appear in `.behaviors` (or similar), in the same way that attributes don't appear in `childNodes` or `children`.

On this question on if a syntax feature like this is possible, if it is possible, then maybe we can support primitive types too (maybe similar to JSON)? For example:

```html
<p id="myPara">
  <#my-behavior foo="0" bar="'blah'" baz="true" lorem="[0, true, 'foo']" />
</p>
<script>
  const myBehavior = myPara.behaviors.myBehavior
  console.log(typeof myBehavior.foo) // "number"
  console.log(typeof myBehavior.bar) // "string"
  console.log(typeof myBehavior.baz) // "boolean"
  console.log(Array.isArray(myBehavior.lorem)) // true
</script>
```

And if we could do this, we'd probably want this ability to extend to regular elements somehow (namely custom elements):

```html
<p id="myPara" #foo="0" #bar="'blah'" #baz="true" #lorem="[0, true, 'foo']"></p>
<script>
  console.log(typeof myPara.foo) // "number"
  console.log(typeof myPara.bar) // "string"
  console.log(typeof myPara.baz) // "boolean"
  console.log(Array.isArray(myPara.lorem)) // true
</script>
```

(There'd be no lexical scope, like JSON).

The only thing missing so far would be boolean attributes (`foo=""` already covers string attributes, but not existing-or-not-existing attributes based on a boolean), and maybe another sigil would be needed:

```html
<p id="myPara" ?foo="true" ?bar="false"></p>
console.log(myPara.hasAttribute('foo')) // true
console.log(myPara.hasAttribute('bar')) // false
```

(that's based on Lit's `html` syntax).

If we could adopt `.` instead of `#` (I used `#` because I'm thinking `.` may be too risky) it would just be a lot nicer:

```html
<p id="myPara" .lorem="[0, true, 'foo']"></p>
<script>
  console.log(Array.isArray(myPara.lorem)) // true
</script>
```

If we did something like the above syntax features, then the following problem could be easily solvable in all frameworks:

- https://github.com/webcomponents/custom-elements-everywhere/issues/2352

I think a parser update could really help us _a lot_. Engines already have `JSON` for primitives. There might be space for behaviors in new syntax, and this would give a reason to languages like JSX to expand, and as a result type checking in TS would expand to support it.

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

Message ID: <WICG/webcomponents/issues/1029/2113933322@github.com>