Add themes, margin and sticky notes, and change layout

[TwoTau]

ACM template theme: https://homes.cs.washington.edu/~vishald/lpub/themes/acm-article/ Normal theme: https://homes.cs.washington.edu/~vishald/lpub/themes/normal/

Things added:

• lpub.js: Outputting to a specific directory
• Themes using SCSS
  • style.scss imports the other SCSS files
  • layout.scss handles the layout of the document, like element sizing
  • common.scss contains styles shared between all themes
  • _theme.scss is autogenerated by the build script, which replaces its content with an import to the document's theme
  • themes/*.scss contains the themes, each in their own file
• Example documents using those two themes: layout.md and acm-template.md
• Copying over style/assets into ${outputDir}/assets
• Sticky margin notes. scroll-manager.js is the component that manages scrolling/stickiness in runtime

Some open questions:

• Syntax: sticky-until-top and sticky-until-bottom are kind of clunky. Would sticky-until="#element" along with sticky-anchor="end" be better?
• Specifying the range of sticky elements should have better defaults. Would it be best for the default to be "end of current section"?
• Where/How do we allow authors to override the theme's CSS?

TODO:

• [ ] "Layout linting": add compiler warnings when sticky figures overlap with non-sticky figures
• [ ] Add compiler warning when sticky-until-* references an anchor that doesn't exist (right now, there's a runtime warning in the console)
• [ ] Smarter, more efficient copying of assets. Maybe only copy over a file if the last-modified time is later?

[jheer]

This is looking great! I added comments/questions on some of the code changes.

A few additional questions:

• How valuable is using SCSS? I'm not against it, but would like to keep things as-simple-as-possible unless a change makes a substantial difference in what we can express.
• What is the difference between an inlinenote (previously just note) and an aside? I'm not currently using aside anywhere in living papers now, so I'm curious what you have in mind here.
• For the sticky attributes, how about sticky-until (stick until you reach the start of the identified section) and sticky-through (sticky until you reach the end of the identified section). Does that match your current semantics for sticky-until-top and sticky-until-bottom? (And on that note, I'm not sure of the semantics for until-bottom... does it reason in terms of paper sections or only via specific element ids?) I'm tempted to keep things simple and use only sticky-until (top) for now, unless you have some compelling argument otherwise!

Also, take a look at this PR, as we'll need to reconcile our approaches: https://github.com/uwdata/living-papers-testbed/pull/9

[TwoTau]

How valuable is using SCSS? I'm not against it, but would like to keep things as-simple-as-possible unless a change makes a substantial difference in what we can express.

The SCSS features I use most are nested selectors and reusable mixins to organize code. I think the main expressiveness benefit of SCSS is being able to pass variables around, but this is now also possible with CSS variables. I've noticed that programmers tend to use SCSS variables for colors and CSS variables for layout, but I'm not sure why (maybe because of the SCSS's color functions?)

What is the difference between an inlinenote (previously just note) and an aside? I'm not currently using aside anywhere in living papers now, so I'm curious what you have in mind here.

I mentioned this in a previous comment; I don't think there was a difference. I'll push a commit that renames inlinenote back to note

For the sticky attributes, how about sticky-until (stick until you reach the start of the identified section) and sticky-through (sticky until you reach the end of the identified section). Does that match your current semantics for sticky-until-top and sticky-until-bottom?

Yep, just pushed a commit to change the naming to sticky-until/sticky-through.

(And on that note, I'm not sure of the semantics for until-bottom... does it reason in terms of paper sections or only via specific element ids?) I'm tempted to keep things simple and use only sticky-until (top) for now, unless you have some compelling argument otherwise!

Right now, both until-top and until-bottom only reason in terms of CSS selectors (#ids but also harder-to-use selectors like #header ~ p ~ p). However, I'm guessing most authors would prefer to specify "sticky until the bottom of the current section" or "sticky until the next h1 or h2 heading" without needing to know the heading's ID.

My reasoning for adding a "sticky-through" option was just aesthetic. I think it's more cohesive for the sticky figure to end at the same y-position as the bottom of the last <p> of the current <section> instead of the first <p> of the next <section> because sections have margins.

[TwoTau]

Rendered with themes:

• Barnes-Hut https://homes.cs.washington.edu/~vishald/lpub/themes/barnes-hut/
• Fast KDE: https://homes.cs.washington.edu/~vishald/lpub/themes/fast-kde/
  • One of the margin notes (Figure 5) overlaps with the page-width Figure 6. TODO: Make scroll-manager move .margin elements down so that they don't intersect .page width elements.

Changes

• Use CSS instead of SCSS
• Rename note/aside components
• Handle scroll logic in an entrypoint script instead of a non-rendering web component