Javascript has been a big no-no at PG for years, and I see no good reason to introduce it, because it gives many people a concern on what might be happening on their system. (Similar discussions have been about ePub 3.0 adding javascript support, leading to dynamic books that can suprise people in many ways.) A compromise called unobtrusive javascript (https://en.wikipedia.org/wiki/Unobtrusive_JavaScript) might be an option. Basically, you separate the functionality from the HTML, load the Javascript separately, which then will pick-up the active elements based on ids (or any other CSS selector). Libraries such as jQuery fully support this style of Javascript. Jeroen On 2013-09-07 13:45, Greg Newby wrote:
On Wed, Sep 04, 2013 at 12:56:13PM -0400, Robert Cicconetti wrote:
On Wed, Sep 4, 2013 at 1:39 AM, Greg Newby <gbnewby@pglaf.org> wrote:
I agree that First Folio is problematic. Otherwise, I don't have a basis for a preference. Actually, I don't even know the was used our #100 (http://www.gutenberg.org/cache/epub/100/pg100.txt), and would be curious to know.
For Shakespeare, like other plays, the main idea is to make it far easier to create custom versions for each player/part (plus stage direction). The markup mentioned above would also make it easy to have a computer-based "minus one" performance, in which a live human performer would read his parts, in the midst of a computer-generated play troup. (This type of thing is already done with MIDI and musical scores, for musical performances.) It would also make it trivial to do speaker-based text analysis or other research.
Let me talk to the PPers, but I think we can also make something that is out of the box useful as well... an HTML edition with some light javascript menu hidden in the corner perhaps that'll toggle a 40% mask over all but one part or such. Or just highlight the specific part in yellow. :) It gets slightly tricky in a complete edition (detecting which play you are in and only displaying the current characters, remembering the last choice, etc.) Chrome, forex, restricts cookies in local copies of HTML, but it might allow HTML5 Web storage.. hmm.
Last time I checked, though, javascript support was inconsistent (at best) to non-existent in the mobile reader space[0]... the only way I could see to make it work is to color code the parts (for color devices) or part-specific versions with tweaked formatting (a PITA to keep maintained, even with scripts).
Thanks, Bob. This sounds promising. I was not actually thinking of doing this with Javascript, but it seems a reasonable approach. It won't work with all viewers, of course, but presumably the markup will be there so that other display methods could also work.
We've avoided Javascript entirely as a mechanism for display. In this case, I think you're talking about a cool (and optional) way of doing speaker highlighting.
On the other hand, if it's going to be a nightmare to code and support (and seems likely to end up broken within a few years, as browser technology advances), then you could just do the HTML tags (such as an id= or similar), and not worry about having a built-in display.
More importantly, it would give us a much cleaner complete Shakespeare!
So we want this one kept together and not broken up into individual plays? Okay. I'm never quite sure how that gets decided.
I'm pretty sure we'll want to keep with one eBook per item (per play, anyway.... sonnets have usually been a single volume together). "Complete" would be a collection of separate PG eBook #s. -- Greg
-Bob [0] Not to mention the different input methods... a lot of the older e-ink devices have no touch screen or mouse equivalents, and are strictly menu based because of the slow refresh.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d