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.

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

Allow epub: attributes #67

Merged
merged 1 commit into from
Jan 3, 2019
Merged

Conversation

alecgibson
Copy link

At the moment, epub: attributes are stripped. There are currently only
two of these attributes defined by the standard:

  • epub:type
  • epub:prefix

The epub:type prefix in particular is very useful for adding semantic
information about content for things like nicer footnote behaviour. This
change adds the above attributes to the attribute whitelist.

For ease of development, this change also adds coffeescript to the
list of development dependencies, and adds an npm script so that
the project can be compiled: npm run compile.

At the moment, `epub:` attributes are stripped. There are currently only
two of these attributes defined by [the standard][1]:

  - `epub:type`
  - `epub:prefix`

The `epub:type` prefix in particular is very useful for adding semantic
information about content for things like nicer footnote behaviour. This
change adds the above attributes to the attribute whitelist.

For ease of development, this change also adds `coffeescript` to the
list of development dependencies, and adds an `npm` script so that
the project can be compiled: `npm run compile`.

[1]: http://www.idpf.org/epub/31/spec/epub-contentdocs.html
Copy link
Collaborator

@pedrosanta pedrosanta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good PR @alecgibson. 👍

Thank you for the neat npm script and dev dependency.

Sorry for this 'nuisance', of having to whitelist these attributes. As we've discussed on #49, we plan to scrap the processing of the chapters HTML contents altogether – which would avoid the issue this PR addresses –, I feel these contents should be of the sole responsibility of the lib user. Doing that processing hinders the flexibility of the lib and adds up unnecessary maintenance.

@pedrosanta
Copy link
Collaborator

Fixes #47.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants