In one box nested with another box I have a line of text I would like to appear gently on load using the TransitionFX. But the box stays closed until the FX kicks in. The content below is thus higher then wished for then suddenly jumps into place once the box opens and the line of text fades in.
Any way I can keep this box open from the beginning of the page load ?
Hi Richard,
This appears to be a limitation of the original Action.
– technical bit –
The Action hides the object from view before fading it back in after a short delay. In hiding the object it gets removed from the document (DOM) which is why the page snaps to a larger size when it starts to fade it back in.
– end of technical bit –
I’ve taken your page and have replaced the code that does the hiding so that the object isn’t removed from the page but simply made transparent.
The modified page is here; http://www.freewayactions.com/test/doucefrance.html
If you are happy digging around in the page for the updated code then you should be OK inserting this as markup and removing the original Action. If you want me to look at changing the Action for you then please let me know and I’ll try and get to this over the weekend.
Regards,
Tim.
On 2 Nov 2012, at 11:45, Richard Lowther wrote:
In one box nested with another box I have a line of text I would like to appear gently on load using the TransitionFX. But the box stays closed until the FX kicks in. The content below is thus higher then wished for then suddenly jumps into place once the box opens and the line of text fades in.
Any way I can keep this box open from the beginning of the page load ?
I’ve not used the action myself, but I wonder if it were applied to an item
that was nested inside a fixed-height item would solve this?
–
Ernie Simpson
On Fri, Nov 2, 2012 at 8:41 AM, Tim Plumb email@hidden wrote:
Hi Richard,
This appears to be a limitation of the original Action.
– technical bit –
The Action hides the object from view before fading it back in after a
short delay. In hiding the object it gets removed from the document (DOM)
which is why the page snaps to a larger size when it starts to fade it back
in.
– end of technical bit –
I’ve taken your page and have replaced the code that does the hiding so
that the object isn’t removed from the page but simply made transparent.
The modified page is here; http://www.freewayactions.com/test/doucefrance.html
If you are happy digging around in the page for the updated code then you
should be OK inserting this as markup and removing the original Action. If
you want me to look at changing the Action for you then please let me know
and I’ll try and get to this over the weekend.
Regards,
Tim.
On 2 Nov 2012, at 11:45, Richard Lowther wrote:
In one box nested with another box I have a line of text I would like to
appear gently on load using the TransitionFX. But the box stays closed
until the FX kicks in. The content below is thus higher then wished for
then suddenly jumps into place once the box opens and the line of text
fades in.
Any way I can keep this box open from the beginning of the page load ?
Thanks for the response. I understand the theory but in practice I am lost in code. I will keep looking and trying to spot the differences but whatever ones I see and paste in make no difference. Sorry !
I see there is an event observer in there but when I paste that code into markup it just appears at the top of the page in the browser view.
Should i be looking in the ‘Page Source’ by the way or the ‘Inspect Element’ and why do these sets of code appear to be different anyway ?
Maybe changing the action is the answer for me but it is not vital - it was just a piece of confection for the client.
Erns I tried the fixed height but no go I’m afraid
Would be interested to know how this differs from Tim’s method - and will it effect my box model - which has yet to be converted into Webyep page ! Nous verrons.
The only difference is that you’d be nesting your fading text box in a fixed height parent item. It adds an extra item to the page but would allow you to use the existing Action without modification.
The modification I made never removes the item from the page in the first place which was the initial cause of the page resizing when it started to fade back in.
Regards,
Tim.
On 2 Nov 2012, at 14:39, Richard Lowther wrote:
Would be interested to know how this differs from Tim’s method - and will it effect my box model
What some freewayers are calling “Box Model” layout, which others call “Inline” layout, these make use of div boxes which shrink in height to fit the content – in this case I guess, dynamic content. But when something like this is initially invisible, well… it has NO height – it’s invisible, right?
Putting the object of the action inside a fixed-height box reserves that space where the effect would take place, keeping it available while the effect starts up.
–
Ernie Simpson
On Nov 2, 2012, at 10:39 AM, “Richard Lowther” email@hidden wrote:
Would be interested to know how this differs from Tim’s method - and will it effect my box model - which has yet to be converted into Webyep page ! Nous verrons.
This all boils down to the differences between display and visibility (or in our case opacity). This w3schools page covers the differences quite well;
Because the Action actually removes the object from the page (display:none) the layout collapses and the layout shuffles up to fill in the gap left by the object. If the Action had used visibility or opacity (visibility:hidden or opacity:0) then the browser knows that the object is still there and leaves a space for it in the layout even though it is invisible.
Regards,
Tim.
It’s swings and roundabouts. There are arguments for and against both ways of doing this, though the main reason we went with display rather than opacity or visibility is for the following use case (among other, similar ones):
A page has a subsection that shouldn’t be shown by default. This subsection is quite large but isn’t required for the page to make sense – it just contains some secondary information that should appear when triggered. If we went with opacity or visibility then there would be a huge gaping hole in the page where that subsection is (because, as you say, it’s in the DOM, just not visible). The only way to avoid this would be to get the user to apply a style with the display property set to none. By using display in the first place we don’t need to put that requirement on the user.
Perhaps having a drop down instead of a checkbox in the settings would solve the problem? It may also just make things more confusing. What do you think?
Thanks Joe and Tim, for clarifying the nature of the problem and explaining
the mechanics. Good stuff.
–
Ernie Simpson
On Fri, Nov 2, 2012 at 3:11 PM, Joe Billings email@hidden wrote:
Hi Tim, all,
It’s swings and roundabouts. There are arguments for and against both ways
of doing this, though the main reason we went with display rather than
opacity or visibility is for the following use case (among other, similar
ones):
A page has a subsection that shouldn’t be shown by default. This
subsection is quite large but isn’t required for the page to make sense –
it just contains some secondary information that should appear when
triggered. If we went with opacity or visibility then there would be a huge
gaping hole in the page where that subsection is (because, as you say, it’s
in the DOM, just not visible). The only way to avoid this would be to get
the user to apply a style with the display property set to none. By using
display in the first place we don’t need to put that requirement on the
user.
Perhaps having a drop down instead of a checkbox in the settings would
solve the problem? It may also just make things more confusing. What do you
think?
Thanks Joe and Tim, for clarifying the nature of the problem and explaining
the mechanics. Good stuff.
Ernie Simpson
Thanks from me too and to you Ernie and Walt although I guess my understanding of it is not as profound as all yours. But I do have it operating as wished for as a result of all this.
Hi Joe,
Oh, I can certainly see the benefits of both methods. Freeway should really have a crystal ball mode so it can tell what the user is trying to do!
I was initially thinking that if the Action could determine if the item it was attached to was inflow then maybe it should switch to hiding rather than removing it from the DOM. Having thought about it again I don’t think that would determine the overall intent of the user.
Adding more options is always going to be more confusing for the user (“what is the difference between hidden and removed”? for example) but I can’t think of a better solution that doesn’t make wild assumptions (and a crystal ball).
Regards,
Tim.
On 2 Nov 2012, at 19:11, Joe Billings wrote:
Perhaps having a drop down instead of a checkbox in the settings would solve the problem? It may also just make things more confusing. What do you think?
