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