openzim
Introduce the ZIM JS API
This new JS API should provide the following features:
Night mode#1240- TOC
webm video reader (https://github.com/brion/ogv.js/)#1239
What needs to be done:
- openZIM spec
- standard implementation for all 3 things
- Put the implementation in libzim (node-libzim?)
- A demo case in iOS
See https://wiki.openzim.org/wiki/Javascript_API for more detail (but still a draft)
@kelson42 The 3 features here are a subset of the spec on the openzim wiki. Is this correct? Is this issue just for the 3 mentioned features?
This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
I would like to propose adopt prefers-color-scheme as an alternative to dark theme. The js API is still useful for extract table of content, etc.
This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be now be reviewed manually. Thank you for your contributions.
Like said @automactic, it's not foreseen (anymore) to use JS API for the dark/light mode, see https://github.com/openzim/overview/issues/53
Now that we only have TOC left in the JS API, are we really sure about the approach?
For the TOC, I feel like a very basic convention on a class to add to every TOC elements could be sufficient. E.g. zim_toc_h1, zim_toc_h2, ... Sufficiently unique to have mostly zero risk of collision with already existing classes. And the readers can then do whatever they want with these classes and elements.
To me it looks way more stable and easy to implement than the JS based approach. But maybe it has already been discussed somewhere and I just miss the downsides of this idea.
@benoit74 Kind of agree even if I don't fully understand the solution abou the TOC. We should:
- Isolate the TOC issue
- Close here the issue after a bit (to see if no new idea pops up)
There was already a previous PR to add the ToC API to mwOffliner and it got nearly to completion, but was never finalized..
But it's up to you. The JS API seemed like a good cross-app solution back in 2019. Not sure why it never gained traction. It seems a bit useless to have a whole API for one feature, when most apps have long-since added their own ToC. The JS apps construct a ToC just using any h1 h2 h3 elements in the document, and it works with Wikimedia, and with many other ZIMs too. No real need to add special classes.
