Ang: Re: Pictogram support (Montreal Summit)

Thanks for your thorough reply Simon, and sorry for the HTML!

You asked: "(Are Ruby annotations actually widely supported? Do common HTML
implementations like Gecko and Webkit actually implement them?)"

I don't have the full picture, but afaik to a certain degree Webkit and IE do, Gecko (Firefox) and Opera don't natively, but add-ons are available, etc. Anyway: This is the only and best w3c standard around that will (potentially) allow graceful graphical symbol support together with text on standard platforms.

A couple of more link references:


-----Simon McVittie <simon mcvittie collabora co uk> skrev: -----

Till: telepathy lists freedesktop org
Från: Simon McVittie <simon mcvittie collabora co uk>
Datum: 2011-10-31 13:10
Kopia: gnome-accessibility-list gnome org, Mats Lundälv <mats lundalv vgregion se>
Ärende: Re: Pictogram support (Montreal Summit)

On Fri, 28 Oct 2011 at 23:19:15 +0200, Mats Lundälv wrote:
> Thanks both for this
> interesting information about the preconditions for graphics in IM! The
> XEP-0231 specs look quite promising (to an amateur in the techy
> field, as I am)! 
> Another question then: Is there any support currently for 
> Ruby Annotation ("";) in any of these IM
> protocols? 

(Vaguely related to this discussion: please send email to mailing lists in
plain text, not HTML.)

IM protocols that support formatted text usually do so via some subset of
HTML. In XMPP, XEP-0071 'XHTML-IM' includes many modules from 'XHTML
Modularization', although not the Ruby module. A client could include Ruby
markup as an extension, although recipients might ignore the Ruby markup.
I believe Ruby annotations have been designed to make this a reasonable
thing to do (graceful degradation), so maybe that's OK.

(Are Ruby annotations actually widely supported? Do common HTML
implementations like Gecko and Webkit actually implement them?)

I don't know exactly what other protocols support - I believe it's usually
a small subset of HTML, or a proprietary formatting mechanism much less
powerful than HTML. libpurple (Pidgin) converts all of its supported
protocols' formatted text into HTML for display, and converts user-supplied
HTML (from a WYSIWYG editor widget) into the protocol's text formatting
language for sending. We intend to do the same sort of thing in Telepathy,

Telepathy currently only supports plain-text messages, not HTML. We know
how we'd represent HTML messages (via the Messages interface), but the
missing part is to design and implement capability discovery, 
so UIs can enable/show or disable/hide formatting controls as appropriate for
the protocol and recipient, rather than misleading the user into thinking
that unsupported markup will be received and understood.

One important reason to support a small subset of HTML is security:
the only safe way to render HTML supplied by a potentially-malicious
third party is to have a "whitelist" of markup that's known to be safe,
and discard everything else. I don't think XEP-0071 really does enough
to address this, and this is something else that a Telepathy HTML interface
will need to document too.


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