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

Paul Kyzivat pkyzivat at alum.mit.edu
Mon Feb 17 13:35:18 PST 2014


At the end of the day, I want to get my draft to look the way I want it 
to look. (Within the constraints of what IdNits allows.) If I can't, 
then I'm going to be mad.

Its best if I can achieve that using "structural" elements. If I can't, 
then I make a tradeoff between getting "close enough" to my preference 
using structural elements, and "hacking" it with explicit presentation 
elements. But it is good to have enough tools to make the choice.

	Thanks,
	Paul

On 2/17/14 4:26 PM, Dave Crocker wrote:
> On 2/17/2014 1:11 PM, Julian Reschke wrote:
>> On 2014-02-17 21:50, Dave Crocker wrote:
>>> And in this case it isn't appropriate to try.  There is nothing 'broken'
>>> in the current version.  There is merely the desire for some additional
>>> features.
>>
>> There are certain things we'll want to discourage, because they are
>> workarounds for missing stuff. Whether we'll be able to remove those is
>> a separate question (I hope we can if there's sufficient time between
>> deprecation and removal).
>
>
> Yes, but...
>
> This entire discussions is an instance of a classic debate between
> theory and practice that has a particularly long history for document
> representation/presentation.  The debate is between being purely
> 'structural' in constructs -- with absolutely all presentation details
> being left to the printing/formatting engine later -- versus permitting
> explicit presentation details in line.  <p> is an example of the former,
> and <vspace> is the latter.
>
> A purist structural model is extremely appealing.  The problem is that
> it is also Procrustean.  Some of you might like having your legs get
> chopped off but some of you might not...
>
> So yes, it's reasonable to press people to use the cleaner, more
> abstract construct.
>
> But no, it is not reasonable to remove all ability to overcome perceived
> limitations with the abstractions.
>
> Rather, we need to understand that the abstraction approach is unlikely
> ever to be perfect, and that the indelicate pragmatics of direct
> formatting directives is likely to continue to be (sometimes) useful.
>
> d/
>
>



More information about the rfc-interest mailing list