custom element attributes are returned as children rather than properties

[hesxenon]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

8

Link to runnable example

https://jsbin.com/mivorid/2/edit?html,console

Steps to reproduce

simply calling h("my-custom-element", {type: "date", value: ""}, []) yields unexpected results.

Expected behavior

It should yield

{
    "type": "element",
    "tagName": "my-custom-element",
    "properties": {
        "type": "date",
        "value": ""
    },
    "children": []
}

Actual behavior

It does yield

{
    "type": "element",
    "tagName": "my-custom-element",
    "properties": {},
    "children": [
        {
            "type": "date",
            "value": ""
        }
    ]
}

Affected runtime and version

bun@1.0.21/chrome@120.0.6099.199

Affected package manager and version

No response

Affected OS and version

No response

Build and bundle tools

No response

[hesxenon]

well, it seems like a rather big issue... this function here seems to be used to differentiate between estree nodes and properties and since both estree nodes and properties may have a type and value property the function incorrectly returns false. An exception for <input> is in place, but that won't help with custom elements.

Is branding a possibility?

[wooorm]

Exception for dash in tag name might be viable?

Can custom elements be used in SVG?
I believe there are some known SVG elements prohibited from custom element names, which do have a dash

[hesxenon]

Hmmm, what do you mean by "can be used in SVG"? There are no custom svg elements (yet?) (see here point 6.4).

But I would expect them to work as a foreign object, embedded in a svg structure.

Then again there's a way to check for registered custom elements but all in all I think all this just makes the issue more and more complex.

If I understood the code correctly (and mind you, I spent all of 5 minutes skimming over it) changing this line to something like return Object.assign(node, {__h: hastscriptSymbol}) where hastscriptSymbol is a Symbol("hastscript") would simplify these checks greatly.

[wooorm]

can be used in SVG"

This project can be used to generate SVG, with s.

HTML has exceptions for custom element names that overlap with SVG: https://html.spec.whatwg.org/multipage/custom-elements.html#valid-custom-element-name.

see here point 6.4)

I think you meant to link to a spec, but linked to the code here? What is point 6.4 in this code?

there's a way to check for registered custom elements

This code can run on servers. Or ahead of time. So it should work regardless of what is registered.

changing this line to something

hast is a plain vanilla json format; so no symbols.
even if we did that, that would not work with other nodes: people can pass comments and doctypes in.
and even if we checked for that, people should be able to define custom nodes.

---

The definition of “node” here is basically any object with a type field set to a string.
And properties is basically any object with mostly primitive values.
Hence the overlap here.

[hesxenon]

spec

🙈 I'm so sorry, fixed it. Meant to link to the DOM spec.

registered elements

Yeah, hit me 5 min after I wrote it as well...

has is plain JSON

I see, that complicates things...

even if we checked for that people should be able to define custom nodes

Well, they're not able to define custom nodes right now, are they? I get your point, but HTML also disallows certain element names etc... maybe an attribute with spaces in it? Would be json compatible but not feasible as an attribute on a custom element I think?

[wooorm]

Well, they're not able to define custom nodes right now, are they?

One popular example in the wild is MDX, which embeds ESM, JSX, and expressions inside HTML.
But for this project also comments and doctypes are essentially “untreated”.

h('div', {type: 'comment', value: 'x'}) is a simple example

maybe an attribute with spaces in it? Would be json compatible but not feasible as an attribute on a custom element I think?

Can you clarify what you mean?

[wooorm]

Seems to be possible to put arbitrary dash-cased named in the SVG namespace:

> document.body.innerHTML = '<svg><x-y></x-y></svg>'
< "<svg><x-y></x-y></svg>"
> document.body.firstElementChild.namespaceURI
< "http://www.w3.org/2000/svg"
> document.body.firstElementChild.firstElementChild.namespaceURI
< "http://www.w3.org/2000/svg"

[hesxenon]

mdx example

I'm not sure I follow completely, but that example you gave also leads to a node with children instead of properties?

clarification

I was thinking that since Symbol cannot be used we'd just have to find another property that is "unique" to hastscript. And since property names with spaces in them are valid json but are not valid html attributes that could be a solution. I.e. return Object.assign(node, {"hast script": 0}).

Though if you want JSON serializability you'd probably want the tree to be as small as possible, so... also not ideal.

[hesxenon]

dash cased names in the svg namespace

true, but those would never be valid html elements? Is the problem here that, when parsing a node like {tagName: "x-y"}, you could not differentiate between properties and children again? At least not based on the dash in the tag name?

Hmmm, this kinda reminds me of all those discussions around JS types, variadic arguments and "aot" knowledge about arguments^^

Isn't the problem originally caused by wanting to offer an "overload" signature of h(selector, ...children)? Even though it would be a breaking change, requiring attributes would definitely fix it, no?

[wooorm]

I'm not sure I follow completely

h('div', {type: 'msxJsxTextExpression', value: 'props.something'}) is an expression inside a div, equivalent to <div>{props.something}</div> in JSX.

but that example you gave also leads to a node with children instead of properties?

Which is inverse from what you are asking about. You want props instead of a node.
It’s always possible manually to choose “props” to be seen as a “node”, by doing h('div', undefined, whatLooksLikePropsOtherwiseButIsANode).
But it’s not possible to do the inverse: what looks like a node to be passed as props. Yet!

And since property names with spaces in them are valid json but are not valid html attributes that could be a solution

Ahh. Yes, we can allow another field. h('div', {type: 'whatever', isProps: true}). And not actually put it on the resulting properties!
However, at that point, you do not need to use h or pass that prop through: const div = h('div'); div.properties.type = 'whatever' is fine! So is {type: 'element', tagName: 'div', properties: {type: 'whatever'}, children: []}.

but those would never be valid html elements?

The concern of hast is more with what DOMs could be generated by an HTML parser; not with what will eventually work at runtime. Folks could have such HTML files and hast needs to represent it.

Isn't the problem originally caused by wanting to offer an "overload" signature of h(selector, ...children)? Even though it would be a breaking change, requiring attributes would definitely fix it, no?

Yep!

hast must be able to represent it all. hastscript, this project, is a convenience around generating elements.

In regular HTML, type is used for buttons (with specific allowed values), and input, with an arbitrary string value. Hence the exceptions in the code for those.
I was initially thinking of whether we could indeed require props for all dash-cased tag names, as they are likely to be custom.

[hesxenon]

inverse, "you want props instead of a node"

Ah, I see. I didn't realize that hast nodes could also be used like that (even though I did just that a few years ago^^)

no need to use h or pass that prop through

true, I think I'm going to use that in my lib. For my case that solves the issue, thanks :)

Now, for this "doing the inverse"... I'm thinking that if arguments.length > 2, then the second argument would always have to be the properties, no? That way consumers could more easily work around the problem by explicitly calling h(selector, undefined, ...children)? Ofc. it still doesn't eliminate the problem for h(selector, nodeOrMaybePropsDunno)...

[wooorm]

true, I think I'm going to use that in my lib.

What are you doing? The props handling other than the type field here might be needed. As you can see in the code, there’s a lot going on.

Without the props handling and the overload, this project is useless, as you can make elements directly: {type: 'element', tagName: 'c-ustom', properties: {type: 'whatever'}, children: [...]}

then the second argument would always have to be the properties, no

No, you can pass children: h('div', {type: 'text', value: 'asd'}, {type: 'comment', value: 'qwe'}, h('em', 'zxc'))