[Standards] Suggestions for updates to XEP-0071: XHTML-IM
Peter.Waher at clayster.com
Sun Nov 10 15:37:16 UTC 2013
Thanks for your response. I’ll respond to your comments one at a time:
> 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?
A minimal fallback that would not destroy the contents of the table could be:
* Newlines inserted between rows, so contents for each <tr>..</tr> end up on different rows
* Tab character (\t) between contents of <th> and <td> elements.
Now, \t is not available in HTML, but available in text output. So, if an HTML engine (that somehow does not support tables) is used for rendering, something similar would be great. If not possible, a little space would be the next best, so that content is not concatenated without space.
> 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.)
Correct. However, if people think it is a better idea to create a tabular data XEP for sending tables, that would work, as long as there are client developers interested in implementing such a XEP. Is there any interest in this? My thought was that it would be simpler for clients to add basic table support if they already support XHTML-IM.
> 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.
I just assumed that as these things are already supported they would be automatically included. It is not a requirement, it’s a possibility. The above mentioned fallback is still better than nothing.
Having said that, do you feel there’s an interest in implementing support for a XEP sending table messages that is not based on XHTML-IM?
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2014.0.4158 / Virus Database: 3615/6810 - Release Date: 11/05/13
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards