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
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
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
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
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
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
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.
<:-)
>
--
You received this message because you are subscribed to the Google Groups
7 matches
Mail list logo
