Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

epubcheck 4.2.0.-beta: meta element with attribute type from OPS namespace #986

Closed
Doktorchen opened this issue Feb 28, 2019 · 10 comments
Closed

epubcheck 4.2.0.-beta: meta element with attribute type from OPS namespace #986

Doktorchen opened this issue Feb 28, 2019 · 10 comments
Assignees
@rdeltour
Labels
spec: EPUB 3.2 Impacting the support of EPUB 3.2 status: has PR The issue is being processed in a pull request type: spec The issue is related to a Specification update
Milestone
4.2.0-RC

Comments

@Doktorchen
Copy link

epubcheck 4.2.0.-beta clains, that it is not correct to use the attribute type from the OPS namespace within the meta element:

Example:
"
<html ...
xmlns:ops="http://www.idpf.org/2007/ops"
prefix="dct: http://purl.org/dc/terms/'
...
>
...
<meta name="creator" ops:type="dct:creator" property="dct:creator" content="Friedrich Schiller" />
"

Reports as:
"ERROR(RSC-005): SchillerndF.epub/Inhalt/andiefreude.xhtml(12,103): Error while parsing file: attribute "ops:type" not allowed here; ..."

EPUB 3.0.1 notes, that this OPS attribute is a global attribute ...
http://www.idpf.org/epub/301/spec/epub-contentdocs.html#sec-xhtml-content-type-attribute
@rdeltour
Copy link
Member

this OPS attribute is a global attribute

Right, although this attribute really only is intended to be used in the body.

I guess making that change doesn't hurt however, or should this be limited by spec? ping @mattgarrish.

@rdeltour rdeltour self-assigned this Feb 28, 2019
@rdeltour rdeltour added type: spec The issue is related to a Specification update spec: EPUB 3.2 Impacting the support of EPUB 3.2 status: in discussion The issue is being discussed by the development team labels Feb 28, 2019
@rdeltour rdeltour added this to the 4.2.0-RC milestone Feb 28, 2019
@mattgarrish
Copy link
Member

Well, the specification notes that it's pointless to put in the head:

As the [HTML5] head element is a metadata container for a document, structural semantics expressed on this element or any descendant of it have no meaning. Reading Systems must ignore such semantics.

It's not for expressing metadata, so is not a complement to the property attribute but a meaningless application of the attribute where it doesn't apply.

@rdeltour
Copy link
Member

This spec note doesn't make it invalid, nor a warning. I suggest we update EPUBCheck to make it pass, as it's an easy change (declaring the attribute in the common.attrs.basic class instead of common.attrs+special cases).

@Doktorchen
Copy link
Author

Previous versions of epubcheck had the bug not to accept the RDFa attribute property here -surprise, now you get trouble with another attribute, this may already result in various attempts to work around the previous bug.
And if indicated as a global attribute, it is ok to set.
This might be used only for authors for internal purposes to extract some information automatically.
I have additionally dct:created and dct:description on other meta elements.

@mattgarrish
Copy link
Member

mattgarrish commented Feb 28, 2019 •
edited
Loading

I suggest we update EPUBCheck to make it pass

From the global aspect, yes. But it's unfortunate it's allowed in the header at all. It might be worth raising it with the CG.

The attribute exists to express a subclass of the carrying element, which is a must per the specification. A structural semantic isn't being applied here, and I doubt one ever could.

The attribute is supposed to be functionally equivalent to ARIA role, which is also technically allowed anywhere but can't actually be valid in the header because you can't modify the roles of the header content (they don't carry roles to begin with).

@rdeltour
Copy link
Member

But it's unfortunate it's allowed in the header at all. It might be worth raising it with the CG.

Right, it's not EPUBCheck's decision to make and needs to come from the CG. In the mean time, I'll "fix" it in the schema.

@rdeltour
Copy link
Member

This might be used only for authors for internal purposes to extract some information automatically.

For this use case I would recommend using data-* attributes…

@Doktorchen
Copy link
Author

Due to the prefixed values it has a general meaning, therefore nothing for this obscure data-* pseudo-attributes.
But authors will not expect, that all user-agents will expose meta information to the audience, however, a few do it. Therefore, surely it has a semantic meaning as well, not defined by the value of the name attribute in HTML5, mainly exposed with the RDFa property attribute.
Because the OPS attribute was only an attempt to work around this bug of previous epubcheck versions, should be no problem to restrict this in a new EPUB version (having a new value for the version indication - else a change introduces backwards incompatibilities, if this is ok in 3.0, but not in 3.2 for example)

@rdeltour rdeltour mentioned this issue Feb 28, 2019
Closed
@JayPanoz
Copy link

JayPanoz commented Mar 3, 2019

As a small clarification on data-* attributes.

They’re meant for proprietary information to be exchanged between the HTML and its DOM representation by scripts – source.

So they should not be used to store content that should be visible and accessible in data attributes, because assistive technology may not access them. In addition, search crawlers may not index data attributes' values, etc. – source

It seems like “internal” is not exchangeable with “proprietary” in this case.

(I know data-* custom attributes can have a really bad rep – go figure – but they have their use-cases, including in Reading Systems, production workflows, etc.)

@Doktorchen
Copy link
Author

Such metadata in digital books is typically not intended for the DOM.
Main use case is maybe additional information for experts (literary studies, literature history).

Typically digital books can have a long lifetime (they are saved permanently in national libraries like Deutsche Nationalbibliothek), there is a use case to provide detailed metadata in digital books for future generations, just in case someone gets interested in those books in a few hundred years. ;o)

If this is restricted in the future, because OPS:type is only intended for metadata about the structure of a text, not general metadata:
The next workaround idea for EPUB3.x books (to survive different versions of epubcheck somehow) could be, to provide metadata about the document in an aside or section with the related role of metadata, similar to the colophon for the complete book.
For example the creation and modification dates (Dublin Core term) of the document now become content of time elements within an appropriate block element like p.
Result: OPS:type not ok for meta now is ok within the content, because it becomes part of the structure?

The major part of the audience will not want to see it, therefore maybe an additional alternate stylesheet with expert view, for normal stylesheets this area can be set to display: none

Metadata in (X)HTML had never a good consideration.

rdeltour added a commit that referenced this issue Mar 13, 2019
@rdeltour
fix: allow epub:type on all HTML elements
afa2cad 
Fix #986
@rdeltour rdeltour mentioned this issue Mar 13, 2019
Merged
@rdeltour rdeltour added status: has PR The issue is being processed in a pull request and removed status: in discussion The issue is being discussed by the development team labels Mar 13, 2019
rdeltour added a commit that referenced this issue Mar 15, 2019
@rdeltour
fix: allow epub:type on all HTML elements
2cafe64 
Fix #986
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rdeltour rdeltour

Labels
spec: EPUB 3.2 Impacting the support of EPUB 3.2 status: has PR The issue is being processed in a pull request type: spec The issue is related to a Specification update
Projects
None yet
Milestone
4.2.0-RC
Development

No branches or pull requests
4 participants
@rdeltour @mattgarrish @JayPanoz @Doktorchen