Karl Kleinpaste <k...@kleinpaste.org> writes: > the application probably has to hack the filter output to spackle in a > standard miniature image to indicate it, to go along with the intended > <img> pseudo-picture actually-audio reference
It occurs to me as well that simply adding a standard "there's audio here" image file to spackle _alongside_ the existing tag... <a href="showImage"><img file="audio-is-here.png"><img file="foo.mp3"></a> ...will have bad visual side effects because any HTML renderer will still try to interpret "foo.mp3" badly, resulting in a typical "a broken picture was here" display in the output. This means that the filter-supplied <img> reference must be removed entirely to prevent this bad visual. So the further hackery done to this content would have to replace entirely the filter-supplied <img>, instead spackling in a total replacement reference, which (just thinking of possibilities off the top of my head) would probably be of the form... <img file="audio-is-here.png" audio="foo.mp3" start=... stop=...> ...which again means that [a] the application must post-hack the filter output severely, [b] we are overloading <img> in ways we should not, [c] we are extending the qualifiers on <img>, and [d] neither the filters nor any apps are anywhere near being able to handle any of this because there is no way at this time to carry the "audio=..." qualifier into the "showImage" by which the app actually interprets the need for display. This is wrong. Creating a new <audio> tag (or something similar) that gets wrapped in something like <a href="passagestudy.jsp?action=playAudio..."> would let this happen in much more consistent, standard, and reliable ways. _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
