Help my page lay-out is screwing up

Hi,

Developed a site in FW Pro (and EE). Everything worked OK till suddenly my published page is screwing the formatting up. Have a look at : http://www.eubottle.nl/index/_zoekresultaten/

As you can see the left and right sides of the DIV (styled within FW just background colour, radius & border) seems to double / broken. I’m working with a Master page based on Box model.

Spend already hours trying to figure out what happened! :frowning:
Can somebody can show me the way >> to a solution?


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

Tried a different method to find the issue:

I took the whole page piece-by-piece (DIV-by-DIV action-by-actio) apart and published the page after every step in order to find the devil.

It seems that FW is doing some funny things with border radius and that is causing the problem.

When I use border radius (no difference between the FW built-in or the CSS3), the preview of the page in FW looks OK. As soon as I publish to whatever browser type it screws up the boxes that use some kind of radius.

Anyone familiar with this?


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

Just tried your page and was given error message that this version of quick menu had not been purchased, does that sound like a valid error? I am on PC with Internet Exploder.


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

Hi

I might be completely wrong, but for starters your stylesheet
is before , and that’s just one of the 22 Errors. Did you hand-code a lot in this site?


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

Hi Guys,

Thanks for the input I’ll take it with me in further improving the design.
The current issue though is clearly related to the usage of the Radius function. I’ve asked Softpress for support. Wait and see!

Atelier. No no handcoding (wish I would be able to)

Rob


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

On 24 Dec 2009, 7:16 am, RobP wrote:

Atelier. No no handcoding (wish I would be able to)

I also did no nothing about Hand-coding. But when I started using EE, I was forced to. (helped by some friendly and patient persons here on the List :wink:
Handcoding is in FW speak also using ‘extended’ (on page or element level) or HTML MarkUp (for js scripts) Called so just because one does ‘something extra’ there by hand (it’s not inserted automatically through an action for example)

But how does one know if it’s OK? A first check if a page is correct should always be validation. (No I’m not a code-nazi thank you :slight_smile: just a cautious person) Another check is to look at the page in all browsers, and also under Windows… I recently bought Parallels and a legal version of XP. There is a nifty app here: http://konigi.com/tools/submissions/internet-explorer-collection-installs-multiple-ie-versions-1-pc that allows you to install more than one version of IE and switch between them. I completed that with FF, Chrome and Opera. Saved my day more than once…

( IMHO that ref to a stylesheet should not be before . )


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

Thanks for the info. Changed the position of the stylesheet already.

I’m under the impression that handcoding (I’m using CODA now) gives a more readable and clean HTML. I’m learning also because of EE. Though I’m still relaying a lot on FW cause it’s beautiful and easy in the design phase. Now changing code afterwards with CODA is OK but every time you upload your site the changes are overwritten by FW, which is logical.

What I would love to see in FW is adding a more CODA like approach to the HTML Markup part where you can really influences the flow of the code (also the code that is generated by FW automatically).

By the way I’m using Adobe’s online BrowserLab to simulate different browsers. Have a look at: https://browserlab.adobe.com

R.


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

Yes, there are more services like that. Problem is that they offer only screenshots. No live thing, so no checking of menu’s, enlarging fontsize etcetera.

There’s already a lot of talk about this issue of code in FW. With a smart combo of some nifty actions one can try to approach the Holy grale. But that’s not enough.

My2cents would be a splitting up into two apps. FW-Standard for sites that focus only on design, without any possible way for a user to interfere. And a real FW-Pro, with full control over HTML and CSS output. Even if that means leaving the WYSIWYG appearance. I can live with that. I look at lines of code anyway if I desing with EE snippets. The real thing is testing in a browser.


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

On Dec 24, 2009, at 5:59 AM, RobP wrote:

I’m under the impression that handcoding (I’m using CODA now) gives
a more readable and clean HTML.

@RobP

What I like about coding is that it offers total control of every
aspect so if someone (me, you, anyone) has the skills to write
clean, well-formatted code then yes, it is possible to improve upon
FW’s code generation in some ways. I use Coda almost exclusively and I
agree that there are aspects of it that would fit quite nicely into FW.

@atelier

I’m with you on the real FW Pro version.

Todd


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

Sometime around 24/12/09 (at 06:59 -0500) RobP said:

I’m under the impression that handcoding (I’m using CODA now) gives
a more readable and clean HTML.

Hand-coding can produce impressively elegant code, definitely.

But remember that part of why Freeway’s output is larger than you
might seem to need is because it produces ‘defensive’ code. The
structure is built to work well across multiple browsers, something
that isn’t necessarily as reliable with stripped-back code.

Also, remember that Freeway’s code isn’t often read directly by
humans. It can afford to use less whitespace padding and so on as
that’s only ever needed for human eyeballs.

k


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