Re: [Standards] XEP-0394: too weak to replace XEP-0071

[Kozlov Konstantin]

Hello!

 

19.03.2018, 11:01, "Jonas Wielicki" <jo...@wielicki.name>:

On Freitag, 16. März 2018 12:11:31 CET Kozlov Konstantin wrote:

 Yes. CSS is really a hard part. But we don't need full support of CSS for IM
 message styling. Maybe it's better to simplify XEP by specifying a small
 subset of CSS rules needs to be implemented, as it was done with XHTML tag
 subset?

XEP-0071 already did that. This doesn’t save an application from having to
parse all inline CSS and sanitize it, which is the hard part.

Well... In my application I have XHTML parser, which I wrote myself. It uses QDomDocument as XML parser framework.

The whole parser is one CPP with less than 3 thousand lines. And it parses both XHTML and CSS.

Of course, it has limitations, but it's enough for the most use cases.

I wonder how lazy developer should be to use existing XHML/CSS library instead of writing his/her own simple parser like I did?

 

 But I don't like the idea of sacrificing ability to compose rich
 text in WYSIWYG editor in favour to "accessibility". Yes, anyone is annoyed
 when interlocutor sends messages abusing rich text formatting. But you can
 abuse any good feature. WYSIWYG is always preferred by end user.

This is true, and in general, '394 does not prevent you from creating a
WYSIWYG-style editor. If you are concerned about the weak definition of
"emphasis", I think it would be fine to say it SHOULD be italic/bold (weak vs.
strong emphasis respectively).

This will allow WYSIWYG to work in *most* cases, and where it does not
represent exaclty "what you get", there will be good reasons for that.

Once again. It's really strange to call WYSIWYG an editor, which do not even allow mo to choose between bold and italic?

When it comes to WYSIWYG reach text editor, every user thinks about three things:

1. Text color: background and foreground

2. Font: name and size.

3. Decoration/style: italic, bold, underline, strikeout

 

Almost every rich text editor has buttons for this. And every user knows what are they for. And almost every user has experience of using them.

Now you are talking about removing most of them. Because of far-fetched problems, you add restrictions which do not allow user to specify text style: bold or italic or underlined or bold italic or italic underlined and so on. Use may only specify some "emphasis" without even knowing how it will be displayed on the other side.

When it comes to fonts, the situation is even worse. I'e already given an example with a postcard. You deprive the user of the ability even to please his interlocutor with a beautifully designed message.

Noone deprecates using HTML markup in e-mails, where the same problems may occur. Noone deprecates HTML itself. But HTML itself allows to compose documents with the same problems. So, why do you think that IM users should be restricted?

 Especially
 when it comes to messaging. Especially on mobile devices, where you need to
 switch between different keyboards every time you want to type special
 characters like ',~,`{},_,* and so on.

This was never and will never be a necessity with '394. A client *may* choose
to offer this as a way to input text, because many are used to this from other
(albeit probably non-mobile-centric) messengers.

Yes. Client may choose. But there is no way to display such "emphasis" correctly if we don't even know how it will be displayed on the other side.

 

 Yes, I'll be annoyed receiving a lot
 of messages with strange fonts, different font sizes and colors. But for
 many years of exploiting XHTML-IM enabled client I never was in such
 situation, 'cause most of the people in this world are adequate.

I am in this situation every other day because stupid clients allow people to
paste XHTML from websites. Websites tend to default to black-on-white. My
client is white-on-black. Now I get black on black. Neat!

So, because of your local problem you decide to forbid the feature at all? Nice solution.

This is of course primarily an issue with my receiving client, which should
prevent this from happening; except that it can’t know the background color
because it runs in a terminal. It would have to set the background color,
which has other portability issues in itself (i.e. it would also have to set
the foreground color and thus ignore all the theming settings I do in my
terminal).

On the other hand, the XEP-0392 (Consistent Color Generation) implementation I
wrote for that client works just fine; which is why I’m confident that
XEP-0394 using XEP-0392 hues would be a great middle-way to this.

Yes. That may be a solution.

But I'm sure you gone too far in restricting a user. At least bold/italic/underline/strikeout must be allowed to be specified explicitely. As well as font family and font size.

 

With my best regards,

Konstantin

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________