The problem is that the page scrolls down way below the page bottom at most viewport widths. This exposes the background fixed position image at the bottom of the page where I don’t want it to be seen. Perhaps this has something to do with the fact that I have a number of in-line disclosures of two types: rotating arrowhead triangles and “show more/show less” expanders. If I open some of the disclosures the content gets longer and the bottom issue goes away, but of course this doesn’t fix the problem.
FYI I have set the page size to just fit the content depth as it shows in FW7 at default 1200, 875, 768 and 480 widths.
On some pages FW7 allows me to set the page height shorter than the PagDiv and Footer depth to address such a problem, and sometimes it doesn’t, disallowing anything shorter and setting the page depth to the content depth.
Anyone have a fix or workaround for this problem? Anyone understand when FW allows you to set pages shorter than in-line content and when it doesn’t?
Uncheck “heights” at all. An inline-construction doesn’t have such a “value” - because it grows and shrinks by its content. The current page example has a height of 4000px applied - no wonder what happens if content is for example just 2000px tall.
Furthermore, you have two items which are called #PageDiv. Never saw this before but you’ll do good to call this item very different.
Well, my attempt to “uncheck” heights failed, but in trying I fixed the problem. I didn’t find any checkbox to uncheck so I tried to remove the value from the page height measurement and the page vertical dimension in the Inspector. I noticed in doing so that for two of the viewport widths these numbers were different from each other. FW7 wouldn’t let me get rid of these values, but it did set them to the same value (within each viewport width) which eliminated the problem.
Curious about the #PageDiv. I named my highest level parent in-line box PageDiv, but nothing else. And FW7 doesn’t let you reuse names.
Perhaps this has something to do with the fact that I have a number of in-line disclosures of two types: rotating arrowhead triangles and “show more/show less” expanders.
Which action is this, Peter? I don’t recall this one?
Curious about the #PageDiv. I named my highest level parent in-line box PageDiv,
The other is actually called PagDiv
And you shouldn’t try to name it PageDiv as FW automatically uses that ID.
PageWrapper would be more appropriate
David
David,
Thanks for pointing out the PageDiv, PagDiv difference and that FW7 applies PagDiv automatically.
On this page the PageWrapper is named PagDiv, and from what you explain, FW7 and not me must have supplied the name.
I see PageDiv as a parent to PagDiv in the source code, but cannot find it in the left hand column of site elements for the page or for its master page in my FW7 file. I suspect FW generated it for some reason when it generated the code for the site.
Freeway will not expose the PageDiv to you as an object to be styled, but rather if you use the Page / Extended menu, you can set various attributes on it that the Page Inspector does not expose to you. If you are able to get Freeway to create this structure without pasting any code into the Page / HTML Markup dialog:
<div id="PageDiv">
<div id="PageDiv">
then you have found a bug, and you should bottle up that document and mail it to support(a)softpress.com, referencing this thread in the mailing list. Freeway at its very core tries to play by the rules of HTML, and one of the more bedrock rules is “no single page may contain duplicate IDs”. Classnames may repeat willy-nilly, but never IDs.
Walter
On Jan 10, 2015, at 11:10 AM, Peter Laundy email@hidden wrote:
On 10 Jan 2015, 12:26 am, DeltaDave wrote:
Curious about the #PageDiv. I named my highest level parent in-line box PageDiv,
The other is actually called PagDiv
And you shouldn’t try to name it PageDiv as FW automatically uses that ID.
PageWrapper would be more appropriate
David
David,
Thanks for pointing out the PageDiv, PagDiv difference and that FW7 applies PagDiv automatically.
On this page the PageWrapper is named PagDiv, and from what you explain, FW7 and not me must have supplied the name.
I see PageDiv as a parent to PagDiv in the source code, but cannot find it in the left hand column of site elements for the page or for its master page in my FW7 file. I suspect FW generated it for some reason when it generated the code for the site.
They aren’t actions, but rather page markup and CSS styling courtesy of Walt D.
Here is the thread in which others helped me implement the rotating disclosure triangles: http://freewaytalk.net/thread/view/150305#m_156810
Uncheck “heights” at all. An inline-construction doesn’t have such a “value” - because it grows and shrinks by its content. The current page example has a height of 4000px applied - no wonder what happens if content is for example just 2000px tall.
Well, my attempt to “uncheck” heights failed, but in trying I fixed the problem. I didn’t find any checkbox to uncheck so I tried to remove the value from the page height measurement and the page vertical dimension in the Inspector. I noticed in doing so that for two of the viewport widths these numbers were different from each other. FW7 wouldn’t let me get rid of these values, but it did set them to the same value (within each viewport width) which eliminated the problem.
“Set them to the same value” is not quite accurate. What seems to work is to set the height measurement to what FW calculates it should be by entering a number lower than it should be, then in dimensions make sure that not only is the upper right item (height minimum?) set to 100%, but that it is selected (when it is the icon background shows in a darker grey) which then makes the item below it (height) equal the height measurement FW calculated.
Any suggestions on how to get a 320px wide page that is over 15000px deep to set the page length properly so that in iOS (and perhaps Android) there is not a lot of white space showing at the bottom of a page?
I’ve got “minimum page height” selected and set to 100% and page height is set to “x”.
I’ve read in another post that FW gets buggy with a page as long as this one is, so I figure that is the problem. Another complicating factor may be the page is full of triangle disclosures, which perhaps cause FW problems with page length.
I unchecked display on the div containing the FB like/share code at 480px and below and it had no impact on the problem.
A couple of FYIs:
This FB code appears at the bottom of all pages and this is the only page with the problem
In Safari on my Mac at 320px there is no problem with the bottom of the page extending too far down. Don’t have an Android to see how it behaves there.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
I’ve tried three settings to get page length to show properly in iOS and elsewhere that I have tested. Elsewhere page length works fine. In iOS it often has page lengths that extend way beyond the bottom of the page.
In Page Inspector under Dimensions>Size I’ve tried:
All Page Size settings unchecked (light grey) as suggested by Thomas K in the first response to the original post
iPad: Investor Offering and Farmland Portfolio pages work properly in both landscape and portrait. All other pages have page heights that are way too high.
iPhone: Investor Offering, Farmland Portfolio and About Us pages work properly in landscape and portrait. Farmer Offering works properly in landscape but not portrait. Home Page is too high in both landscape and portrait.
Is there another setting I should try?
freewaytalk mailing list
email@hidden
Update your subscriptions at: