OK. I’ll see how it goes...
On Jun 9, 2014, at 9:31 PM, Alex Harui <aha...@adobe.com> wrote: > OK, I guess TLF doesn't really have block elements. I was just wondering > if there would be some problem further down the line. Folks seem to want > to have TLF elements work like HTML elements. > > I was pondering if you next had to support DIV and if block elements > should first be introduced to TLF. So those are some concerns that popped > into my head, but no real objections at this point. > > Good luck, > -Alex > > On 6/9/14 11:21 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> That’s pretty close to what I already did. Table composition is all >> working very well as each table cell acting as a separate TextFlow and >> container. Except extending InlineGraphicElement does not make sense. >> There’s a lot of code in there dealing with loading assets which is not >> applicable to tables. >> >> I’d just subclass FlowLeafElement (which is what InlineGraphicElement >> does) instead of subclassing FlowGroupElement as tables currently do. >> >> If I had to pick between block or inline for tables, I think I’d pick >> inline… >> >> On Jun 9, 2014, at 9:05 PM, Alex Harui <aha...@adobe.com> wrote: >> >>> I'm not an HTML expert, but they seem to divide up their elements >>> between >>> those that default to "inline" and those that default to "block". I >>> think >>> in TLF, SpanElement and InlineGraphicElement are inline and >>> ParagraphElement is "block". I haven't really thought through this, but >>> one possible strategy to make Table extend InlineGraphicElement to >>> reserve >>> space and then then make each cell its own TLF container in that space? >>> Is that sort of what you are trying to do? >>> >>> -Alex >>> >>> On 6/9/14 10:28 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>>> I have not yet implemented arrow navigation (beyond what was there >>>> originally), but here’s my plan: >>>> >>>> * When text outside the table is selected, arrow navigation would treat >>>> the entire table like a single atom (i.e. if the cursor is right >>>> before, >>>> a right arrow will move the cursor beyond the table). >>>> * If text inside a cell is selected, arrow navigation will work within >>>> the cell confines (as a separate TextFlow) >>>> * If a cell is selected, arrow navigation will select the next previous >>>> cell in the row/column. >>>> >>>> #1 and #2 should be working now out of the box. #3 will take a bit of >>>> work getting it to work. >>>> >>>> In HTML, tables are general layout elements similar to divs. I’m >>>> treating >>>> tables much differently. (Each cell is a separate TextFlow.) Trying to >>>> handle tables purely inline had too many challenges for me to >>>> stomach... >>>> Just looking at the spaghetti that was composition and selections made >>>> me >>>> dizzy... >>>> >>>> Treating tables as block elements, requires handling the table content >>>> as >>>> leaf elements. This make composition and selections (especially things >>>> like column selections) very challenging. >>>> >>>> On Jun 9, 2014, at 7:20 PM, Alex Harui <aha...@adobe.com> wrote: >>>> >>>>> What is the leftArrow/rightArrow navigation model when Tables are >>>>> involved? >>>>> >>>>> Also, in HTML, isn't a Table a block-level element? Are there other >>>>> reasons for making it a leaf? Shouldn't Table be more like >>>>> ParagraphElement? >>>>> >>>>> -Alex >>>>> >>>>> On 6/8/14 10:48 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>> >>>>>> My real concern is the fact that findLeaf() is used in so many >>>>>> places. >>>>>> It >>>>>> makes the assumption that you can find a leaf by index anywhere in a >>>>>> text >>>>>> flow. That assumption falls apart with tables. I make a clear >>>>>> separation >>>>>> between tables and their contents. As far as the text flow is >>>>>> concerned, >>>>>> the table has a single index (and can only be selected as a whole >>>>>> when >>>>>> selected with surrounding text). >>>>>> >>>>>> So, unless I go through every place findLeaf() is used in TLF and >>>>>> make >>>>>> special cases for tables, the only way I can see of handling it is by >>>>>> making a table a leaf. Even if I fix all the findLeaf() calls in the >>>>>> framework, I’d still be causing client code to fall apart when it >>>>>> comes >>>>>> to tables. >>>>>> >>>>>> Although tables have cell children, they are not index tracked within >>>>>> the >>>>>> text flow as other children are. I could override the text property >>>>>> to >>>>>> return all text contents of all cells in the table. That actually >>>>>> makes >>>>>> kind of sense. >>>>>> >>>>>> On Jun 9, 2014, at 6:59 AM, Alex Harui <aha...@adobe.com> wrote: >>>>>> >>>>>>> Hmm. The doc says that FlowLeafElement doesn't have any children. >>>>>>> But >>>>>>> Tables can certainly contain other tables, right? And aren't the >>>>>>> headers/rows/cells considered children? >>>>>>> >>>>>>> FlowLeafElement also has a text property. Are you going to be >>>>>>> overriding >>>>>>> that? >>>>>>> >>>>>>> Is it just too hard to make a TableElement extend FlowElement and in >>>>>>> other >>>>>>> ways be treated as an InlineGraphicElement? >>>>>>> >>>>>>> -Alex >>>>>>> >>>>>>> On 6/8/14 12:46 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>>>>> >>>>>>>> Please see this issue. I¹m sure there are plenty of related bugs. >>>>>>>> >>>>>>>> https://github.com/Harbs/TLF-Table-Work/issues/28 >>>>>>>> >>>>>>>> I¹m thinking of changing the base-class of TableElement to change >>>>>>>> it >>>>>>>> to a >>>>>>>> leaf element rather than a group element. I don¹t see any reason >>>>>>>> off-hand >>>>>>>> not to do that, but I very likely might be missing something. >>>>>>>> >>>>>>>> Reason why I think it makes sense: >>>>>>>> >>>>>>>> Basically, I¹m treating a table as an inline object. The contents >>>>>>>> of >>>>>>>> a >>>>>>>> table are laid out in a grid, but largely independent from the main >>>>>>>> text >>>>>>>> composition. It¹s really not much more than a really fancy inline >>>>>>>> object >>>>>>>> (or one that can span across multiple containers). >>>>>>>> >>>>>>>> If anyone can think of a good reason why it¹s a bad idea, I¹d >>>>>>>> really >>>>>>>> like >>>>>>>> to hearŠ >>>>>>>> >>>>>>>> Harbs >>>>>>> >>>>>> >>>>> >>>> >>> >> >
