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 ...