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.
Related
Have a look at this video. In MS Word, one can drag any element anywhere. Based on that, the remaining content (only text, in this video example) reflows and wraps to fit. For example, when two images are side by side and one is dragged away or towards the other, the text in between shrinks or expands accordingly.
Is it anyhow possible to mimic such behavior in HTML, with Javascript? The biggest difficulty I find is the fact that elements own their content in HTML. So, a span owns its text, a div owns its text. But in the video, we can see that the text element in between the images hasn't exactly any content of its own, it gets whatever fits into it while transferring text from left to right. That is why, its content changes with change in orientation. Also, its text is not continuous. It contains bits and pieces of multiple sentences.
Are such manipulations possible with HTML and Javascript? If so, any heads-up will be nice...
Have a look at css exculsions:
http://adobe.github.com/web-platform/samples/css-exclusions/
it might help you acheive what you want. note that it is an experimental feature.
I'm trying to create a column-based, blog layout. I want the text to wrap to a new column when it hits the bottom of the page. At it's very simplest form something like, when the column height == the_height_of_the_wrapper then column-count++.
The problem with something like that would be the text would be distributed evenly. Also, that would rely on css columns and I want something a bit more browser-friendly. Are there any existing plugins for this functionality or anywhere I can get some ideas?
If anyone is familiar with any of the text-heavy windows 8 "metro" apps (such as the news one) that's the kind of layout I'm trying to mimic.
As i noticed in comments, you cannot use column-count there. But there is solution, check this one please: Continuing overflowed text in a different div?
Alternatively. You can apply a fixed height (even a percentage will work) to the wrapper the columns will fill appropriately. (example: w3schools.com/css3/tryit.asp?filename=trycss3_column-count). It even seems as though you don't have to specify a fixed column count as it appears to create extra columns as the content dictates.
I'm writing some code that wraps various content into columns of text (and images, videos, etc). The code works fine, but due to the algorithm I'm using it's rather slow, specifically this general logic:
add something (text for this example) to a column
check to see if column.scrollHeight > column.offsetHeight (this requires a DOM reflow)
if yes, start to binary split the text until it's shorter
Basically my issue is that I'm adding an unknown amount of text to a column, so after each chunk of text I check the column's scroll height which requires the browser to actively reflow the DOM in order to give me the correct scrollHeight. So I have 50-100 or more reflows in order to properly lay everything out.
Any general ideas on how to avoid most of these?
You could render the content multiple times. Since the first time would cache it, this should be fairly fast. The reason for the multiple rendering would be as follows.
Render the original content in a hidden area
Check to see what the column width is compared to content
Overlay the content over the column, but beneath the page. This
will cut off part of the content that is overflowing. You can accomplish with
z-indexing or with overflow: hidden;
Based on what the check from step 2 was, overlay a copy of the content with
the calculated offset in the next column in the same fashion, hiding the
extra content.
Keep track of the rendered content versus total content so you can tell how many
columns you need to do this to if there are multiple columns.
Maybe this is the same thing Travis J is suggesting, but I'm not sure, I don't quite understand his solution.
You could render everything first, on a single column, then loop through the elements top-down to know when to split, based on your desired column height versus each element's offsetTop plus height. When you find an element to break at, cache its position and go on. At the end you should have an array with the list of elements to break at, so you can actually split the content in columns.
Does this make any sense to you?
I've got a small issue with a website I'm currently working on, that doesn't bother me too much, but would be nice to fix. We've designed the site (along with the rest of the advertising for this event) to be based on a strict square grid. Everything is working just fine, except for one little problem:
At the bottom of the page, we have a few paragraphs of body copy that are throwing off the page by a third of a grid square. (We have the line-height of the text to be a third of a grid square) Short of Javascript calculations, is there any way we can add some sort of "smart" padding to the bottom of these paragraphs to re-align the next elements to the grid?
is there any way we can add some sort of "smart" padding to the bottom
of these paragraphs to re-align the next elements to the grid?
I don't think there's a pure CSS fix, particularly when you take into account the fact that different browsers/operating systems might render the text with slightly different height.
The only other thing I can add to my answer is a JavaScript fix, which you don't want:
document.body.style.height = Math.round(document.body.offsetHeight/72)*72 + "px";
At least it's short.
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);