[Standards] Suggestions for updates to XEP-0071: XHTML-IM

Ivan Vučica ivan at vucica.net
Sun Nov 10 15:20:25 UTC 2013

Hi Peter,

On 5. studenoga 2013. at 12:53:52, Peter Waher (peter.waher at clayster.com) wrote:

> I would however not explicitly require support for tables, as that would imply no IM client could be considered properly compatible with the XEP-0071 without support for rendering HTML tables. 

What could be required is to support the markup (and not reject the XHTML as a whole), and either be able to render a small subset or use a valid fallback mechanism (as that explained in Example 8 in the extension).

That I agree with. It makes little sense to throw the data away.

On the other hand, what *is* a reasonable fallback?

> Perhaps a separate XEP could define support for HTML tables? Or a client could render replacement as strings?

The idea was to avoid a separate XEP just for adding a detail to a XEP that already exists.

The XEP that tries really hard to encourage only basic additional formatting? (To be honest, it seems to me as even image support might be troublesome, requiring HTTP downloads, JPEG/PNG/etc decoders, but a simple text rendering engine almost certainly can insert bitmaps of varying sizes. Table support only complicates the thing further.)

> Proper support for tables could be... complex, especially if a client was not using an existing HTML engine. Consider the very realistic option of using something like Core Text on Apple platforms to draw chat lines. 

This is true. This is why a drastically reduced set is sufficient. Most elements in XEP-0071 are reduced. Just think about what attributes are supported, and how the style attribute has been reduced. From my original mail (which is overly simplified, but explains the general idea):

“The most basic would be support for <table>, <tr> and <td>, perhaps also with <th>. If colspan and rowspan attributes are seen as difficult to implement, they could be omitted. The important aspect here is to be able to output textual information in columns. The text-align attribute would be a bonus, but not required.”

Yes, that simplification is the primary reason why I’m not voicing support to throw the idea of <table> support completely out.

> Maybe the tables should be transferred not using XHTML-IM inside <html/> along with other entries, but using a separate entity directly inside <message/>. How about defining them using a separate XEP? This would allow easy and somewhat formatted transfer of pure data (the intended use for tables) while letting the tables be displayed alternately, similar to data forms. If I can use an NSTableView in place of custom drawing for tables, and if I know that table cells containg only simple oneliners or only simple images, possibly displaying tables in a popup, then adding support for tables on a client becomes very easy.


Wouldn’t that be more work? And less flexible? Say you want to use different colors of text, or use bold, italics, etc. Or images?

Ah! There we go. Colors, bolds, italics, images, etc.

That would mean even MORE work to integrate that in a simple Core Text-based renderer. (Replace Core Text with text drawing API of your choice.) With something like NSTableView, or other toolkit-specific equivalents, you’re relying on the toolkit’s understanding of tables … and doing so optionally, ignoring the <table> element if you want to.

Cell sizes are not all that trivial to calculate. It took a while for „links” to appear to replace „lynx” and bring some semblance of layouts to text-based browsers. As soon as you start complicating that, you’re opening the IM clients for a whole new set of complications.

IM clients already shouldn’t be using HTML renderers, but they do, sometimes not even whitelisting elements. Requiring or encouraging table support would encourage that even more.

Let me put it this way: a solution that would permit tables, but would not require mark a client as noncompliant to XEP-0071, or result in widespread expectation that tables should be rendered, is fine by me. (Not that my opinion needs to be considered.) Anything else means turning requirement for simple formatting support (<b>, <i>, …) into requirement for an HTML renderer and a layout engine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131110/b7dcd3b6/attachment.html>

More information about the Standards mailing list