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

Additional Names field and box! #332

Merged
merged 6 commits into from
Nov 24, 2023
Merged

Additional Names field and box! #332

merged 6 commits into from
Nov 24, 2023

Conversation

towerofnix
Copy link
Member

Snazzy! This PR adds a new Additional Names field to various classes of data objects, which is written similarly to the "who (what)" format for contributions, and adds a neat box presenting those details on corresponding pages:

Fuchsia Ruler, thin layout - a subtly glowing, round-corner box beneath the cover art is titled: 'Additional or alternate names:' and has two items: 'Witc)(ing )(our (contest-submitted name)' and 'Witching Hour (contest-submitted name, normalized) Iron Knight, medium layout: a similar box, glowing grey to match the track, spans spans beneath the cover art floating on the right, and reads: Additional or alternate names: Caw Caw Motherfuckers (contest-submitted name)

Development:

User-visible changes:

  • The new "additional or alternate names" box!
    • This is invisible by default, and shown when the title text is clicked. Since the title isn't necessarily an element you expect to be interactive, it gets both the standard-fare dotted underline and a tooltip. (This should probably be expanded to other interactive elements, but it's particularly useful here.)
    • Clicking the title text will usually toggle the visibility of the additional names box, but if it's offscreen or most of the way down the screen, clicking will always show the box (rather than toggle it) and smoothly scroll it into view. Clicking again will toggle the box closed.
    • This box is loosely styled off of macOS and iOS notifications, which it certainly isn't exactly the same kind of element as, but shares an "ethereal" quality with - it's something that can appear or disappear and whose presence is something you have control over. Thus the rounded corners, frosty appearance, and generally "touchable" look (it has a light faux-3D glowing effect!).
  • Additional names aren't used for anything else, just yet - they're treated as purely extra text. That said, there is room to integrate these into, for example, "by Name" style listings, or an altogether alternate view for the track list on the album page...
  • Additional names are entered into the Additional Names field in much the same format as artist contributions - name, optionally plus annotation in parentheses.
    • This should be ordered after the name (e.g. Track) and directory fields, but otherwise should precede anything else (usually artists).
    • While this format is familiar and works a lot of the time, it isn't necessarily the best fit... it's challenging to include, for example, an alternate name "Savior of the Dreaming Dead (Blaze Remix)" with annotation "beta title" because the "Blaze Remix" part could be interpreted as the annotation.
    • So you can also represent alternate names in an object-structured format: Name: Savior of the Dreaming Dead (Blaze Remix), Annotation: beta title. Cool!
    • This goes for artist contributions too, e.g. Who: Toby Fox, What: arrangement. It just doesn't come up nearly so often there, part because artist:foo-bar-baz lets you get around Foo (Bar Baz) type syntax already.

Supporting internal changes:

  • New additionalNameList wiki property, plus isAdditionalNameList validator - this titling is intended to be in line with e.g. isContributionList, isAdditionalFileList.
  • The parseContributors function in yaml.js is generally refactored - the regular expression it works with is now on its own, since it's used by the new parseAdditionalNames, and is touched up with named capturing groups, for better regex form.
  • The additional names box is generated by the page definition but slotted into generatePageLayout, much the same as cover art, and the automatically generated title heading (whether sticky or not) adapts to be interactive if that slot is filled.
  • On the client, the hash links code gets a new internal event, beforeHashLinkScrolls - if any of its listeners returns false (exactly), the hash scrolling behavior is completely cancelled and it's up to a separate DOM click event listener to control click behavior (if custom behavior is desired at all).
  • Notably, both pieces of data-specified text in additional names are processed with transformInline for display purposes. This allows some ridiculosity as well as, for example, Markdown-formatted links or [[string]] content tags in the annotation - but will cause some trouble for treating these as ordinary text data down the line (e.g. for sorting purposes). It's a low stakes place to mess around since most of the benefit of "additional names" is just getting to see them on the info page for the thing they belong to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Alternate Title(s) field for tracks and albums
1 participant