Re: Seeking input on "top 100" collection
Jeroen Hellingman <[email protected]> Sat, 07 Sep 2013 14:03:00 +0200
| Newsgroups | gmane.culture.literature.e-books.gutenberg.volunteers |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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-4LCm/o+qPMZ96Xl/[email protected] > http://lists.pglaf.org/mailman/listinfo/gutvol-d > _______________________________________________ gutvol-d mailing list gutvol-d-4LCm/o+qPMZ96Xl/[email protected] http://lists.pglaf.org/mailman/listinfo/gutvol-d