Problems caused by <a> markup used for index markers

[yucca]

The command Ctrl+Shift+X creates an element of the form<a class="sigil_index_marker" title="...">...</a, and creating an index then causes an id attribute to be added to the element. While this is formally valid, it causes problems in Adobe Digital Editions, which handles any <a> element (even without a href attribute) as a link, displaying it in a link-like manner.

I though I had fixed this in CSS:

.sigil_index_marker {
text-decoration: none;
color: inherit;
cursor: text;
}

Now I was told that this does help in iBooks, which still shows the markers using a link color. Maybe this can be fixed by using black instead of inherit, but this is an ugly fix, and I cannot test this directly.

I wonder if Sigil could be changed to use <span> instead of <a> for the index markers. This would avoid the problem and would be better in accordance with modern HTML style. I guess the difficult part would be to create compatibility, but I would expect that simply changing any <a> in class sigil_index_marker to <span>, when opening an existing .epub, would handle this.

[Hitch]

Originally Posted by yucca

The command Ctrl+Shift+X creates an element of the form<a class="sigil_index_marker" title="...">...</a, and creating an index then causes an id attribute to be added to the element. While this is formally valid, it causes problems in Adobe Digital Editions, which handles any <a> element (even without a href attribute) as a link, displaying it in a link-like manner.

I though I had fixed this in CSS:

.sigil_index_marker {
text-decoration: none;
color: inherit;
cursor: text;
}

Now I was told that this does help in iBooks, which still shows the markers using a link color. Maybe this can be fixed by using black instead of inherit, but this is an ugly fix, and I cannot test this directly.

I wonder if Sigil could be changed to use <span> instead of <a> for the index markers. This would avoid the problem and would be better in accordance with modern HTML style. I guess the difficult part would be to create compatibility, but I would expect that simply changing any <a> in class sigil_index_marker to <span>, when opening an existing .epub, would handle this.

You certainly don't want to use black--not because it's an ugly fix, so much, but because that means that anyone who tries to read the book in Night Mode will be screwed. They won't be able to read the text.

Myself, I think this is a very small price to pay for the usability of the links. The reader needs to know what they are linking to, in addition to the functionality of jumping back and forth. How are you marking the indexed text, anyway? I mean, assume that you replaced the a's with spans--arguably, those would be invisible to the user, right? When the user jumps from the index to the indexed item, how on the page or pages would you propose that he knows where his eye is to go? If you are using an index that is somewhat like a TOC, and you are linking to named headers, I suppose that is less of a concern for you, but say you are linking to a conceptual paragraph--how would the reader know which paragraph on the page is related to that index item, just out of curiosity?

I'm curious from a functionality standpoint. I assume you mean that each span would have its own ID...you could, you know, just do it quasi-manually. You could do all the indices, and then regex the targets to spans, I suppose? That might work, and you could style the spans as you wished, assuming you have a particular styling in mind.

OR...it could just be that your base a styling is already set, or you haven't set it. Can you change your base anchor link styling, or do you need the blue links or (default display) link behavior elsewhere?

Hitch

[Jellby]

Originally Posted by Hitch

I mean, assume that you replaced the a's with spans--arguably, those would be invisible to the user, right? When the user jumps from the index to the indexed item, how on the page or pages would you propose that he knows where his eye is to go?

Just as with paper books: just search for it, the page is not so large (even less so with typical ebooks). In general, an index is a kind of secondary feature, it should not make the reading experience more inconvenient.

Anyway, if you want to mark with colors the index targets, you can do it with spans too.

[Hitch]

Originally Posted by Jellby

Just as with paper books: just search for it, the page is not so large (even less so with typical ebooks). In general, an index is a kind of secondary feature, it should not make the reading experience more inconvenient.

Anyway, if you want to mark with colors the index targets, you can do it with spans too.

Yes, but, wasn't not having color the same problem the OP was trying to solve in the first place? Otherwise, simply changing the color would be simplicity itself, no?

Hitch

[Jellby]

Originally Posted by Hitch

Yes, but, wasn't not having color the same problem the OP was trying to solve in the first place? Otherwise, simply changing the color would be simplicity itself, no?

As far as I understood, the OP wants the anchors to be "invisible", and the problem is even with "color:inherit" iBooks adds some color to <a> elements. The suggested solution is using <span> instead of <a>, which would not produce any default formatting, and I don't see any drawback other than the loss of semantics.

Of course, the real solution would be to fix ADE and iBooks to not apply any default formatting to <a> elements without href (at least).

[Hitch]

Originally Posted by Jellby

As far as I understood, the OP wants the anchors to be "invisible", and the problem is even with "color:inherit" iBooks adds some color to <a> elements. The suggested solution is using <span> instead of <a>, which would not produce any default formatting, and I don't see any drawback other than the loss of semantics.

Of course, the real solution would be to fix ADE and iBooks to not apply any default formatting to <a> elements without href (at least).

LOL, Agreed, but somehow, I don't expect that Adobe and Apple are reading this thread and responding to our every wish, Jellby! ;-)

In any event, we gave the OP a few ways to work around it.

Hitch

[yucca]

Originally Posted by Hitch

Myself, I think this is a very small price to pay for the usability of the links.

It is a high price to pay when the text has colored words with no understandable (to the user) reason. And it does not increase usability. Rather the opposite. The words are not links, so showing them as if they were is misleading and confusing.

The reader needs to know what they are linking to, in addition to the functionality of jumping back and forth.

In hypertext, such things are normally not indicated at all. Maybe they should (and you can do that in CSS nowadays with :target, though I’m afraid e-book readers won’t support it), but definitely not in a misleading manner that shows something as a link when it is not.

I assume you mean that each span would have its own ID...you could, you know, just do it quasi-manually.

Of course. The question is whether Sigil can be improved so that such clumsy fixes are not needed. This would just be a matter of changing the name of the tags generated, from “a” to “span”, when generating index markers (which are supposed to be link destinations, not links).

Can you change your base anchor link styling, or do you need the blue links or (default display) link behavior elsewhere?

Changing the styling of all links would be a wrong way to fix the problem that some non-links look like links. Of course links need to be different from normal text.

[yucca]

Originally Posted by Jellby

As far as I understood, the OP wants the anchors to be "invisible"

Right, similar to normal text. An “a” element with no “href” attribute is not expected to affect rendering at all; and the problem here is that it does, on some e-book readers.

and the problem is even with "color:inherit" iBooks adds some color to <a> elements.

Yes, probably because in iBooks, CSS support does not cover “inherit”.

The suggested solution is using <span> instead of <a>, which would not produce any default formatting, and I don't see any drawback other than the loss of semantics.

The only drawback that I can imagine is how to deal with existing e-books that have index markers as “a” elements. If an author’s CSS code styles them somehow, the styling might thus get lost. But I think this is a small risk.

Semantically, an “a” element without “href” is just as empty as “span”. It has no meaning beyond the meanings of its attributes, i.e. it is just a text-level carrier of attributes. And according to HTML5 CR, which is virtually the de facto HTML standard, more or less, “If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant, consisting of just the element's contents.” So it’s OK to use such an element in a navigation menu, for the item that would be a link to the current page, and is such a link on other pages. But the use of “a” without “href” just to mark a destination for links hardly fits into the definition.

[Jellby]

Originally Posted by yucca

And according to HTML5 CR, which is virtually the de facto HTML standard, more or less

Note that ePub 2 uses XHTML 1.0 (or 1.1, I forget). This irrelevant for the current issue, though (I mean, the HTML5/XHTML distinction, not your comment).

[Hitch]

Originally Posted by yucca

It is a high price to pay when the text has colored words with no understandable (to the user) reason. And it does not increase usability. Rather the opposite. The words are not links, so showing them as if they were is misleading and confusing.

Then wouldn't the simpler answer just be to add the words to the Index editor, and build your concordance/index from there? You may not want every instance of the occurrence indicated, but it completely solves the linking issue. The paragraph containing the relevant word gets marked with an index id--no links or indicators thereof. You'd want to add it to the index editor as you went through, instead of using the "Mark for Index" functionality.

Then, if you want to remove some instances, simply remove them from the index page in html. Is it a tad clunky? Yes, if you have numerous instances that you don't really want marked or included in the index, but it does solve the underscore-color issue and allows you to create a linked-from index in Sigil without the reader confusion, or by having to do it by hand.

This actually works the same way (concordance-like) that most word-processors work; you indicate a list of terms, the word-processor finds all instances, and you build it last. The other method also works like most word-processors--even if you can't see it in the WYSIWYG, the x-ref marking is certainly there.

FWIW, for anyone who comes along after, reading this thread, regexing the target a id's to spans works fine, and the book functions properly, and doesn't have any marking in ADE or iBooks. You may wish to consider doing the index editor-method when you have a single file, which means all your id's are sequential, but for very heavily-indexed books, you may prefer that each chapter restarts numbering, (which is what it does with each XHTML/HTML file, so you get links that include the filename and the id, e.g., "Chapter_0006.xhtml#sigil_index_id_1" as the a href link to.

In hypertext, such things are normally not indicated at all. Maybe they should (and you can do that in CSS nowadays with :target, though I’m afraid e-book readers won’t support it), but definitely not in a misleading manner that shows something as a link when it is not.

Agreed, but the alternative, obviously, is to build it by hand. It still seems far simpler to me to simply complete the index and then regex the entries, which you could create a clip for and do in mere minutes. As we've all learned that user_none is not going to be making any further major changes to Sigil--and we may need a new maintainer--this is likely to be your best solution. It's certainly going to be your fastest. I've tried a number of alternative solutions, but none of them eliminate the underscoring issue, at least, not without making it more work than it would be just to create the index by hand.

Of course. The question is whether Sigil can be improved so that such clumsy fixes are not needed. This would just be a matter of changing the name of the tags generated, from “a” to “span”, when generating index markers (which are supposed to be link destinations, not links).

See my comment above.

Changing the styling of all links would be a wrong way to fix the problem that some non-links look like links. Of course links need to be different from normal text.

I was asking--not suggesting. Some books have links; some don't. However, if changing the styling of the a elements won't solve the problem in any event, then it's a moot point, right? I agree it would be the "wrong" fix, but using "wrong" fixes to deal with various retailers that don't necessarily follow the standards is something that we've all had to deal with, when making books for commercial purposes.

Hitch