I know the diffs are hard to read, so this is easier to just explain:
Short version
This reorganizes the stylesheets for reader view/PDF into logically-named plain CSS, and drops the one file that was implemented as SCSS. The CSS is served by Django as regular static assets and not through the webpack bundler.
This introduces some style duplication in favor of a more streamlined, performance-first approach to laying out these very long pages. It will also makes it easier to eventually fork off a casebook into a standalone mini-site.
Long version
In doing performance profiling for PDF output, I was finding it difficult to isolate the effects of PDF/annotation code because of noise from other bundled CSS. In addition, the asset bundler we're using renders CSS as JavaScript in development mode, which introduces overhead, and also invalidates some performance strategies like defer. For example in dev:
when bundled for production. The only way to get around this is to bundle for prod locally, but that's painful to iterate on because the bundle step takes many seconds.
I had been originally thinking that PDF output would just be a byproduct of a reader-focused view. I now think they should be treated as distinct sub-products, with different goals, especially when it comes to performance and accessibility. There are some optimizations (like lazy loading) that we should do for screen viewing that don't make sense in PDF rendering. And there are some kinds of markup that are desirable for screenreaders or interactivity that are unnecessary overhead in HTML bound for PDF conversion. (For example, I can tell that handling elisions as straight deletions of text nodes will be much faster than wrapping the deleted text with markup, but doing so in screen mode would eliminate the possibility of a "show elided text" feature.)
So this is just housekeeping work in preparation for more rigorous benchmarking, and also more cleanly isolates the print styles from the screen styles, since we dropped the feature that let you toggle between print preview and screen modes.
Lastly, I made the casebook font in reader mode match the site font, to better tie it together with the platform. You only get Caslon, the more book-like font, in PDF output, where the slab site font would look odd.
To do
Bypassing the bundler also bypasses the asset version stamp, so plain CSS is always sent to production with no cache-busting. I'm sure there's a lightweight solution here, but I haven't given it thought yet.
(Switching to draft because the SCSS file wasn't actually deleted, and when I do that, the bundler is still looking for it even though it's no longer referenced. Will investigate.)
I know the diffs are hard to read, so this is easier to just explain:
Short version
This reorganizes the stylesheets for reader view/PDF into logically-named plain CSS, and drops the one file that was implemented as SCSS. The CSS is served by Django as regular static assets and not through the webpack bundler.
This introduces some style duplication in favor of a more streamlined, performance-first approach to laying out these very long pages. It will also makes it easier to eventually fork off a casebook into a standalone mini-site.
Long version
In doing performance profiling for PDF output, I was finding it difficult to isolate the effects of PDF/annotation code because of noise from other bundled CSS. In addition, the asset bundler we're using renders CSS as JavaScript in development mode, which introduces overhead, and also invalidates some performance strategies like
defer
. For example in dev:contains almost entirely static assets, and becomes
when bundled for production. The only way to get around this is to bundle for prod locally, but that's painful to iterate on because the bundle step takes many seconds.
I had been originally thinking that PDF output would just be a byproduct of a reader-focused view. I now think they should be treated as distinct sub-products, with different goals, especially when it comes to performance and accessibility. There are some optimizations (like lazy loading) that we should do for screen viewing that don't make sense in PDF rendering. And there are some kinds of markup that are desirable for screenreaders or interactivity that are unnecessary overhead in HTML bound for PDF conversion. (For example, I can tell that handling elisions as straight deletions of text nodes will be much faster than wrapping the deleted text with markup, but doing so in screen mode would eliminate the possibility of a "show elided text" feature.)
So this is just housekeeping work in preparation for more rigorous benchmarking, and also more cleanly isolates the print styles from the screen styles, since we dropped the feature that let you toggle between print preview and screen modes.
Lastly, I made the casebook font in reader mode match the site font, to better tie it together with the platform. You only get Caslon, the more book-like font, in PDF output, where the slab site font would look odd.
To do
Bypassing the bundler also bypasses the asset version stamp, so plain CSS is always sent to production with no cache-busting. I'm sure there's a lightweight solution here, but I haven't given it thought yet.