Hi Kelly, > While working on my class, I’ve been thinking about the available tools and > where 2e is necessary vs. what can be replaced with L3 methods. > > I know that there isn’t a consensus on how boxes should work, so things like > `\parbox` and friends should still be used (unless coffins happen to work > better for a given use case). > > However, I think there’d be no harm in providing an L3 interface for dims and > skips. I know that the 2e kernel already provides tools for this, and so an L3 > interface would have some redundancies. I think an `xskips` package would still > be useful because: > > 1. it would provide more tools than 2e does; and > 2. it would harmonize with the other L3 design-level interfaces. that's a good question what harmonizes with L3 design-level interface. Remember that we think of the designer level of more or less free of programming, i.e., you make declarations (possibly using CamelCase syntax but you don't "program" (or if you do, because the features you are looking for require that it would be in a clearly separate section that is actually package code only not separated out --- and then that kind of code would be direct expl3). So what is the purpose for example of \VerticalSpace? would it have a natural place to live and if so why? I guess our ask here would be use cases for the commands you proposed to get a feeling whether they should and if so in what form they should be provided but not embark on making a copy of the expl3 code interfaces 1-2-1 into CamelCase unless we all agree on seeing a good reason for it. There are of course boundary cases, eg a function for setting length parameters should naturally support evaluations of its value argument (which right now \newlength doesn't offer (unless you load calc. But already the distinction between skips and dimens (that exist on the programming level but not on the 2e user level in the setters) is something to ponder. An I would be interested to see examples why the distinction os sensible on the designer level (I'm not convinced it is) I mean, why shouldn't there be a single set of design-level setters. As for allocation, to what extend are they needed on the design level? Aren't they only needed when you are actually asking for some programmed code? > I have attached the raw .sty code which contains what I think are appropriate > tools for the designer level. Of course, this would become a proper .dtx file > with documentation and examples. So rather than documenting that suggestion, I would ask for convincing examples for each of the proposed functions that are design tasks that should live in a class file rather than programming tasks that should live in package/modules that offer building blocks for titles building blocks for headings etc etc. I'm not saying none of them are, maybe some are the right choice for the design level, but instead of embarking on providing stuff that we later regret, let us first better understand the needs. So if you have the time I would very much look forward in seeing how you intend to use each and every of these functions. best frank ps while we are at it, uses of \parbox and friends (or coffins) would be also very much of interest. where do you use them and how ...