ietf-822
[Top] [All Lists]

Re: Text/Enhanced straw man

1993-02-13 21:37:19
      -o It should be trivial to type.  In fact, as much as
           possible, it should mimic the current email and news
           conventions.  It should be unlikely that a user would
         accidentally imply markup.

This paragraph, when quoted using "> ", shows another reason why tabs
are bad.


      -o It should be trivial to type.

Yes, but the intention should be to use a good composing agent.
People won't be able to type it exactly right.


           It should be unlikely that a user would
         accidentally imply markup.

Well, the presence of "text/enhanced" in the header would indicate
that it wasn't accidental.


      -o It should be possible to read an enhanced message as
           straight text on a non-compliant UA and get a good feel for
           what the markups mean.

Yes, that's the whole point.  If a new format is unreadable in current
software, users of the new software won't dare to use it.  This is one
of the reasons why so few people use RFC 1341 RichText on this mailing
list.  (It's not only because there are few good composers out there.)


           The end user should be able to decide how the
           markup looks.

This is an important point.  As Bill has been saying, his intention is
for *...* to mean "emphasis", not "bold".  I.e. he wants a
"descriptive" markup, not a "procedural" one.  I used to think that it
would be better to make it procedural, but I'm now willing to
compromise: *...* means emphasis, and must be displayed in bold if the
display is capable, unless the receiving user specifies that *...* is
displayed in italics or whatever.

Of course, if things like +...+ (meaning "bigger") are added, these
would be purely procedural.  Indentation, etc is also procedural.


The phrase must begin and end with the markup
character (star or underscore), and spaces between words must also be
changed to the markup character.

What if you want to use the markup character itself?  I think it would
be better to use pairs.  I.e. one before and one after the text, and
then double the character when a single one is desired.  I.e.:

    This (**) is a single asterisk, and *this* is emphasized.

This makes it possible to say things like:

    This format uses **s before and after *emphasized* text.


If the markup characters are displayed and line breaking occurs within
a marked string, both the pre-break and post-break text should be
marked, as in

      - : ... _a_long_
        : _phrase_ ...

I sort of agree.  *I.e. each pair should be on one line, and*
*multiple pairs can be used if the text spans more than one line.*


        - ~ > Here is a controversial word
        - ~             ^^^^^^^^^^^^^  You said it!
...
I have to confess that I don't know a good solution to this problem.

This is also quite easy to solve if you define the format in terms of
an 80-column terminal model.  The receiver's UA is responsible for
matching up the circumflexes (^) with the pointed-at text, and then
somehow displaying that.


You can take this whole approach quite far, actually, even including
such things as:

  +-----+    +-----+
  | MUA |--->| MTA |
  +-----+    +-----+


But I think we're going too fast here.  It's easy to come up with
ideas, but it's harder to implement them, and even harder to get
people to use them successfully (and interoperably).  I think we
should first define a "core" set of primitives, and have a header
like:

    Content-Type: text/enhanced; version=1

and then people could experiment with

    Content-Type: text/enhanced; version=x-2

until the spec is frozen again, after which they use

    Content-Type: text/enhanced; version=2

and so on.

We need to gain experience implementing and using the stuff before we
go into the complex stuff.


Cheers,
Erik


<Prev in Thread] Current Thread [Next in Thread>