[rfc-i] Proposed way forwards on backward compatibility with v2

Nico Williams nico at cryptonector.com
Mon Feb 17 12:31:06 PST 2014


On Mon, Feb 17, 2014 at 2:09 PM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> Exactly what are the cases where vspace can't be replaced with something
> else?

http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#rfc.section.2.3.1.10

Lists three cases:

 - line break
 - page break
 - list item paragraph break

All three can be replaced with better first-class elements.

I suppose additional uses might have to do with pagination relative to
floating elements.

> Assuming it is allowed in enough places, <artwork> can replace many uses of
> vspace where blankLines is > 1, and maybe when blankLines=1.

Maybe.

> It is a bit more troublesome when blankLines==0.

I'm not sure why we should need an explicit line-break anywhere.  But
we could have a <br> if we did need it.

But look, the RFC-Editor is going to need the ability to affect
pagination.  I don't think we'll get out of having to give them some
way to affect that short of deprecating pagination.  I think we should
keep <vspace> *and* not throw errors about it when formatting RFCs
(but maybe when formatting I-Ds).  At least until we gain experience
with the new tools.

>> Do people here like this proposal? If there is agreement I should try
>> this, I would revert all of the non-backwards-compatible changes, mark
>> things as deprecated and indicate the newer way of doing them. For lists, I
>> would then go to HTMLish lists like <ul>, <ol>, and so on.
>
> I'm for it.

Yes.

Nico
--


More information about the rfc-interest mailing list