Don't change case of tags

[rscott78]

I noticed that the parser changes everything to lower case, which is bad for me since I have some case sensitive tags.

Is there a way to prevent this?

[remarkablemark]

Can I ask for an example of this problem? Technically, shouldn't HTML tags and attributes be case-insensitive?

But regarding the question at hand, the parser is lowercasing the attributes to easier convert them to React props (see here).

If we were to keep the attribute names unchanged, we could technically keep the original attribute key instead of replacing it here.

Actually, the attributes are lowercased when the HTML string is transformed to DOM nodes. This is coming from html-dom-parser, which uses htmlparser2 under the hood (when using with Node.js).

I'm open to making these options configurable.

[thismarcoantonio]

Sorry for revive this issue, but I'm using this package and I need the tags to be camel case, because C# will parse it later (I know, it's messy, not my code and I cant change it)... I've read the htmlparser2 docs and there is lowerCaseTags option, it's enough to prevent tags from being lowercased?

[remarkablemark]

@thismarcoantonio There's a PR (#79) that might do what you need

[remarkablemark]

To give you an update @thismarcoantonio, it turns out that #79 ended up not getting merged.

Regarding your question about the tags being camelCase, are you referring to the raw HTML markup that gets passed to the parser?

[thismarcoantonio]

Yes, those tags are like: <someText: someOtherCodeHere />. I know it is strange, but in my case, I use Parser to have those tags in React and then I use renderToString from react-dom/server to get my output code, and I end up with <sometext: someothercodehere></sometext: someothercodehere>. In React chrome extension, my element is something like: createElement('sometext: someothercodehere')

[Raskatan]

Another problem related to this: Parsing a string containing onclick or viewbox attributes, those attributes are invalid in React because React uses onClick and viewBox instead, so in converting the attributes from an html string to React components they need to be transformed to camel case or they break. It would be nice if these conversions could just happen by default, but alternatively if you could provide an option for replacing attributes that would work.

[tabrez96]

@remarkablemark Any updates regarding this issue?

[tabrez96]

I'm facing a similar issue but in my case, my string to be parsed is like
Hello world <HighlightMe>Text to be highlighted</HighlightMe>
where HighlightMe is a custom component.

Basically, I need help in parsing the string which has custom components.

[frank-dspeed]

i Am working on that issue i am coding at present a clean fork of htmlparser2 and parse5 joing both algorythms you will then be able to use parse5's react dom adapter that will be based on this code base

[remarkablemark]

In html-react-parser v0.12.0, you can pass htmlparser2 options when parsing on the server-side (Node.js):

$ node
> const parse = require('html-react-parser');
> parse('<FooBar>baz</FooBar>', { htmlparser2: { lowerCaseTags: false } });
{
  '$$typeof': Symbol(react.element),
  type: 'FooBar',
  key: null,
  ref: null,
  props: { children: 'baz' },
  _owner: null,
  _store: {}
}

See README.md, Repl.it demo, or pull request #161 for more information.

[remarkablemark]

I also updated the README FAQ

[BaniGrisson]

I'm having this same problem. But I need it client-side. Any news on it?

[remarkablemark]

@BaniGrisson Unfortunately there is no update on adding the support in html-dom-parser.

[linonetwo]

Is it possible to use a React component with this lib?

[remarkablemark]

@linonetwo do you mean the input being JSX instead of HTML? If so, this library doesn't support that. There should be other libraries that can do that

[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.

[Yankovsky]

Also, maybe this will help to eliminate the confusion around options that work only in NodeJS environment, but not in the browser.

[Yankovsky]

Copied the comments to a more recent thread.