Support TeX content in message list

[rajveermalviya]

Fixes #46

[gnprice]

Thanks for posting this! This structure looks promising, and I see there are some TODOs highlighting bits of CSS that may be more challenging.

Which area or two do you think are likely to be the toughest to handle?

[gnprice]

I think this is probably one area where we can do it more simply than it's expressed in the CSS — I believe the point of these classes is to take it to the size named in the sizeNN class. The CSS rules are more complicated because they have to express it in terms relative to the enclosing size, in order to use CSS's em concept, but we can instead go straight to the desired size (and just scale it relative to the overall font size that prevails outside of the whole math node).

[gnprice]

(Also this sort of complex logic should ultimately go in the parsing phase, as you might already realize. Putting it here in the widget build phase is perfectly sensible at this prototype stage of the work, though — that's exactly what I did for content parsing as a whole in the very early stage of prototyping this app.)

[gnprice]

I think these two are another case where our implementation can be simpler than the CSS ­— I think we can probably just ignore both of these.

From the source:

    .vlist-t2 {
        margin-right: -2px;
    }

    .vlist-s {
        // This cell solves Safari rendering problems. It has text content, so
        // its baseline is used for the table. A very small font avoids line-box
        // issues; absolute units prevent user font-size overrides from breaking
        // rendering. Safari refuses to make the box zero-width, so we give it
        // a known width and compensate with negative right margin on the
        // inline-table. To prevent the "width: min-content" Chrome workaround
        // from shrinking this box, we also set min-width.
        display: table-cell;
        vertical-align: bottom;
        font-size: 1px;
        width: 2px;
        min-width: 2px;
    }

So vlist-s is there to work around quirks in Safari. And then vlist-t2 is apparently there to work around a quirk introduced by the vlist-s workarounds — it's that negative right margin mentioned in the comment. (In at least your \sqrt x example, that class appears together with vlist-t, i.e. on the table.)

[gnprice]

(We'd want to have the parser validate that it sees vlist-t2 only alongside vlist-t, and complain if it sees it somewhere else, to confirm that understanding.)

[gnprice]

One thought that I have looking at the styles for this one:

    .vlist {
        display: table-cell;
        vertical-align: bottom;
        position: relative;

        > span {
            display: block;
            height: 0;
            position: relative;

            > span {
                display: inline-block;
            }

            > .pstrut {
                overflow: hidden;
                width: 0;
            }
        }
    }

is that those styles look like they're written with an assumption that the children and grandchildren of a .vlist element will have a fairly particular structure: any child span is given a particular role, and any grandchild span is given a different particular role.

So I think there may be quite a bit of structure in the subtrees that KaTeX generates that use this vlist class. For example, again just looking at your \sqrt x example, it might be:

• each child of a .vlist has two children,
• one of which is a .pstrut with a height but no other styles and no children
• (and the other of which then has more-or-less arbitrary recursive structure).

If that pattern holds, or something like it, then that could substantially simplify thinking through what this CSS does and how to apply it.