[HTML output] CSS size and structure

[pkra]

Moving this conversation to the issue tracker for broader discussion.

@pkra wrote:

The generated stylesheet is very large (500kb / 400kb minified / 40kb zipped).
Even though it compresses well, it is still large compared to, e.g., an MML+HTML distribution (375kb minified, 80kb zipped). And it is (of course) also very large compared to the old stylesheet (2kb zipped).

I'm slightly worried about this.

• it makes server-side processing less interesting as the page size increases not just by the HTML markup but also by the stylesheet - even though, from my tests, the HTML output has decreased in size in real life examples (often not more than MathML)
• in situations where client-side rendering is used but CSP blocking of inline-styles is required, it adds 50% load
• I'm wondering about CSS performance, especially as it interacts with other CSS

@dpvc wrote:

There are several possible approaches to this issue. Right now the CSS includes everything needed for every character in the fonts. It would be possible to generate only the CSS needed on the page. For example, for server-side pre-rendering of non-dynamic pages, this would produce only what is needed. For dynamic pages, it would be possible to generate the CSS as needed by the page, rather than all of it all the time.

Alternatively, the CSS could be broken down into smaller chunks and loaded as needed. For example, the Fraktur, script, sans-serif, and other such variants could be left our initially and loaded by the page author when those variants are desired.

It would also be possible for MathJax to do most of the CSS inline instead, as it is now in v2. It may be that we want to not use the "content" CSS styling but rather insert the character directly. Aside from reducing the CSS size, this would also fix some problems with Safari bugs, and would also allow the removal of the width specifications, as those are to work around a Safari bug that seems to be due to the use of content.

Finally, the fonts need to be reorganized and rebuilt. This will help slim down the CSS, which right now has some awkwardness due to the layout of the current fonts

The current implementation is a rough-and-ready approach that was only to get the output working enough to get the CHTML layout underway. It will need to be revisited when the fonts are reorganized and rebuilt. That will involved building the new font tools, and that will take some time; I didn't want to hold up the release for that. So there are still some iterations to be done for the fonts and their data, and I think that is something to look at early next year.