Show element when in viewport (on scroll)?

[Hubert]

Hello,

I know that we have the Dynalist plugin but from what I've gathered it's currently at the proof of concept stage of development. From studying its documentation and code I can also see that it's very ambitious and that it may take some time/effort to make it truly "deployable".

What I'm looking for is a fairly simple functionality whereby an element (a div or even a portion of text within a tiddler, definitely not the entire tiddler) could be hidden and only appear when scrolled into view (through JS and CSS display:none > display:initial or something else).

Could this be accomplished by wrapping the content in a widget, either a new standalone widget or perhaps an upgraded $reveal widget, that would detect the vertical scroll position/viewport etc. and only reveal content when it's visible?

I've already had a look at a similar solution here but could not get it to work as a TW JavaScript widget yet.

I'm using the poor man's single tiddler view ;) (zoomin) with animation set to 0 and have no interest in the other storyviews, though I understand that there might be an issue getting this solution to work consistently across all the storyviews.

I was wondering if anyone built something similar and would be willing to share their approach?

Thank you,

Hubert

[TonyM]

Hubert

A possible line of enquiry may be html css overflow parameters which allow scrollable content, but you may need to set a height.

I may be missing your requirement but I hope it helps.

Regards
Tony

[Mat]

Hubert wrote:

[...] hidden and only appear when scrolled into view

Doesn't that hold for exactly everything? Could you perhaps link to some site that features this so it is more clear what you mean.

<:-)

[Hubert]

Hi Mat,

Doesn't that hold for exactly everything?

Yes, it does :) But only visually. I should have mentioned that I would want to prevent rendering of anything so encapsulated until it becomes visible. My goal is to save processing cycles on mobile.

Probably the best analogy is the $reveal widget -- whatever is within the $reveal widget becomes re-rendered every time the widget is revealed (on click). However in what I'm trying to achieve the trigger would not be a click but a scroll into view.

Could you perhaps link to some site that features this so it is more clear what you mean.

The link I've included in my original post (sorry, it was somewhat hidden) shows what I mean, please see here:

https://stackoverflow.com/questions/49916259/show-element-when-in-viewport-on-scroll

Thanks again!

Hubert

[Hubert]

Hi Tony,

A possible line of enquiry may be html css overflow parameters which allow scrollable content, but you may need to set a height.

Thanks for your suggestion. I was actually looking at CSS @media queries and overflow-block sounds familiar but I suspect that we do need a JS element for this approach. I might be wrong though.

Thank you!

Hubert

[Mat]

I agree it does sound like JS would be needed. Still if I were to attempt something anyway with CSS then I agree it would be some element set to display:none wrapped in some parent element. And when the parent element is "affected" (how?) it changes the display of the inner. I don't know if "display:none" means it never had to be loaded to begin with before though?

But if you "reverse" the matter it is easier; i.e if you click-to-scroll rather than scroll-to-activate. There's for example this CSS solution. Maybe something here.

<:-)

[Saq Imtiaz]

The dynalist plugin is fully functional,  and it essentially works by creating state tiddlers for reveal widgets that should be rendered only when visible in the viewport. If you study the templates used, you should be able to use the same logic to trigger different reveal widgets inside of one tiddler as well.

I don't fully understand the use case for such a very long tiddler though.

[TonyM]

Hubert,

Keep in mind what the bottleneck on a phone is, for many it is processing, to my understanding using javascript is more processor intensive than CSS or html render to my knowledge. Also the load or first render time is more likely the most impact on the experience of the user, just like the splash screen feature makes a big difference for wiki load because people know something is happening. 

It is also my view that javascript solutions should be last on the list of solutions where possible, and if resorted to they should be generic in nature, better native features than plugins. I think a search for html/css solutions would be the best, but then javascript is not my hammer, ie when you have a hammer everything looks like a nail.

I have made some large tables on a desktop and adding a reveal feature, like hiding columns or rows at initial load the user then exposes more with a click is one approach.

Regards

Tony

[Hubert]

Hello again,

Thanks everyone for your input.

I don't know if "display:none" means it never had to be loaded to begin with before though?

Mat, I'm not sure about this either. I've found this in reveal.js which may suggests that the DOM needs to be involved directly in order to prevent rendering of the hidden content:

    if(!this.isOpen) {
        domNode.setAttribute("hidden","true");
    }

But again, I'm no JS expert to draw any such conclusions.

But if you "reverse" the matter it is easier; i.e if you click-to-scroll rather than scroll-to-activate. There's for example this CSS solution. Maybe something here.

I agree :)

The dynalist plugin is fully functional,  and it essentially works by creating state tiddlers for reveal widgets that should be rendered only when visible in the viewport. If you study the templates used, you should be able to use the same logic to trigger different reveal widgets inside of one tiddler as well.

Thank you Saq for explaining the mechanism on the top level. It will be some time before I get the level of understanding that's required here.

Also the load or first render time is more likely the most impact on the experience of the user

Tony, that's right and this impact is exactly what I'm trying to attenuate by delaying rendering until the moment the content is visible.

It is also my view that javascript solutions should be last on the list of solutions where possible, and if resorted to they should be generic in nature, better native features than plugins. I think a search for html/css solutions would be the best, but then javascript is not my hammer, ie when you have a hammer everything looks like a nail.

I 100% agree with you Tony. I'm a core purist/minimalist in the sense that I give precedence to the tools already available in the core. I'm actually in the process of replacing all my $formula macros with the core math/compare operators. But again, in this particular scenario it looks like a step up to JS would be needed.

Regards,

Hubert

[Jeremy Ruston]

Hi Hubert

I’m afraid the dynaview plugin examples were out of date which made things difficult. It’s fixed now, and you can try it out on the prerelease:

https://tiddlywiki.com/prerelease/#%24%3A%2Fplugins%2Ftiddlywiki%2Fdynaview

Here’s a minimal example of making a DIV invisible until it is scrolled into view:

<div class="tc-dynaview-track-tiddler-when-visible" data-dynaview-track-tiddler="$:/state/lorem-visibility">

<$reveal state="$:/state/lorem-visibility" type="nomatch" text="0" tag="div">

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

</$reveal>

</div>

The dynaview plugin checks the DOM at frequent intervals for DOM nodes with the class tc-dynaview-track-tiddler-when-visible and the attribute data-dynaview-track-tiddler. For any that it finds, it updates the specified tiddler with the visibility state of the DIV (blank = not scrolled into view, 0 = scrolled into view but subsequently scrolled out again, 1 = nearly in view and 2 = fully or partially in view).

As usual with TiddlyWiki, the current visibility state is kept in a tiddler. If you have many DIVs to handle then you’ll need to adopt an approach for generating unique state tiddler titles.

Best wishes

Jeremy.

even through CSS ("display: none") based on it's class

Show element when in viewport on scroll

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7ae015fc-0679-460b-b3a3-584906aff425%40googlegroups.com.

[Hubert]

Hi Jeremy,

Thank you for the instructions add the additional information!

Best regards,

Hubert

To unsubscribe from this group and stop receiving emails from it, send an email to tiddl...@googlegroups.com.