Standard way of adding HTML5 widgets?

12 posts / 0 new
Last post

What is the standard way of adding HTML5 widgets in epub3. Since ePub3 provides HTML5 support as well, so can widgets be integrated through URL (widgets hosted on some server and share the URL to run) or widgets should be embedded in the ePub3 package and should be distributed along with the ePub?

You can hyperlink out to a remotely hosted widget just as you would any other web page, but otherwise you have to include the widget in the container to use it within the content. Currently only audio and video files referenced from the html5 audio/video elements are allowed to live outside the container.

There are a couple of specifications under development to try and standardize the inclusion of third-party widgets, which may or may not be of interest to you (see [1] and [2] below). You should be aware that only container-constrained scripting (inside an iframe) is required to be supported in epub.

[1] http://www.idpf.org/epub/sc/api/

[2] http://www.idpf.org/epub/sc/pkg/

Just to clarify your last sentence ( to be sure I'm not misunderstanding the specs); scripting support is not required at all but Reading Systems that support scripting must support container- constrained scripting as a minimum.

Right, if it is supported the only requirement is to support it in container-constrained contexts. The current support landscape is unstable, at best, in other words.

The 3.1 revision is revisiting support requirements, but even if scripting becomes mandatory reality suggests the landscape won't be stabilizing for some time to come.

I find using declarative programming is so much more elegant for a system like EPUB but that's just my opinion. I find SVG animations have a lot of promise.

SVG hasn't been brought up yet, but animation support was raised during the 3.0.1 revision and passed over again, so I'm not expecting anything will change on that front.

Given the painful support gaps that exist in some areas, there has been pushback against going further in directions where a reasonable expectation of support cannot be guaranteed. And because SVG animations didn't make the cut for 3.0, they have a higher bar to cross now to get in.

The lack of inclusion is not a comment on their usefulness, in other words, or a statement against declarative programming, just a support reality.

Why is that? Why was SVG animations not supported? Was it because of the failure of groups like Adobe to implement it? I'm wondering what the rationale for the lack of support it considering the elegance of using declarative programming.

The restriction is rooted in epub 2.0 and before my involvement with the specs, so I can't speak authoritatively to it. I expect it was originally excluded because of the complexity of implementation in what were then mostly eink devices. It was also persisted into epub 3.0 before I got involved, so it might have been a combination of lack of support in browser cores plus some persistence of compatibility with epub 2 that kept it sidelined.

When I have heard it raised for reconsideration the question that is asked is where is support at now -- is it stable enough that content will render reliably across reading systems. There are people in the working group who would like to have it added, but without the support case the discussions haven't gone far.

There's probably an argument to be made that epub should just be silent on the topic and let the market figure it out, but it's no easier to remove restrictions once they're in than to add things that are not.

I don't imagine supporting it in the spec has to do with realible rendering across reading systems as that wouldn't be the technical issue. With regards to eInk devices, correct, animations are more CPU intensive so you could imagine those pale devices would fail to handle the extra rounds of computation required.

I'd go with the reason someone mentioned with another thread. That there were indeed attempts (e.g by Adobe) but they found it too complex to implement. I then suggested it would make a good research project, a Ph.D project perhaps.

It was likewise continued into epub 3.0 preceding I got included, so it may have been a blend of absence of support in program centers in addition to some perseverance of similarity with epub 2 that kept it sidelined.For more details you can visit http://essaydune.com/ .

Actually, Adobe's SVG Viewer (last public release 3.0, last beta 6.0. Now no longer supported at all) DID fully support both programmatic (JS) and declarative animation of SVG 1.1. I know this because I was part of the SVG Viewer team and wrote most of the import/export SVG support in Adobe tools.  Sun supported part of the declarative animation, but not all.

Although several of us on the EPUB WG really like declarative animation, there is virtually no tooling for it out there (that I am aware of, correct me if I am wrong). The libraries I wrote at Adobe did support it, but only a Beta of LiveMotion ever used declarative animation and Adobe killed LM long ago. More importantly, declarative animation is poorly supported by the browsers even today.

The proposed EPUB 3.1 fortunately does not contain those restriction on declarative animation and interacitivty anymore.
This is some progress.

Of course, viewers have many bugs, this is not specific to their animation support.
There needs a lot of work to be done in severa areas on all viewers to get finally right, was is required for EPUB.

Secondary menu