Thoughts on "e0 Incarnate, and a Note on Navigation"
39 views
Skip to first unread message
Baldur Bjarnason
Jul 16, 2013, 8:58:36 PM7/16/13
to epub-ng
This is in response to this blog post (http://epubzero.blogspot.co.uk/2013/07/e0-incarnate-and-note-on-navigation.html) containing an example e0 ebook.
I have a few thoughts which I'm going to post here since the comments section on that blog post was thoroughly broken when I tried it.
How is the cover section going to work? Are user agents supposed to find the first element in index.html with the role of cover and use the elements it contains as a cover, no matter what they are? How's that supposed to degrade and adapt to varying contexts? Or are user agents supposed to pick the first img element in the section?
What's wrong with using a link tag for covers so that producers can supply a variety of cover types, letting the user agent choose whichever is most appropriate? That'd be much more 'webby'. E.g. <link rel="cover" type="image/jpeg" href="cover.jpg">
And if you are applying the spine/toc properties directly to the chapter element then the role attribute is inappropriate since each chapter element is basically just a link. IMO, what you should be doing is adding them as rel values to the links. That'd get your meaning across much more clearly and the issue of whether we were allowed to use the role attribute would be moot. Or, it would at least minimise our use of role. There's a lot of precedent for using rel to indicate relationships like this in HTML, rel="chapter" is even a part of the basic HTML rel vocabulary. There's also a lot more history of community-led extensions to rel than to role.
In any case, neither spine nor toc are defined as properties in EPUB3 Structural Semantics Vocabulary in the way you're using them (in EPUB3 'toc' is applied to the nav element, not the chapters themselves) so you would have to write out a proper definition for what they mean in e0 if this is to be the way you go. (When this discussion first started I was under the impression that those properties would be applied to the nav elements like 'toc' is done in EPUB3.)
IMO, typing links in some way should be the first tool you reach for when you're planning on extending HTML.
I'd much prefer a <nav role="landmarks"> element in the index page containing a list of links each with rel values of frontmatter, bodymatter, etc. than for those things to be defined in the chapter files themselves. Or just define them using link tags in the header. That way the entire structure of the book would be defined in the index file instead of having to scan through every html file to extract landmark values. By defining them in each chapter instead of in the index.html file you are pretty much guaranteeing most user agents will ignore the landmark roles.
I also have major misgivings about using role to define the type of an entire chapter at once. As the role attribute is defined, it "describes the role(s) the current element plays in the context of the document". Using it de facto to describe the entire document feels way off.
Anyway, those are my first thoughts about the sample posted.
- best
- baldur
I have a few thoughts which I'm going to post here since the comments section on that blog post was thoroughly broken when I tried it.
How is the cover section going to work? Are user agents supposed to find the first element in index.html with the role of cover and use the elements it contains as a cover, no matter what they are? How's that supposed to degrade and adapt to varying contexts? Or are user agents supposed to pick the first img element in the section?
What's wrong with using a link tag for covers so that producers can supply a variety of cover types, letting the user agent choose whichever is most appropriate? That'd be much more 'webby'. E.g. <link rel="cover" type="image/jpeg" href="cover.jpg">
And if you are applying the spine/toc properties directly to the chapter element then the role attribute is inappropriate since each chapter element is basically just a link. IMO, what you should be doing is adding them as rel values to the links. That'd get your meaning across much more clearly and the issue of whether we were allowed to use the role attribute would be moot. Or, it would at least minimise our use of role. There's a lot of precedent for using rel to indicate relationships like this in HTML, rel="chapter" is even a part of the basic HTML rel vocabulary. There's also a lot more history of community-led extensions to rel than to role.
In any case, neither spine nor toc are defined as properties in EPUB3 Structural Semantics Vocabulary in the way you're using them (in EPUB3 'toc' is applied to the nav element, not the chapters themselves) so you would have to write out a proper definition for what they mean in e0 if this is to be the way you go. (When this discussion first started I was under the impression that those properties would be applied to the nav elements like 'toc' is done in EPUB3.)
IMO, typing links in some way should be the first tool you reach for when you're planning on extending HTML.
I'd much prefer a <nav role="landmarks"> element in the index page containing a list of links each with rel values of frontmatter, bodymatter, etc. than for those things to be defined in the chapter files themselves. Or just define them using link tags in the header. That way the entire structure of the book would be defined in the index file instead of having to scan through every html file to extract landmark values. By defining them in each chapter instead of in the index.html file you are pretty much guaranteeing most user agents will ignore the landmark roles.
I also have major misgivings about using role to define the type of an entire chapter at once. As the role attribute is defined, it "describes the role(s) the current element plays in the context of the document". Using it de facto to describe the entire document feels way off.
Anyway, those are my first thoughts about the sample posted.
- best
- baldur
Dave Cramer
Jul 18, 2013, 3:05:39 PM7/18/13
to Baldur Bjarnason, epub-ng
Hi Baldur,
Thanks for this! Comments below.
On Tue, Jul 16, 2013 at 8:58 PM, Baldur Bjarnason
<baldur.b...@gmail.com> wrote:
>
> This is in response to this blog post (http://epubzero.blogspot.co.uk/2013/07/e0-incarnate-and-note-on-navigation.html) containing an example e0 ebook.
>
> I have a few thoughts which I'm going to post here since the comments section on that blog post was thoroughly broken when I tried it.
>
> How is the cover section going to work? Are user agents supposed to find the first element in index.html with the role of cover and use the elements it contains as a cover, no matter what they are? How's that supposed to degrade and adapt to varying contexts? Or are user agents supposed to pick the first img element in the section?
>
> What's wrong with using a link tag for covers so that producers can supply a variety of cover types, letting the user agent choose whichever is most appropriate? That'd be much more 'webby'. E.g. <link rel="cover" type="image/jpeg" href="cover.jpg">
Covers are an odd beast, both part of the book and separate from the
book, both content and metadata. EPUB2 had no concept of a book cover;
early EPUBs had covers embedded in HTML as regular content, but Amazon
didn't like that. So they asked us to use <meta name="cover"
content="cover-image"/> and linear="no" on the cover html. I still
cringe when I hear talk of the "logical cover" or "duplicate covers."
And I was annoyed when distributing files, because I'd send an EPUB
with a cover image inside it, and have to separately upload the very
same image that was inside the EPUB (not to mention the distributees
already received all the cover images in ONIX).
EPUB3 has a cover-image property for manifest items, but I expect
that, like many other things, we'll end up using both that and the
older approach. EPUB3 in the wild seems to be evolving towards belt,
suspenders, and elastic waistband.
* * *
I've hoped e0 could be simpler. The simplest thing I can think of is
for the reading system to open index.html, and render the contents. If
I want the cover image to display when opening the book, I just put an
image element in index.html. If there's a link pointing to the cover
image in index.html, how should it be rendered? Or does that become
the choice of the reading system rather than the author?
I agree that identifying the image that serves as the cover is quite useful.
>
> And if you are applying the spine/toc properties directly to the chapter element then the role attribute is inappropriate since each chapter element is basically just a link. IMO, what you should be doing is adding them as rel values to the links. That'd get your meaning across much more clearly and the issue of whether we were allowed to use the role attribute would be moot. Or, it would at least minimise our use of role. There's a lot of precedent for using rel to indicate relationships like this in HTML, rel="chapter" is even a part of the basic HTML rel vocabulary. There's also a lot more history of community-led extensions to rel than to role.
I have no problems with that. As mentioned in a different thread, I'd
like the simplest case to work without any additions beyond that
required by an HTML5 nav element.
>
>
> In any case, neither spine nor toc are defined as properties in EPUB3 Structural Semantics Vocabulary in the way you're using them (in EPUB3 'toc' is applied to the nav element, not the chapters themselves) so you would have to write out a proper definition for what they mean in e0 if this is to be the way you go. (When this discussion first started I was under the impression that those properties would be applied to the nav elements like 'toc' is done in EPUB3.)
I'd expect we'll need to make some additions to the vocabulary.
Perhaps "toc" is the wrong term to use here, since it already has a
separate meaning.
>
>
> IMO, typing links in some way should be the first tool you reach for when you're planning on extending HTML.
>
> I'd much prefer a <nav role="landmarks"> element in the index page containing a list of links each with rel values of frontmatter, bodymatter, etc. than for those things to be defined in the chapter files themselves. Or just define them using link tags in the header. That way the entire structure of the book would be defined in the index file instead of having to scan through every html file to extract landmark values. By defining them in each chapter instead of in the index.html file you are pretty much guaranteeing most user agents will ignore the landmark roles.
>
>
> I also have major misgivings about using role to define the type of an entire chapter at once. As the role attribute is defined, it "describes the role(s) the current element plays in the context of the document". Using it de facto to describe the entire document feels way off.
Having role="bodymatter chapter" in the individual HTML files is more
about accessiblity than about identifying landmarks. That was done
just as we're using epub:type="bodymatter chapter" now.
Landmarks are an interesting question. I'd guess the most common
landmarks are the table of contents, the cover, and the "begin
reading" location. In e0 we already know that primary navigation is in
index.html. The cover either will be there, too, or some reference to
it. Perhaps if we want to mark some element as being a landmark, it
could also happen in nav in index.html as an attribute value.
Again, I'm hoping the simple cases wouldn't require any additions to nav.
Thanks for this! Comments below.
On Tue, Jul 16, 2013 at 8:58 PM, Baldur Bjarnason
<baldur.b...@gmail.com> wrote:
>
> This is in response to this blog post (http://epubzero.blogspot.co.uk/2013/07/e0-incarnate-and-note-on-navigation.html) containing an example e0 ebook.
>
> I have a few thoughts which I'm going to post here since the comments section on that blog post was thoroughly broken when I tried it.
>
> How is the cover section going to work? Are user agents supposed to find the first element in index.html with the role of cover and use the elements it contains as a cover, no matter what they are? How's that supposed to degrade and adapt to varying contexts? Or are user agents supposed to pick the first img element in the section?
>
> What's wrong with using a link tag for covers so that producers can supply a variety of cover types, letting the user agent choose whichever is most appropriate? That'd be much more 'webby'. E.g. <link rel="cover" type="image/jpeg" href="cover.jpg">
book, both content and metadata. EPUB2 had no concept of a book cover;
early EPUBs had covers embedded in HTML as regular content, but Amazon
didn't like that. So they asked us to use <meta name="cover"
content="cover-image"/> and linear="no" on the cover html. I still
cringe when I hear talk of the "logical cover" or "duplicate covers."
And I was annoyed when distributing files, because I'd send an EPUB
with a cover image inside it, and have to separately upload the very
same image that was inside the EPUB (not to mention the distributees
already received all the cover images in ONIX).
EPUB3 has a cover-image property for manifest items, but I expect
that, like many other things, we'll end up using both that and the
older approach. EPUB3 in the wild seems to be evolving towards belt,
suspenders, and elastic waistband.
* * *
I've hoped e0 could be simpler. The simplest thing I can think of is
for the reading system to open index.html, and render the contents. If
I want the cover image to display when opening the book, I just put an
image element in index.html. If there's a link pointing to the cover
image in index.html, how should it be rendered? Or does that become
the choice of the reading system rather than the author?
I agree that identifying the image that serves as the cover is quite useful.
>
> And if you are applying the spine/toc properties directly to the chapter element then the role attribute is inappropriate since each chapter element is basically just a link. IMO, what you should be doing is adding them as rel values to the links. That'd get your meaning across much more clearly and the issue of whether we were allowed to use the role attribute would be moot. Or, it would at least minimise our use of role. There's a lot of precedent for using rel to indicate relationships like this in HTML, rel="chapter" is even a part of the basic HTML rel vocabulary. There's also a lot more history of community-led extensions to rel than to role.
like the simplest case to work without any additions beyond that
required by an HTML5 nav element.
>
>
> In any case, neither spine nor toc are defined as properties in EPUB3 Structural Semantics Vocabulary in the way you're using them (in EPUB3 'toc' is applied to the nav element, not the chapters themselves) so you would have to write out a proper definition for what they mean in e0 if this is to be the way you go. (When this discussion first started I was under the impression that those properties would be applied to the nav elements like 'toc' is done in EPUB3.)
Perhaps "toc" is the wrong term to use here, since it already has a
separate meaning.
>
>
> IMO, typing links in some way should be the first tool you reach for when you're planning on extending HTML.
>
> I'd much prefer a <nav role="landmarks"> element in the index page containing a list of links each with rel values of frontmatter, bodymatter, etc. than for those things to be defined in the chapter files themselves. Or just define them using link tags in the header. That way the entire structure of the book would be defined in the index file instead of having to scan through every html file to extract landmark values. By defining them in each chapter instead of in the index.html file you are pretty much guaranteeing most user agents will ignore the landmark roles.
>
>
> I also have major misgivings about using role to define the type of an entire chapter at once. As the role attribute is defined, it "describes the role(s) the current element plays in the context of the document". Using it de facto to describe the entire document feels way off.
about accessiblity than about identifying landmarks. That was done
just as we're using epub:type="bodymatter chapter" now.
Landmarks are an interesting question. I'd guess the most common
landmarks are the table of contents, the cover, and the "begin
reading" location. In e0 we already know that primary navigation is in
index.html. The cover either will be there, too, or some reference to
it. Perhaps if we want to mark some element as being a landmark, it
could also happen in nav in index.html as an attribute value.
Again, I'm hoping the simple cases wouldn't require any additions to nav.
Hadrien Gardeur
Jul 18, 2013, 4:33:41 PM7/18/13
to Baldur Bjarnason, epub-ng
How is the cover section going to work? Are user agents supposed to find the first element in index.html with the role of cover and use the elements it contains as a cover, no matter what they are? How's that supposed to degrade and adapt to varying contexts? Or are user agents supposed to pick the first img element in the section?
What's wrong with using a link tag for covers so that producers can supply a variety of cover types, letting the user agent choose whichever is most appropriate? That'd be much more 'webby'. E.g. <link rel="cover" type="image/jpeg" href="cover.jpg">
We should definitely use a link for covers.
In a way, this is a light replacement for a manifest. We only declare the resources for which the relationship is important and useful.
And if you are applying the spine/toc properties directly to the chapter element then the role attribute is inappropriate since each chapter element is basically just a link. IMO, what you should be doing is adding them as rel values to the links. That'd get your meaning across much more clearly and the issue of whether we were allowed to use the role attribute would be moot. Or, it would at least minimise our use of role. There's a lot of precedent for using rel to indicate relationships like this in HTML, rel="chapter" is even a part of the basic HTML rel vocabulary. There's also a lot more history of community-led extensions to rel than to role.
Agree, but such links should not appear in the header of the document (unlike the link to the cover).
Ideally, we would limit these rel values to the spine (that's where it makes most sense).
In any case, neither spine nor toc are defined as properties in EPUB3 Structural Semantics Vocabulary in the way you're using them (in EPUB3 'toc' is applied to the nav element, not the chapters themselves) so you would have to write out a proper definition for what they mean in e0 if this is to be the way you go. (When this discussion first started I was under the impression that those properties would be applied to the nav elements like 'toc' is done in EPUB3.)
Sure, the role should be applied to the nav element.
I'd much prefer a <nav role="landmarks"> element in the index page containing a list of links each with rel values of frontmatter, bodymatter, etc. than for those things to be defined in the chapter files themselves. Or just define them using link tags in the header. That way the entire structure of the book would be defined in the index file instead of having to scan through every html file to extract landmark values. By defining them in each chapter instead of in the index.html file you are pretty much guaranteeing most user agents will ignore the landmark roles.
I'd rather have it in the spine and make the spine the only requirement.
You shouldn't have to duplicate links in landmarks to provide such useful information.
Baldur Bjarnason
Jul 22, 2013, 12:12:58 PM7/22/13
to Hadrien Gardeur, epub-ng
I agree with what Hadrian said.
Basically:
* link tags for covers
* landmarks as rel attributes on a tags in the nav list
* Spine nav element is mandatory and if no nav element is marked as role="spine" then you use the first nav > ul in the index document
* ToC is an optional separate nav list marked with role="toc"
The primary reason as far as I'm concerned for having the cover as a link tag in the head is the type attribute.
It also ties in with how websites indicate what image should be used as the site's icon in web app contexts (which is something e0 books should also include when possible, letting reading systems use an icon instead of a cover where appropriate.
- best
- baldur
Basically:
* link tags for covers
* landmarks as rel attributes on a tags in the nav list
* Spine nav element is mandatory and if no nav element is marked as role="spine" then you use the first nav > ul in the index document
* ToC is an optional separate nav list marked with role="toc"
The primary reason as far as I'm concerned for having the cover as a link tag in the head is the type attribute.
It also ties in with how websites indicate what image should be used as the site's icon in web app contexts (which is something e0 books should also include when possible, letting reading systems use an icon instead of a cover where appropriate.
- best
- baldur
Hadrien Gardeur
Jul 22, 2013, 12:28:02 PM7/22/13
to Baldur Bjarnason, epub-ng
The primary reason as far as I'm concerned for having the cover as a link tag in the head is the type attribute.
Right, we should keep the semantics/relationships as separated as possible from the type.
Reply all
Reply to author
Forward
0 new messages