We Keep Coding

In Chrome, SVG elements constructed too far off-screen do not render when brought into view

I am creating a web-site that drives content for a large 2D area off a CMS, so I have a system that runs on a timer, examines the part of the area that is currently on-screen, and loads content that is close enough to the view area that it might soon come into view.
This all seems to work quite nicely, apart from one small glitch.
Some of my content is SVG elements created procedurally via JS (the load mechanism feeds data from the CMS into JS functions, which create the using document.createElementNS and insert it into a div in the correct absolute position).
This content appears fine if is on-screen at the time it is loaded (this happens when the page is initially loaded).
And it also appears if it loaded while an animation is moving the visible area (animation is used to follow paths across the 2D space).
HOWEVER, if I am manually moving the visible area (which I have implemented via click+drag) then the SVG elements are added to the document tree, but when they come into view they do not render.
If I do something to "nudge" the renderer, such as hiding an unrelated element via DevTools, or resizing the window slightly, then they appear.
I am thinking this may be a bug in Chrome? e.g. where it has initially decided the elements need not be drawn and does not reprocess correctly when that needs reconsideration? Or maybe I am missing something, I am only semi-experienced in manipulating HTML documents via JS (but after a quick look I do not see the same behaviour in firefox...)
I am moving the visible area by changing the (left, top) of a parent element (I do not want to use scrolling for that as the size of the 2D space is not defined in advance...)
Otherwise, is there some way I could trick the browser into recalculating what should be drawn? I was wondering about having a small transparent element on screen that I show and hide on a timer, although a workaround that prevents the problem in the first place would be preferable...
Thanks for any advice!
Ian
p.s. I cannot instantly produce demo code for this as the code-base is moderately large, but I will spend time to make a simpler example if that proves necessary...

Does javascript or jQuery have any technique to create a holding object that end user can shrink or expand on the fly?

see this gwt Panel
http://samples.gwtproject.org/samples/Showcase/Showcase.html#!CwSplitLayoutPanel
The user can shrink or expand to make the space holding the text smaller or bigger depending on their need.
My question is:
Does javascript or jQuery have any technique to create a holding object that end user can shrink or expand like that?

There's no easy native method to do this in javascript or jQuery, but jQuery UI has a re-sizable component.
https://jqueryui.com/resizable/
This does't replicate the behaviour of the google web toolkit example. This is quite complicated behavior. If you open the DOM inspector in chrome, you can see each section has an inline style with the width height and position. These are then recalculated and updated when you drag the bars.

How can I split HTML content into pages that fit the screen?

I'm making a book reader web application. From the server I get a long string with all of the book text in HTML format. It looks something like this:
<div><p>Alice was beginning....</p></div></div>to get very ... </div>
What I want is to split this text into pages. I want to get something like this:
<li id='page1'>... text ...</li>
<li id='page2'>... text ...</li>
...
A single page should fill the viewport. Users shouldn't be able to scroll the book text. Instead, they should be able to move between the pages using buttons.
I need some function to measure all content, split it into pieces of same maximum height, and tag the pieces with page numbers. It must also take into account pictures and long paragraphs (which may not fit on a single page).
How can I accomplish all of this?

To find out the dimensions of each bit of content, you'd have to let the browser actually render it and then measure it. Additionally, if you want to break in the middle of flow (e.g. in the middle of a paragraph), things get pretty difficult. (You cannot measure individual characters/words without wrapping them in elements.) You'd also have to disable zoom, etc., so that your measurements have some lasting meaning. All in all, HTML rendering engines are specifically tailored to render flow content, which is pretty much the opposite to paged content.
However, there are some approaches to paging, you could take, neither of which actually deals with rendering the whole text and taking measurements.
Scroll Override
One approach I'd try would be to simply
render all text into a container,
style the container in such a way that the scrollbar is not visible (e.g. by pushing it off the screen),
disable manual scrolling, and
provide "paging" buttons that programatically scroll by exactly the height of your "page".
This solution has the advantage of being simple to implement, but it's not perfect. Images can be rendered across the break and the user wouldn't be able to see them whole.
Columns
The only other approach I could think of at short notice is using columns. You'd have to
render all text into a container,
style the container to be "infinitely" wide and have "infinite" number of columns, each the width of the page,
absolutely position the container in its parent,
make your "paging" buttons move the container horizontally by the width of the page.
This solution needs modern browsers with support for columns, but using columns solves the problem of properly breaking flow content into pages. I'd recommend trying this first, if at all possible.

Dynamic number of thumbs according to available area in a webpage

I'm creating a photo gallery website, and there are pages for browsing the photos, with a listing of thumbnails (yes just a regular photo site). The problem is that, I want thumbnails to fill up the available space (I know how to get that one). Actually, what I want to achieve is very similar to this: imagine you have a big number of (more than the screen area allows) thumbnails, and you have set overflow-y to hidden. The thumbs just fill up the space and it goes, off the screen. This would be what I wanted to have if the thumbs in the bottom didn't go off the screen. I need something more, let's say, "dynamic". I've got jQuery, but haven't been able to model the desired effect in my mind.

You should load the images dynamically as needed to improve performance. See the "Reduce the Number of DOM Elements" section in the Yahoo! Best Practices for Speeding Up Your Web Site. Use jQuery to check the size of the div in which you are rendering the images. Load just enough images to fill the div and then load more images on the fly as needed (on window resize or scroll). It is not clear to me exactly what you want to achieve so I can't be more specific than that.

Ok found the way into it anyway. I just load a big number of thumbs, set the overflow-y of the thumbs container to hidden, and by Javascript (actually jQuery), when I resize the window check if the thumbs top + height exceeds window's height. if it does, I simply hide that thumb, if it doesn't I simply show it. It works great!

Parallel scroll textarea and webpage with jquery

This is both a conceptual and how-to question:
In wiki formatting, or non WYSIWYG editor scenarios, you typically have a textarea for content entry and then an ancillary preview pane to show results, just like StackOverflow. This works fairly well, except with larger amounts of text, such as full page wikis, etc.
I have a concept that I'd like critical feedback/advice on: Envision a two pane layout, with the preview content on the left side, taking up ~ 2/3 of the page, and the textarea on the right side, taking up ~ 1/3 of the page. The textarea would float, to remain in view, even if the user scrolls the browser window. Furthermore, if the user scrolls the textarea content, supposing it has exceeded the textarea's frame size, the page would scroll so that the content presently showing in the textarea syncs/is parallel with the content showing in the browser window.
I'm imagining a wiki scenario, where going back and forth between markup and preview is frustrating. I'm curious what others think; is there anything out there like this? Any suggestions on how to attack this functionality (ideally using jquery)?
Thanks

Any markup language or simplified markup language like the wiki notation will differ from the output due to the formatting, so scrolling both textarea and formatted output by the same ammount of pixels or with some proportions will always loose sync.
Give them users two scrollbars and give up...
or
I've got an idea for You. It's based on the idea of not scrolling the preview at all, but generating it only from a currently edited part.
Finding out what is visible in the textarea was my first idea, but it won't be any more reliable than scrolling both views together.
What You can do is get the current cursor position in the textarea (can be done. has some browser issues)
Then get some n characters before and after the current position rounded to full lines and generate preview from that. You can check for cursor position change every 1 or 2 seconds and upate preview if it changed.
n depends on the textarea size.
pros:
no sync problems, need to generate only a part of a larger text
cons:
updates only if user moves text cursor.
You could make it a feature... The textarea would be a dominant part of the page and the preview div would float by.
If You need more details or help just ask in comments.

Looks like a great idea! You might have a #preview and a #input, with the preview updated with a simple event:
document.getElementById('preview').addEventListener('change', update, false);