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
If you add a non-String attribute to any node and ask dom-serializer to parse it, it will treat the attribute value as a string and quickly throw an error.
Here is a condensed example: https://runkit.com/atjn/64073ea61e340b000802a5cd
In my case, I am trying to add a width and height to an SVG node. I know that these values are technically speaking strings, but they are supposed to be parsed as numbers, so I think it makes sense that I can set them to a Number without breaking the parser. This is also how the normal DOM APIs work in JS.
Therefore I would suggest adding a quick conversion to string before encoding the attributes.
If you don't think the parser should support non-string values, then I would suggest adding a check that throws a more concise error. The current one is very hard to decipher:
file:///[...]/node_modules/entities/lib/esm/escape.js:46
return ret + str.substr(lastIdx);
^
TypeError: str.substr is not a function
at encodeXML (file:///[...]/node_modules/entities/lib/esm/escape.js:46:22)
The text was updated successfully, but these errors were encountered:
Hello and thank you for making these tools :)
If you add a non-String attribute to any node and ask
dom-serializer
to parse it, it will treat the attribute value as a string and quickly throw an error.Here is a condensed example: https://runkit.com/atjn/64073ea61e340b000802a5cd
In my case, I am trying to add a
width
andheight
to an SVG node. I know that these values are technically speaking strings, but they are supposed to be parsed as numbers, so I think it makes sense that I can set them to a Number without breaking the parser. This is also how the normal DOM APIs work in JS.Therefore I would suggest adding a quick conversion to string before encoding the attributes.
If you don't think the parser should support non-string values, then I would suggest adding a check that throws a more concise error. The current one is very hard to decipher:
The text was updated successfully, but these errors were encountered: