There are some issues with FW5 that is causing us problems upgrading sites from FW4 to FW5 namely:
Draw a HTML box to the full width of a page
Create a 8px HTML border to just the bottom, or top edge
The FW5 displays the box as being nudged to the right and bottom by 8px. (FW4 does not do this)
Now try updating a FW4 site into FW5 which has design aspects like this, it makes the whole procedure unnerving as your carefully prepared layouts are thrown out of kilter?
Now I could just style the box using a style, but this defeats some of the visual aspects of FW.
Is this a bug waiting for a fix, or just something we have to put up with in FW5?
David Owen
Freeway Friendly Web hosting and Domains ::
I followed your instructions, and yes it seems to me there is a bug. However, I believe that I also have a workaround for you.
First, the problem doesn’t seem to affect the page code Freeway 5 produces, but only how Freeway displays the working page. When I used the custom border dialog and set only one edge to 8px, the entire box displays 8px of “border”. Now the edge I set displays the color chosen for it while the other edge borders appear in the div/box’s background color. I was puzzling over this when I noticed the Border pane of the Inspector showed 8px for the border instead of “-” which usually means that the border width is not uniform. So I went back into the custom dialog and set the other borders to 0px. Surely enough, Freeway then displays the working item correctly.
Clearly this is a bug of some sort, and hopefully will be resolved in the next update.
On Wed, Apr 9, 2008 at 2:11 AM, David Owen wrote:
There are some issues with FW5 that is causing us problems upgrading sites from FW4 to FW5 namely:
Draw a HTML box to the full width of a page
Create a 8px HTML border to just the bottom, or top edge
The FW5 displays the box as being nudged to the right and bottom by 8px. (FW4 does not do this)
Now try updating a FW4 site into FW5 which has design aspects like this, it makes the whole procedure unnerving as your carefully prepared layouts are thrown out of kilter?
Now I could just style the box using a style, but this defeats some of the visual aspects of FW.
Is this a bug waiting for a fix, or just something we have to put up with in FW5?
Yes I’ve noticed similar with bottom margin. If the setting is 0px then FW5 still displays a gap, whereas if you delete the value FW5 closes the gap.
Insert a div into a HTML box
Make this inserted box to have 0px margin at the bottom
FW5 displays a gap at the bottom. (gap not published)
Delete the 0px value, and the gap closes.
Ernie, I would be interested if any of your existing FW4 work has been opened with FW5? We produce sites built in FW4 with “no height” divs, page alignment “none” with 100% width, and borders, that do not upgrade. FW5 is causing iltems to overflow out their holding divs (displayed with an X on the bottom corner).
Clearly this is a bug of some sort, and hopefully will be resolved in the next update.
David Owen
Freeway Friendly Web hosting and Domains ::
I have not opened any Fwy 4 sites with 5 – I am not really planning on it. I may end up doing so, but only after I understand how Freeway 5 does its thing. Freeway 4 was so different from the previous versions that I decided to reproduce the old sites from scratch, allowing me to employ new techniques that 4 introduced.
I’ve tried your second example, with margins on inline divs, and that looks like a bug as well. Sorry that I didn’t participate in the public beta as I’d have hoped these types of positioning behaviours would have been ironed out already. Oh well, here’s to hoping the next patch will address these fairly fundamental oddities.
On Thu, Apr 10, 2008 at 12:56 AM, David Owen wrote:
Ernie,
Yes I’ve noticed similar with bottom margin. If the setting is 0px then FW5 still displays a gap, whereas if you delete the value FW5 closes the gap.
Insert a div into a HTML box
Make this inserted box to have 0px margin at the bottom
FW5 displays a gap at the bottom. (gap not published)
Delete the 0px value, and the gap closes.
Ernie, I would be interested if any of your existing FW4 work has been opened with FW5? We produce sites built in FW4 with “no height” divs, page alignment “none” with 100% width, and borders, that do not upgrade. FW5 is causing iltems to overflow out their holding divs (displayed with an X on the bottom corner).
I’ve seen this quite a bit when opening an inline FW 4 site in 5. This isn’t the most elegant solution but it (usually) works for me. Try deleting an inline element then reinsert it back into the layout being sure to reset floats, clear etc. On occasion I’ve also been able to retype an elements width that has for reason doubled or tripled in size and this will put the page right once more with no cut/paste needed. After that things are fine for me.
Todd
On Apr 10, 2008, at 2:56 AM, David Owen wrote:
Ernie, I would be interested if any of your existing FW4 work has been opened with FW5? We produce sites built in FW4 with “no height” divs, page alignment “none” with 100% width, and borders, that do not upgrade. FW5 is causing iltems to overflow out their holding divs (displayed with an X on the bottom corner).
I’d agree with Todd – having now opened an inline flexible v4 site with 5. I had to use the page element pane (site map thingy) to select the containers and reset the heights to a fixed number before going back and removing them. I can imagine how frustrating that must be on more complicated sites.
Freeway 4 was also touchy when it came to nested divs and such. It seems v5 continues that tradition.
On Thu, Apr 10, 2008 at 6:45 AM, Todd wrote:
David,
I’ve seen this quite a bit when opening an inline FW 4 site in 5. This isn’t the most elegant solution but it (usually) works for me. Try deleting an inline element then reinsert it back into the layout being sure to reset floats, clear etc. On occasion I’ve also been able to retype an elements width that has for reason doubled or tripled in size and this will put the page right once more with no cut/paste needed. After that things are fine for me.
Todd
On Apr 10, 2008, at 2:56 AM, David Owen wrote:
Ernie, I would be interested if any of your existing FW4 work has been opened with FW5? We produce sites built in FW4 with “no height” divs, page alignment “none” with 100% width, and borders, that do not upgrade. FW5 is causing iltems to overflow out their holding divs (displayed with an X on the bottom corner)
I don’t think that I’ve seen the problem you describe… is it both IE6 and 7? I’ve viewed v5 pages with this alignment in both browsers and not seen any scrollbar problems.
This could be a browser problem with IE… certainly sounds familiar. Often IE must be prodded to accept the dimensions or positions described by a style. For example, I helped someone recently who was using the display:block to create a CSS link button, only IE would not respect the display:block attribute of the hover style. However, when a width attribute was added to the hover style, IE suddenly began behaving as it should have all along.
On Thu, Apr 10, 2008 at 3:15 AM, David Owen wrote:
Have you seen the problem in FW5 with page alignment set as “none”?
In IE so scroll bar is created unless you use:
#PageDiv { height: 100%; }
With your knowledge of styles, I’d be interested in your take on it?
We’ve got an PC here with IE6 on it. And in FW5 if you just create a long (high) div and fill it with text, to create a scroll bar, and have the alignment set to none, the PC can’t see the bottom of the page as no scroll bar is created.
I don’t think that I’ve seen the problem you describe… is it both IE6 and 7? I’ve viewed v5 pages with this alignment in both browsers and not seen any scrollbar problems.
David Owen
Freeway Friendly Web hosting and Domains ::
Ah, okay – thanks for the side by side demonstration David
Clearly the difference between these two pages is the position attribute of the #PageDiv structure. Freeway 5 isn’t doing anything incorrect here by giving a position attribute to this structure – it’s IE6 that is fouling things up by its inability to deal with the absolute children of relatively positioned items. Because Freeway 4 doesn’t give any position attribute to the #PageDiv, IE6 just “guesses” how to handle the layout and in this case gets it right.
The article describes the “Holly Hack” which will fix the problem for IE6. What SoftPress should do, imo is include this hack in the ie6.css file whenever the position:relative attribute is given to the #PageDiv structure. Or you could add it manually (if only there was a way for advanced users to add to these css files from within Freeway
On Fri, Apr 11, 2008 at 2:01 AM, David Owen wrote:
Ernie,
We’ve got an PC here with IE6 on it. And in FW5 if you just create a long (high) div and fill it with text, to create a scroll bar, and have the alignment set to none, the PC can’t see the bottom of the page as no scroll bar is created.
