attributesToProps converts case to lower case

[h0jeZvgoxFepBQ2C]

It seems that the attributesToProps method is converting all keys to lowercase (see https://github.com/remarkablemark/html-react-parser/blob/master/lib/attributes-to-props.js#L37 ).

Why is this happening?
We would like to pass case-sensitive attributes to our dynamic html content and with the current implementation it doesn't work, since all attributes are converted to lower case?

[remarkablemark]

Thanks for the question @h0jeZvgoxFepBQ2C, attributesToProps converts all keys to lowercase because the DOM/SVG attributes get remapped to React props (e.g., class to className).

On the browser, the attributes technically don't care about case-sensitivity. Is there a particular reason why you need case-sensitive attributes?

There are htmlparser2 options, but they only work on Node.js (server-side) and do not work in the browser (client-side).

[h0jeZvgoxFepBQ2C]

Thanks for the follow up @remarkablemark

Actually we would like to pass react specific arguments to our html, so we can use these attributes directly.. F.e. imagine a div should be replaced with a countdown element with the argument endsAt:

<div role="countdown" endsAt="2021-10-10 01:01:01+0200"/>

should be converted to

<Countdown endsAt="2021-10-10 01:01:01+0200"/>

So if the arguments are always downcased, I cannot use them for the react components?
Also we cannot map the arguments, since we provide the arguments dynamically (yeah, this is a security concern, but we are in a trusted environment, so this is not an issue for us)

[h0jeZvgoxFepBQ2C]

@remarkablemark Any thoughts on this? Your library would offer much more possibilities if it doesn't convert all keys to downcase. And as you said, browsers don't care about case sensitivity, so it wouldn't make a difference?

Right now there is only this downside, that we can't use it to pass props directly to other React components?

[remarkablemark]

@h0jeZvgoxFepBQ2C If you're using the library only on the server-side (Node.js), then you can override the htmlparser2 options. You can find a list of the parser options here.

[h0jeZvgoxFepBQ2C]

I know, but we are clientside rendering

[Heilemann]

Adding my vote to this. If possible it would be nice with an option to enable the client side version to work the same as the server side version. Some use cases, like mine, don't need to care about e.g. XSS issues.

[h0jeZvgoxFepBQ2C]

@remarkablemark would you accept a PR for this, to make the option also available for the client side?

[remarkablemark]

@h0jeZvgoxFepBQ2C I feel the approach will add more complexity to html-dom-parser.

If you really want to achieve this, one approach is to override Webpack to ensure htmlparser2 is imported in html-dom-parser. The downside is your bundle size will increase a lot.

[T-Fletcher]

I second this issue, case conversion is a pain as you can't export a string as React components - I thought this would be a key use case but maybe not.

[Yankovsky]

@remarkablemark You can use new DOMParser().parseFromString(html, 'text/xml'), which preserves the casing. Considering the numerous issues related to casing in this and other repositories, and since it's something that can be supported, I think it's worth a try.
Also, maybe this will help to eliminate the confusion around lowerCaseAttributeNames and lowerCaseTags options that work only in NodeJS environment, but not in the browser.

[remarkablemark]

@Yankovsky Thanks for the suggestion. I'm just concerned that this may not be backwards compatible and could cause a breaking change for existing users.

Currently, html-dom-parser falls back to new DOMParser().parseFromString(html, 'text/html'): https://github.com/remarkablemark/html-dom-parser/blob/v5.0.8/src/client/domparser.ts#L37

[Yankovsky]

Yeah, I checked the code already. It won't be as easy as just changing the mime type to text/xml, but it should be possible. Do you have some tests that we can run the xml parser against?