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.
Related
Alright, so what I'm looking for is something I can't really put a name to.
It's similar to scrolling text, except I don't want it to scroll. Maybe a little fade in/out effect if possible, but that's totally optional.
Basically, this is for an area on a website with limited vertical space. I have an area of, let's say 120 characters wide and 4 lines vertical, and that's all.
I have a list of song quotes. Right now it's a text file, and I can format it as however. (meaning if I need to put one quote per text, name it lyric1.txt, lyric2.txt, lyric3.txt, that's fine... or if I put an extra blank line between them, that works too. Whatever is necessary.)
What I want to do is display one set of lyrics at a time. They vary in length, but they will all fit in my limited area. Have it display for, let's say 2 minutes, then change to a different set of lyrics.
So essentially what I'm trying to do is have a static area of text that changes what text is displayed every X amount of seconds, in order to prevent scrolling or cropping.
If it won't work as a time-based thing, having it show a different selection each time the page is loaded (or refreshed) would also work.
Something tells me Javascript is capable of doing this, but I really don't know where to start.
You can use <marquee> tag of html. after some period of time you can change the text inside of <marquee> tag with help of javascript.
Simple use of marquee is :
<marquee>This is basic example of marquee</marquee>
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'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?
Is there any JS/CSS/jQuery magic I can work to identify whether the last visible bit of content in a div is being cut off, and slightly increase/decrease the DIV's height to prevent the cut off text?
Our system allows the user to enter "elements" containing XHTML (using a Telerik Edit control). We have an ElementList page, where we show all the user-entered elements. However, since the user-entered XHTML can be very large, on the list page we only want to show the first 3 lines of each. So I set the DIV containing the XHTML to a specific height equal to 3 rows of text, and set overflow: hidden. So far, so good.
However, since the user can enter XHTML, they can create tables with padding (or otherwise diverge from standard text height). The text within those cells appears to be sliced off horizontally, due to the combination of height and overflow: hidden. Our requirements person doesn't like the look of this; but of course we cannot restrict the XHTML editable by the end user.
Here is a JSFiddle example of the issue.
This question is not a duplicate of:
"Stopping cut off text in variable height div..." as that question involves "webkit-line-clamp" which is irrelevant to my situation. (and in any case, that question was never answered)
"Cut text by height, no truncate" as that question is about a DIV containing pure text; my DIV contains XHTML. You'll note in the JSFiddle that I'm already sizing the DIV height using the em measurement.
This issue has me completely baffled - I'm hoping the SO community can come to my rescue!
UPDATE:
Ultimately, I suspect this cannot be resolved using HTML/JS/jQuery. In fact, you can craft a table (or series of DIVs) with gradually increasing top-margins, such that there's no way to avoid slicing at least one of them.
Thanks to all for their responses. I'm marking one as an answer, because in my opinion, it's a particularly simple/elegant workaround.
This is not the solution you were looking for, but it might be a good design workaround.
I put a white gradient in the bottom of the div, so that it creates sort of a "visual ellipsis"
Take a look: http://jsfiddle.net/robertofrega/LkYjs/3/
It is not as ugly as when the text is simply cut.
Your trouble is coming from overflow:hidden;. This line is doing exactly what you tell it to do, namely hiding the overflow. Can you use overflow-y: auto or something like that? That along with a grippy (like SO uses on its text areas), should help you out.
Instead of having overflow:hidden, you could set it to auto and then check for the presence of a scrollbar upon submission of the content. See this thread:
detect elements overflow using jquery
Try CSS3 property: text-overflow and set it to ellipsis, the default value is clip
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);