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 >>>>>> >>>>> >>>> >>> >> >
