[Pro] Relative Page Layout PAGE SHADOW Woes

I previously spoke about this problem in the following thread:
http://freewaytalk.net/thread/view/43023#m_124545

But since not a single soul has replied back to me there, I decided to start this new thread in hopes of grabbing much needed attention.

Simply put, adding the RPL Action to my page messes up my page shadow. Killing RPL fixes it. But there are cases where I need to use RPL, hence my plead to you good people to help me!

Here’s a single page sample document, with instructions, that allows you to reproduce the problem yourself:

http://www.kiramek.com/21test95/RPL_Shadow_Prob.zip

And here are screen shots showing you the GOOD shadow, BAD shadow, and the HTML Markup I used:




The reason this is even an issue is because I want the page shadow OFFSET downward a bit. But the shadow overshoots the bottom of the page too much when I do that, and it looks really stupid. So to fix that, I’ve added the HTML Markup code you see in “PageShadowMarkup_B.jpg”. The problem is, for reasons unknown to me, the RPL Action ignores that code! So my question is, what’s the workaround to get RPL to recognize the code that makes the shadow at the bottom of my page look correct?

I look forward to your detailed replies! :slight_smile:

Thank you!

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Probably not much help here, but have you just tried simply using the built in action for the drop shadow and not coding it? It might make a difference, who knows.

Trev

On 22 Feb 2013, at 09:01, JDW wrote:

I previously spoke about this problem in the following thread:
http://freewaytalk.net/thread/view/43023#m_124545

But since not a single soul has replied back to me there, I decided to start this new thread in hopes of grabbing much needed attention.

Simply put, adding the RPL Action to my page messes up my page shadow. Killing RPL fixes it. But there are cases where I need to use RPL, hence my plead to you good people to help me!

Here’s a single page sample document, with instructions, that allows you to reproduce the problem yourself:

http://www.kiramek.com/21test95/RPL_Shadow_Prob.zip

And here are screen shots showing you the GOOD shadow, BAD shadow, and the HTML Markup I used:

http://www.kiramek.com/21test95/NoRPL_NoShadowProblem.jpg
http://www.kiramek.com/21test95/RPLused_ShadowProblem.jpg
http://www.kiramek.com/21test95/PageShadowMarkup_A.jpg
http://www.kiramek.com/21test95/PageShadowMarkup_B.jpg

The reason this is even an issue is because I want the page shadow OFFSET downward a bit. But the shadow overshoots the bottom of the page too much when I do that, and it looks really stupid. So to fix that, I’ve added the HTML Markup code you see in “PageShadowMarkup_B.jpg”. The problem is, for reasons unknown to me, the RPL Action ignores that code! So my question is, what’s the workaround to get RPL to recognize the code that makes the shadow at the bottom of my page look correct?

I look forward to your detailed replies! :slight_smile:

Thank you!

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Trev,

Even though I have Freeway 6, I am still using Freeway 5.6.5 for the time being on my big sites. The “built-in” shadow you are referring to is new to Freeway 6. However, that new Freeway 6 CSS3 shadow feature isn’t a solution for me because it does not have PIE fallback. And because my business is located in Japan where the vast majority of our visitors still use Internet Explorer, having fall back for CSS3 effects is very important. Using Walter Davis CSS3 Suite and using my code affords me such fall back, ensuring the shadow will appear in older browsers like IE7 and IE8.

You can learn more about PIE here:

http://css3pie.com/

Even if I were to use Freeway 6’s CSS3 shadow, I would still need the same code I use now, shown here:

Try it yourself in Freeway 6.

  1. Sketch an HTML box the same size as the page and color it.
  2. Now shrink the vertical size of your box, from the very top, down about 15px or so. That mimics my design.
  3. Inspector > Item Appearance Settings > Shadow
  4. Make it Black, Opacity 75%, 0° Global Angle, Offset 19px, Blur 11px, Spread 4px.
  5. Preview and note how the shadow overshoots the bottom of the page excessively and looks stupid. It only looks reasonably nice when the thickness of the shadows all match. It becomes strange if the shadow at bottom becomes much thicker than the width of the shadows at the sides of the page.

But again, I prefer to do it the way I am doing it now because my way has PIE fallback.

If anyone else has any ideas, I am open to hearing them!

Thanks,

James W.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi James,

The simplest solution would be to remove the empty placeholder item and make the height of the shadow item 774px (or thereabouts, you might want to play with the value a little). This accounts for the 29px vertical offset you have applied to the shadow item (which is why the shadow was sticking out the bottom so far).

Joe

On 22 Feb 2013, at 09:46, JDW email@hidden wrote:

Hi Trev,

Even though I have Freeway 6, I am still using Freeway 5.6.5 for the time being on my big sites. The “built-in” shadow you are referring to is new to Freeway 6. However, that new Freeway 6 CSS3 shadow feature isn’t a solution for me because it does not have PIE fallback. And because my business is located in Japan where the vast majority of our visitors still use Internet Explorer, having fall back for CSS3 effects is very important. Using Walter Davis CSS3 Suite and using my code affords me such fall back, ensuring the shadow will appear in older browsers like IE7 and IE8.

You can learn more about PIE here:

http://css3pie.com/

Even if I were to use Freeway 6’s CSS3 shadow, I would still need the same code I use now, shown here:

http://www.kiramek.com/21test95/PageShadowMarkup_B.jpg

Try it yourself in Freeway 6.

  1. Sketch an HTML box the same size as the page and color it.
  2. Now shrink the vertical size of your box, from the very top, down about 15px or so. That mimics my design.
  3. Inspector > Item Appearance Settings > Shadow
  4. Make it Black, Opacity 75%, 0° Global Angle, Offset 19px, Blur 11px, Spread 4px.
  5. Preview and note how the shadow overshoots the bottom of the page excessively and looks stupid. It only looks reasonably nice when the thickness of the shadows all match. It becomes strange if the shadow at bottom becomes much thicker than the width of the shadows at the sides of the page.

But again, I prefer to do it the way I am doing it now because my way has PIE fallback.

If anyone else has any ideas, I am open to hearing them!

Thanks,

James W.


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Joe,

Thank you for the suggestion. However, the item named “Placeholder” is actually being used in conjunction with Paul Dunning’s “make me into a page footer” action. In this particular case, that empty HTML box is not being used as a footer; rather, I am using it to deliberately add space between the very bottom of my page and the bottom of the browser window. Without using that action, the very bottom of my page would slam right up against the very bottom of the browser window, and in such a case you could not see the shadow at the bottom of the page at all.

You can see how the bottom of my webpages are supposed to look in terms of shadow and spacing, by examining other pages in my site which do not use the RPL action:

So what do you suggest in light of this?

Thank you,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Joe, this screen shot shows a problem that results when setting outerShadow to a height shorter than the page contents (when RPL is used, of course):

Again, I look forward to hearing further thoughts and ideas.

Thank you,

–James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi James,

The placeholder item is at the bottom of the page, behind all the content (screenshot: http://cl.ly/image/3H262o0w2a3S). I was under the impression that the “MakeMeIntoFooter60px” item was solely responsible for adding the extra spacing. In fact, in my tests, leaving the empty item at the bottom of the page resulted in exactly the same thing that you’re seeing. Removing it makes the page work correctly, as you can see here: http://users.softpress.com/joe/jw/

Joe

On 26 Feb 2013, at 00:27, JDW email@hidden wrote:

Joe, this screen shot shows a problem that results when setting outerShadow to a height shorter than the page contents (when RPL is used, of course):

http://kiramek.com/21test95/outerShadow_774px_Test.pdf

Again, I look forward to hearing further thoughts and ideas.

Thank you,

–James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi Joe,

That’s interesting. The way Paul setup his action is that it needs a non-layered HTML box for pages without the RPL action, and for pages with RPL, the action looks for a layered HTML box (immediately below which it will drop in that 60px spacer box). So it seems that in this particular test, Paul’s action is using another HTML box to do its job.

Okay, I see the shadow looks right now, and there is a nice 60px of space between the bottom of the page and the bottom of the browser window. And for my test document, that’s all one needs to worry about. But one the pages in my site where I have RPL applied, I have a large text box that expands the vertical height of the page as its content grows. More specifically, I am using an HTML markup item in Freeway to dump in Atomz Search results.

You can simulate that effect in my test document simply by setting the “INSTRUCTIONS” HTML box to Publish, then Preview, then click the big “A” a few times to bump the text size up. Note that the page elongates beyond the shadow, making it look odd. How does one go about making sure the shadow follows the page as it shrinks or elongates?

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

To do that you’d need to use a different shadow effect, or use inline layout (which I would recommend upgrading the site to Freeway 6 for the greater control).

The problem is that the effect you’re going for (the shadow extending out all sides other than the top) requires the containing item (the one with the shadow) to be smaller than the child items, causing the RPL Action to determine that the items are siblings, and not parent/child.

Joe

On 26 Feb 2013, at 09:22, “JDW” email@hidden wrote:

Hi Joe,

That’s interesting. The way Paul setup his action is that it needs a non-layered HTML box for pages without the RPL action, and for pages with RPL, the action looks for a layered HTML box (immediately below which it will drop in that 60px spacer box). So it seems that in this particular test, Paul’s action is using another HTML box to do its job.

Okay, I see the shadow looks right now, and there is a nice 60px of space between the bottom of the page and the bottom of the browser window. And for my test document, that’s all one needs to worry about. But one the pages in my site where I have RPL applied, I have a large text box that expands the vertical height of the page as its content grows. More specifically, I am using an HTML markup item in Freeway to dump in Atomz Search results.

You can simulate that effect in my test document simply by setting the “INSTRUCTIONS” HTML box to Publish, then Preview, then click the big “A” a few times to bump the text size up. Note that the page elongates beyond the shadow, making it look odd. How does one go about making sure the shadow follows the page as it shrinks or elongates?

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I follow you, Joe. But since I want to retain the existing shadow effect, even if I change to a 100% inline layout in Freeway 6, wouldn’t the shadow box still need to be shorter than the other items? Or would the JavaScript hack work in that case? (The JS hack doesn’t work on the page when the RPL action is used. That hack keeps the shadow at the bottom of the page from overshooting the bottom of the page.)

I attempted a completely inline layout once in the past and failed, which is why I was hoping the RPL action would be my savior. The fiddly part is that I am pasting an HTML markup item inside an HTML box, and the markup item will contain my Atomz search results. The results could contain nothing or many lines of information (causing the page to elongate).

–James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

This is what the inline layout was made for – the signature reason for its very existence!

Walter

On Feb 26, 2013, at 6:17 AM, JDW wrote:

The fiddly part is that I am pasting an HTML markup item inside an HTML box, and the markup item will contain my Atomz search results. The results could contain nothing or many lines of information (causing the page to elongate).


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

I follow you, Walter. But your words certainly don’t make a good case for the existence of the Relative Page Layout action! :slight_smile: Logic dictates that the RPL action exists for the very reason that manual labor involved in creating a fully inline layout is not a 2-second job.

So my personal feeling is, if the RPL action is truly supposed to recreate a fully inline layout for us, then the RPL action should accomplish the same thing as if I were to spent all that time making a manual layout. Don’t you agree?

As such, I am wondering if there is some existing limitation in the RPL that perhaps could be addressed, such that I can achieve my aims without being forced to move to a fully inline layout. For as I said earlier, I tried that once in the past and failed to accomplish my aim (with respect to page shadow looking correct).

I will give a fully inline layout on my Atomz search page another shot right now and report back. But I still feel that if the RPL action is suppose to give us a fully inline layout, we should examine what needs to be improved in the RPL action to make that dream a reality.

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

On Feb 26, 2013, at 7:19 PM, JDW wrote:

I follow you, Walter. But your words certainly don’t make a good case for the existence of the Relative Page Layout action! :slight_smile: Logic dictates that the RPL action exists for the very reason that manual labor involved in creating a fully inline layout is not a 2-second job.

So my personal feeling is, if the RPL action is truly supposed to recreate a fully inline layout for us, then the RPL action should accomplish the same thing as if I were to spent all that time making a manual layout. Don’t you agree?

In principle, yes. In practice, well… There’s this thing called the 80/20 rule, where 80% of the users use 20% of the application. The goal (some would say the trick) when developing an application is to concentrate your efforts where you believe that 20% actually is.

There’s a lot of code in RPL, and a lot of assumptions and “guesses” that it absolutely must make, since it cannot read your mind. (You should spend a little time in the RPL Action’s source code – that’s a masterful job that Joe has done, in JavaScript, to reverse-engineer the inline layout from an absolute positioned Freeway layout! I only understand a fraction of how it works under the hood.)

Having spent a lot of time writing pages by hand, and wrestling Freeway 5 to the ground to make it create an inline layout, I am frankly staggered that it works at all. Considering how well it does most things, and how little time Joe and co have to work on it, I would hope that you could cut it some slack.

Your accept-no-compromises approach to design does yield some stunning results, but you may be blaming the wrong tool here when your layout – which is very nice, but well outside of the mainstream of what Freeway can do on its own – fails to translate perfectly from your ideal to the real world.

As such, I am wondering if there is some existing limitation in the RPL that perhaps could be addressed, such that I can achieve my aims without being forced to move to a fully inline layout. For as I said earlier, I tried that once in the past and failed to accomplish my aim (with respect to page shadow looking correct).

I will give a fully inline layout on my Atomz search page another shot right now and report back. But I still feel that if the RPL action is suppose to give us a fully inline layout, we should examine what needs to be improved in the RPL action to make that dream a reality.

I hope that this time around it works out better for you. It’s one of those things where once the penny drops, you will be wondering why you put it off for so long. Freeway 6 is SO much better than 5 when it comes to inline elements. Hopefully that will be the leg up that you need to get it to work for you.

Walter

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Walter, please know that I’ve read and noted the comments made in your last post. And to Joe and the rest of the SoftPress team, I publicly would like to say that appreciate the work involved in making the RPL action a reality. I never sought to appear ungrateful. Nevertheless, my second attempted at a fully inline Atomz search page has failed; and yes, I was using Freeway 6.0.3.

Here are screen shots of Freeway’s PAGE view and PREVIEW:


And here is the Freeway document (both FW5 and FW6 versions, although the FW6 doc is the one you should fiddle with):
http://www.kiramek.com/21test95/AtomzSearchPageTest.zip

As you can see, I now have a bigger mess on my hands than before. If someone can take me by the hand and guide me toward INLINE PARADISE, I would be grateful.

Two Notes:

  1. I cannot get Paul Dunning’s MakeMeAFooter action to do its job on my fully inline page in Freeway 6. As such, I cannot achieve my aim of getting a 60px height invisible spacer between the very bottom of my page and the bottom of the browser window. (If you examine my FW6 doc, you will see that item rests atop the page, and it is set to not Publish because I cannot get it to display on Preview.)

  2. If you Preview the RPL page in my FW5 doc in FW5.6.5, and then if you Preview the same RPL page in my FW6 doc in FW6.0.3, there are some surprising differences. The Preview in FW6 is worse because the leftmost field and rightmost copyright text are popped out and downward in FW6, but the remain perfectly in place in FW5.

I look forward to your reply.

Thank you,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

On Feb 26, 2013, at 8:39 PM, JDW wrote:

Walter, please know that I’ve read and noted the comments made in your last post. And to Joe and the rest of the SoftPress team, I publicly would like to say that appreciate the work involved in making the RPL action a reality. I never sought to appear ungrateful. Nevertheless, my second attempted at a fully inline Atomz search page has failed; and yes, I was using Freeway 6.0.3.

Here are screen shots of Freeway’s PAGE view and PREVIEW:

http://kiramek.com/21test95/FW6_InlineLayout_PageView.jpg
http://kiramek.com/21test95/FW6_InlineLayout_Preview.jpg

And here is the Freeway document (both FW5 and FW6 versions, although the FW6 doc is the one you should fiddle with):
http://www.kiramek.com/21test95/AtomzSearchPageTest.zip

As you can see, I now have a bigger mess on my hands than before. If someone can take me by the hand and guide me toward INLINE PARADISE, I would be grateful.

Two Notes:

  1. I cannot get Paul Dunning’s MakeMeAFooter action to do its job on my fully inline page in Freeway 6. As such, I cannot achieve my aim of getting a 60px height invisible spacer between the very bottom of my page and the bottom of the browser window. (If you examine my FW6 doc, you will see that item rests atop the page, and it is set to not Publish because I cannot get it to display on Preview.)

You shouldn’t need that for your inline page. Make your footer element itself also inline, and everything above it will push it down.

Here’s an example done in F5.0, long ago. Should look familiar… Click the text in the middle to make the page grow, simulating what happens on your Atomz search page. Download the document here: http://scripty.walterdavisstudio.com/fwtalk/freewaytalk.freeway.zip

  1. If you Preview the RPL page in my FW5 doc in FW5.6.5, and then if you Preview the same RPL page in my FW6 doc in FW6.0.3, there are some surprising differences. The Preview in FW6 is worse because the leftmost field and rightmost copyright text are popped out and downward in FW6, but the remain perfectly in place in FW5.

Try making a completely inline layout, without any Actions at all. None were harmed in the making of this document (except Protaculous, to make the expando text trick work). Once you make a layout this way, you will see that you don’t need anything else to get exactly what you want. Start simple, without any of your shadows or rounded corners. Then layer those grace notes on top after you master the basics.

Walter

I look forward to your reply.

Thank you,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Walter, I downloaded and tested your document in FW5.6.5. And yes, when I previewed, I expanded the size of the text to see how it expands overall. I see perfectly how YOUR EXAMPLE works; and prior to even seeing it, I understood the fundamentals of the inline layout. The issue is with MY PAGE…

Per your advice in my sample FW6 document (the ZIP file I linked for you in my previous post), I did the following:

  1. Deleted all Actions
  2. Deleted all HTML Markup

Upon Preview I see that my page shadow is gone and my search bar is broken, which is understandable, but the previous problems I showed you before in my two screen shots remain.

Have a look at the screen shots. Note the gap above the CSS Menubar. For the life of me, I cannot get rid of it even though all objects are inlines (pasted into the HTML boxes) AND they are set to Float Left too! If I insert my cursor above the CSS Menubar and then if I press Delete, it deletes my menubar! So you’ll have to open my document and give it a try yourself if you don’t know what I am talking about.

Also, the problem shown in my screen shot where the bottom of the gray part of the page undershoots my footer graphic remains too. Yes, even though all the Actions are deleted and there is no HTML Markup!

Ack!

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Okay, Walter and Joe. I’ve spend a good number of hours today on a fully inline layout in Freeway 6. I’ve managed to solve the problem where page contents were vertically smashed in Page View, simply by using Minimum Height for my Undefined Height boxes (something impossible to do in FW5, by the way). I also managed to solve the gap problem by incorporating some trickery – I made the header graphic a background graphic that doesn’t tile. I honestly think there should be a way to paste two inlines into a box, float them left, and then have them slammed against each other vertically. But again, I couldn’t do that. I always got a gap. Using the background image trick was my workaround.

After that I ditched Paul’s MakeMeAFooter action, elongated the page by 60px, then sketch in an HTML box 60px in height at the very bottom (just beneath my footer). That gives me the space between the bottom of the page and the bottom of the browser window I wanted.

Now where does all this leave me? Well, I’m absent a few hours of time and back to square one. Why? Because the shadow at the bottom of my page is still overshooting the page too much. The page looks exactly the same as when I first started using the RPL action!!! And just like with the RPL action, the JavaScript I use in BEFORE is being ignored. That JS code normally works great to keep the page-bottom shadow from overshooting the page bottom. But again, it’s being ignored for some reason. Here’s the code:

 <script>
var outer=document.getElementById("outerShadow");
var inner=document.getElementById("PageDiv");
if (PageDiv && outerShadow){
	outerShadow.style.height = (parseInt(outerShadow.offsetHeight) -28) + "px";
}
</script>

Here’s my latest edition document (sans the 60px space at bottom):

http://www.kiramek.com/21test95/AtomzSearchPageTest2.zip

Now, Joe, I know you suggested that I make the “outerShadow” box SHORTER than the page contents in order to shorten the shadow. As you can see in my document, all the page contents are child inlines of “outerShadow”. But even if I popped out the contents into a separate HTML box and made outerShadow another box that sat behind everything, because the page has flexible height, the same problem I reported before would occur. Namely, as the page contents elongate the page, the length of the outerShadow box remains fixed, so it starts to look more and more silly as the height of the page increases!

I look forward to hearing your thoughts. (And please give my document a whirl. You will better understand what I am talking about if you do.)

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Hi James,

It would seem the same barrier is there for inline layouts. As I mentioned before, it all comes down to your shadow. It’s going to be a bit of a compromise, but how about changing the shadow settings to one of the following:

“29px 29px 24px -24px #000, -29px 29px 24px -24px #000

“0 29px 24px -24px #000

“0 29px 24px -24px #000, 29px 10px 24px -24px #000, -29px 10px 24px -24px #000

The first is more similar to the original one but the shadow at the bottom of the container is doubled up, so darker than the sides. The second only has a shadow on the bottom. The third is the same as the second but has a shadow on all three sides, just not the bottom corners.

Note that you would be able to continue using the RPL Action if you went down that road.

Joe

On 27 Feb 2013, at 06:17, JDW email@hidden wrote:

Okay, Walter and Joe. I’ve spend a good number of hours today on a fully inline layout in Freeway 6. I’ve managed to solve the problem where page contents were vertically smashed in Page View, simply by using Minimum Height for my Undefined Height boxes (something impossible to do in FW5, by the way). I also managed to solve the gap problem by incorporating some trickery – I made the header graphic a background graphic that doesn’t tile. I honestly think there should be a way to paste two inlines into a box, float them left, and then have them slammed against each other vertically. But again, I couldn’t do that. I always got a gap. Using the background image trick was my workaround.

After that I ditched Paul’s MakeMeAFooter action, elongated the page by 60px, then sketch in an HTML box 60px in height at the very bottom (just beneath my footer). That gives me the space between the bottom of the page and the bottom of the browser window I wanted.

Now where does all this leave me? Well, I’m absent a few hours of time and back to square one. Why? Because the shadow at the bottom of my page is still overshooting the page too much. The page looks exactly the same as when I first started using the RPL action!!! And just like with the RPL action, the JavaScript I use in BEFORE is being ignored. That JS code normally works great to keep the page-bottom shadow from overshooting the page bottom. But again, it’s being ignored for some reason. Here’s the code:

<script>
> var outer=document.getElementById("outerShadow");
> var inner=document.getElementById("PageDiv");
> if (PageDiv && outerShadow){
> 	outerShadow.style.height = (parseInt(outerShadow.offsetHeight) -28) + "px";
> }
> </script>

Here’s my latest edition document (sans the 60px space at bottom):

http://www.kiramek.com/21test95/AtomzSearchPageTest2.zip

Now, Joe, I know you suggested that I make the “outerShadow” box SHORTER than the page contents in order to shorten the shadow. As you can see in my document, all the page contents are child inlines of “outerShadow”. But even if I popped out the contents into a separate HTML box and made outerShadow another box that sat behind everything, because the page has flexible height, the same problem I reported before would occur. Namely, as the page contents elongate the page, the length of the outerShadow box remains fixed, so it starts to look more and more silly as the height of the page increases!

I look forward to hearing your thoughts. (And please give my document a whirl. You will better understand what I am talking about if you do.)

Thanks,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Thank you for the suggestions, Joe. I will close this discussion with one more question.

Can you please tell me the technical reason why the following code works on pages with normal layout but fails to work on RPL or fully inline pages? (Page HTML Markup, Before )

<script>
var outer=document.getElementById("outerShadow");
var inner=document.getElementById("PageDiv");
if (PageDiv && outerShadow){
  outerShadow.style.height = (parseInt(outerShadow.offsetHeight) -28) + "px";
}
</script>

Thank you,

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Joe,

As I asked yesterday, I am still quite curious as to why the JS code hack didn’t work to shrink the page shadow overshoot at bottom. But if you or Walter don’t know, then I shall simply relegate it to “one of the great mysteries of life.” :slight_smile:

Anyway, thank you very much for your suggestions two days ago. Here’s what I’ve done to get a solution that is satisfactory to me (which is saying a lot considering my never-ending quest for pixel perfect web designs).

I ended up using the following code block in BEFORE (Page HTML Markup):

<style type="text/css">
<!--
#outerShadow {
	-moz-box-shadow: 29px 0 24px -27px #000, -29px 0 24px -27px #000;
	-webkit-box-shadow: 29px 0 24px -27px #000, -29px 0 24px -27px #000;
	box-shadow: 29px 0 24px -27px #000, -29px 0 24px -27px #000;
}
#FooterGraphic {
	-moz-box-shadow: 0 4px 24px 0 #000;
	-webkit-box-shadow: 0 4px 24px 0 #000;
	
	box-shadow: 0 4px 24px 0 #000;
}
-->
</style>

Two of the three styles you proposed were very good, Joe. Thank you. They simply lacked the well-formed shadow I wanted at the bottom left corner and bottom right corner of the page. So to spruce up those two areas, I dwelt on your for a while code and then considered that I could just add an additional separate shadow to the Footer Graphic itself. The code above is just that. But there’s a trick required to get it to work properly.

The trick I used started with ditching the fully inline layout and going back to the basics of where I started. Such brings joy to my life, since designing a NORMAL layout with the RPL action is THE GLORY OF HEAVEN compared the the pain and suffering one must endure in tweaking a fully inline layout to look just right (and then when you want to go back and change something, the real pain begins). The main reason I had to ditch the inline layout was that there is no other way to hide the shadow spill that appears at the top of my FooterGraphic. So what I did was go back to my original Freeway 5.6.5 document, add the HTML markup you see above, then sketch a 950px wide HTML box just above FooterGraphic, and I colored that new HTML box the same medium gray as the rest of the page. When you Preview, everything looks great. Without that gray HTML box, you would see the shadow spill out above FooterGraphic. But with my little HTML box cover trick, that spill is covered, and you only see a nice shadow at the bottom of the page. The shadow comes out the sides too, and that mixes with the shadow applied to my outerShadow item, but you really cannot see any extra darkness there unless you’re looking specifically for it. All said, it’s satisfactory to me, which means it probably would be good enough for anyone else who wants to try it on their sites too.

I’d like to mention that I tried to accomplish the same thing in the fully inline layout, and the result was horrific. I tried to layer the gray HTML box above the FooterGraphic by bringing the gray box to the top, having both of those items as child items (but not floated left) of a parent HTML box. And I copied and pasted the parent box inside my outerShadow box and made it Left Aligned. In theory, it all should have turned out well, but the end result is that both of the items (neither of which were floated left) were cast to the top of the page in the browser! And although some may say “just make both items floated Left,” the fact is that doing so would not allow me to make the gray box above the footer box, thereby coving the shadow spillover. So I am not sure how the RPL action accomplishes its version of the inline layout, but RPL solved my problem perfectly.

So kudos on the sheer genius of the RPL action. Sometimes it just takes ingenuity to find a work-around for its limitations. Thank you for pointing my brain in the right direction.

Now the only problem I have is how to get the JavaScript version of PIE to work on my page shadow. Such is not a problem on any of my other web pages because all of those reside on my own server, which enables me to use PIE.htc. (I just add ‘behavior: url(“/PIE.htc”);’ to my style code in HTML Markup.) But since my Atomz search page resides on the Atomz server, PIE.htc cannot be used. I’ve read that PIE.js is a solution in those cases, but for the life of me I just can’t figure out how to get PIE.js to do its job. If anyone can point my brain in the right direction on that, I will truly be in HEAVEN.

http://css3pie.com/documentation/pie-js/

Thank you!

James Wages


freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options