Re: Inheritance of column attributes

There are two ways that I have seen to handle situations like column
inheritance.  

1.  In EBT stylesheets for SGML, the expression language on the right hand side
gives sufficient power to reference the COLGROUP elements.  In addition, we
provide canned functions for the common table DTDs.  For example:

      <style name="TD">
          <justification>tableinfo(html)</>
      </style>

2.  In DSSSL stylesheets, there are flow objects for tables which explicitly
deal with the multiple inheritance needed for columns.  If you want to know more
about this approach, let me know.


Jeff Yemin
EBT



>    From: Hakon Lie <Hakon.Lie@sophia.inria.fr>
> 
> |    Scott Preece:
> |    > My point was that what is in the draft is not acceptable.  I understand
> |    > that multiple inheritance is a complication, but I think that for
> |    > tables you have to do something to work around the limitations of
> |    > SGML tree structure.  It is simply not acceptable to have no way to
> |    > affect the styling of an entire column as a unit - changing its
> |    > font-weight or background, for instance.
> |
> |   Assuming that most authors only want to hilite a column and doesn't
> |   care too much about how this is done, setting the borders should be
> |   sufficient.
> ---
> 
> I don't think borders alone are sufficient.  They are inherently
> ambiguous and overloaded, since each border falls between two columns.
> How would you, for instance, *differently* highlight two adjacent
> columns?  Also, an author may want a particular style of highlighting
> because that style is common in a given industry or medium.
> 
> ---
> 
> ---
> |   Also, you can have full control, but the you need to use ID or
> |   CLASS. E.g., your style sheet would look like:
> |
> |     #1a, #2a, #3a { background: blue }
> |
> |   instead of
> |
> |     COLGROUP.thisone { background: blue }
> ---
> 
> Unless I missed something, any solution using the current CSS1
> specification requires that the author tag every cell in a styled
> column.  This is certainly possible, but it is also error prone,
> maintenance-resistant, and author-unfriendly.
> 
> ---
> |   Supporting the latter is a complication, and I don't see it being
> |   superior.
> ---
> 
> Oh, come on.  As  an exercise, go create a sample table with a hundred
> rows and twenty columns, with three of the columns separately
> highlighted, and then tell me you still believe entering tags on 300
> individual cells is not inferior to entering tags on three COLs.
> 
> ---
> |    If you still think this should be supported, could you
> |   suggest a scheme for handling multiple inheritance?
> ---
> 
> I thought I had, in both previous notes: state in the standard that
> for purposes of inheritance of attributes and determining context
> for stylesheet-entry selection, a TH or TD is a descendant of both the
> TR in which it occurs and the COLGROUP and COL defining the column in
> which it occurs, with the COLGROUP and COL being considered more
> specific than the TR.
> 
> Another way of saying this is that, for stylesheet purposes, the user
> agent should act as though a TABLE's COLGROUP and COL elements were
> replicated as elements within each TR of the table and the TH and TD
> elements occurred inside the appropriate COL element.
> 
> As I've also stated before, I believe user agents already have to do
> most of the necessary work of figuring out which colgroup and col a cell
> is associated with, making the additional effort modest.  Perhaps one of
> the browser authors would care to comment.
> 
> scott
> 
> ---
> scott preece
> motorola/mcg urbana design center	1101 e. university, urbana, il   61801
> phone:	217-384-8589			  fax:	217-384-8550
> internet mail:	preece@urbana.mcd.mot.com
> 
> >

Received on Wednesday, 24 January 1996 10:17:49 UTC