OK, good luck ;-) On 12/5/13 10:47 AM, "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 >> >
