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);
Related
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.
I am developing a website for a report. The majority of the report fits within a column that can be no larger than 800px. However there are a couple of sections of the report that include tables that are just so detailed it is impossible to fit within that space.
The solution I am considering is to use JavaScript/jQuery to detect tables that are too large for the column and turn them into links, that when clicked, brings up a light box using more available screen space and displays the table.
This does not seem to difficult to do… but then I started considering accessibility.
So after detecting the oversized tables should I cut them out of the DOM and store them in a variable or should I hide them?
Do accessibility devices such as screen readers use the original source or do they respect changes made by Javascript?
If you hide the content with display:none then the screen reader will not see it until you toggle that attribute.
You could also rip the content out of the DOM as the screen reader only looks at the rendered DOM.
When you create a lightbox, you will have to set focus into the lightbox in order for the screen reader to read the content.
I was flirting with an idea of making a bookmark app which might let users bookmark only a section of a page like in this image. They will click twice on the page to mark two horizontal lines. Area between these lines will be highlighted to show the selected portion of the page.
I will be saving the y-coordinates of the two lines. That's it.
But what if:
The user opens the bookmark in a bigger or smaller screen afterwards. The webpage will re-size to fit the new width and some of the elements will definitely change their position. Then the coordinates will mismatch and wont show the original selected area.
The page content on the url changes later on.
The webpage is responsive. Then the mobile view will be completely different. It might not contain some of the elements from the original normal monitor screen.
Solution for problem 2 can be that we save a permanent copy of the page and then set coordinates on it. I have figured out this part of saving the webpage to a single html file which looks very much like the original.
And for 1 and 3 points I am thinking if it can be possible to somehow fix the width of the webpage to show against the screen width. i.e. just stretch or shrink the original page width according to the screen width. Is there a way to do this? I did some experimentation with viewport meta tag but it didn't work.
Do you guys have any idea? Anything else according to you that can go wrong? Any extra add-on?
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 work out how to do "type-writer scrolling" in JavaScript for a textarea in a web-page, but I'm having no luck. Essentially, what I'm trying to do is make a textarea that, when a new line is created, scrolls the document automatically so as to keep the new line in the same position as the previous line. I've seen something similar in desktop applications such as Write Monkey, but can't work out how to do it in JavaScript.
Thanks in advance for any suggestions!
Have a look at this page http://www.mediacollege.com/internet/javascript/page/scroll.html it shows basic scrolling methods
You could either scroll down by the height of your line (line-height css property) or scrollTo a specific point on the page
I have achieved something close to this, automatically expanding a textarea the way it is done on Facebook, but that was based on a conservative estimate, considering font size, box width, etc, to determine how many lines have probably wrapped. What you are describing is more exact -- down to the character.
The challenge here lies in knowing exactly how many lines are currently in the textarea and I can think of no way to do this. When you say, "a new line is created," you're talking about automatic wrapping and there is no way to read that or to trigger from it. It is part of the browser's hard-coded interpretation of many things, including your CSS.
If you went through with the whole typewriter theme, you would have a bell and the user would hit RETURN when they needed to, then you'd have your cue to scroll, but that sounds like a sure way to remind people why we no longer use typewriters.