I would reference the W3C spec for a few reasons. One you almost starting from scratch because it's not yet functioning and two, the author of what has been done may have been referencing it in which case you'd find out soon enough.
I've found a lot of valuable information when I was looking up accessibility support in HTML. They have a section on border conflict resolution here, http://www.w3.org/TR/CSS21/tables.html#border-conflict-resolution. As far as DTP support goes, I would think that a product like InDesign would require more fidelity. Since the HTML spec for a Table tag is mainly for viewing multidimensional data it may lack the considerations that a Flex application may require. But would you be using TLF tables for editing? It may be something like the Label and RichEditableText components where you have one that is for display and another that supports more advanced features. Like Alex said, it's more what your goals are. On Thu, Dec 5, 2013 at 12:47 PM, Harbs <harbs.li...@gmail.com> wrote: > > On Dec 5, 2013, at 7:28 PM, Alex Harui wrote: > > > > > > > On 12/5/13 12:11 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > > >> Okay. To sum up: > > I'm not sure I picked up on whatever point you were trying to make with > > the HTML table examples. > > There were two points. > > One was the existence of column groups for setting column styling. I'm not > sure I see any advantage to that over setting the columns directly > > The second one was table head, table footer and table body elements. The > advantage of those would be being able to set all the body cell properties > in the table body element. Of course, the same thing could be accomplished > by setting the table properties and overriding them for header/footer rows. > > >> I need some take-aways from this. > >> > >> 1) Do we care to style TLF tables after HTML so the above markup will > >> render? If yes, we probably want table body, table header and table > >> footer elements, as well as column groups. > > Would be nice, but for now, just make the code do what you want it to do. > > I kind of doubt anyone has used TLF tables so I'm not sure anyone will > > notice if you change existing behavior. > > I really doubt they were used because they don't work… ;-) > > I'm thinking of leaving out these elements and if we want to support the > markup, we could just parse the markup and apply the styling. (or add the > elements later on) > > >> > >> 4) I'm not sure how to handle border settings. What do I do if cell #1 > >> has a 3 pixel border on the right, and cell #2 (to the right of that) > has > >> a 1 pixel border on the left? Do I draw a 3px line (higher number)? A > 1px > >> line (lower number)? A 2px line (the average)? or a 2px line ((higher/2) > >> + (lower/2)? (I'm not sure there's any difference between the last two > >> options.) > > I could definitely be wrong, but I thought that either you draw both or > > the CSS folks might have some rules on this specified somewhere, like > > their rules around margin handling. I think in HTML, there may be a > > default margin between cells that would allow both borders to show with > > some space between them. Flex doesn't support margins and means that > > these things can draw on top of each other, but maybe that's still the > > right thing to do. > > I think HTML and DTP application take very different approaches here. > Word, for example draws the wider of the two lines. Vertical lines are > split between the two cells, while horizontal lines have the top of the > line aligned with the top of the cell. OpenOffice has a mixed approach > where the top and bottom lines take the wider stroke. Vertical strokes > follow the left cell. Although, I'm not sure how it works internally. It > could all be a UI thing… As usual, I like InDesign's behavior. Line weight > is always split between cells. Again, I'm not sure how conflicting > weights/colors are handled internally. > > None of the aforementioned apps have gaps between cells. I have no need > for them. Should I care? > > One way I can handle things would be for each cell to have their own > borders. So, if cell #1 has a 1pt border and cell #2 has a 1pt border. > Assuming there's no gap between them, a 2pt border will be drawn between > the cells. If there's a 1pt gap, there would be a double line between them. > As I'm writing this, I think this does make the most sense. It should offer > the highest level of flexibility, and we don't need to deal with conflicts. > > > -Alex > > > >
