On Wed, Apr 7, 2010 at 4:36 PM, Maciej Stachowiak <[email protected]> wrote:
> > It's not clear to me how "PositionIterator" is the same concept as > "EditingPosition". The latter implies that it would only ever represent a > position where you can edit. The former implies that it produces a sequence > of positions (perhaps retaining additional state to be able to step > forward/back efficiently). It also seems to me that it is useful to have a > concept of a Position that is primarily optimized iteration. > Perhaps "EditingPosition" is not the best of names. The basic idea is that we shouldn't need 2 different classes Position and PositionIterator and convert back-and-forth between them. I'm also still not clear on the proposed relation between EditingPosition > and VisiblePosition. Does every EditingPosition have an associated > VisiblePosition? How about vice versa? Is the mapping one-to-one? > That is a good question - it depends how we want to treat stuff like :before/:after content, list items, and such. A renderer-based VisualPosition could technically select/iterate/identify such content, but wouldn't necessarily have a corresponding Editing/DOMPosition. OTOH, an EditingPosition probably would always have an associated VisiblePosition (At least off the top of my head I can't think of a case where the user can edit stuff that isn't rendered). An EditingPosition with reflection or somesuch could in theory have more than one VisiblePosition, but I think that's getting awfully fanciful. However, the immediate idea here is more one of code separation: to put the code that operates on renderers into its separate class. > Safari doesn't make this non-contiguous region a selection. It marks it > with a visual highlight. Only the first hit is actually selected. This makes > a big difference when doing a find in editable text - typing only overtypes > the first hit, rather than replacing the non-contiguous selection. > > Being able to represent a non-contiguous region is interesting, but it > would be UI hell to allow such a thing to actually act as the user > selection, and to get copied and pasted. > FWIW Firefox seems to handle it fine, but I agree that it's probably not used much in practice (apart from column selection as you mentioned). I'm thinking more of feature-completeness vs. the HTML5 spec here, and the aforementioned non-selection highlights. But whether or not to add this should be a separate discussion. > On Wed, Apr 7, 2010 at 3:53 AM, Justin Garcia <[email protected]> > wrote: > >> >> For example: >> >> <div><img style="display:block"><img style="display:block"></div> >> >> [img1, 1] and [img2, 0] are different visually but would both be >> normalized to the same position under the above proposal. >> > > I think this is a great example and shows that normalizing [img, 0] to > [parent-of-img, index-of-img] can probably only happen once styles and > renderers are taken into account, which doesn't strictly contradict Darin's > point though (?). > > > I'm not sure how it implies that. Would you assign a real DOM position > differently between the two styles? > > I think the real difference here is in affinity, i.e. whether the caret > would be at the end of one line or the start of the next. However this > doesn't affect the DOM parent and offset. > > Yes, that's what I meant - the DOM Position itself should obviously not be affected by styles/CSS. This however leads me to a clarification question of my own: The [img1, 1] in Justin's example would be an invalid position, no? Do you mean that (the internal representation of) [img/block, 0] and [img/block, 1] should render the caret at different positions (i.e., the start/left side and end/right side of the block line, respectively)? Or did you mean the case of 2 images (i.e., without a real internal visual position) on different lines? Thanks, - Roland
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
