[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] table models [was: Meeting Minutes 7/20/04 -- DITA Technical Committee]
At 14:32 2004-07-21 -0500, Don Day wrote: >Paul Grosso <pgrosso@arbortext.com> wrote on 07/21/2004 01:32:31 PM: > >> HTML table rules are more limited than CALS. The table tag has a frame >> and rules attribute, but you cannot turn rules on and off at the row >> or cell level. >> >> HTML tables are also restricted in column width specifications to just >> unitless integers (implying pixels) or percentages. >> >> The CALS model doesn't have markup to specify cell background shading color. >> >> I think that's most of the non-trivial capability differences. Given that, >> I'd say the CALS model still has the capability advantage. > >What I get from this, however, is that this presentational advantage is only possible for printed format; But that is still an important advantage, no? People are used to "reduced capability results" in HTML, but that doesn't mean they want lowest common denominator for their print/pdf output. > when you output your CALS content using those features to HTML, the carefully crafted point measures and rules get down-converted to whatever HTML can support anyway. If your conversion is willing to use CSS styling, you can get HTML output that reflects the input more closely than you can sticking just to HTML tagging of tables (e.g., you can get rules and in some versions of some browsers get the widths too). > Perhaps the question is not about greatest potential for authoring, but rather about greatest popularity for rendering. Isn't this, though, just the opposite of what you say below about focusing on content rather than appearance? > In that respect, going to the HTML model as source means that PDF loses out on the ability to support those rules and close column control. In a production environment trying to keep authors focused on content rather than appearance, perhaps thats not such a bad tradeoff? I'm a fan of content over appearance, but users usually aren't. I fear folks will say they just have to be able to turn on or off this rule or that or their table just doesn't work. I'd hate to pick a table model that requires loss of information from much legacy data and then have people say that they just can't use DITA because of it. >> I agree. (My most favorite model and the most capable of major models out >> there today is the XSL-FO one!) > >Every real writer I know secretly desires to code raw fo:-namespaced table markup by hand. ;-) It's the only way to fly, man. There's no reason table editors couldn't support the XSL FO table model. But, I admit, few do at the present. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]