meta-issue: technical debt

[rsek]

since many of these touch the same files, here's an overview of tasks to improve code readability, semantics, or otherwise improve dev QoL without user-facing changes to appearance or basic functionality :) alternatively/additionally, i could open issues for all the ones that don't have an issue already; that might benefit from some appropriate tags/labels, though.

is there anything i've missed, or that bears adding to the wishlist?

• [x] standardize formatting + its configuration: #377
• [x] migrate to FVTT v9 types: #392
• [x] update other dependencies: #392
• [x] where practical, migrate to typescript
  • [x] build scripts? on one hand, handy to just have 'em ready to run without getting ts-node involved. on the other, they're complex enough that typings might save some grief
  • [x] SFCs. this requires stricter tsconfig options (like noImplicitAny and noImplicitThis) that will require rewrites of significant chunks of code.
    • one of the biggest offenders here is handlebars' helper function registrations.... but we might be able to trim those out, see the next item
• [ ] where possible, do complex composition in Vue rather than in Handlebars, with handlebars acting mainly as a wrapper; having to track functionality across multiple files isn't ideal - SSoT, and all that
  • [ ] many ironsworn-specific sheets suffer from this; revist them once more component refactors are complete
• [ ] rewrite HTML for improved semantics + accessibility
  • [ ] all widgets should have implicit or explicit role attributes. this has the handy side effect of making the code easier to parse
  • [ ] descriptive, meaningful class names for html elements
  • [ ] where practical, prefer pre-existing HTML attributes over component methods or DOM manipulation. examples:
    • .disabled class + prevent click events w/ component method =>disabled=true and/or aria-disabled=true
    • prevent submit events with <button> w/ component method => use type=button on <button> so it doesn't default to type=submit
  • [ ] prefer CSS grid for grid-like layouts that currently rely on nested div.flexcol/div.flexrow
  • [ ] prefer CSS styling over HTML elements that have defined semantics but are being used presentationally. examples:
    • <hr> => CSS margin-* properties or :before pseudo-elements
    • <button><i class="fa-icon">[...]></button> decorator => CSS button:before pseudo-element containing icon
  • [ ] full keyboard accessibility
    • [ ] investigate a vue library to manage keybindings
    • [ ] investigate a vue library to manage focus
    • [ ] figure out how all this is going to interact with FVTT's native keybinding
  • [x] investigate using SVG icons over icon fonts
• [ ] rewrite CSS for better modularity + easier retheming
  • [ ] prefer relative units (rem, em) over static px where practical
  • [ ] remove all inline HTML style elements; prefer descriptively-named classes instead, but still keep component-specific CSS encapsulated in the relevant component file
  • [ ] standardize CSS variables across all themes - underway in #490
  • [ ] decouple layout/positioning from other styling concerns (typography, color + other decorative elements, etc)
• [ ] standardize Vue components to provide an readily-maintainable, modular set of building blocks for future expansion
  • rule of thumb: if a design pattern is (or is likely to be) used more than once, consider making it a component
  • i've got drafts of most of these on a general purpose semantic components branch already, but i'll be reworking them so that each can be its own, more-readily-reviewable PR instead of one monster PR
    • [x] Buttons: #390
      • there's a couple straggler buttons that might bear standardizing with the same patterns, like "delete item", but the PR above was already huge - i'll circle back to them when i work on progress items specifically
    • [x] Tabs: #396
    • [x] condition meters and other slider-type components: #501
    • [x] progress tracks: #486
    • [ ] number spinners (e.g. stat widget)
    • [ ] xp tracks (particularly the 'classic' one)
    • [ ] simple collapsibles (e.g. completed progress items, asset items)
    • [ ] complex collapsibles (e.g. oracle tree, move tree)
    • [ ] plain text inputs like <textarea> and <input type=text> (e.g. character vitals)
    • [ ] any "building-block" components that i've forgotten above
    • [ ] widgets composed of the components above
    • [ ] pages composed of the widgets above