use of "cover image"

[TzviyaSiegman]

https://w3c.github.io/wpub/#cover

Some in the group expressed interest in allowing the cover to be something other than an image. The cover section is mostly written with the assumption that the content is an image.

[deborahgu]

In the conversation about this, didn't we agree that all of the non-image covers people could thing of, eg ibooks or scholarly paper covers, were still generated images made from non-image content? I mean, it would be cool if they didn't have to be, except we didn't hear from anyone (that I recall) that there's actually a demand for rendering a thing called a "cover" as non-images.

[TzviyaSiegman]

@deborahgu I don't remember. Maybe @atyposh recalls?

[llemeurfr]

The cover may be a raster or vector image, it is still an image. I’m curious to hear from those who’d like some other kind of content, which kind they would see fit the notion of cover: video? Audio? Text?

[laudrain]

@TzviyaSiegman and @deborahgu in the Toronto F2F I find:

Charles LaPierre: Cover’s don’t have to be images.

Non-image covers could still be captured as an image and included as such in WP.

[HadrienGardeur]

A cover could also be HTML + <canvas>.

The New Yorker is a good example, they often have "interactive covers" that would work nicely with a <canvas> element.

[avneeshsingh]

In Toronto face to face we decided to allow use of HTML for cover image. It can have an image with alttext and also animation or video with equivalent text. It is a good approach for accessibility.
The pending issue was regarding use of aria role. The aria role coverimage can be applied to only images as per DPUB ARIA module, how can we extend its usage to other HTML elements.

[danielweck]

Whilst I agree that "rich" covers offer valuable design opportunities (from basic vector images to full-blown animated and interactive visuals), there is also tremendous value in static raster images (for example, to render as dumb "thumbnail" covers in a catalog / library view).

In that light, would the distinction between "cover page" (https://www.w3.org/ns/wp#cover-page) and "cover image" be useful?

[TzviyaSiegman]

I was suggesting an editorial revision of this section. I don't think we need to restrict what can/cannot be a cover or make this complicated.

[mattgarrish]

No, it should be simple just to swap image with resource. Let's not go into dpub-aria here. That's where a distinction between the two would be necessary, as we can't just change cover now that it maps to the img element.

[mattgarrish]

I am now wondering if it's worth making a distinction between a cover "page" and a cover "image", as Daniel suggests. It puts a burden on the user agent to determine what to do with this property if it has no use for non-image resources. If the media type is specified it can attempt to parse out what are images, but what does it do with an html page containing a canvas if it needs something to display in a bookshelf?

Also, if we're allowing multiple cover images to be specified, shouldn't we include a property like the source element's media attribute?

[llemeurfr]

what does it do with an html page containing a canvas if it needs something to display in a bookshelf?

Nothing.

[llemeurfr]

To be more precise, I believe that a standard should not be based on "what if ..." potential features but should be the intersection of the needs of an industry.

[mattgarrish]

what does it do with an html page containing a canvas if it needs something to display in a bookshelf?
Nothing.

Right, so is there value in separating images from "pages" so that we're not overloading the property?

If we're identifying the cover and allowing it to be anything, what are the expectations for its use, in other words? We know how images have been used by epub, but those use cases aren't necessarily compatible with an open-ended concept of the cover.

It feels like a case of overloading if we lump everything together.

[mattgarrish]

Sorry, your second response only showed up when I posted my reply.

[HadrienGardeur]

what does it do with an html page containing a canvas if it needs something to display in a bookshelf?
Nothing.

That's not necessarily true. In the case of RMSDK for example, when the cover image was missing, it generated a screenshot from the first page as a replacement for the cover image.
It doesn't always look terribly good, but that's an example going all the way back to EPUB2.

[HadrienGardeur]

Most browsers have a similar feature for bookmarks or websites that are often visited.

Here's en example taken from Chrome when I open a new tab:

I'm not convinced that we need two separate concepts (cover image + cover page), but we might consider the following fallback option:

• limit cover to an image
• if the cover is missing, fallback to the entry page (which might end up being a screenshot of the entry page for UAs that need a bitmap)

[avneeshsingh]

The use of html container for cover image initially came up due to accessibility reasons. The alttext attribute is provided by img element, it is not present if we use image without html.

Of course group members also mentioned about use of animation and other creative things as cover page.

So, if we are restricting cover image to only image, how can we handle missing alternate text?

[llemeurfr]

I agree that if an author wants to express a cover artwork that is not an image, he can use the entry page to express that. And it also answers to @avneeshsingh 's concern: the alttext, with a full description of a cover artwork, should be expressed in the entry page.

Therefore the cover (a metadata) can still be an image, easy to use e.g. in catalog views; and authors can express their creativity in the entry page, with 100% accessibility.

If the cover image is missing, the most frequent fallback for catalog views will still be a background image (usually a single color) + the ebook title. But if some UAs want to use a snapshot of the entry page, they will be welcome.

[mattgarrish]

So, if we are restricting cover image to only image, how can we handle missing alternate text?

Ideally what we do is separate cover images from cover pages so that, yes, what are called images are restricted to images. EPUB lets the cover image be identified, and it is restricted to images, and this doesn't have major negative implications. It doesn't have to exclude an accessible cover page, but enables user agents to determine one from the other.

Similar to the problem I had with #260 and #266, we need to make sure we don't try to enforce interfaces. We'll never get anywhere with that kind of approach, as, like @HadrienGardeur pointed out above, even if we require HTML a user agent can still generate an image from it. Ensuring interfaces are accessible is certainly important, but it's better addressed by getting user agent designers to follow guidelines like UAAG.

[iherman]

@avneeshsingh

The use of html container for cover image initially came up due to accessibility reasons. The alttext attribute is provided by img element, it is not present if we use image without html.

This is not true any more. In the current draft a cover is expressed via a PublicationLink object in the manifest; this object has a name and a description property, too. These may play the same role as a title and an alt for an image in an HTML element.

[avneeshsingh]

@iherman, are you referring to
"User agents SHOULD NOT use the cover image as the sole means of selecting or accessing Web Publications. A user agent SHOULD use the Web Publication's title and creators as text alternatives for such interfaces."

I would like to clarify that this can be applicable to some cases. The coverimage can be used as an identification symbol for a publication and also as a marketing tool.

This approach would work for indentification symbol. But if cover image is used for marketing then title and creators may not be appropriate text equivalent. We will need a place to add proper description of the image. I am aware that this piece was neglected in EPUB 3, but now we have opportunity to improve it.

[llemeurfr]

@avneeshsingh have you got something AGAINST using the entry page for handling such information ? (cover description which is, as you said, marketing info ... exactly what the entry page can become).

[iherman]

@avneeshsingh this is not what I meant.

In the current draft a cover is expressed as an instance of a PublicationLink object. E.g.,

    "resources"  : [{
        "@type"          : "PublicationLink",
        "url"            : "whale-image.jpg",
        "encodingFormat" : "image/jpeg"
        "rel"            : "https://www.w3.org/ns/wp#cover-page",
        "description" : "Image of a whale swimming in the sea",
       "title" : "image of Moby Dick"
    },{
        …
    }],

(An aside, the current example in the draft does not include the description and title properties, it probably should...)

[avneeshsingh]

@llemeurfr.
Cover page on entry page is fine. My post was for clarification for description of cover image. At the same time I also think that entry page is getting overloaded with many things, coverpage, TOC, pagelist and even more to come. But it is not the discussion topic for this thread.

[mattgarrish]

To try and bring this back to the question at hand: do we need cover images and cover pages identified separately, do we squash them together, or do we stay with the current requirement that the cover be an image (and maybe call the property cover-image for clarity)?

Also, if we're allowing multiple covers to be specified, do we need to consider a property along the lines of the media attribute to make sense of why there are multiple offerings?

[GarthConboy]

My 2-cents (perhaps worth less) is that we need ONE cover-IMAGE for shelving, regardless of what else along these lines is desired.

[deborahgu]

The factors that came up in meetings:

• UAs need quick, infoset access to a cover image for shelf and thumbnail display
• UAs need straightforward guidelines to know when a cover image is to be displayed, aside from UA-specific design decisions
• Accessibility needs a way to describe cover images, possibly in a richer way than just based on descriptive metadata
• Publication creators really, really, need to not have the current EPUB status quo, where there's a black art to knowing how to add a cover image so it will display, in all major UAs, in all the desired locations (eg. shelf view, as first page of open book, etc.)
• We have agreed on the necessity of non-image covers. (I'm not one of the people who thinks this is important, but we've agreed on it.) But we still need an easy way for UAs to do all of the above.

tl;dr answer for @mattgarrish: We should spec a cover image (with title and description, as Ivan showed, we should spec a cover page, and we should write very clear non-normative suggested guidelines:

• for creators, what to do to get covers to display in certain ways
• for UAs/reading systems, what to do in the absence of a cover image or a cover page
• for UAs/reading systems, what to do in the presence of both a cover image and a cover page, especially if they conflict
• for UAs/reading systems, the difference in expected display between "cover image", "cover page", and any included splash cover info in the HTML. (I know this one seems like it goes without saying, but all we need to do is look at existing Epub reading systems to know that it doesn't. In order to meet the needs of publication creators, we have to give guidelines to make a reasonable set of shared expectations.)
• for UAs/reading systems, how to cope with accessibility (this one won't be normative, but if we write a "WP Accessibility" to parallel "EPUB Accessibility", which we absolutely should, it might become so in that context.

[mattgarrish]

I'm trying to focus on the infoset at this time and leave the user agent expectations for when we flesh out that section. The cover image property definition is not the right place to define how to use a cover image in a bookshelf, for example, especially when we haven't defined bookshelves yet. Nor is the infoset the place to define splash screens for cover pages, which may be a conflation of possible EPUB 4 behaviour.

That I think they're inappropriate in the infoset is not a statement on whether we might need to define such features later. They just don't belong in this section, just as the table of contents property does not define how to present the table of contents, only how to locate it.

My impression so far is that:

1. we keep cover as defined but change the name to cover-image
2. we disallow more than one cover image unless we work out the details of how to differentiate why there are multiple images available
3. we introduce a cover-page property that accepts a single url (although the use case for this remains unclear to me)

Including some verbiage on how to create a cover image if one is missing is fine, although I suspect we won't be able to do more than provide suggestions, as we have elsewhere.

Is there agreement on the above points, at least as a means of moving the infoset/manifest requirements forward?

[danielweck]

Matt, this looks good.

Although if I am nit-picking, these two points seem to contradict each other:

"leave the user agent expectations for when we flesh out that section"

"Including some verbiage on how to create a cover image if one is missing"

[llemeurfr]

I still don't see any need for a cover-page property, as the html entry page can (should?) include a cover artwork in any format, with a high level of accessibility. A cover-page would be a duplicate of this entry page is most (all?) cases.

If we finally agree on this, I see not real need to rename cover (better to define it as a rester image) and to allow for multiple images (optimization of the image resolution can be achieved by resizing, client side, or based on modern multi-resolution image formats).

Re. file formats, we'll have to agree on which formats are accepted. JPEG, PNG, GIF for sure. Animated GIF also? HEIF already?

[llemeurfr]

By the way I forgot to mention that if an author wants to include a "cover page" as the first item in the reading order, he does not need any additional spec: he will just create an html page, include the cover (which maybe simply be the cover image, full-screen), and place it first in the reading order.

[mattgarrish]

these two points seem to contradict each other

I don't think so. We're talking about populating the infoset information, so if a cover image isn't present then stating how one might be created for the infoset isn't different than how we've explained how to populate other properties when they're missing. We shouldn't get into how to use the cover in any specific scenario in the infoset, or what to do if it isn't available (and can't be generated).

I see not real need to rename cover

My problem with leaving it as "cover" even if we don't identify pages is that the note in the manifest section says we're proposing "cover-image". We should be consistent. And given how deeply most people read specs, "cover-image" is far less like to be misapplied than "cover".

if an author wants to include a "cover page" as the first item in the reading order, he does not need any additional spec: he will just create an html page

This is what I'm unclear about. What purpose does identifying a page serve in the infoset, assuming the cover even is available as a separate page? I think we agree now that having an image identified doesn't mean that alternative text and descriptions can't be provided, so that use case isn't relevant in my opinion. It could allow things other an images to be used, but it's also not clear whether that is relevant or not. As you say, the cover in the default reading order can be much sexier than an image, but experience seems to suggest that user agents want something static to work with. Leaving it to the user agent to generate the image is asking for sub-optimal results.

[HadrienGardeur]

we disallow more than one cover image unless we work out the details of how to differentiate why there are multiple images available

1. Multiple formats

{
  "url": "cover.jpg",
  "rel": "cover",
  "encodingFormat": "image/jpeg"
},
{
  "url": "cover.svg",
  "rel": "cover",
  "encodingFormat": "image/svg+xml"
}

2. Multiple resolutions

{
  "url": "cover.jpg",
  "rel": "cover",
  "encodingFormat": "image/jpeg",
  "height": 400,
  "width": 250
},
{
  "url": "cover-large.jpg",
  "rel": "cover",
  "encodingFormat": "image/jpeg",
  "height": 800,
  "width": 500
}

3. Covers variant (comics)

{
  "url": "cover.jpg",
  "rel": "cover",
  "encodingFormat": "image/jpeg"
},
{
  "url": "cover2.jpg",
  "rel": ["cover", "https://schema.org/variantCover"],
  "encodingFormat": "image/jpeg"
}

[TzviyaSiegman]

Conclusion at meeting on 23 July: publish spec using "cover' (i.e. document that can include image or anything else). We will assess feedback after this draft has been in public for some time.

[mattgarrish]

Shouldn't the identifier then be changed to: https://www.w3.org/ns/wp#cover ?

[TzviyaSiegman]

Shouldn't the identifier then be changed to: https://www.w3.org/ns/wp#cover ?

yes

[TzviyaSiegman]

@mattgarrish and @iherman I think this issue has been addressed?

[mattgarrish]

The note we added about a lack of consensus references this issue. We should probably keep open until we're ready to say once and for all what cover can reference, or are you proposing that we go with anything?

[iherman]

This issue was discussed in a meeting.

• RESOLVED: close #261

View the transcript

Wendy Reid: #261
Wendy Reid: #261: use of “cover image”
Ivan Herman: ‘cover’ is a structural property in the manifest
Leonard Rosenthol: cover is optional?
Ivan Herman: yes
Wendy Reid: any objection to closing this?
Ralph Swick: [none expressed]
Garth Conboy: we have to update the editor’s draft now to close it
Ivan Herman: yes; that’s the mechanics
Resolution #4: close #261

[llemeurfr]

This is resolution by exhaustion. With the current state of the resolution, the resource tagged as cover may be anything (html, svg, jpeg ...).

We've seen in this thread that:

• reading systems NEED a cover-image for populating a catalog of stored publications, along with a title and one or more authors.
• most reading systems won't even try to process html to get such cover-image (the cost of creating an image rendition of an html document is really high). They will fall back to a "white" cover created from the title and authors.
• allowing every type of resource as a "cover" will provoque round-trip issues with EPUB 3 (which expect a cover-image).
• accessibility (alttext) is not the rationale for allowing html here (the link to the cover has a title and description)
• nobody raised the need for a specific tag identifying the cover-page (html) from the manifest. The cover page is usually the first item in reading order and everybody seems fine with it.

My take is that this decision is a step toward LESS interoperability between implementations of the spec, not more. I would therefore like this issue to be reopen, if others also think the current solution is not optimum.

[danielweck]

@llemeurfr in the current draft, multiple "covers" are allowed (rel = cover), using any appropriate "media type" (encodingFormat), and optional "variants" metadata (e.g. width, height).

https://w3c.github.io/wpub/#cover-infoset

More than one cover MAY be referenced from the infoset (e.g., to provide alternative formats and sizes for different device screens). If multiple covers are specified, each instance MUST define at least one unique property to allow user agents to determine its usability (e.g., a different format, height, width or relationship).

Examples:
#261 (comment)

There is however no conformance requirement for at least one image-type cover, i.e. rel = cover + encodingFormat = image/xxx (which includes image/svg+xml, not just raster bitmap formats).

This is fine, right?

[llemeurfr]

@danielweck not really.

Having alternative renditions of a cover image is good. The issue has only to do with the html variant which is allowed now.

If a WP only contains an html cover, most UAs will use the title and authors to compute a simple cover image, as usual today.

Even if he also provides raster images as alternatives, the link to the html cover will be of no use, to the deception of its author. An author who may have done it for a11y reasons, a false assumption because the spec recommends to use the title and description for that purpose.

IMO we should not make an experimental feature a standard. This what we are doing with an html structure for "a resource that user agents can use to present the Web Publication (e.g., in a library or bookshelf, or when initially loading the Web Publication)"

[danielweck]

@llemeurfr I want to get to the bottom of this too, so allow me to play the devil's advocate here. Content creators make informed decisions, right? :) ... Such as deliberately choosing to author a full HTML "image wrapper" (i.e. rel=cover + encodingFormat=text/html) instead of ; or ideally in addition to ; the simple-but-probably-more-than-adequate rel=cover + encodingFormat=image/* with name and description properties.

The rationale for including such HTML-cover in a Web Publication may indeed be based upon accessibility considerations (typically, for long / extended descriptions), in which case production guidelines / good practice documentation (which may in fact be inlined in the WP specification as non-normative statements) should clearly explain the implications with respect to reading system support. For example, a typical bookshelf implementation will (typically) ignore the HTML wrapper, as it will look for a plain raster image with optional name + description metadata ... but a reading system would be able to "discover" the enhanced HTML cover, and offer a direct link to it, either as part of the readingOrder or as an adequately dedicated rendering viewport for non-spine resources.

Note that this HTML-cover feature could also be useful for an animated and/or interactive cover page ... which brings me to your statement "we should not make an experimental feature a standard": I think that this comes down to the Web Publications use-cases / requirements ... if indeed the UCR does not mention any of the aforementioned scenarios (or similar), then in my opinion the WP specification should not overload the commonly-understood definition of "cover" (i.e. image) with the open-ended concept of "cover page".

So, is there value in enabling a reading system to discover a "cover page" in addition to ; or as a replacement for ; a "cover image"? ( time machine: #261 (comment) )