I'm happy. Thanks for going the extra kilometer. On Mon, Aug 21, 2017 at 3:31 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote:
> > > On 08/21/2017 09:38 AM, Jonathan Gibbons wrote: > >> >> >> On 8/20/17 4:11 PM, Martin Buchholz wrote: >> >>> Again, I am happy to take the current state of this change. >>> >>> On Sat, Aug 19, 2017 at 2:19 PM, Jonathan Gibbons < >>> jonathan.gibb...@oracle.com <mailto:jonathan.gibb...@oracle.com>> wrote: >>> >>> Actually, thead and tbody have no direct significance for >>> accessibility. They provide a semantic differentiation of the >>> content, and provide a hook for different styling, as you have >>> seen for "striped". Also note, although you can have many <tbody>, >>> you can only have at most one <thead>, and at most one <tfoot>. >>> >>> Looking at Summary of BlockingDeque methods again, we have what might >>> logically be a thead in the middle of a table, and the law of "only one >>> thead, and only at the beginning" might be yet another hint that the html >>> gods want us to split this table. This could become a nested table with two >>> rows, one for "first" and one for "last", each of which contains a subtable >>> with a thead. >>> >> >> I can investigate that. >> > > I investigated. > > It won't be a table with two rows; it'll be a table with 3 rows, because > it would need a header row with column headings :-( Also, you wouldn't > have the columns aligned, because of the use of two tables. And so you > might as well go with two separate tables, and the "First"/"Last" labels > moving into captions. > > I guess I'd like to declare victory on the BlockingQueue/Deque tables. > They meet the desired accessibility requirements, which was the primary > goal. Even if they don't get the full "striped" approach, they are at > least visually similar to the original versions in the JDK 8 and JDK 9 API, > with respect to font, centering, etc. > > If we want to continue to enhance the appearance of these tables, we > should take it offline from this review, and do more experiments on smaller > API examples that are faster to turn around. > > -- Jon > >
