On Wed, Nov 4, 2015 at 2:09 AM, James Teh <[email protected]> wrote:

> On 4/11/2015 3:14 AM, Alexander Surkov wrote:
>
> An edge case is a text document, but where the selection start or end is a
> graphic. In that case, I think the returned object should actually be the
> parent and the offset should be the relevant offset of the embedded object.
>
>
> I'm not sure I follow why this is an edge case and where the problem is,
> because if a document has an image as a child, and the document implements
> text interface, then the returned object should be the document and offset
> should be the text offset for embedded character for the image accessible.
>
> I guess it isn't an edge case after all. I was originally confused by
> using child indexes in the case of no text, as this seems strange to me.
>

I'm not sure where we are on this idea. Do you think we'd rather drop it?


>
> I don't quite follow what you mean by *before* the child. So, for the
> second child, would the offset be 1?
>
> opposite :) if the offset is 1 then the selection is right before the
> second child, if the offset is 2 then selection is right after the second
> child and right before a third child.
>
> I don't really follow this. As I understand it, selection starts are
> inclusive and selection ends are exclusive. So, why are we talking about
> "before" a child? If you have 4 children and children 2 and 3 are selected,
> IMO, the start offset should be 1 (the selection starts at the second
> child) and the end offset should be 3 (the selection ends after the third
> child). Maybe this is just terminology; it doesn't really matter so long as
> we agree on the numbers. :)
>

I'm not sure I have clear understanding how values differs for inclusive
and exclusive end boundaries. Can you give me please an example for, say,
when a container has one child and it is selected, i.e selection starts
before it and ends after it?


>
> I'm actually wondering whether, in this case, the returned object should
> just be the relevant child; i.e. startOffset and endOffset are just
> irrelevant.
>
> say, you have an object with number of children, and the selection
> contains the last child only, i.e it starts before the child and ends after
> it. How would you describe the selection having no start/endOffsets?
>
> That's a good point. I agree my proposal can't handle this case. However,
> I'd suggest then that perhaps this interface just doesn't really suit
> selection for non-text cases. We're already hitting confusion with the term
> "offset", and for non-text cases, it seems more logical to me to just have
> a way to enumerate selected objects.
>
> Jamie
>
> --
> James Teh
> Executive Director, NV Access Limited
> Ph +61 7 3149 3306www.nvaccess.org
> Facebook: http://www.facebook.com/NVAccess
> Twitter: @NVAccess
> SIP: [email protected]
>
>
_______________________________________________
Accessibility-ia2 mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2

Reply via email to