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: http://en.wikipedia.org/wiki/Ruby_character http://www.useragentman.com/blog/2010/10/29/cross-browser-html5-ruby-annotations-using-css/ Mats -----Simon McVittie <[email protected]> skrev: ----- Till: [email protected] Från: Simon McVittie <[email protected]> Datum: 2011-10-31 13:10 Kopia: [email protected], Mats Lundälv <[email protected]> Ä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 ("http://www.w3.org/TR/ruby/") 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, eventually. 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. S _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
