Add html.resolveText() and html.compareText() functions #380
Labels
scope: page generation - content
type: groundworks
Changes are foundational to further issues & code work
So, these are basically functions which try to interpret and operate on the rendered text appearance of a tag or template without actually resolving it more than necessary, and we're brainstorming them while thinking about stuff like displaying a tooltip for
[[artist:alex-rosetti|Albatross]]
, but not for[[artist:toby-fox|Toby fox's]]
or[[track:hardchorale|"Hardchorale"]]
. We'd need to interpret the custom content provided for a link, and decide whether or not to set a slot or default value (this is probably implemented as custom handling forlinkThing
's slottooltipStyle: 'auto'
).html.resolveText(content)
Fully resolve all the text contents of a tag or template join it together into a big ol' string. This should consider attributes like
[html.edgeWhitespace]
and[html.joinChildren]
for the sake of joining tags/children together, but it shouldn't ever need to actually stringify any tags outright.html.compareText(content1, content2)
Attempt to figure out if the text in the two contents look about the same. This would probably take an optional function like
compareStrings(string1, string2)
, providing a default that is either===
or that normalizing-ish comparison described above. And it would also take a flag for whether to match the whole content, or return true if there's any complete overlap (i.e. if one of the content texts fully contains the other).A super simple implementation would just mean running a comparison on the fully resolved texts of both sides, which is what we should implement as the base case. But
compareText
is also ripe for some really ridiculous (but care-requiring) optimization, which we're filing in a follow-up issue: #381.One caveat / todo for later: I'm not sure how to handle metatags here, in a general sense.
blockwrap
andsplit
won't cause any trouble because they manipulate tag hierarchy, not text content, but we could conceivably have other metatags that do operate on text. We'd ideally want to have those implemented such that#stringifyContent
andcompareText
/resolveText
reuse the same code, but it's not exactly clear how, just yet.The text was updated successfully, but these errors were encountered: