Hello!
 
15.03.2018, 17:40, "Sam Whited" <[email protected]>:

On Thu, Mar 15, 2018, at 02:22, Kozlov Konstantin wrote:

  1. Embedding pics into messages: ~80%. Pics are used to display memes,
     as custom smilies, as parts congratulation cards, as small parts of
     screenshots to explain something and so on.


Custom smileys should probably be its own XEP, but I agree we should make something for that at some point.
Attatching images is better handled by XEP-0066 and does not need to be a part of a message formatting spec. It's likely that even if you don't support formatting you may want to include an image.

I don't think XEP-0066 suits for attaching inmages.
  1. It provides no way to tell client softwarem that provided link contains image. So, client have to check every link to find out if there's an image on the other side.
  2. Even if I attach a link to image, that doesn't mean I want other party's client to display it within my message. I need a way to specify, if this image is to be attached to the message or just to be displayed as a link.
  2. Striking out parts of text to make funny messages, like author
     wanted to insult other party say something else, but changed his/her
     mind: ~10%
  3. Highlighting parts of text with *bold* (sometimes *italic* or
     _underscrore_), to add _expression_ or just attract attention to
     highlighted parts: ~5%


These are supported, so nothing to do there.

Right now we have just <emphasis/> element whch sugested to be rendered either bold or italic. It's up to other party's client how to render it. I just want to be able to specify bold, italic or underlined explicitly. Otherwice I'll be unable to have WYSIWYG in my client, won't be sure what other party will see.
  4. Using different fonts, font sizes and colors, for the same as in 3
     or as parts of congratulation cards: ~3%.

This is an anti-pattern. It's bad for users and bad for accessibility. There is a reason most modern messaging systems leave it out. If I have a black background and you send me messages with your text color set to black, I can no longer read it. If you set your font to be tiny and I'm hard of seeing, I can no longer read it. If you set it to be huge and I'm on my phone, it takes up half the screen and I'm annoyed. etc.

That's mostly abuse. Most of the features of any client could be abused. You may send large meaningless messages, or you may annoy other party by sending him an Attention every 5 seconds or just sending him meaningless messages 2 times per second.
A user should have a feature, and it's up to him how to use it. If he abuses font or color customization, other party will tell him not to do it or just ban him that or other way.
  5. Sometimes used links[1] to make messages more compact.


Links are great, feel free to automatically link URLs in your messages, I don't think we need a spec for this since most people do it already.
Making text appear as links (without showing the link itself) is only a nice to have that seems like unnecessary complexity to me, but you could certainly write a spec to do it if it's something that you have a real use case for that can't be satisfied by auto linking URLs like most clients do already.

Yes. Embebbed links are useful when link itself is too long and contains no useful information. I beleive that only human friendly content should be displayed in the message and the technical parts (like URLs) should be hidden.
Attaching links via XEP-0066 solves the problem only partially. My client, for example displays link only if there's no <desc/> element. If <desc/> element present, it display it as a link.
But often its much better to put link right where it mentioned in the message. It makes message more compact in makes it more comfortable to user to click on the link just where it sees it in the text without looking for it in the list of attached links below the message or somewhere else.
And XEP-0071 was a good solution for this usecase. And I don't see the reason to invent specification for such a little thing, if we can easily put it into XEP-0394, making it the one to substitute XEP-0071.
 
With my best regards,
Konstantin
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to