Walter, following on from your suggestion in the other thread where we were exchanging posts, I have done what you said, and put in 2 fixed html items with the top one having Sticker applied.
When it is loaded initially, scroll the page WITHOUT dragging/pulling down in Safari. You’ll see firstly that the '1’s scroll on top of the ‘Sticker’ text. After that, pull the screen down so it goes past the top. Then you will see a slight adjustment, and now the '1’s go below the Sticker box.
Where does that leave us in terms of using Sticker in in-flow designs?
Sticker is designed to handle an in-flow layout, but in that case, it does expect the container element or the sticker element itself to have a defined width. That way it can determine the correct offset to add to the left when it transitions from a relatively-positioned element to an absolutely-positioned one.
Walter
On Nov 9, 2014, at 2:17 PM, Iain Mackenzie email@hidden wrote:
Walter, following on from your suggestion in the other thread where we were exchanging posts, I have done what you said, and put in 2 fixed html items with the top one having Sticker applied.
When it is loaded initially, scroll the page WITHOUT dragging/pulling down in Safari. You’ll see firstly that the '1’s scroll on top of the ‘Sticker’ text. After that, pull the screen down so it goes past the top. Then you will see a slight adjustment, and now the '1’s go below the Sticker box.
Where does that leave us in terms of using Sticker in in-flow designs?
I haven’t tested this in FW7 yet, so it’s possible that it is broken there. But when I built this Action, there were two different ways you could use it, and both worked. You could insert an HTML item inside another HTML item on the page, and apply the sticker to the inner-most of those items, and you could apply the sticker to an item that you drew on the page. I never tested it with an item that was inserted into the main PageDiv – I tend not to work that way because it limits what you can do, layout wise.
Try the following, in a new document, with no template applied, so you get the benefit of reducing complicating factors.
Draw an HTML box on the page somewhere. Fill it with a color, so you can see it, and apply Sticker to it. Draw another element on the bottom of the page, far enough down to force a scrollbar. When you scroll down the page, the item should fix at the desired offset, and release when you scroll back up. Center the page, there should be no change to the effect.
Delete the first example elements, and draw a new HTML item on the page. Double-click inside it, and insert an HTML item within it. Fill it with color, and apply the Sticker to it. Insert a bunch of other elements in the first element, to force the page to be tall enough to scroll. Repeat the test above. The sticker should stay put as desired, whether the page is centered or not.
I don’t insert onto the main PageDiv either, I was doing that as you asked me to in previous post!
The 2 options you asked me to do, are what I have done and posted about already, but I have put 2 tests up for you to see.
eyemack.co.uk/test here you can see that the scrolling goes over the top of the ‘sticker’ box. Usually, one only sees that at first load. It is normally fixed when the screen is pulled down from the top.
eyemack.co.uk/test2 here, just try to scroll and you’ll see a problem. Pull the screen down past the top to see an example of the jumping.
Incidentally, I have sorted the main eyemack site out by removing the ‘Sticker’ box and container and replacing them with the same content, but as a layer with the ‘Fixed in window’ checked. I haven’t put it up ‘live’ so that you can see the original issue still.
I made a sample document in 7 last night, and applied the Action both ways, as described above. It seemed to work as I remembered it. I suspect that having the initial position of the bar already at the top of the screen would throw off the math and logic in the Action. It was designed more for an element that is mid-way down the first screen, and then sticks as you scroll past it. I noticed the effect in the Apple Store site, where your shopping cart remains in view, even on a very tall page. Go start a purchase there to see what I’m talking about.
For the kind of layout you are using, as long as you don’t worry about supporting old Android devices, you should be just fine with the position:fixed layout you settled upon. That’s actually a lot “lighter” and thus more appropriate for mobile users, since you don’t need to load JavaScript or poll the page for scroll events (which leads to “janky” re-positioning as you scroll in your touch-driven browser.
I’ve done it slightly in the way of the Apple store link. You can see that although it works OK, there is the same sort of jump and change of width when you go past the ‘sticky’ position.
Apply the Box-Sizing Action to the sticker, and I think you’ll have it. The issue appears to be related to the padding on your box. My example didn’t have any, and that seems to be the issue. If you can’t find that Action, you can do this long-hand by clicking once on the sticker element, opening the Item / Extended dialog, clicking on the
tab, and then adding the name/value pair box-sizingborder-box to the box’s extended attributes.
If you look at the generated CSS in your browser, you will see that your sticker box is set to a width of NaN%. NaN is a JavaScript constant that means “not a number”. So something (an Action, most likely, as those are written in JavaScript) has attempted to rewrite the dimensions of your sticker box with a corrected dimension, and failed to do so cleanly. I am not sure which version of the Box Sizing Action you have there, but I suspect it may be implicated in this.
Try the following steps:
Remove all Actions from the Sticker box (and the rest of the elements on the page, or the page itself) and publish once.
Click once on the Sticker box and apply the Sticker Action to it. Check how you have defined the dimensions of that box – it should be in Pixels.
Using the Item / Extended /
trick, add properties for the following:
name
value
padding
8px 12px
box-sizing
border-box
In this manner, you can add padding to a sized element without altering its visible size (and confusing Freeway’s layout engine).
You can set a different (fixed) width at each breakpoint, and the Action should still be able to work. It doesn’t read the width of the element, it interrogates the browser at the moment the page is displayed on screen and works out the arithmetic at that instant. What this means specifically is that you will not see the change if you drag-resize the screen – the calculation happens only once when the page loads, so whatever is true at that moment becomes the truth for that entire page view. If you drag-resize the page to another breakpoint for testing, then force-reload the page and see how it looks at that size.
So, it won’t dynamically resize if the browser screen is drag-resized?
Setting different break points means that it will just jump when resizing desktop windows, does it not? Sort of spoils in-flow design with its smooth resizing of text and graphics, doesn’t it?