Export singular table to html as div

[Phil C]

Implement a checkbox option on the "HTML Export Options" dialog: "Export single-cell table as div"

Rationale:

When dealing with html output from H&M, the use of a container that can be given class and id properties is essential to the ability to control styling (via CSS) of some html elements and structures. Lists are but one example. The ideal html container is a div or span. (Although div and span are basically interchangeable, span is generally used only for text because it defaults to "inline", whereas div is generally used as a universal container).

However, "table" is presently the only container structure that a user can directly instruct hm6 to generate. When output to html, a single cell table acts "something like" a div. However, a table comes with tons of excess baggage that has to be worked around when writing CSS. To begin with, there are four levels of DOM containership to deal with (table, tbody, tr, td) vs one level for a div. Secondly, styling of any of these containing elements is inherited by all lower levels, making the css exceedingly complicated to write. Dealing with a div is much simpler.

On the surface, I see no particular advantage of ever generating a single cell html table, as opposed to a div. However, there is no doubt tons of css in use that expects H&M to generate the multilevel table structure. Therefore, to avoid breaking existing css, the feature must be optional.

[Tim Green]

Hi Phil,

I've put it up for discussion and you're right that it would have to be optional. I think it would also have to be optional on a per-table basis, a global setting would also have too much potential to make a mess.

The original rationale behind the use of tables like this was that they were the only reliable cross-platform construct that would work pretty much the same in HTML, PDF, RTF and (when it was still in use) WinHelp as well. Also, in HTML a table is fairly predictable. It will always wrap its content, for example. Whether and how a DIV wraps its content depends on a number of settings, both in the DIV itself and in its parents in the DOM tree. That is fine if you are only targeting HTML, but if you are also targeting other formats with the same document you start getting into a complex and confusing set of differences and exceptions regarding how your container is going to behave in the different formats. Using tables sidesteps that problem for multi-format output.

HTML 5 flex boxes can solve the problem to a certain extent, but there are still enough browsers around that don't support them or support them badly so that they can't be used as a standard option yet.

[Phil C]

Hi Phil,

I've put it up for discussion and you're right that it would have to be optional. I think it would also have to be optional on a per-table basis, a global setting would also have too much potential to make a mess.

Thanks very much. I hope it is considered favorably.

I thought a good deal about the project vs per-table issue before submitting the request. As I stated in my post, I can think of no reason for wanting this anything but project-wide. If you have a specific example, I would love to see it. Although I obviously have no knowledge of the internals, it would almost certainly seem to be easier to implement as a project option than as per-table. From the user perspective, it would be a nuisance to have to set it independently for every table if that was the user's intent.

The original rationale behind the use of tables like this was that they were the only reliable cross-platform construct that would work pretty much the same in HTML, PDF, RTF and (when it was still in use) WinHelp as well.

I assumed that was the rationale, and it makes perfect sense. Which was why I came to the conclusion that having the "table" dialog generate a div was the ideal way to implement it. I see this as conceptually similar to other html-only options.

Also, in HTML a table is fairly predictable. It will always wrap its content, for example. Whether and how a DIV wraps its content depends on a number of settings, both in the DIV itself and in its parents in the DOM tree.

I am baffled as to what you mean by "wrap its content". The use of tables for layout in html has all but vanished among professional web designers. Essentially every pro designer uses div layout, and for the past several years the use of table layout has been considered the mark of a novice. (I note the HM6 templates also make heavy use of div layout, as one would expect.)

However, tables used as tables are certainly important. And as noted above, tables are a universally applicable model, so are useful for targeting multiple outputs. This isn't a request to eliminate tables. It is a request to optionally generate a better html element than a one-cell table.

That is fine if you are only targeting HTML, but if you are also targeting other formats with the same document you start getting into a complex and confusing set of differences and exceptions regarding how your container is going to behave in the different formats. Using tables sidesteps that problem for multi-format output.

I don't quite understand your point. The extensive use of floated images in my project looks like a dog's breakfast in the editor (and no doubt also in any output other than html). The reason is, the project is intended for html only output and the layout depends on strategically placed clear attributes. To simplify inserting these I created three simple styles based on normal. The CSS lloks like:

Code: Select all

    
p.p_clear {clear:both; line-height: 0;}
p.p_clearleft {clear:left; line-height: 0;}
p.p_clearright {clear:right; line-height: 0;}

The document looks exactly as I want in html. I don't really care if it is not suited for other output. Yes, designing a document targeted for multiple outputs can be complicated. I certainly grant you that. But, I don't understand that point as having any bearing on whether or how to provide this as an html-only optional feature. If the point is to consider multiple outputs as rationale for not having an html-only feature, then I suggest image float as a candidate for elimination, based on my project as a prime example. (Of course, I can easily float the images in CSS )

[Tim Green]

Hi Phil,

I am baffled as to what you mean by "wrap its content".

I mean that tables behave pretty much like HTML5 flexboxes, with the advantage that they already work consistently in all browsers. The content of a table will always control the behavior of its container, the contents of a div will not. For some constructs a table is quick, simple and reliable, where achieving the same thing with divs will be much more convoluted. I'm not promoting tables as a general design solution, but there are times when I say oh screw it and use a table to get the job done quickly, and I don't see anything wrong with that.