I am using a javascript based calendar. I am supposed to introduce a line in it marking today's date. I was able to achieve it for cells that are expanded. But I cannot introduce a line when the cells are collapsed. The reason is that, during the collapsed case, the row is one full div as opposed to seven individual cells.
You can see in the above image there is an ash Line running indicating today's date. But not for the collapsed times. What is the best way to achieve a line in between them?
Is it required that those collapsed ones be only one div or can you make them into seven divs and get rid of the borders?
The idea being that making them separate divs then allows you to put in thicker borders (assuming that is how you are generating the line).
Alternatively you may be able to use a relatively positioned DIV for the marker line and do some calculations on where it needs to be and then have it floating over the rest of your content. This way it would not matter what layout the stuff underneath was. This does rely on there being a relatively easy way to calculate the desired position (I'm assuming its not always just before the last day).
Related
I need to get the bounding rectangle of the text selection. I am using this code:
if (window.getSelection && window.getSelection().rangeCount) {
var range = window.getSelection().getRangeAt(0).cloneRange()
if (range.getBoundingClientRect && range.getBoundingClientRect()!=null)
return range.getBoundingClientRect()
}
But it often returns a rectangle that is much wider than the text selection, even though every element of the selected text doesn't extend that wide.
For example, when I select the text of the fist two paragraphs of https://simple.wikipedia.org/wiki/Gluon the rectangle includes the picture to the right.
It seems that the problem occurs every time when the paragraph boundary is inside of the text selection, and this makes the rectangle to extend to the paragraph width.
How to solve this problem?
The image being included in the multi-paragraph selection may be a problem for what you want to accomplish or the way you want to interpret the document structure--yet isn't "wrong" from the point of view of the HTML/CSS layout model or the browser's layout engine.
Simplifying the document structure:
<div id="nw-content-text">
<div style="float: right">
<img src="gluons.png">
</div>
<p>From Wikipedia...</p>
<p>Gluons are what hold quarks together...</p>
...
</div>
In Chrome e.g., inspect the page. Then in the Elements view select either of the <p> tags. The rendered view will show highlighted background extending across the image area:
That's because the image floating to the right is indeed consuming part of the paragraph's maximum possible bounding box. If you want to consider just paragraph text, that feels wrong, but it's how the CSS layout model works. Depending on your font sizes and such, you may be able to select the third para as it flows underneath the image, and it indeed flows to the same far right edge.
Given the float: right of the image's container, the browser "thinks" the image and its container <div>s "lives" to the right of the first para, but before the second. That is its logical "attachment point" or "anchor point." Select the first para, and the browser knows the image isn't included. Select the second, and likewise. Select the combination, though, and the image is correctly included because the anchor point lives between the two paragraphs. Ask for the bounding box of either para alone and the browser responds with a tight box. But ask for tbe bounds of the selection that spans those paras, and it must include the anchor point and contained image that anchor point represents. The much larger bounding box including the image is the right answer.
Okay, so much for the layout theory explaining why this happens as it does. Now how to get it to do what you want it to do, and exclude the contained image from the selection bounding box?
Given that CSS and the browser doesn't interpret the selection the way you want, you won't be able to use getBoundingClientRect() on the selection directly. However, you can navigate from the selection to the nodes included, and filter out any tags that you don't want. In this case, you seem to only want <p> tags, which are easy enough to filter for. Compute the bounding box of each para in your selection, then return a box that is the union of them.
Beware that working with ranges is a bit tricky, especially as browsers historically had different models for how to manage them. A cross-browser library like rangy might help, though simply navigating from a range to the underlying nodes probably doesn't require that much extra framework. There are quite a few articles on Stack Overflow about "getting from JavaScript selection to underlying nodes," with many code samples. They're not all simple...but just filtering for paras is a fairly simple case. Or if you don't want to dive into all the range issues, you can use something like Selection.containsNode() to less elegantly but still quickly iterate through possible nodes and see if they're in the selection.
Also beware: Your example document makes things simple by just needing filtering for paras, and by having just one floating item to exclude. But the variability across all HTML / CSS documents is enormous. That variability can make solutions fragile. E.g. if sometimes you need to filter for more than just <p> elements, or need to filter into the middle of text nodes not affiliated with a tightly-wrapped tag, things quickly get more dicey. The variations and the different edge cases will complexify your reinterpretation of what a selection's bounding box should enclose (and should ignore).
Looking for some solution to my big big problem with text edit. Short description below:
Lets say I have two (or more) editable containers. What I need is when you typing on a first container and the cursor reaches end of it, instead expanding it i want it to move to next editable container, it is like in regular Word document, when you reach end of the page it takes cursor to the next page, i need the same thing on two div containers, looking for tips solutions. Is it doable ?
You really don't want to use plain contentEditable :D. And it won't help - it will be exactly the same situation. You're looking for a holy grail of editors based on contentEditable - how to split content into multiple pages. It's doable using the CSS regions, but only Safari IIRC supports them. Thus, we're keeping fingers crossed for this spec :).
I'm creating a page where there's a textbox that displays a text string from the database, and its length varies. Because of this, some strings happen to be long enough to run onto two lines, but that second line is short, and this doesn't look good:
Here the blue box shows the div that contains the content. It's got a fixed width (80% of the container), and text-align:center.
So my question is: how can I get the text to flow into lines where the line widths are closer to each other? I'm willing to do some math and dynamically adjust the width or font size, but I'm not sure how to do this reliably.
You need JavaScript to do this. CSS alone cannot fix this issue if you are using dynamic text.
Once you've detected that the height of the box goes beyond the limit of one line you can either shrink the font, expand the box or calculate the mid-point to add a break and have two balanced lines.
Here are various jQuery plugins that an do this for you. There are many if you look.
http://fittextjs.com/
https://github.com/jquery-textfill/jquery-textfill
personally I don't like use javascript to "simple things"
you use the following properties
overflow
white-space
http://jsfiddle.net/ALWqd/
Assuming I have a div with a fixed width and some auto wrapping text inside. Now I want to insert a span element at the end of the first line. Because the text isn’t written in a specific structure, the first line could contain five words as well as three or just one. So I would need to find the position on which the automatic line-break happens. Is that possible or do I need to insert a manual br or some marker?
It's painfully possible. The question is why are you trying to do this? There may be an easier way to accomplish what you need.
If you decide you still need to do this, what you would have to do is create a clone of this div that cannot be seen. You would set this cloned div's height to 1px or something like that. You can then fill this clone with identical text word by word. Once the div's scrollHeight jumps, you know that the first word wrap has occurred. You can then use this data to figure out where the original paragraph' first line has word wrapped.
You need add or some marker. Different browser calculate how many words should be placed in the first line. And if user change setting of browser, for instance increase font size, the first line will change number of words.
Ok I need to be able to position a bunch of random sized absolutely positioned words on a page but I don't want any of the elements to overlap.
The end goal is to have a fluid word cloud that responds to user interaction (remember the Google Balls Doodle?). I would really like to build this from scratch to develop my understanding of this type of development. Any help in this department would also be appreciated :)
I'm not sure if you also want to position the words randomly inside a container, but i've written a fiddle that does just that. You can modify the code to position one word right after the other if you want to though. I think the key part is the method to check if there's a collision.
see http://jsfiddle.net/fZtdt/13/
EDIT: Be aware that this is very simple and unoptimized code. If for example you would add to many words, chances are that the script won't be able to fit all words inside the container, and get into an endless loop.
I have forked Jules' script to add this improvement : the search for a non-overlapping region is bounded (otherwise the original script will loop I believe), and the best region (the one with the smallest overlap) is selected.
see http://jsfiddle.net/Vnyvc/21/
play with the maxSearchIterations variable and/or the size of the whole region, it really makes a difference.