[Pro] Freeway 7 Pro - Position:relative

Is it just me, or does FW7 Pro no longer specify position:relative to its div tags?
It seems to be a heck of a change from previous versions, and means that existing sites I have are falling apart.
For example, Safari (and maybe others) don’t correctly display overflow:hidden when display:relative isn’t specified, which it has been for years.


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

On 30 Jul 2014, 8:48 am, Ian Webb wrote:

Is it just me, or does FW7 Pro no longer specify position:relative to its div tags?

As far as I know - which isn’t much, the position: relative never was an option just by setting in inspector. To position an item relative, you’ve to double-click into your workspace (or another item) and choose Insert → HTML item from the context-menu.

It seems to be a heck of a change from previous versions, and means that existing sites I have are falling apart.
For example, Safari (and maybe others) don’t correctly display overflow:hidden when display:relative isn’t specified, which it has been for years.

No positon declared means automatically relative (cool - just recognized this - what a positive milestone). Do you have an example link - just to investigate what’s going on?

Cheers

Thomas


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

As far as I know - which isn’t much, the position: relative never was an option just by setting in inspector. To position an item relative, you’ve to double-click into your workspace (or another item) and choose Insert → HTML item from the context-menu.

Yes, you are correct - it was never an inspector option, it was automatically output into the CSS for every relatively positioned item.

No positon declared means automatically relative (cool - just recognized this - what a positive milestone). Do you have an example link - just to investigate what’s going on?

No, I don’t think that’s right. Undefined is not automatically Relative. In fact, if you start mixing Absolute with Relative, items without a position specified are ignored, with the absolute item being positioned relatively to the first relative parent - which I’m pretty sure is the reason why FW has always output the relative. This would not be a positive milestone, but a layout disaster.

OK - I’ve done some testing and it appears that FW7 only outputs a position:relative if the item has an absolutely positioned child - which makes sense.

So I guess if you’re just using FW ‘out of the box’ you’re fine but if, like me, you like to mix in a bit of custom CSS and JQuery - just be aware that FW won’t automatically output a position:relative any more.


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

Thanks for reporting that, Ian. We’ll take a look at it internally and see what solution we can come up with.

Joe


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

… am not sure if I got you - but if you really need the position declared, you could choose the item and via extended dialogue, under DIV-Stlye tab simply add it there.

About the rest I have indeed to mind about.

Cheers

Thomas


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

No position declared (in CSS) equals position:static, which is not quite the same as relative. It does “repel” its neighbors when it shrinks and grows, as relative does, but it does not set a new layout context, as relative does. If you have two elements with position relative and position static side-by side, and each of them has a position:absolute child, the one that is relative will find that child positioned at the correct offset from the parent, while the position:static parent will find that its child has wandered off (usually to the top-left corner of the page).

Walter

On Jul 30, 2014, at 5:02 AM, Thomas Kimmich wrote:

No positon declared means automatically relative (cool - just recognized this - what a positive milestone). Do you have an example link - just to investigate what’s going on?


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

the one that is relative will find that child positioned at the correct offset from the parent, while the position:static parent will find that its child has wandered off (usually to the top-left corner of the page).

The child of the position:static parent will look backwards through its ancestors until it finds on that is position:relative, then position itself relative to that. Often (as Walter stated) this is the PageDiv, so it becomes relative to the top left origin of the window.


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

Right. If you’re hand-coding, then maybe not even there. the tag is automatically position:relative, but nothing else is.

Walter

On Jul 30, 2014, at 9:26 AM, Ian Webb wrote:

the one that is relative will find that child positioned at the correct offset from the parent, while the position:static parent will find that its child has wandered off (usually to the top-left corner of the page).

The child of the position:static parent will look backwards through its ancestors until it finds on that is position:relative, then position itself relative to that. Often (as Walter stated) this is the PageDiv, so it becomes relative to the top left origin of the window.


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

Yep - thanks understood.

I simply hope that there is a tricky solution for this which covers both (declared or not).

A couple of moons ago I had a go with a small script of type “scroll to fix”. It broke, cause Freeway had positioning declared and I had no chance to overwrite (or let it overwrite) by script (even not !important). The end of this song was, to turn the ID into class, externalize the styles and throwing the position attribute out.

I wished a quicker solution at that time (however it worked) but if position attribute needs to be there - I’ll understand and support.

Cheers

Thomas


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