Web-component properties casing are treated like ordinary element attributes

[pedro00dk]

Describe the bug

I'm not sure if this is expected behavior...

I have a web-component that accepts a camelCase property. When consuming the web-component and setting its prop, the generated code lowercases the property.

What I understand is that web-components have different code generation than ordinary elements. By default, the attributes are passed as properties if no directives are provided. However, I think the property names are being lowercased as if they were ordinary element attributes.

The behavior is also a bit weird with constant props, as they are optimized as attributes in the template string, even though they are being passed to a web-component.

I found out I can pass the property as kebab-case and the output will be transformed to camelCase, but that messes up the component types.

Your Example Website or App

https://playground.solidjs.com/anonymous/1003943b-a363-4e73-b3af-6b1c1e8fdd15

Steps to Reproduce the Bug or Issue

1. Open playground link.
2. Check output tab (client side mode)

This code does not really run anything, the point to see the output code.

Expected behavior

I expected that when declaring a web-component in JSX, the properties without directives (regardless if they are constants or expression) would be passed down to the web-component element as if they were properties, not attributes, and that the prop casing would be preserved.

Screenshots or Videos

No response

Platform

• OS: Linux
• Browser:Chrome
• Version: 114

Additional context

No response

[ryansolid]

Where we landed here was the result of conversations with the community around how to handle this and ultimately came to a place that I'm not sure is the best in hindsight but that we would handle things as as properties but that we would convert dash case to camelCase. Interestingly we using to do straight pass through but I think it caused inconsistencies when output as HTML.

The problem is HTML isn't case sensitive so the choice of passing properties without a prefix is awkward in general. I'm gathering that is why Lit defaults to attributes even if it is sort of not the best default. That being said I'm also not sure how useful the HTML compat is because you'd have to serialize the value to a string in that case anyway and without manual intervention I'm not sure you are going to get what you want.

So sort of awkward place always forcing the prop: prefix. I suppose we could inspect the value or looks at the component prototype and make a decision but that is also a bit inconsistent. I'm open to revisiting this for sure but what you have witnessed is "by design" currently.

I'm going to move this to discussions. I think this is a worthwhile topic.