You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The text property is the only point of reference from sync media to HTML. It is currently defined as a URL fragment, e.g. #id1234
This fragment-only definition makes sense when the sync media file is discovered from within an HTML file. It can also make sense if the sync media file is discovered from data in a publication manifest, but only if the reading order item that it appears on is an HTML file.
If however it appears on an audio file item, we have no way of knowing the corresponding HTML document.
* - : it would probably be "technically optional" but given that Audiobooks is our most likely real-world use case, then we should be sure to write our examples in a way that will copy/paste well for that context.
Add a property to the sync media file, at the root level, giving the filename. E.g.
and so the sync media file must say what HTML document it is using to synchronize with this audio file.
(I don't really like this option but for completeness, here it is:)
Audiobooks should instead directly refer to the HTML document, which in turn refers to the sync media file from its <head>.
If we went this way, it would suggest that we could skip packaging sync media entirely and just always have the HTML refer to it. This to me feels like the easiest to specify and also the most cumbersome to author and maintain and process because 1. It increases the destructive editing burden on the HTML document, which I think we should be increasingly moving away from; and 2. Having to open an HTML document before you decide to fire up your sync media player is also additional processing burden.
The text was updated successfully, but these errors were encountered:
This fragment-only definition makes sense when the sync media file is discovered from within an HTML file. It can also make sense if the sync media file is discovered from data in a publication manifest, but only if the reading order item that it appears on is an HTML file.
See my thoughts / remarks on the "base URL" of the JSON document: #28
The
text
property is the only point of reference from sync media to HTML. It is currently defined as a URL fragment, e.g.#id1234
This fragment-only definition makes sense when the sync media file is discovered from within an HTML file. It can also make sense if the sync media file is discovered from data in a publication manifest, but only if the reading order item that it appears on is an HTML file.
If however it appears on an audio file item, we have no way of knowing the corresponding HTML document.
An Audiobooks processor encounters the following:
But according to the current
text
definition, thetext
property would not say which file to open:sync-media/part001-1.json
:Ideas to fix this:
text
* -
: it would probably be "technically optional" but given that Audiobooks is our most likely real-world use case, then we should be sure to write our examples in a way that will copy/paste well for that context.and so the sync media file must say what HTML document it is using to synchronize with this audio file.
Audiobooks should instead directly refer to the HTML document, which in turn refers to the sync media file from its
<head>
.If we went this way, it would suggest that we could skip packaging sync media entirely and just always have the HTML refer to it. This to me feels like the easiest to specify and also the most cumbersome to author and maintain and process because 1. It increases the destructive editing burden on the HTML document, which I think we should be increasingly moving away from; and 2. Having to open an HTML document before you decide to fire up your sync media player is also additional processing burden.
The text was updated successfully, but these errors were encountered: