-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add buildHTMLTree #1022
Add buildHTMLTree #1022
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no problem with changing the export names. Hopefully no one has used in the few days it's been available. Would we still consider a breaking change?
): domTree.span { | ||
const options = optionsFromSettings(settings); | ||
const htmlNode = buildHTML(tree, options); | ||
const katexNode = buildCommon.makeSpan(["katex"], [htmlNode]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the katexNode necessary here? Why not just return htmlNode
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, good question. htmlNode
would be natural too. My reasoning here was that there are various CSS rules that only apply with the .katex-display .katex
nesting...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah okay.
@rrandallcainc I think because we haven't released a version with this change (right?) it's probably OK, though obviously not ideal. |
Yup, agreed that this should not be an issue. Forgot it hasn't been released. |
@edemaine These changes look fine to me. What were you thinking for the new naming convention? |
How about the following?
Hmm, maybe we should have |
Using the existing "render" nomenclature sounds good. I agree that consistency would be nice here. |
OK, I did the renames. I also added some clarifying documentation so it's clear what the different functions provide. It occurs to me that a "no MathML" option would still be neat in that it would allow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. The comments around the exports are a nice addition.
🎉 |
@rrandallcainc Thanks for the quick review! |
This is a followup to #1017 (Exposing the build tree). It includes a new
generateBuildHTMLTree
function that skips the MathML step, and exposes that function as__getBuildHTMLTree
. See #800 for discussion.I'd like to have a discussion about the naming of these functions. I find the naming of these functions, and the
generateBuildTree
and__getBuildTree
that come from #1017, to be "incorrect". I don't think these were ever supposed to be called "build trees". "Build" inbuildTree
was meant as a verb, as in "build a tree". I think it would make more sense to renamebuildTree
todomTree
or something. Alternatively, we could renamegenerateBuildTree
toparseAndBuildTree
or something like this, which is what it's doing. I also am not a fan of theget
in__get
. If there's consensus, I can rename in this PR.