[kupu-dev] captioning, linking, and lightboxing, oh my!

[Jon Stahl]

Duncan Booth wrote:
> "Jon Stahl" <jon at onenw.org> wrote:
>
>   
>> If this is intended as a hook for lightbox, why not say so?  ;-)   And
>> why not include the lightbox js, css & supporting graphics with kupu?  
>>
>> As it is right now, if one naively turns on image captioning, images
>> suddently become clickable, which our users found unexpected and
>> confusing.  It felt like a bug to them. :-(
>>
>> Secondly, is it wise to pack lightboxing into the captioning 
>>     
> transform?
>   
Sorry, yes, that's what I meant.
>> Shouldn't lightboxing be selectable separately from captioning, and
>> perhaps implemented through a separate transform?  IOW, not everyone
>> would want both captioning and lightboxing, why not make them
>> independently selectable?
>>
>> Is there some other intent here that I'm missing?
>>
>>
>>     
> There are two parts to this: the simple one is that if you insert an 
> image which is reduced in size then it becomes a clickable link to the 
> fullsize image. I thought this was mentioned in CHANGES.txt (1.4rc2 was 
> when the captioning changes went in) but I guess I forgot to mention it 
> explicitly.
>   

Hmm.. yeah, I don't see it in 
http://codespeak.net/svn/kupu/trunk/kupu/doc/CHANGES.txt.

I'm -1 on this change.

Unless a lightbox effective is active, our  users don't expect images to 
be clickable.  Worse, when they click through to the full-size image, 
it's a dead-end.  There's no way out except to use the back button.  
That feels like a really rough edge, and it doesn't feel like it adds 
much value, at least not as a default behavior.

That said, I understand how having a <a> tag on an image is necessary 
for lightboxing.
> The other one is the lightbox support: the intention here was not to 
> force any particular lightbox implementations on a site, nor even to 
> force any lightbox implementation. Danny asked me to put this feature in 
> and I reckoned it would be harmless for those sites without the lightbox 
> js. I certainly don't want to propose shipping Plone with mootools 
> included: that is one bit of javascript I'm rapidly coming to dislike.
>   
Ah, that makes sense.  The basic "Lightbox" script doesn't use mootools, 
FYI, or any library at all, just its own little custom class.  There are 
other implementations that use Mootools, Prototype/Scriptaculous, and I 
don't doubt there's a jQuery implementation as well.  Not bundling one 
is probably wise, at least not until Plone chooses a default library to 
ship with.  (Privately, I'd bet on jQuery there.)

> I think that (at least in principle) you are correct that there should 
> be more options to configure the transform. So captioning, link to 
> fullsize image, and lightboxing could all be separate (though I think 
> the lightbox stuff needs the backlink so maybe each option implies the 
> earlier ones). The template is going to be more complex though, and I've 
> got a problem with unit tests at the moment (unit tests for captioning 
> are broken since I added the template, and I haven't figured out how to 
> fix them properly).
>   
Yes, I think that's the answer.  I think the options should be, 
conceptually:

Captioning: enables captioning, no link to full-size image.  Requires 
only linkbyUID.

Link to full-size image: adds the link.  Probably doesn't have to 
require captioning.  But it would be OK if it did.

Lightboxing: adds the rel tag, too.  Requires link to full size image 
enabled.  Help text informs you that you need to add an appropriate 
lighboxing javascript class/library.

In the meantime, I think slightly better documentation would solve the 
problem, since the transform is now so easy to configure/edit through 
the ZMI.

> The other thing is that, whether the transform is left as-is or 
> improved, the documentation needs improving.
>
> If you'd like, create an issue for this so that I don't forget to come 
> back to it.
>   
Thanks for the clarification.  I will create a ticket with these ideas.

Overall, I love the intent here, I'm just pushing for a slightly cleaner 
implementation that doesn't create odd out-of-the-box behaviors. :-)

When things get sorted a bit more, let me know, and I'll happily write 
some documentation!

best,
jon