::before and ::after pseudo-elements

[runarberg]

I’ve noticed that Chrome does not render the ::before and ::after pseudo-elements. The spec doesn’t appear to specify whether they should or shouldn’t be supported. I would expect that most CSS features would be supported unless explicitly specified not to.

My use case was trying to implement something like the old <menclose notation="downdiagonalstrike"> with CSS:

<mrow class="cancel">
  <mn>1</mn><mo>+</mo><mn>1</mn>
</mrow>

.cancel {
  position: relative;
}

.cancel::after {
  background: linear-gradient(
    to bottom right,
    transparent calc(50% - 0.1ex),
    currentColor calc(50% - 0.05ex),
    currentColor calc(50% + 0.05ex),
    transparent calc(50% + 0.1ex)
  );
  content: "";
  inset: 0;
  position: absolute;
}

I could off course just add the background to the original element, but if the line is a different color than the content, then the line is drawn behind the content.

[runarberg]

Note, absolute positioning on MathML elements seems not to be implemented in firefox.

[dginev]

Cross-referencing a similar discussion from the SVG WG, which may be useful related work to be aware of:
w3c/svgwg#125

[NSoiffer]

Although my comment doesn't address ::before and ::after, it may help solve @runarberg's needs...

Several years ago I wrote polyfills for Core and that includes a polyfill for menclose. The code is at https://github.com/w3c/mathml-polyfills/blob/main/menclose/menclose.js. It handles all the menclose notation attributes including arrows (impressive CSS that I borrowed and slightly modified from MathJaX). You can see the polyfill in action here. The lines are the same color as the text, but I think it is not hard to change that.

[bkardell]

The Working Group discussed this today and while we believe this is interesting,
we also believe it is probably unlikely that we can feasibly get generated content sorted out for MathML-Core Level 1 (the related SVG issue has been open for ~8 years, for example). For now our main focus is on landing a stable, well specified and interoperable level 1 across implementations - that may lead to implementation questions that give this topic energy, but it's not clear yet. We've moved this to level 2 for now, but will revisit as we can.