Re: aria-rowindex and aria-colindex

We need to make sure whatever we come up with also works when aria-owns 
is used to achieve the ordering of cells in a row.
We have a number of instances where the row isn't the DOM parent of all 
the cells within it so we use aria-owns to achieve the relationship. 
This works quite well in FF. aria-colindex needs to support this.
Regards,
James
On 1/29/2015 1:07 PM, Alexander Surkov wrote:
> As I understand it that was original idea but it looks people agreed 
> that it should not be used to override native ordering. The use case 
> was to skip number of rows and columns in the grid/table; there's no 
> consensus yet on markup how to achieve it.
> Thanks.
> Alex.
>
> On Thu, Jan 29, 2015 at 2:31 PM, Bryan Garaventa 
> <bryan.garaventa@ssbbartgroup.com 
> <mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
>
>     I think I’m misunderstanding the purpose of aria-colindex.
>
>     I thought it was to specify X Y coordinates like row3 cell7, but
>     it looks like from this thread that aria-colindex is meant not to
>     do this at all, but to simply specify the number of total columns
>     in a row, is that correct?
>
>     If yes, this doesn’t match the functionality of aria-rowindex,
>     which actually is a Y coordinate.
>
>     *From:*Alexander Surkov [mailto:surkov.alexander@gmail.com
>     <mailto:surkov.alexander@gmail.com>]
>     *Sent:* Thursday, January 29, 2015 9:51 AM
>     *To:* Joanmarie Diggs
>     *Cc:* Dominic Mazzoni; W3C WAI Protocols & Formats
>     *Subject:* Re: aria-rowindex and aria-colindex
>
>     On Wed, Jan 28, 2015 at 4:55 PM, Joanmarie Diggs
>     <jdiggs@igalia.com <mailto:jdiggs@igalia.com>> wrote:
>
>         On 01/28/2015 04:11 PM, Alexander Surkov wrote:
>         > But why? having aria-colindex on cell makes my example
>         possible. It
>         > doesn't look any better than on row.
>
>         >From a conceptual and property naming point of view, I think
>         it does
>         look better on the cell.
>
>
>         In my mind, a "column index" describes the column number in
>         which a
>         given cell is located. In other words, a "column index" is one
>         half of a
>         cell's coordinates.
>
>     I think here's a problem since your description means that cell
>     can be moved all around the table through columns. In particular
>     the web author can do
>
>     <table>
>
>       <tr>
>
>         <td aria-colindex="2">2nd col</td>
>         <td aria-colindex="1">1st col</td>
>
>       </tr>
>
>     </table>
>
>
>
>     Also that means it overrides the native semantics that Dominic was
>     against of. I'd say that the column index is a property of *set*
>     of cells and not a property of an individual cell, thus you cannot
>     override column position on the cell itself and thus the cell is
>     not right place for aria-colindex attribute.
>
>
>         What you're describing seems more like the "first
>         visible column" which, as I believe you suggest in a different
>         response,
>         is a property of the table.
>
>
>         Naming issues aside, let's say we put this property on the row
>         or table
>         rather than on the cell.
>
>
>     right, just attribute on the table to specify amount of skipped
>     rows/columns should be good for spreadsheat use case.
>
>         What then happens if we have a case where there
>         is a gap. Like in a spreadsheet in which certain columns are
>         hidden?
>         What would the value of your property contain?
>
>     I wasn't aware of this use case. If cells are hidden then should
>     be they taken into account when counting? Also I'm curious if
>     doesn't mean that native semantics is overridden by that.
>     Otherwise than that the aria-colindex attribute approach can work
>     here but you have to be very cautious defining this attribute. For
>     example, it would worked out if aria-colindex was allowed on cells
>     of the first row only, aria-rowindex was allowed on rows only.
>
>     But if we don't want to support this use case then I think I
>     prefer properties right on the table element, plain and easy.
>
>
>         --joanie
>
>