CSS3 in Lightroom 4

In my previous article about the Lightroom 4 Public Beta, I described the new APE -- AIR Player Embedded -- web browser now being using by Lightroom's Web module to render the gallery preview. Since, I have been involved in conversations with a member of Adobe's team working on the Web module, and have been experimenting with various ways of overcoming the limitations inherent to APE's being built on an outdated version of the Webkit web browsing engine. And while my opinion of the browser is still that it's a step backward for Mac users in regard to CSS3 support, I have to admit it's a step forward or Windows users. And as I continue to find ways around APE's limitations, I am becoming more accepting of it.

Here I present our updated findings. There will be some good news here, and some things unchanged from my previous report (which we may understand to be bad news). I will wax technical here, so you may or may not find the specifics of interest.

border-radius support

I previously complained of APE's lack of support for the CSS3 border-radius property, used to create rounded corners. We have found that while APE does not offer support for the border-radius property, it does support the prefixed, experimental version of the property, -webkit-border-radius, which newer versions of Webkit no longer require.

This is excellent news, and means that I will be able to update my CE2 web engines to support rounded corners in the Web preview. I will begin work on this and will hopefully be able to deliver this support in the next round of updates.

box-shadow support

I previously reported that APE does support the CSS3 box-shadow property. Truth be told, APE does not support the proper box-shadow property, but does support the experimental -webkit-box-shadow property. This has no bearing on our CE2 releases, as we never stopped using -webkit-box-shadow, but I thought it worth mentioning in the interests of being comprehensive.

transition support

Running with our theme of experimental support, LR4 does not support the CSS3 transition property, but does support the experimental -webkit-transition property.

transform support

LR4 does not support the CSS3 transform property, but does support the experimental -webkit-transform property.

Background gradients

Gradients are complicated.

I previously reported that LR4 does not support CSS3 background gradients; this remains true in part. We have found that LR4 does support webkit's older, experimental implementation of background gradients, which varies wildly from the syntax used in all non-webkit browsers. This approach has been depreciated in newer versions of webkit as the CSS3 specification for gradients has evolved nearer to completion.

The older syntax will preview in LR4, and looks like this:

background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#666), to(#222));

The newer syntax will not preview in LR, and looks like this:

 background-image: -webkit-linear-gradient(90deg, #666, #222 100%);

In my opinion, while gradients may be made to preview in LR4, it is unwise to implement the older method of creating gradients. Reasoning follows.

The two syntax versions are fundamentally different, including several values which do not correlate from the older version to the new. For example, there is no direct correlation between or way of converting from the older x,y cooridinates (0% 0%, 0% 100%) to the new degree value (90deg) to control the direction of the gradient. A part of the problem is that this "newer" syntax is only new to webkit; other browsers had been using it all along. Using the older webkit syntax, it is difficult then to create a unified set of gradient controls which translate values to a format that can be used by all browsers, including non-webkit browsers such as Firefox. To do so would necessitate that we actually remove options from the CE2 gradient controls. Not cool, especially because we would then be removing options in service to an outdated, abandoned, experimental specification.

To downgrade gradients might also create conflicts or breakages in the future. The older webkit implementation being experimental, there is no way of knowing whether it will be understood or gracefully depreciated in future webkit versions. To rely upon the older gradient syntax now might cause published pages to break in future versions of Safari, Chrome or APE as Webkit continues to evolve.

In summary, I feel it would be damaging to support gradients within the Lightroom preview, as it would greatly restrict our gradient implementation in more current versions of both webkit and non-webkit browsers, and as it might introduce undesirable complications going forward. My stance at the moment is that background gradients should not be supported for the LR4 web preview as to do so would undermine gradient support for the Web at large.

@import support

From what I can tell, APE still offers no support for @import includes of stylesheets, and doesn't even provide a graceful fallback. Any attempt I have made to make use of @import has resulted in a completely blank preview; not even raw HTML will display, which is unusual to say the least. All stylesheets must be referenced from the <head> section of your HTML using old-fashioned <link> elements.

Live Update

Lightroom 4 introduces a new live update script. "Live update" dictates how the web preview updates in relation to the settings you dial into the web engine's controls. In my experience, I have found that live update is great for updating page styles, but not great for updating page structure. Because TTG engines rely heavily upon structural modifications for the implementation of various features, I have chosen to abandon live update in favor of manual page refreshing. Lightroom 4 does not change this decision, though it has changed how we implement it. For those of you out there who may be working on your own web engines, this is what you should know about live update:

1. Setting supportsLiveUpdate = false, in your galleryInfo.lrweb file will cause the engine to reload its preview following every adjustment made to gallery settings. This is the least desirable behavior for a web engine.

2. Setting supportsLiveUpdate = true, but including no live update script will cause the preview not to update when adjustments are made. Users should initiate a preview refresh manually by pressing CMD-R (Mac), CTRL-R (Win) or by selecting "Reload" from the Web menu. This is the method I prefer, and is deployed in TTG web engines. I also include an on-screen button in my preview that forces reload via Javascript; jQuery example:

<% --[[ Refresh Notice ]] %>
<% if mode == 'preview' then %>
<div id="refresh">
	<p id="refresh-content">Refresh</p>
	$('#refresh').click(function() { 
<% end %>

3. Those wishing to create web engines with live update support should set supportsLiveUpdate = true, and include both the older version live_update.js from LR3 and the newer version live_update.js from LR4. You can instruct the engine to load the appropriate live_update script by differentiating the LR version:

<% local LrApplication = import 'LrApplication'
if ( LrApplication.versionTable().major >= 4 ) then %>
<script type="text/javascript" src="$theRoot/resources/live_update.js"></script>
<% else %>
<script type="text/javascript" src="$theRoot/resources/live_update_old.js"></script>
<% end %>

In short, Lightroom 4 no longer presents any live_update conundrums; at least, no new conundrums. Live update behavior is back to normal in CE2 engines as of the 2012-01-12 CE2 product updates. In fact, LR4 has even cleaned up some of the live update bugs I had complained about in LR3. So if you're running the latest versions, you should be in good shape for using the LR4 Public Beta.


This has been a further exploration of Lightroom 4's APE web browser used to render previews in the Web module, and I hope the information presented here might be of use to some readers. While these explorations do help set to rest some of my fears and frustrations regarding the LR4 Web module, I maintain that the APE browser is not all that it could be or should be. Likely this will change in time. As APE continues to evolve and adopts newer versions of webkit, the situation will improve. Unfortunately, these improvements will come at the speed of Adobe, which is decidedly slower than the fast pace at which the Internet plunges forward. Very likely APE will always be several steps behind current browsers at any given time. But at some point, we might hope that its shortcomings will cease to be of concern for our purposes.

I must also thank Zhao Yu and Simon Chen at Adobe for maintaining an open dialogue with me regarding Lightroom 4's implementation of web-standards, and helping me to find ways of circumventing some of the road bumps in moving from LR3 to LR4.

2 Responses to “CSS3 in Lightroom 4”

  1. Nice, and quite useful, overview of the situation. Of course the Live Update version selection code looks really familiar 😉

    · January 14, 2012 @ 1:51 pm

    • Matt says:

      Of course! I ran with the version handed out by Adobe, though.

      · January 14, 2012 @ 2:52 pm

Comments are now closed.


The CE4 Web Publishing Suite

Welcome to The Turning Gate. Our plugins for Lightroom's Web module allow you to create mobile-friendly, fully responsive image galleries, websites, blog themes, shopping carts and more!

Learn more, or hit the shop!

Got Questions?

Get answers in the support forum.

Find Your Order

Can't find your download? Look it up.

Need Web Hosting?

Get affordable, reliable, TTG-certified hosting with Bluehost.

Need a Logo?

We've partnered with an award-winning graphic designer and brand consultant to offer Branding Services to our users.

TTG Recommends


Lightroom Queen

The Turning Gate receives a small portion of affiliate sales. This costs you nothing extra, but helps to support our work. Though compensated by affiliate relationships, The Turning Gate carefully chooses affiliates based upon the quality of services and products these entities provide to TTG users.