Title attribute on the links object about epub31-bff

[rdeltour]

I've not followed the latest discussions but what's the use case for this title attribute? Why not use the HTML document title?

Also, how to specify the language, text direction, etc? See the W3C i18n best practices.

[HadrienGardeur]

We have a JSON serialization, not all documents will show up in HTML. It's a best practice to have a title attribute on links, since this is the best way to present them to the user if we need to.

But depending on the context, it might or might not be important to require a title, I think that's precisely what we're talking about here.

[rdeltour]

It's a best practice to have a title attribute on links, since this is the best way to present them to the user if we need to.

If you say so... but I'd be interested in reading a study or article that backs this up :)

But you haven't answered my questions:

• what's the use case?
• how to deal with i18n issues? (text direction, language, etc).

[HadrienGardeur]

Studies and articles?
If the title attribute is the only place where you can provide that information, I'm not sure what you'd like to compare it with.

Let's take an example in another standard: Atom.
In Atom, I can provide a number of links for each entry. In OPDS we use that as a way of offering navigation in a catalog: I'm looking at an entry that describes a book, and the links point to books in the same series or the same author in that catalog.
The title attribute on the link is tremendously helpful here, since without it I wouldn't be able to display that link to the user.

In BFF, we could also have similar situations where the links element is the only place where one can actually provide a title or any kind of user facing information at all.

For example, if a BFF links back to multiple versions of a classic EPUB (let's say 2.0 and 3.1, or a fixed layout vs a reflowable one), this could help the user in order to select the right one.
BFF could also provide something similar to what OPDS provides: navigation to other publications or places in a catalog.

Another example that has already been provided are images in spine for comics. Right now, having to wrap them in HTML feels very strongly like an unnecessary burden and makes EPUB quite an unattractive format for that community. If we could simply include them in the spine and force them to use a title instead, this would be much more inline with expectations for a comic book format.

[rdeltour]

Studies and articles?
If the title attribute is the only place where you can provide that information, I'm not sure what you'd like to compare it with.

Precisely. You said "It's a best practice to have a title attribute on links" and "this is the best way to present them to the user". I just don't know that this is true in general: there are certainly plenty of formats that include links with no titles, when there is no need for these links to be presented to humans.

So my question (which was sincere and not rhetorical) was about why we needed a human-facing representation of these links. And you just gave a couple of them later in the comment, thanks (sorry if I missed that from previous discussions, I didn't attend the last call).

While I'm personally not convinced that these are valid use cases (see #17), I won't fight this if there's consensus already.

My comment on the need to look at potential i18n issues still holds.

[HadrienGardeur]

I actually have a hard time thinking about a format where there's no such human facing representation.

HTTP headers, HTML, Atom, RSS, HAL and many others include a title for their equivalent of link.

[dauwhe]

I wouldn't expect anyone to need titles for fonts, most images, javascript files, etc. And I would like to hear more about use cases where we'd need to present humans data from the manifest that isn't in HTML or other formats actually designed for humans. I can easily see needing titles or labels for renditions to help with rendition selection, but I'm skeptical of the general case.