Reply To: colgroup support for HTML tables

[Derek Read]

Including

and

and the attributes they support in an HTML table will not cause any rendering changes in XMetaL Author or XMAX.

The goal of XMetaL's user interface is to provide an easy to use editing environment, not one that matches any particular output format exactly. That having been said, because the products (Author and XMAX) support the rendering and editing of HTML and CALS tables, and because this particular functionalty would be pretty jarring to users if they knew they had this markup but it didn't do anything (did you set it wrong? is the product broken? is the DTD wrong?, etc), it would be nice if both products supported all the basic features of both table specs, including

and in the case of HTML. So, I will log this as feature request with development and ask that they try to find time in the future to implement it.

If anyone else would like to see this feature implemented please let us know (via XMetaL Support) because when we are deciding which features to implement the more people that ask for something the more likely it will be done.

---

One thing I can think of doing would be to use your existing interface (whatever you have created) to allow your users to manipulate the and / or

elements and after the user has changed something there set the same width attribute value on all the corresponding

elements in that column. Assuming you have a script (stand alone or in an XFT) that does the former it would then just be extended to also do the latter. This would be purely for visual effect in XMetaL but it would make things consistent during editing. You would then either strip out any attributes set on that already have a corresponding

or

attribute in On_Before_Document_Save or during your XSLT process (or you don't worry about it depending on what final format you are transforming to from XML).

---

This next part of my response is more of an opinion (mine) and does not actually answer the original question, but I think it might be useful to bring it up.

Tables are a real sticking point for me in XML. Ideally XML should be all about content (that's what everyone constantly talks about anyway) but tables by their inherent visual nature (as we tend to think of them anyway) have a built-in layout and formatting. To me there's an inconsistency here. So, to my way of thinking, ideally, and if at all possible, (and I agree it is difficult) it would be best to format tables during any transformation process because that process can (in theory) be designed to make the best decisions based on the content it is transforming from and the output format it is transforming to. Ideally, ignoring anything the user has set (beyond how many rows and columns and perhaps cell merging) should be used as a suggestion, rather than a requirement.

If you ask yourself the following questions it might help to understand where I'm coming from:
Are there any elements besides

in your DTD or Schema that you allow the author to influence the style of by using markup, or is that styling decided by you and implemented in the most suitable way during the transformation process?

Reply