Re: [rfc-i] t with indent

On Tue, Dec 29, 2020 at 12:47 PM John Levine <johnl@taugh.com> wrote:

> In article <
> CABcZeBOvxuD0pnWrkcywcKBMsd4CuCrLB4YkmDStpwh7e-SkSA@mail.gmail.com> you
> write:
> >   <t indent="0" pn="section-2-5">
>
> >First, do we really want this kind of layout-specific markup rather
> >than semantic markup? Searching for <t> with indent != 0 in the
> >published RFCs, I see the following cases:
>
> It was added quite recently. Before that the RPC was faking indented
> paragraphs with single element unnumbered lists which was silly.
> You'll find over a thousand of those.
>
> >It seems like we might be better served here by introducing some new
> >semantic constructs. Both nested definition lists and equations are
> >natural structures that would benefit from consistent layout ...
>
> Perhaps, but I find one fairly quickly hits the point of diminishing
> returns when trying to assign semantics to every typographic feature.
> If someone can find consistent semantics in the thousand fake indents
> I wouldn't be opposed to adding semantic tags (even retroactively) but
> I'm not holding my breath.
>

Well, I certainly don't think all of them will have the same semantics.
Rather,
what I would expect is that the majority fall into a relatively small number
of buckets. We'd then need to go and look to see whether it was worth
having a typographical feature like this for the remainder or whether
we could just live with suboptimal typesetting in those cases -- it's not
like
it would be the first time our typesetting was suboptimal!

> >Second, even assuming that <t indent=...> is a good thing, it seems
> >suboptimal to have it attached to every paragraph in the XML. Is
> >there a reason why it can't simply be omitted when it is set to
> >the modal value of "0"?
>
> The default is zero so I agree that there's no need to indicate zero
> indents.
>

That seems like a good start. What's the process for doing that? Based on
Julian's
note it sounds like this is a requirement documented somewhere.

-Ekr

R's,
> John
>