[Pro] How to get views inside FW narrower than default to render properly

Perhaps others besides me find that what we’ve created at the default width does not always render inside Freeway when narrower width views are selected.

At the same, the stretchy aspects of what we’ve created at the default width narrow properly when previewed or viewed published. So it becomes a head-scratcher as to why the content doesn’t narrow properly when viewed inside Freeway.

This is important because it is very hard to apply breakpoint changes when you can’t see exactly what is happening at a breakpoint, nor the result of change you make without previewing.

I’ve been using the following rules of thumb to increase the odds that Freeway renders properly in narrower widths. The rules are:

1 Use flexible pass-through graphics with 100% max width rather than applying extended code to images to make them flexible

2 Use “available width” and not "fixed width 100% " in situations where either appear to work when previewed

And two more rules that have an impact both on published sites as well as FW’s internal views of sites:

3 Apply the box-sizing action to any box that has box left and/or right side padding specified in pixels

4 Have pages specified with fixed width, with the Flexible Page and Auto Clearfix actions applied (both with the “enable” or “enabled” box checked)

Am seeking both correction to these rules and additional rules, because they aren’t doing the trick in my current file.


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

##Better get snacks and drinks, this is going to be a long post

I’m no help when it comes to how to get Freeway’s workspace to resemble its output. My focus is on what Freeway produces and much less on how it looks in the raw.

Here’s a sample of my workspace: … and the same page in preview mode

##You must choose your path

I think the way to get the best from Freeway is to accept the reality that the app has strengths and weaknesses that are mutually exclusive.

  1. You can build things fairly wysiwyg-- trusting Freeway to generate working code for your design, but you will quickly find there are limits to what you can build that way-- limits that most users quickly exceed.

  2. You can also build things very modern and clever, leveraging Freeway’s ability to generate code by consciously directing the process. This means utilizing Freeway in a way that it was not designed to be used-- specifically, Inflow Layouts and Extended Styles. These give you more control of the output Freeway makes, but the app itself has no real way to graphically interpret elements used this way.

So, in summary, you can embrace Freeway’s wysiwyg workspace and live with what you can make that way, or you can let go of a literal workspace and leverage Freeway’s strength to write the code you need for whatever design you want.

##And now to the solicited opinions…

1 - Use flexible pass-through graphics with 100% max width rather than applying extended code to images to make them flexible

I don’t approve of 100% on max-width values… the reason being max-width is a limiter and 100% is not much of a limit. A width value of 100% makes more sense.

One of the good things about Freeway 7 is that you can set percentage widths on pass-thru graphics. Even nicer, the workspace reflects this setting, making it much easier to manage these images.

Percentages are tricky… they most often refer to parent containers. So width:100% on an image will make it scale as wide as it’s parent will allow. As long as you understand which elements are parents and which are children, this is fairly straight-forward.

Let’s say, for example, that you insert an image inline with a paragraph, float it right and give it a left-margin so the paragraph runs around the image. With FW7, the size of it as a pass-thru image doesn’t matter… if you select the image and give it a width of 25%, it will scale to be 25% the width of the paragraph container-- regardless of how you define the size of that container.

What I usually do is insert an html item (or div) into a run of text and size that by percentage of the container width, then insert my pass-thru image into that, sizing its width at 100%. This just gives me extra styling hooks, but both these methods absolutely create images that scale with the page and the rest of the content, without the use of Extended values.

2 - Use “available width” and not "fixed width 100% " in situations where either appear to work when previewed.

I’m not sure what the meaningful difference between “available” width and “100%” width is, except that I don’t need Freeway to write any extra code for available width items. My philosophy is less is best. If you don’t know how the browser will behave when you feed it your code, then more isn’t going to help.

Percentages less than 100% make more sense to me… like say, two divs side-by-side like columns, set at width:50% each. This of course leads to the next question-- the (in)famous Box Sizing debate.

3 - Apply the box-sizing action to any box that has box left and/or right side padding specified in pixels

Technically, you’re right-- box-sizing, especially with Inflow Layout techniques is essential for exactly the reason you state. I, however, think the implementation needs to be global instead of applied to individual items. Just the opposite strategy of Clearfixing. Here’s a recent article on how I implement global box-sizing values in Freeway using a method popular among web designers and one I hope Softpress will adopt as a preference or page option.

4 - Have pages specified with fixed width, with the Flexible Page and Auto Clearfix actions applied (both with the “enable” or “enabled” box checked)

It seems to me Clearfixing strategy in Freeway is currently a shotgun blast of code all over the place. This is unnecessary, like the stupid practice of wrapping the entire page in the form element when you want to make a form on a page. Once you understand what Clearfixing is-- and which elements in your design actually need it-- then it becomes much more sensible to target only those items. “Why did I clearfix that item?” “Because it contains a floated item.” And not “I don’t know the difference, so I blindly trust apps and actions to make up for my not-knowing.” Which is, of course, a path users can choose.

I also explained my approach to Clearfixing in Freeway here

My inflow layouts actually have Flexible Width pages. I fill it with Available Width items, and then fill those with a content container that is Center Aligned and Max-Width. All other content goes inside of those. The result is a normal looking page that is flexible at narrower viewports. But that’s just me.

As I said before, especially with inflow layouts, box-sizing is essential and clearfixing will be necessary if floats are employed. I have my ways of doing those things, but how you implement them is your choice.


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

This is what I do.

Question Ernie… What do you think of using overflow:hidden on floated divs rather than clearfix?

For speed I use this a lot and of course no action needed (I use as few actions as possible).

David Owen

On 18 Apr 2015, at 18:36, The Big Erns email@hidden wrote:

My inflow layouts actually have Flexible Width pages. I fill it with Available Width items, and then fill those with a content container that is Center Aligned and Max-Width. All other content goes inside of those. The result is a normal looking page that is flexible at narrower viewports. But that’s just me.


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

Question Ernie… What do you think of using overflow:hidden on floated divs rather than clearfix?

David, that is a fast solution and works well in most cases. There are times, however when the overflow fix doesn’t work-- notably when the overflow isn’t vertical. Also in cases where an overflow is desired.

The clearfix solution works most reliably for me, and is as simple as applying the .group class to the floated item’s parent.


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

Thanks, Ernie for your long and thoughtful reply. My forays into extended code so far hadn’t gotten me yet to the point of realizing I will soon be abandoning the WYSIWIG benefits of Freeway, but it makes sense. Am only on my second inline layout, so am not so far along the path that I can evaluate differing opinions of FW pros on the best way to do things. But I really appreciate getting a deeper understanding of what is going on under the covers, and I understand your points.

As to the problem that provoked my original email, you helped me figure out at least part of the problem: I had been using fixed 100% width divs to stretch across the viewport, with Fixed % centered divs with max widths to provide page-width bands to put content in. When I changed all these to available width (as you use) all the content inside them reappeared in at least the wider FW breakpoint editor views.

For those expecting WYSIWYG in the FW breakpoint editor, there remains a problem with fixed % width divs that make up multi-column inline content. If in default view you size them to fit snuggly in a single row, they work on the web, but in the FW editor at breakpoints the last div will often show up not fitting in the row.

In general, when using % widths, with box-sizing applied to divs with left and/or right padding, there is a discrepancy between what fits in default view (and on the web pages generated) and what fits in breakpoint views in the FW editor, leading to a lot of (to my mind unnecessary) manual editing if you try to get such things to look right in these FW breakpoint editing views.


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