Hi,
I have put a question to support, but wondered if there was anyone awake who can help me:
Boxes in a layout are just not rendering to scale-
I want to put two 160 wide boxes below a 320 wide one.
If I use the layout inspector to dimension them, say one 160 wide starting at the edge of the page, and the other starting at 161 from the edge of the page, they overlap on screen by at least ten or fifteen pixels.
If I draw them to fit, one of them shows as 150 wide!
Surely it’s something I’ve done! I’ve had the problem before but always somehow worked around it, this time I’m stumped!
Are you using padding, border or margin? Are your preferences set to adjust
box dimensions when adding padding?
Padding, border and margin all affect box dimensions. FWP will compensate
for padding when the preferences are set, but not for borders.
If none of that applies, then publish your page somewhere so I can see what
Freeway thinks you’re doing.
–
Ernie Simpson
On Wed, Oct 31, 2012 at 11:08 PM, PeterH email@hidden wrote:
Hi,
I have put a question to support, but wondered if there was anyone awake
who can help me:
Boxes in a layout are just not rendering to scale-
I want to put two 160 wide boxes below a 320 wide one.
If I use the layout inspector to dimension them, say one 160 wide starting
at the edge of the page, and the other starting at 161 from the edge of the
page, they overlap on screen by at least ten or fifteen pixels.
If I draw them to fit, one of them shows as 150 wide!
Surely it’s something I’ve done! I’ve had the problem before but always
somehow worked around it, this time I’m stumped!
First, there is a thing called the CSS Box Model… it basically describes
how browsers calculate the dimensions of html objects. It’s a whole topic
of discussion, so for the sake of brevity let’s just talk about the Box
Model in relation to div’s (the html equivalent of Freeway Pro’s HTML
Item). You can learn more later at places like
The CSS Box Model calculates the width of a div box with this formula:
Content Area + Padding (Left and Right) + Border (LR) + Margin (LR)
The Margin area is always transparent, essentially pushing away other
objects with the same parent. Since they are “invisible” let’s drop Margins
out of the equation for now. So that leaves us with Content plus Padding
Plus Border to arrive at our “visual” dimension.
In your example, box ONE has a content area of 320px and overall padding of
10px. This calculates as 320 (content) plus 20 (10 Left + 10 Right) plus 0
(border) for a calculated width of 340px. You can see this in your screen
grab of the Inspector for ONE – dimensions of 320px, padding 10px, border
0px. Below that, the Screen Measurements pane lists the total Width as
340px.
Freeway Pro does some of the Box Model math for you… which is helpful, but
not foolproof. For example, if you want your box to visually be 320px wide,
you would set that in the Dimension pane first, then when you add 10px of
Padding, FWP would subtract 20px (10+10) from the Width dimension automatically – changing the width dimension to 300px so that your box
would remain visually at 320px, as verified in the Screen Measurements
pane. This behavior is what is controlled by the Preferences setting.
However, if you alter the width of an item after having added padding (or
border) FWP no longer can anticipate your intent for the total width.
That’s why the Screen Measurements pane is important to understand how much
visual space your box requires.
Item TWO in your example has a content width of 159px, but the Screen
Measurement pane is 174px – and that’s what my screen ruler says. We can
deconstruct that by observing that the content width is set to 159px, but
the padding is set differently than item ONE… this time it is 5px Left and
10px Right. Still with no border, so 159 + 15 = 174px.
Item THREE is an anomaly. It is also 174px wide, but it doesn’t match the
Inspector measurements – it has no padding and contains a table. I can only
guess that it was altered between the time of the screen grab and this
publishing.
So, hopefully this explains why things don’t seem to add up. Now, how to
fix it.
Start by removing the padding from each box – this will reset Freeway Pro’s
behavior. Set the desired optical width of the first box… let’s say 320px.
THEN, add your 10px padding. You will see FWP has reduced the content width
in the Inspector but preserved the overall width in the Screen Measurements
pane. Now, make the second and third box exactly half the width of the
first box, or 160px THEN add your padding of 10px. Verify in the Screen
Measurements pane the overall width has remained at 160px.
I’ve made an example to show this approach, simulating with color the
padding and content areas of the divs:
A long explanation, hopefully it will help you understand how the browser
calculates the size of an html item, and how to make Freeway give you the
results you want.
Hi - interesting - was wondering, is there way when using % instead of fixed width to have a min % - in other words i would like the text box to go from 70% down to 100px wide only?
max-height and max-width, min-height and min-width are the attributes to
restrict how items can shrink or grow. They can be added to html div boxes
through the Item > Extended menu.
min/max attributes and percentage sizes can be quite tricky.
–
Ernie Simpson
On Thu, Nov 1, 2012 at 2:25 PM, Justin Easthall email@hidden wrote:
Hi - interesting - was wondering, is there way when using % instead of
fixed width to have a min % - in other words i would like the text box to
go from 70% down to 100px wide only?
Thank you you so much, you have gone to such trouble with your answer and it’s very clear. One thing I was unaware of is that:
***"However, if you alter the width of an item after having added padding (or border) FWP no longer can anticipate your intent for the total width. That’s why the Screen Measurements pane is important to understand how much visual space your box requires. "
That explains many hours of head scratching in the past!
This time however, I have removed padding, tried to construct new boxes, etc etc.
Sadly, here is the problem:
***Item THREE is an anomaly. It is also 174px wide, but it doesn’t match the Inspector measurements – it has no padding and contains a table. I can only guess that it was altered between the time of the screen grab and this publishing.
No, nothing was altered between the screen grab and the publishing!
I have rightly or wrongly therefore decided that there is some sort of corruption in the file, and have ditched the whole thing, started again without a problem.
Starting from scratch took less time than posting the first post did!
