Cannot set leftmargin via \SetTemplateKeys{block}{display}

[mbertucci47]

I am trying to implement margin setting for keytheorems with tagging enabled and ran into trouble overriding the block settings locally with \SetTemplateKeys. The following MWE shows the issue:

\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,math,table,title,firstaid}
  }
\documentclass{article} 

\usepackage{kantlipsum}

\SetTemplateKeys{block}{display}{
  leftmargin=2cm, % does nothing
  rightmargin=2cm, % this works
  }

\begin{document}

\kant[1][1-2]
\kant[2][1-2]
\begin{enumerate}%[leftmargin=2cm] % this works
\item abc
\item \kant[1][1-2]
\kant[2][1-2]
\end{enumerate}
    
\end{document}

If leftmargin or rightmargin is set in the optional argument of enumerate then it works as expected. The same is true for rightmargin if set with \SetTemplateKeys{block}{display}. But leftmargin set in \SetTemplateKeys has no effect. It doesn't matter if this is executed in the preamble or right before the environment.

Am I trying to use this the wrong way? Or is this a bug in the block code? Even in the first case, it's odd that rightmargin does something while leftmargin does not.

[u-fischer]

The block still calls the legacy commands, in this case \@listi and that contains
\leftmargin\leftmargini.

[mbertucci47]

@u-fischer I see, thanks. I understand these interfaces are a work in progress. So is there any way to change the settings besides either passing the key directly to enumerate or redefining \@listi? I guess setting \leftmargini but that assumes I know the current listdepth is 1.

[FrankMittelbach]

I think we have conflicting goals here. I think that the block implementation has to make use of the legacy list environments because they are all over the place in existing document classes and as long as those aren't updated (and many will not) this means that either we keep it (which allows for tagging even of those classes) or drop it (which means we rule out those as being usable going forward) without a full replacement of their code.

So my tendency is to just document this as a restriction.

[mbertucci47]

@FrankMittelbach I'm a little confused. Isn't the point of separating the block and list templates to remove any connection between them? At least for kernel commands where you have full control, shouldn't there be a trueblock or something that uses its own parameters completely separate from the list parameters?

[FrankMittelbach]

@FrankMittelbach I'm a little confused. Isn't the point of separating the block and list templates to remove any connection between them? At least for kernel commands where you have full control, shouldn't there be a trueblock or something that uses its own parameters completely separate from the list parameters?

@mbertucci47 yes the idea is to separate both and for new classes that do not also implement \@listi and friends that would be the case (and the intention is to offer such classes eventually). However, the goal also is to make existing classes work evne if they do not get updated and that means honoring their \@listi settings somehow. That means you can't overwrite their settings as cleanly is you could otherwise but if we don't do that then their settings would be ignored which means tagging or no tagging would result in possibly severe layout differences.

Some of that behavior might eventually be controlled with something like compatibility={...} in \DocumentMetadata but we are not quite there yet.