dginev / ar5iv-css Goto Github PK

It is uncanny how close we get to the the 2-column view in the PDF files for some .cls files by simply by adding:

.ltx_abstract,
.ltx_section,
.ltx_appendix,
.ltx_bibliography {
  columns: 2;
}

To the CSS ruleset. Adding that as a toggle-able theme, orthogonal to the light/dark theme toggle, feels rather reasonable as an experiment.

But every type of content that refuses to reflow, makes this difficult. Cases I've spotted on a quick glance:

• long display equations, and their tags
• certain side-margin notes get stuck between columns
• verbatim code blocks sized for a single-column width
• tables sized for a single-column width

So maybe it is best to defer this until we can auto-reflow nearly everything, and see if there is additional interest / ideas floating around.

As seen in author block of:
https://ar5iv.labs.arxiv.org/html/2005.05579

.ltx_graphics used in ltx_personname shouldn't get the display:block; directive.

Large equations (and equation groups) are pretty hard to navigate on a vertical phone display, as bad as a PDF equation would be.

We should introduce an approach to reflow them in a meaningful way.

There is a good mathml-core issue to track, which has some CSS ideas: w3c/mathml-core#127

A simple upgrade to the fragment markup would be to have an anchored # button which points to the current heading.

Add to that a reframing of the CSS, where headings get a top padding (say 1em), and we get a nice landing experience, as in this site.

Making it visible on hover is a nice extra touch. The only question is whether we should be adding a post-processing theme to latexml (i.e. implement this in XSLT), or do this in the final Rocket web service (either on serve, or as a Javascript patch).

Tables are pretty hard to navigate on a vertical phone display, as bad as a PDF table would be.

We should introduce an approach to reflow them in a meaningful way.

I stumbled on a blog that had enabled custom selection highlights which seemed nice. For ar5iv, they would be roughly equivalent to:

:root {
  --background_contrast_pop: rgba(157, 157, 171, 0.4);
}

[data-theme="dark"] .ltx_document ::selection, .ltx_document ::-moz-selection {
  background-color: var(--background_contrast_pop, #724714);
}
[data-theme="light"] .ltx_document ::selection, .ltx_document ::-moz-selection {
  background-color: var(--background_contrast_pop, #8db8eb);
}

Some early testing comments:

• The MathML support is a bit inconsistent in Firefox, it looks like <mo> elements are not covered?
• The Firefox selections seem to encounter some lag with the custom rule - especially on a large document. Is that annoying to lay users?
• Also if desired, what are the most reasonable colors?

Shelving it as an issue for now, but if anyone wants to take over and experiment - feel free and let me know.

At the moment, ar5iv theme defaults to light when javascript is disabled.

It would be nice to default to prefers-color-scheme instead so that:

1. it works without JS
2. it does not blink from white to dark on slow connections or devices

This could be done by following the example of the CSS of the furo theme, for instance.