Several sites have been reporting problems after upgrading past 7.7.15, where the new templates where installed.  The problems arise from the <div> tag that was added to the default Image Asset template.

For example, where users used to do this:

<a href="#" removed="javascriptStuff">^AssetProxy(myImageAsset);</a>

The div from the image asset causes the anchor tag to have no area.  You can see this on PlainBlack.com, with the search button in the top right hand corner.

I understand the problem. One could argue that in this case a different template should be made, because the main use of the image asset is putting images on a page and there the div is useful for positioning, styling etc.

(One could also argue that the image should be a background image, but let's not go there :-)

Do you have any more examples? I can't think of anything fundamentally different than this, where the problem is a block element being put inside an inline element.

There is a workaround, using the FileUrl macro, but then you lose the asset features like title, parameters, etc.

I'd like to revisit the rationale for adding the div, or, to have a set of recommended practices for using the Image Asset with its new templates.

OK, let's list our options.

Option 1: keep the div

• Pros: consistency. Currently all templates have a containing div with standard classname(s) and ID and an anchor. And: a wrapper element makes styling easier and gives you more styling flexibility.
• Cons: image can't be put in an inline element, which is used om some existing sites.

Option 2: use a span instead of a div

• Pros: a span is an inline element, so the plainblack.com problem would be solved.
• Cons: inconsistency.

Option 3: remove the div alltogether (and add the class and id to the img tag)

• Pros: the template will just serve an img tag, which makes it predictable and easy to use with and AssetProxy.
• Cons: inconsistency, not having a wrapper element.

Regarding a set of recommended practices: let's make a wiki entry anyway, regardless of what we decide. Since the image template either breaks with consistency or it behaves differently from the previous one. In both cases some documentation would be nice.

I would prefer option 1 + documentation, because I find that consistency and flexibility outweigh a few cases of failed backwards compatibility.

But 3 would be acceptable I guess: an image is an image is an Image Asset.

Any other ideas?

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl

How about option 1a:

Option 1a: keep the div, write some documentation, supply a 2nd template for AssetProxy

• Pros: Same as Option 1. Also, with the 2nd template, allows usage with AssetProxy.
• Cons: It would not be possible to have an Image as part of a page, and to be used in an AssetProxy if the Proxied usage required embedding the Image in an inline element.  Also, must maintain two templates.

Is a good option. The scenario of having an image on an page and in an AssetProxy is probably less likely. And maintaining a template with only an img tag isn't much work at all.

And if it should be necessary to use the same image on a page and in an AP, it can be done with a shortcut or uploaded twice.

I assume you want a solution that includes a div-less template, because bugs have been reported and "we made a template for you to fix this" would sound much nicer than "you'll have to make new template to fix something that's worked before."

So the current template becomes "Image block" (or something similar) and the "Default Image" will be just an img tag: no div, no anchor (you don't need that either if you use it inline).

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl

So the current template becomes "Image block" (or something similar) and the "Default Image" will be just an img tag: no div, no anchor (you don't need that either if you use it inline).

This sounds like the most practical option to me.

Tessa Harmon

Knowmad Technologies

http://www.webgui.org/wiki/image-asset-templates

Rogier | United Knowledge
www.unitedknowledge.nl · www.webgui-help.nl