Tidy up id and tabindex in docconformance table rows

[carmacleod]

In hopeful preparation for linking into the ARIA in HTML spec from the HTML element specs, need to ensure that row id's in the docconformance table are all present and robustly named, and that tabindex="-1" is consistently added to each row.

For example:

• use hyphens to separate multiple words (for consistency), i.e. anohref -> a-no-href
• add missing id's for figcaption, input-color, param, attr-contenteditable
• fix incorrect id's - input-color -> input-date, input-datetime -> input-datetime-local, source2 -> slot, dd-dt -> dd, dd-dt2 -> dt
• add missing tabindex="-1" for input-color, param
• fix typo - autonomous-custom-elemenet -> autonomous-custom-element
• lowercase - TD -> td
• el-title -> title

Not sure what to do about:

• img-alt, img, img-no-alt... maybe change to img-alt-empty, img-alt, img-no-alt ?
• either append -no-list to input-email, input-tel, input-text, input-url or remove -no-list from input-search-no-list?
• select/select2... maybe change to select-no-multiple-no-size-greater-1/select-multiple-or-size-greater-1 ? (or is that too complex)
• tbody-tfoot-thead - alphabetical order, or logical order (thead before tfoot)?

I will provide an initial PR for this shortly.

[scottaohara]

Thanks @carmacleod.

[carmacleod]

Any opinions on the items in the "Not sure" list above? I could go either way on those.

[scottaohara]

per talking to @carmacleod some more about this offline, reopening for further updates.

[carmacleod]

Decision was to go with:

• el-xx for elements (xx is tag)
• el-input-xx for input elements (xx is type)
• att-xx for attributes (xx is attribute)

Note that this naming scheme makes id's consistent with the HTML-AAM spec.

Also decided that only one id is needed for each element/type/attribute because planned consolidation will place related entries next to one another.

[ZoeBijl]

Also decided that only one id is needed for each element/type/attribute because planned consolidation will place related entries next to one another.

Oef, that sounds dangerous to me. As it stands it’s super easy to link to a specific part. I would regret it if that wasn’t possible anymore in the future.

[scottaohara]

i don't think it will be an issue. also, as work is still going on here, better to plan for what we know is going to be available, vs a bunch of ids that will need changing.

[carmacleod]

Tidying up even more, with a new PR: https://github.com/w3c/html-aria/pull/183

@ZoeBijl For now, the specific direct links are still there. The first link to an element entry uses el-xx, and if there are other entries, they look like el-xx-whatever, and they link to the entry immediately following el-xx.

The only inconsistent one is el-input-text-list, which is being used for

input type= text, search, tel, url, or email with a list attribute

... but that one was inconsistent before, so I don't feel too bad about leaving it like that for now. ;)

I'm sure @scottaohara will figure out a nice way to consolidate those... :) perhaps by creating new el-input-xx-list entries that immediately follow el-input-text, el-input-search, el-input-tel, el-input-url, and el-input-email.