Anybody know why there would be page background showing above the top of a page when there is nothing inline in the PageDiv, but when it is inline in the PageDiv there is no background showing above the page?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Could you post a link showing both ways? I’ve never seen any
difference between the two constructions myself.
Walter
On Jul 1, 2008, at 1:50 AM, chuckamuck wrote:
Anybody know why there would be page background showing above the
top of a page when there is nothing inline in the PageDiv, but when
it is inline in the PageDiv there is no background showing above
the page?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
It’s the pesky form page you’ve already seen. http://zanegerson.com/contactZane.html
I don’t have the page without the space at the moment, but the other pages at the site are examples also.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Whenever you see a page shift like this, and it has a form on it, usually it can be fixed using this:
<style type="text/css">
form { margin:0; padding:0 }
</style>
There’s something funny going on with your page styles, though, because Freeway will usually add this automatically to work around just this problem.
But I see a larger problem with your page. Each of your form fields is in a positioned DIV, and each one of them has the same ID as the form field they contain. I’m not sure how this is possible – Freeway doesn’t usually allow duplicate IDs on a page. If these form fields were IDd with my Action, then that’s one possibility. I didn’t look for ID clashes inside its logic. But if you have manually added IDs, take them out! Or, if not, click on the form field in Freeway, make sure that whatever is entered in the Title field on the left-most tab is different from whatever is entered in the Name field on the right-most tab.
In my opinion, it is always a Bad Idea to lay out a form in this manner. I usually use a table, drawn with the table tool, to hold the captions and form fields in relationship to one another. It’s actually semantically correct to do this, and it also keeps naughty browsers from messing up your entire page when they display form fields of many sizes.
Walter
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Thanks Walt. There are no custom IDs. Point well taken about forms as tables. I have been so intent to remove “table” from my vocabulary I ignore it legitimate uses.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
On 1 Jul 2008, 3:53 pm, chuckamuck wrote:
Thanks Walt. There are no custom IDs. Point well taken about forms as tables. I have been so intent to remove “table” from my vocabulary I ignore it legitimate uses.
I just revved the FormFix Action to solve this problem, although I’m still not sure how it’s being activated in your case. Are you using the FreezeForm Action as well? I see some style code in the page head that makes me suspect so. It may well be that this problem is arising there. I have never tested that Action in a layered form, only an inline (in a table) one or one made in a non-layered Freeway layout.
Anyway, give it a try: http://freewaypro.com/actions/downloads
Be sure that Freeway gives you an alert when you install it about installing Actions that update existing actions, otherwise you may have to go on a hunting expedition to locate the previous version.
What this new version does is to check each form element on the page to see if it has a wrapper DIV. If so, and if that DIV has the same ID as the form field, then the form field “wins”, and the wrapper’s ID gets ‘_wrap’ appended to it.
Really, this should be a property that Freeway sets, and tracks, in core.
Walter
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
I just figured out what was causing the problem for you. You’re using
my FreezeFormItem Action on this page. That Action was written in
2004, and never had to deal with form elements in positioned DIVs. I
just folded the same “check for DIV parent” test into that Action as
I added to the FormFix Action, and now it will not cause you this
grief any more.
http://freewaypro.com/actions/downloads
Remember particularly in this case to manually replace the Action. Go
into your [username]/Library/Application Support/Freeway 5/Actions/
General folder and remove the old before adding the new. The old one
will be named FreezeFormItem.act3.fwaction, and the new one drops the
act3 part, since it is only for Freeway 4 and 5 at this point.
Walter
On Jul 1, 2008, at 11:53 AM, chuckamuck wrote:
Thanks Walt. There are no custom IDs. Point well taken about forms
as tables. I have been so intent to remove “table” from my
vocabulary I ignore it legitimate uses.
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 just figured out what was causing the problem for you. You’re using
my FreezeFormItem Action on this page. That Action was written in
2004, and never had to deal with form elements in positioned DIVs.
Umm… nope, never heard of the FreezeFormItem action before just now. The only “form” action applied to page (beside FormFix) is the Form Styler.
If it is on the page, it either was added by magic…or from an another action. Perhaps from Form Styler?
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Form Styler must be doing much the same thing as FreezeFormItem,
then. Who wrote it?
Walter
On Jul 1, 2008, at 1:31 PM, chuckamuck wrote:
I just figured out what was causing the problem for you. You’re using
my FreezeFormItem Action on this page. That Action was written in
2004, and never had to deal with form elements in positioned DIVs.Umm… nope, never heard of the FreezeFormItem action before just
now. The only “form” action applied to page (beside FormFix) is the
Form Styler.If it is on the page, it either was added by magic…or from an
another action. Perhaps from Form Styler?
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
Form Styler must be doing much the same thing as FreezeFormItem,
then. Who wrote it?
First of all, the correct action name is Form Element Styler created by our own MikeB of Easibase fame. I was only interested in the styling aspect of it to keep the fields all the same length, but if it is creating the problem i’ll revert to table.
Thanks for the action updates by the way.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Try using the updated FreezeFormItem.fwaction in place of the Form
Element Styler. Until Mike updates his Action, FES is making the page
invalid.
Walter
On Jul 1, 2008, at 2:06 PM, chuckamuck wrote:
Form Styler must be doing much the same thing as FreezeFormItem,
then. Who wrote it?First of all, the correct action name is Form Element Styler
created by our own MikeB of Easibase fame. I was only interested in
the styling aspect of it to keep the fields all the same length,
but if it is creating the problem i’ll revert to table.Thanks for the action updates by the way.
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