You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
attributesToProps converts case to lower case #263
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?
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).
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:
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)
Reacted by Fayçal Hammoudi, Paulo Soares, h0jeZvgoxFepBQ2C, Kenrick Everett and Brian Ressler
@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?
Reacted by Michael Heilemann, Tim and Brian Ressler
@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.
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 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.
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.
@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.
@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.
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?
I definitely agree with this. I had issues when I was trying to parse an html string from a source string in a json file and it kept transforming my props incorrectly into lowercase. Most props use camel case so I am not sure why this wasn't anticipated. At the time, I thought well no problem I'll pass options from the documentation into it, and that doesn't work because html2parser is server side only and my application is static. Unfortunately, these limitations render this package useless for many common use cases. I realize the devs of this package aren't at fault here because there are reasons for these limitations. But sadly, I will have to find something else or come up with something hacky.
Activity
remarkablemark commentedon Aug 11, 2021
Thanks for the question @h0jeZvgoxFepBQ2C,
attributesToPropsconverts all keys to lowercase because the DOM/SVG attributes get remapped to React props (e.g.,classtoclassName).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 commentedon Aug 11, 2021
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:should be converted to
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 commentedon Jan 25, 2022
@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 commentedon Feb 5, 2022
@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 commentedon Feb 5, 2022
I know, but we are clientside rendering
Heilemann commentedon May 5, 2022
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 commentedon May 5, 2022
@remarkablemark would you accept a PR for this, to make the option also available for the client side?
remarkablemark commentedon May 6, 2022
@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
htmlparser2is imported inhtml-dom-parser. The downside is your bundle size will increase a lot.T-Fletcher commentedon Feb 13, 2023
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 commentedon Apr 24, 2024
@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
lowerCaseAttributeNamesandlowerCaseTagsoptions that work only in NodeJS environment, but not in the browser.remarkablemark commentedon Apr 24, 2024
@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-parserfalls back tonew DOMParser().parseFromString(html, 'text/html'): https://github.com/remarkablemark/html-dom-parser/blob/v5.0.8/src/client/domparser.ts#L37Yankovsky commentedon Apr 24, 2024
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?bressler95tops commentedon May 29, 2024
I definitely agree with this. I had issues when I was trying to parse an html string from a source string in a json file and it kept transforming my props incorrectly into lowercase. Most props use camel case so I am not sure why this wasn't anticipated. At the time, I thought well no problem I'll pass options from the documentation into it, and that doesn't work because html2parser is server side only and my application is static. Unfortunately, these limitations render this package useless for many common use cases. I realize the devs of this package aren't at fault here because there are reasons for these limitations. But sadly, I will have to find something else or come up with something hacky.