Meeting minutes
PR 2788 - w3c/epub-specs#2788
wendyreid: Discussing scrolled in rendition:layout
… over to Hadrien
Hadrien: This is a followup to continuous scrolled comics
… we had an agreement that a new value was a good idea, and we would add a note to explain what has happened to date
… Working on it, there was a lot in fixed layout that aren't really fixed layout
… for instance, the property for layout was a subsection, even though it can specify flowing
… so i bumped it up a level, and then after some more feedback from mgarrish I reorganized again
… I also added an example from a previous doc
… this is really a draft, since I have yet to add the RS side, and I still don't have the note
… I am a bit concerned about revisiting again
… since we already have agreement
duga: I was reading the comments this morning
… I understand not wanting to re litigate this, it works, I'm not interested in revisiting this
… we shouldn't discount the fact that ivan is confused, so I'm certain others are also
… I'm concerned we haven't made this clear enough
… perhaps it is because we are missing the reading system piece
… perhaps "scrolled" is the wrong word, it is a behavior, not a format
… and we have used it somewhere else for something different
… perhaps we should find a name that expressed the format and not the reading system behavior
… like contiguous vertical
ivan: Forget about my comment about alternatives
… I officially revoke that comment
ivan: but the term itself is what I find confusing, since it is already used
… so if we find another term I am happy
CharlesL: Are there horizontal scroll comics
… ?
Hadrien: That is a thing, but uncommon
… We did cover a possible direction field
SueNeu: Do we feel that horizontal scroll can be specified with FL?
Hadrien: Not really, same problem as vertical
mgarrish: Are comics the sole use case here?
… Rather than scrolled
<LaurentLM> comics is a US term
duga: I did consider that, but it seems that is also a layout term
… what if someone wants to use if for something else
… I don't like the term vertical that I suggested,
… because then we can't pivot to a horizontal format
Hadrien: I do think the only real use case are comics
… having an html container is less than ideal for this use
… Industry would prefer a list of images
SueNeu: Amazon calls everything comics, even children's books
… I have a lot of questions what the document would look like
Hadrien: What do you mean?
SueNeu: Is it one html with multiple images? Can this apply for panel by panel navigation?
Hadrien: for this content, there is no concept of a page. Think of the files as if they were tiles
… the comics themselves are designed to be read in a continuous scroll
Dale: I wonder if this is the way it is, because people approach epubs coming from the web, and that is the convention there
… Do we want to lock people into a convention or do we want people to have a chance to experiment?
LaurentLM: Today there is no question, the webtoon is tiled vertically, period. If there is one case where the RS must follow the author intent, this is it
… We have seen some horizontal, but they did not have much success
… If scrolled is not a layout, how about pageless? It is very literal
CharlesL: According to some LLM, I got 'axis' or 'single axis', or 'ribbon'.
… also continuous
wendyreid: To Dale, the reason these exist is due to mobile phones
… It is the most natural way to read comics on the phone
… traditional omics are not as good on the phone (zoom, etc)
… the challenge is more and more RSes support scrolled for flowing as well
… we do need to be clear that we are discussing fixed width image format and not other content
shiestyle: I just proposed unpaginated or pagefree
<toshiakikoike> +1
shiestyle: we can define vertical is the default
duga: I'm enjoying the "pageless" and "page-free" we could add "contiguous"
… I don't like "unpaginated" since it is negative
… we could take this offline and find a way for ranked choice voting
… we could talk about this name for the rest of the meeting
wendyreid: That makes sense, let's go back to content
SueNeu: Hadrien mentioned tiles, what are the tiles, are they svg, jpeg, etc?
LaurentLM: Currently they are jpeg pictures
Hadrien: It is still common to send a single file, and let the publisher cut it down to size
… but the reality is no one in this industry cares about html
… the industry today is just bitmaps
… and html isn't really helping, even for a11y
ivan: I think we said we should look at the a11y issues again, with fallbacks for images
… and maybe this is something we should address in the WG, but not today
wendyreid: Aside from the name and a11y, what else is there?
ivan: I am in favor with going forward, and the new structure works for me
… for the RS, you have a sentence that characterizes what you expect will happen
… the one thing missing is the log entry, that we need
… Big question: will we have enough implementations?
SueNeu: I was also thinking that scrolling was an option for flowing, but wasn't supported by RSes
wendyreid: Totally different question, probably for authoring spec:
… we do have to tell authors how to construct a scrolled document, and we need that to be consistent enough that implementers can do stuff with it
… traditionally, these are released as chapters, but you may also get a season, is it one html file with a single chapter, or do we have something to tell us where the boundaries are? How do we address that?
… One hack might be a single file per chapter
Hadrien: There is a technical reason for multi files, mainly performance
… ideally we would have a bunch of images, and then something else that would define a structure
… I think it will have to be one html per tile, and structure can be in the nav document
… I do agree that full seasons make sense for some retailers who can't handle a subscription
mgarrish: The whole 1to1 html to image is an old topic, but you can add images directly to the spine, with a fallback to a single html document
… So there are workarounds to the spine level image documents
wendyreid: On the html file per tile question, we used to require this for performance, but do we really still need this? Performance is now much better
… And does having a local file change anything, since you don't have to stream?
Hadrien: For a good RS, they usually have a few files in memory and discard the ones that won't be needed soon
… Usually this is done with images directly
… on the web, I have seen canvas, iframe, etc
… but you always have this caching to make it work
duga: both of these work, you could put all your content into a single HTML and then put images in the spine
… or you could split up your images to individual HTML files
… the industry will decide which one
… if the giant HTML causes performance issues people will stop
… if publishers don't like making one HTML per panel they will not do that
Hadrien: I think what mgarrish suggested was that we can do images in spine, we can just point at a "this is broken" html
… which is different from what you said
… if people are comfortable with that then it is fine
… so I very much agree with mgarrish
Dale: as a web designer, I was taught that as I develop a design, I am always in the viewport
… so I am always in the browser, and I adjust what I am doing to the browser
… and I am learning not all RSes handle content in the same way
… so I am wondering, as we discuss the spec, how much does the spec say this is how it should be and the RS must adjust, vs how much are we explaining to authors what will work
duga: I understand we can have a single file that says "this is broken"
… or we can have a single HTML file that contains all images with single line of CSS to make width 100%
… and you don't get that the book is broken
… it might not be ideal, but it could be a fall back
… it would retain the content for RS that require HTML
… then it is up to the reading system to choose to use the HTML or the image isn the spine
… this is consistent with the current spec
shiestyle: In Japan we had many comic epubs, we had one image in one html in the spine
… and we use the same for scrolled
… we have many RSes that support that, and they also support vertical scroll
… even for traditional comics
… So in Japan, the only difference is RS behavior. EPUB behavior is the same
… with just the metadata on the EPUB
… we don't need the additional metadata for episodes, etc
ivan: The approach from duga is fine, with the minimal html file
… But images in the spite with fallback to single html doesn't work because the image size isn't available from just the image
Hadrien: The PR is designed this way due to the spec. If we want to do images in spine, then we need different requirements
… on a spec level I think it is hard to say what to put in these documents (can't require images, vs broken comment)
… The benefit to images in spine is it removes the guesswork
… but if we do it here, we should also consider it for comics
Hadrien: the ability to know vs guess is a huge benefit
CharlesL: I would be uncomfortable if it cannot be made accessible
… we would need an image in the spine with some way to specify alt text
mgarrish: if you do all the images in a single html document, you would need to only reference it once, then add blank documents