Thanks. That should be helpful. I think I'll revisit conflicts once things are more-or-less working…
On Dec 6, 2013, at 2:35 AM, jude wrote: > 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 >>> >> >>
