Can be previewed here: https://raw.githack.com/w3c/epub-specs/feature/add-index/epub33/core/index.html#index

Would it be better if we added to our css

Should this be raised against respec?

It's respec that colours the code tags in the body, so if we manually override the index then we have to keep watch that the respec css doesn't change in the future.

Would it be better if we added to our css

Should this be raised against respec?

It's respec that colours the code tags in the body, so if we manually override the index then we have to keep watch that the respec css doesn't change in the future.

Oops, somehow I always thought that we set the color, not respec...

Yes, that should be a respec issue. Not only for this case; I have added the following entries to our common css files to ensure the right colour when using xref:

code a[data-type~="element"], 
code a[data-type~="dfn"],
code a[data-type~="element-attr"]
{
    color: #c63501 !important;
}

These should be superfluous as well.

Do we want to start by setting it for ourselves and raise an issue afterwards, or just raise an issue? I would be in favour of the former; I do not know whether such an issue would be taken care of with high priority...

Do we want to start by setting it for ourselves and raise an issue afterwards

That works for me. I'll update the PR when I have a minute.

Also: do we want to switch indexing on for RS? It does not define many new concepts, but I also found the generated list of external concept references useful... (I cannot judge the value for the A11y document).

Do we want to start by setting it for ourselves and raise an issue afterwards

That works for me.

Although, looking at the result of adding custom CSS, I'm not so sure it's a good idea. Linked code is now hard to distinguish from unlinked code as there may only be a faint dotted underline. We also get links that are part orangey-red and part blue if they include a code-tagged word with other words. It's really quite messy. It might be better to remove the custom CSS and figure out with the respec/spec-prod folks what should be done.

It does not define many new concepts, but I also found the generated list of external concept references useful...

I'm of the opposite view: it's rather clunky and duplicative. It appears to take the text of every a element and add an entry. If we link to definitions and sections using the same words, we get different entries, although nothing makes clear which is which until you follow the link into the body and then click on that link to see where it goes.

Here's a random sampling I spotted in the RS spec only looking at a few "p" entries:

- package document
- package document
...
- properties
- properties attribute
- properties attribute
...
- publication resources
- publication resources

I'm opting for a middle road on this and adding indexes to the three rec-track specs but removing the CSS link overrides so we have consistent colouring of our links.