Re: mailto: with Body part broken (was: Re: [Evolution] Three small questions about Evolution)



On Wed, 2005-11-16 at 23:41 +0100, guenther wrote:
I can't say that Evo's behaviour is strictly wrong, since all it's doing
is what Firefox is telling it, i.e. create a message with a given Body.
The Evo developers could argue that adding an extra line in Normal
format is exceeding the spec.

It would be nothing more than adding a newline at the end of the given
Body string.

Of course, but standards lawyers will say it's still a change, so maybe
it should be optional.

If they do, they are wrong. ;-)  This is not claimed by the standard.
See below.


It's what I want in this case, but is it
always what I want? Neither can we ask Firefox to know about Evo's
formatting features.

True.

One solution would be an extra Evo command line option to allow callers
to ask for strict/nonstrict inclusion of the body text.

Don't think this will work, since mailto: is some kind of a standard,
implemented by Browsers and MUAs all over the place.

Yes, according to Google it's RFC2368, and there isn't any obvious way
of making it do what we want.

Oh, I didn't know there is a RFC. Good catch, Patrick. :)


Seems to me the alternatives are:
[...]

I beg to differ. :)  I just read that whole RFC, neither the format nor
any additional text is mentioned -- apart from a claim that "The user
can edit the message". So it's the responsibility of the MUA to chose a
sane paragraph format (if it actually supports multiple) and to add
additional text -- at least the signature and a newline does make sense.

According to the RFC it is totally legitimate for the MUA, to add a
newline char to the body given in the URL.

Could be. I didn't read it that carefully.

Regarding the paragraph style (Normal vs. Preformat), both make sense in
different cases:

* Sending long URLs (the original example) wraps with "Normal", but is
  fine with "Preformat".
* Giving a short natural language text [1] for the body is fine with
  "Normal", but is ugly and unwanted with "Preformat".

It can be hard to determine the correct (or at least best) paragraph
style for *all* cases possible. But with a newline at the end of the
given body string and using "Normal" at least for the second line where
the *user* is supposed to enter text, we get a better solution than we
do have now.

Absolutely.

poc




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]