feat: support equals signs in \htmlData attributes#4109
feat: support equals signs in \htmlData attributes#4109AljoschaMeyer wants to merge 4 commits intoKaTeX:mainfrom AljoschaMeyer:main
Conversation
See #4108 for discussion of this change, and https://stackoverflow.com/a/4607799 for the implementation technique.
src/functions/html.js
Outdated
| const keyVal = data[i].split("="); | ||
| if (keyVal.length !== 2) { | ||
| const keyVal = data[i].split(/=(.*)/s); | ||
| if (keyVal.length !== 3) { |
There was a problem hiding this comment.
This seems like a weird use of split to me, though it does appear to work, provided there's no newline in the value (. doesn't match newline). Perhaps it would make more sense to do a regular expression match? Something like const match = data[i].match(/^([^=]+)=([^]*)$/). This also makes it easy to correctly reject an empty key.
There was a problem hiding this comment.
I had assumed an empty key should be allowed, since data attributes are allowed to be empty. Do you prefer a different syntax for setting empty data attributes?
Newlines are matched already of the /s modifier.
As for using split like this, that was simply the first result of a web search for splitting a string into two parts in js: https://stackoverflow.com/questions/4607745/split-string-only-on-first-instance-of-specified-character/4607799#4607799
I'll wait for your response and then implement whichever variant you prefer =)
There was a problem hiding this comment.
Thanks, TIL /s option!
I guess while we're debating the best form, the indexOf plus two slices would actually be much more efficient (as discussed on that StackOverflow page), so maybe we should go for that. Allowing an empty key (so data- attribute) is fine I guess; seems we currently allow it, so probably better to still allow it.
Now handles inputs with zero equals signs. And I deleted the prior logic...
|
Apologies, I'm doing things with git that are not very clever... Will open a new PR from a clean branch with the commits squashed. |
What is the previous behavior before this PR?
\htmlData{foo=<value>}{}results in a parse error if<value>contains equals signs.What is the new behavior after this PR?
All equals signs but the first (which marks where the attribute name ends and the value starts) are ignored. Values can contain equals signs now.
Closes #4108
Did this in the Github WebUI, I'm unable to run the yarn tests locally =/