From maxm at mxm.dk  Mon Oct  1 12:35:26 2007
From: maxm at mxm.dk (Max M)
Date: Mon, 01 Oct 2007 12:35:26 +0200
Subject: [kupu-dev] Avoid filtering of specific attribute
In-Reply-To: <Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>
References: <fdj8bk$71s$1@sea.gmane.org>
	<Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>
Message-ID: <fdqihh$tcs$1@sea.gmane.org>

Duncan Booth skrev:

> includeTagAttributes('span', 'dynafield:view')
> 
> But I'm not sure that will work or if the unexpected namespace might cause 
> problems.

Turned out that I was close all the time:

editor.xhtmlvalid.setTagAttributes(['div','span'],['dynafield:uid','dynafield:view']);
editor.xhtmlvalid.setAttrFilter(['dynafield:uid']);
editor.xhtmlvalid.setAttrFilter(['dynafield:view']);

Det fik det til at k?re. I missed the setAttrFilter at first. I thought 
that would make it actually do filtering on the attribute not allow it.

-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science


From duncan.booth at suttoncourtenay.org.uk  Mon Oct  1 14:59:14 2007
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Mon, 1 Oct 2007 12:59:14 +0000 (UTC)
Subject: [kupu-dev] Avoid filtering of specific attribute
References: <fdj8bk$71s$1@sea.gmane.org>
	<Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>
	<fdqihh$tcs$1@sea.gmane.org>
Message-ID: <Xns99BC8E33ACC7Eduncanrcpcouk@127.0.0.1>

Max M <maxm at mxm.dk> wrote:

> Duncan Booth skrev:
> 
>> includeTagAttributes('span', 'dynafield:view')
>> 
> 
>> But I'm not sure that will work or if the unexpected namespace might
>> caus 
> e 
>> problems.
> 
> Turned out that I was close all the time:
> 
> editor.xhtmlvalid.setTagAttributes(['div','span'],['dynafield:uid','dyn
> afield:view']); editor.xhtmlvalid.setAttrFilter(['dynafield:uid']);
> editor.xhtmlvalid.setAttrFilter(['dynafield:view']);
> 
setTagAttributes overrides the permitted attributes for the tag: so you 
have said that div and span can *only* have your custom attributes.

I think you really do need includeTagAttributes (although with the 
parameters you used for setTagAttributes, not the ones I suggested).

> Det fik det til at k?re. I missed the setAttrFilter at first. I
> thought that would make it actually do filtering on the attribute not
> allow it. 

It does, it makes it filter the attribute instead of ignoring it. The 
default filter function just copies the attribute.


From maxm at mxm.dk  Tue Oct  2 18:51:29 2007
From: maxm at mxm.dk (Max M)
Date: Tue, 02 Oct 2007 18:51:29 +0200
Subject: [kupu-dev] Avoid filtering of specific attribute
In-Reply-To: <Xns99BC8E33ACC7Eduncanrcpcouk@127.0.0.1>
References: <fdj8bk$71s$1@sea.gmane.org>	<Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>	<fdqihh$tcs$1@sea.gmane.org>
	<Xns99BC8E33ACC7Eduncanrcpcouk@127.0.0.1>
Message-ID: <fdtsuk$cd3$1@sea.gmane.org>

Duncan Booth skrev:
> Max M <maxm at mxm.dk> wrote:
> 
>> Duncan Booth skrev:
>>
>>> includeTagAttributes('span', 'dynafield:view')
>>>
>>> But I'm not sure that will work or if the unexpected namespace might
>>> caus 
>> e 
>>> problems.
>> Turned out that I was close all the time:
>>
>> editor.xhtmlvalid.setTagAttributes(['div','span'],['dynafield:uid','dyn
>> afield:view']); editor.xhtmlvalid.setAttrFilter(['dynafield:uid']);
>> editor.xhtmlvalid.setAttrFilter(['dynafield:view']);
>>
> setTagAttributes overrides the permitted attributes for the tag: so you 
> have said that div and span can *only* have your custom attributes.


Hmmm .... yeah well I set it in 'kupuploneinit.js' and if I use 
includeTagAttributes I get an error: "this.tagAttributes[tag] has no 
properties" Seems that the attrs are not set at the time where I try to 
call includeTagAttributes.


>> Det fik det til at k?re. I missed the setAttrFilter at first. I
>> thought that would make it actually do filtering on the attribute not
>> allow it. 
> 
> It does, it makes it filter the attribute instead of ignoring it. The 
> default filter function just copies the attribute.

It does not work when I don't do it. But setting the attrfilter like 
that, also just copies.

I guess it probably doesn't work because I use setTagAttributes instead 
of includeTagAttributes.

-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science


From wouter at netcentric.be  Wed Oct  3 21:52:30 2007
From: wouter at netcentric.be (Wouter Vanden Hove)
Date: Wed, 03 Oct 2007 21:52:30 +0200
Subject: [kupu-dev] Avoid filtering of specific attribute
References: <fdj8bk$71s$1@sea.gmane.org>
	<Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>
	<fdqihh$tcs$1@sea.gmane.org>
Message-ID: <fe0rtp$kir$1@sea.gmane.org>

Max M wrote:

> Duncan Booth skrev:
> 
>> includeTagAttributes('span', 'dynafield:view')
>> 
>> But I'm not sure that will work or if the unexpected namespace might
>> cause problems.
> 
> Turned out that I was close all the time:
> 
> editor.xhtmlvalid.setTagAttributes(['div','span']
['dynafield:uid','dynafield:view']);
> editor.xhtmlvalid.setAttrFilter(['dynafield:uid']);
> editor.xhtmlvalid.setAttrFilter(['dynafield:view']);

This is the working solution?

in kupuinit.js there is:
kupu.xhtmlvalid.includeTagAttributes(['div'], ['*']);

this would mean that
<div dynafield:view="find_issn" class="dynafield">dynamisk</div>

should be working out-of-the-box? But this doesn't seem to be the case.


I have a very similar use-case, trying to get ZPTField working with kupu to
enable tags like this:
<span  tal:replace="here/title"> title </span>

what is the best way get disable the filtering for this?
edit kupucontentfilters.js or kupuinit.js?


-- 
Wouter Vanden Hove
Netcentric.be


From duncan.booth at suttoncourtenay.org.uk  Wed Oct  3 22:37:38 2007
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Wed, 3 Oct 2007 20:37:38 +0000 (UTC)
Subject: [kupu-dev] Avoid filtering of specific attribute
References: <fdj8bk$71s$1@sea.gmane.org>
	<Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>
	<fdqihh$tcs$1@sea.gmane.org> <fe0rtp$kir$1@sea.gmane.org>
Message-ID: <Xns99BEDBF98240Dduncanrcpcouk@127.0.0.1>

Wouter Vanden Hove <wouter at netcentric.be> wrote:

> I have a very similar use-case, trying to get ZPTField working with
> kupu to enable tags like this:
><span  tal:replace="here/title"> title </span>
> 
> what is the best way get disable the filtering for this?
> edit kupucontentfilters.js or kupuinit.js?

The best thing is to edit your initialisation javascript.
Max M implied that he is using the Plone version of kupu, so in his case 
kupuploneinit.js is the one to edit. YMMV


From maxm at mxm.dk  Thu Oct  4 13:00:06 2007
From: maxm at mxm.dk (Max M)
Date: Thu, 04 Oct 2007 13:00:06 +0200
Subject: [kupu-dev] Avoid filtering of specific attribute
In-Reply-To: <fe0rtp$kir$1@sea.gmane.org>
References: <fdj8bk$71s$1@sea.gmane.org>	<Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>	<fdqihh$tcs$1@sea.gmane.org>
	<fe0rtp$kir$1@sea.gmane.org>
Message-ID: <fe2h44$huk$1@sea.gmane.org>

Wouter Vanden Hove skrev:
> Max M wrote:
> 
>> Duncan Booth skrev:
>>
>>> includeTagAttributes('span', 'dynafield:view')
>>>
>>> But I'm not sure that will work or if the unexpected namespace might
>>> cause problems.
>> Turned out that I was close all the time:
>>
>> editor.xhtmlvalid.setTagAttributes(['div','span']
> ['dynafield:uid','dynafield:view']);
>> editor.xhtmlvalid.setAttrFilter(['dynafield:uid']);
>> editor.xhtmlvalid.setAttrFilter(['dynafield:view']);
> 
> This is the working solution?

Not really. Turned out that Duncan was right. That way it only allows 
those two attributes in divs and spans. So something like the class 
would be filtered out :-s


> I have a very similar use-case, trying to get ZPTField working with kupu to
> enable tags like this:
> <span  tal:replace="here/title"> title </span>
> 
> what is the best way get disable the filtering for this?
> edit kupucontentfilters.js or kupuinit.js?

I will let you know when I find out :-)


-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science


From maxm at mxm.dk  Thu Oct  4 14:01:21 2007
From: maxm at mxm.dk (Max M)
Date: Thu, 04 Oct 2007 14:01:21 +0200
Subject: [kupu-dev] Avoid filtering of specific attribute
In-Reply-To: <fe0rtp$kir$1@sea.gmane.org>
References: <fdj8bk$71s$1@sea.gmane.org>	<Xns99B9BB73382CBduncanrcpcouk@127.0.0.1>	<fdqihh$tcs$1@sea.gmane.org>
	<fe0rtp$kir$1@sea.gmane.org>
Message-ID: <fe2kmv$u5v$1@sea.gmane.org>

Wouter Vanden Hove skrev:

> what is the best way get disable the filtering for this?
> edit kupucontentfilters.js or kupuinit.js?

Ok. The only solution I can think of is this:

this.initialize = function(editor) {
     // The initialize method is called automaticaly by Kupu
     // This is where we add the event handler.
     this.editor = editor;
     var allowedAttrs = ['class', 'dynafield:uid','dynafield:view']
     var validator = editor.xhtmlvalid;
     validator.setTagAttributes(['span'],allowedAttrs);
     validator.setAttrFilter(allowedAttrs);
     addEventHandler(this.button, 'change', this.execCommand, this);
     // make the dynafield tags valid.
};


This way a span will keep the attributes in 'allowedAttrs'. I could not 
find another way to set it.

includeTagAttributes will not work, as span and div does not have any 
attributes set to begin with.

But on the other hand it is pretty simple to add additional attributes 
in that list.

If this is a hack, so be it. I cannot use more time on the problem now 
:-s If anybody figures out a more correct approach, please let me know ...

-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science


From duncan.booth at suttoncourtenay.org.uk  Thu Oct  4 17:24:22 2007
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Thu, 4 Oct 2007 15:24:22 +0000 (UTC)
Subject: [kupu-dev] Avoid filtering of specific attribute
References: <fe0rtp$kir$1@sea.gmane.org> <fe2kmv$u5v$1@sea.gmane.org>
Message-ID: <Xns99BFA1B259970duncanrcpcouk@127.0.0.1>

Max M <maxm at mxm.dk> wrote:

> includeTagAttributes will not work, as span and div does not have any 
> attributes set to begin with.
> 

That's news to me. They should have a load of attributes set to begin with: 
kupucontentfilters sets them both up with attributes id, title, style, 
class, lang, dir, xml:lang, plus align for div but not span.


From maxm at mxm.dk  Fri Oct  5 11:11:24 2007
From: maxm at mxm.dk (Max M)
Date: Fri, 05 Oct 2007 11:11:24 +0200
Subject: [kupu-dev] Avoid filtering of specific attribute
In-Reply-To: <Xns99BFA1B259970duncanrcpcouk@127.0.0.1>
References: <fe0rtp$kir$1@sea.gmane.org> <fe2kmv$u5v$1@sea.gmane.org>
	<Xns99BFA1B259970duncanrcpcouk@127.0.0.1>
Message-ID: <fe4v4g$7lo$1@sea.gmane.org>

Duncan Booth skrev:
> Max M <maxm at mxm.dk> wrote:
> 
>> includeTagAttributes will not work, as span and div does not have any 
>> attributes set to begin with.
>>
> 
> That's news to me. They should have a load of attributes set to begin with: 
> kupucontentfilters sets them both up with attributes id, title, style, 
> class, lang, dir, xml:lang, plus align for div but not span.

Ok. That makes sense.

But if I try to write

      validator.includeTagAttributes(['span'],allowedAttrs);

Instead of

      validator.setTagAttributes(['span'],allowedAttrs);

I get the error

     this.tagAttributes[tag] has no properties

And this happens in kupucontentfilters.js::

     // define some new attributes for existing tags
     this.includeTagAttributes = function(tags, attributes) {
         for (var j = 0; j < tags.length; j++) {
             var tag = tags[j];
             this.tagAttributes[tag] = 
this.tagAttributes[tag].concat(attributes);
         }
     }

So at least when I am trying to call it in kupuploneinit.js in function 
initPloneKupu(), it is not possible to use includeTagAttributes. 
Seemably because it has no prior attributes set.

-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science


From duncan.booth at suttoncourtenay.org.uk  Fri Oct  5 15:38:46 2007
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 5 Oct 2007 13:38:46 +0000 (UTC)
Subject: [kupu-dev] Avoid filtering of specific attribute
References: <fe0rtp$kir$1@sea.gmane.org> <fe2kmv$u5v$1@sea.gmane.org>
	<Xns99BFA1B259970duncanrcpcouk@127.0.0.1>
	<fe4v4g$7lo$1@sea.gmane.org>
Message-ID: <Xns99C094D181E77duncanrcpcouk@127.0.0.1>

Max M <maxm at mxm.dk> wrote:

> So at least when I am trying to call it in kupuploneinit.js in
> function initPloneKupu(), it is not possible to use
> includeTagAttributes. Seemably because it has no prior attributes set.
> 
Very strange. I just added a line:

    	kupu.xhtmlvalid.includeTagAttributes(['span'],['random']);

to kupuploneinit.js right after the line:
      kupu.setHTMLBody(initialtext);

and it works fine for me. I stepped through the code as well, and it all 
executes quite happily.



From robichon at esrf.fr  Mon Oct 15 10:53:58 2007
From: robichon at esrf.fr (Marie Robichon)
Date: Mon, 15 Oct 2007 10:53:58 +0200
Subject: [kupu-dev] style definition in table of contents
Message-ID: <fev9r6$hm4$1@ger.gmane.org>

Hi everyone,

why is it that in the anchor dialog box I have the possibility to select 
one of my defined styles for the table of contents, but this style is 
not kept once I have saved my page?

Even before saving when I look at the html once I have defined my table 
I do not see where my style is declared, I just see

<ul><li class="level0"> etc

I have tried adding a line mystyle|span|mystyle or mystyle|ul|mystyle in 
the config but this doesn't see to make any difference.

What do I have to do to ensure that the style is kept?  Where does kupu 
store the table of contents style info before the save?

Thanks in advance for your help

Marie


From sune at headnet.dk  Tue Oct 16 11:22:45 2007
From: sune at headnet.dk (Sune Toft - Headnet)
Date: Tue, 16 Oct 2007 11:22:45 +0200
Subject: [kupu-dev] Kupu shortcuts
In-Reply-To: <Xns99C094D181E77duncanrcpcouk@127.0.0.1>
References: <fe0rtp$kir$1@sea.gmane.org>
	<fe2kmv$u5v$1@sea.gmane.org>	<Xns99BFA1B259970duncanrcpcouk@127.0.0.1>	<fe4v4g$7lo$1@sea.gmane.org>
	<Xns99C094D181E77duncanrcpcouk@127.0.0.1>
Message-ID: <471482E5.5000201@headnet.dk>

Hi :)

Is there a overview of kupu keyboard-shortcuts somewhere ?

br
/sune


Duncan Booth skrev:
> Max M <maxm at mxm.dk> wrote:
>
>   
>> So at least when I am trying to call it in kupuploneinit.js in
>> function initPloneKupu(), it is not possible to use
>> includeTagAttributes. Seemably because it has no prior attributes set.
>>
>>     
> Very strange. I just added a line:
>
>     	kupu.xhtmlvalid.includeTagAttributes(['span'],['random']);
>
> to kupuploneinit.js right after the line:
>       kupu.setHTMLBody(initialtext);
>
> and it works fine for me. I stepped through the code as well, and it all 
> executes quite happily.
>
>
> _______________________________________________
> kupu-dev mailing list
> kupu-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/kupu-dev
>
>   

-- 
========================
Sune Toft
Partner, Projektleder

Headnet ApS
Fruebjergvej 3
Symbion Science Park - Box 50
2100 K?benhavn ?.

Telefon: +45 3917 9750
Fax: +45 3917 9751
Mobil: +45 2943 9585

http://www.headnet.dk
sune at headnet.dk
=======================

Headnet - devoted to Plone
http://www.plone.org
Vinder af "Bedst til Nettet" 2005 - 2006
http://bedstpaanettet.dk 

 

 


From duncan.booth at suttoncourtenay.org.uk  Wed Oct 17 13:59:12 2007
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Wed, 17 Oct 2007 11:59:12 +0000 (UTC)
Subject: [kupu-dev] Kupu shortcuts
References: <fe0rtp$kir$1@sea.gmane.org>
	<Xns99C094D181E77duncanrcpcouk@127.0.0.1>
	<471482E5.5000201@headnet.dk>
Message-ID: <Xns99CC827B9FADBduncanrcpcouk@127.0.0.1>

Sune Toft - Headnet <sune at headnet.dk> wrote:

> Hi :)
> 
> Is there a overview of kupu keyboard-shortcuts somewhere ?
> 

Not that I am aware of.


From sisi at foei.org  Thu Oct 18 11:57:20 2007
From: sisi at foei.org (sisi)
Date: Thu, 18 Oct 2007 11:57:20 +0200
Subject: [kupu-dev] style definition in table of contents
In-Reply-To: <fev9r6$hm4$1@ger.gmane.org>
References: <fev9r6$hm4$1@ger.gmane.org>
Message-ID: <47172E00.3020202@foei.org>


Hi Marie,

Marie Robichon wrote:
> Hi everyone,
> 
> why is it that in the anchor dialog box I have the possibility to select 
> one of my defined styles for the table of contents, but this style is 
> not kept once I have saved my page?

Did you put your style in the Style Whitelist?

Cheers,
sisi

> Even before saving when I look at the html once I have defined my table 
> I do not see where my style is declared, I just see
> 
> <ul><li class="level0"> etc
> 
> I have tried adding a line mystyle|span|mystyle or mystyle|ul|mystyle in 
> the config but this doesn't see to make any difference.
> 
> What do I have to do to ensure that the style is kept?  Where does kupu 
> store the table of contents style info before the save?
> 
> Thanks in advance for your help
> 
> Marie
> 
> _______________________________________________
> kupu-dev mailing list
> kupu-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/kupu-dev

-- 
# sisi nutt # extranet coordinator
# Friends of the Earth International
# PO Box 19199 # 1000 GD Amsterdam # The Netherlands
# Tel 31 20 6221369  # Fax 31 20 6392181  # http://www.foei.org
# email sisi at foei.org # skype foei_sisi

From robichon at esrf.fr  Thu Oct 18 13:50:35 2007
From: robichon at esrf.fr (Marie ROBICHON)
Date: Thu, 18 Oct 2007 13:50:35 +0200
Subject: [kupu-dev] style definition in table of contents
In-Reply-To: <47172E00.3020202@foei.org>
References: <fev9r6$hm4$1@ger.gmane.org> <47172E00.3020202@foei.org>
Message-ID: <4717488B.2060300@esrf.fr>

Hi Sisi,

No this doesn't make any difference - anyway the style is included in
the styles list in the kupu configuration so should already be
considered as on the whitelist.

Thx

Marie

sisi wrote:
>
> Hi Marie,
>
> Marie Robichon wrote:
>> Hi everyone,
>>
>> why is it that in the anchor dialog box I have the possibility to 
>> select one of my defined styles for the table of contents, but this 
>> style is not kept once I have saved my page?
>
> Did you put your style in the Style Whitelist?
>
> Cheers,
> sisi
>
>> Even before saving when I look at the html once I have defined my 
>> table I do not see where my style is declared, I just see
>>
>> <ul><li class="level0"> etc
>>
>> I have tried adding a line mystyle|span|mystyle or mystyle|ul|mystyle 
>> in the config but this doesn't see to make any difference.
>>
>> What do I have to do to ensure that the style is kept?  Where does 
>> kupu store the table of contents style info before the save?
>>
>> Thanks in advance for your help
>>
>> Marie
>>
>> _______________________________________________
>> kupu-dev mailing list
>> kupu-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/kupu-dev
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: robichon.vcf
Type: text/x-vcard
Size: 277 bytes
Desc: not available
Url : http://codespeak.net/pipermail/kupu-dev/attachments/20071018/353b2549/attachment.vcf 

From jon at onenw.org  Fri Oct 26 00:03:12 2007
From: jon at onenw.org (Jon Stahl)
Date: Thu, 25 Oct 2007 15:03:12 -0700
Subject: [kupu-dev] what's up with the new "lightbox" hook in the captioning
	transform?
Message-ID: <79EDBCCCD70E25499369860FC555BBFAB81A47@bunnyluv.onenorthwest.office>

Duncan-

We just noticed in Kupu 1.4.3 that if one enables the captioning
transform (which we are pleased to see is now in a ZMI-configurable
template -- thanks!!!), we get a few extra little bits that weren't
there before, namely:

-- an <a href="path to original image> tag on the image
-- a <rel="lightbox"> tag on the image

To me, this looks like a hook for the well-known "Lightbox JS" script.
(http://www.huddletogether.com/projects/lightbox/)

Way cool!

But... a couple of questions:

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?
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?


best,
jon

--------------------------
Jon Stahl | Program Manager

ONE/Northwest
 New tools and strategies for engaging people in protecting the
environment

www.onenw.org
jon at onenw.org
206-286-1235x15
http://blogs.onenw.org/jon

Subscribe to ONEList, our email newsletter!
 Practical advice for effective online engagement
  http://www.onenw.org/full_signup
 
 
 

From duncan.booth at suttoncourtenay.org.uk  Fri Oct 26 14:03:40 2007
From: duncan.booth at suttoncourtenay.org.uk (Duncan Booth)
Date: Fri, 26 Oct 2007 12:03:40 +0000 (UTC)
Subject: [kupu-dev] what's up with the new "lightbox" hook in the
	captioning transform?
References: <79EDBCCCD70E25499369860FC555BBFAB81A47@bunnyluv.onenorthwest.office>
Message-ID: <Xns99D57D1A8C91Bduncanrcpcouk@127.0.0.1>

"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?
> 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.

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.

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).

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.



From jon at onenw.org  Fri Oct 26 20:55:58 2007
From: jon at onenw.org (Jon Stahl)
Date: Fri, 26 Oct 2007 11:55:58 -0700
Subject: [kupu-dev] captioning, linking, and lightboxing, oh my!
In-Reply-To: <Xns99D57D1A8C91Bduncanrcpcouk@127.0.0.1>
References: <79EDBCCCD70E25499369860FC555BBFAB81A47@bunnyluv.onenorthwest.office>
	<Xns99D57D1A8C91Bduncanrcpcouk@127.0.0.1>
Message-ID: <4722383E.8090509@onenw.org>

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