Skip to content
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 html.resolveText() and html.compareText() functions #380

Open
towerofnix opened this issue Jan 15, 2024 · 0 comments
Open

Add html.resolveText() and html.compareText() functions #380

towerofnix opened this issue Jan 15, 2024 · 0 comments
Labels
scope: page generation - content type: groundworks Changes are foundational to further issues & code work

Comments

@towerofnix
Copy link
Member

towerofnix commented Jan 15, 2024

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 for linkThing's slot tooltipStyle: '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 and split 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 and compareText/resolveText reuse the same code, but it's not exactly clear how, just yet.

@towerofnix towerofnix added scope: page generation - content type: groundworks Changes are foundational to further issues & code work labels Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: page generation - content type: groundworks Changes are foundational to further issues & code work
Projects
None yet
Development

No branches or pull requests

1 participant