I spend couple of hours to try to get width of my div container. I read many questions and answers but none of them seem to work in my case - I always got 0. Finally I found that I can get it through scrollWidth property which wasn't even mentioned in this question and similar.
Now I have what I wanted by I still have no idea how this works.
Why all the other methods fail? Why this is named scrollWidth? I don't want to scroll anything - it's so confusing. Can I get the size of an element before I append it to a document - even scrollWidth don't work in that case. Is there any model I should follow to always get what I see on the screen? I can't see any patterns right now, I write someting, see something different on the screen, and get something even more different in the output. Every time I want to do someting it seem to be 10 different methods I can use but usually only one or two work because it depends on which methods I used earlier. When i work with 2d graphics I used to have x,y,width and height but in html I allways got those smarty CSS which seem to know better what I want to do. Sorry if this sound a little officious but I'm a little annoyed when i need to spend so much time on a trivial task like this. I use to draw graphic on canvas and it was much simpler but now I want to make a simple website so it's probably not a good idea to build it this way.
Here is my example
I understand that i get 0 size becouse those properties refer to element independently of its children and my container has 0,0 size, right? I read that if I set display: inline-block; style it will adapt size to match its children automatically - why this in not working?
The container element in fact has no width. This is why you are getting widths of zero. You can see this if you use dev tools element inspector.
The reason for it being that the container element is absolutely positioned and has no set width. Your child elements are also position: absolute and therefore they will not force the container element to 'grow' to their size.
To get the visible width of the menu, instead you could total up the widths of all the child elements (the first-level menu items). This is probably the best approach to use for the way you currently have things set up. Otherwise, I would suggest completely changing your approach with the html elements you are using, to the CSS properties you are using to position elements where it would not be required to use position: absolute.
I would advise you to open up your dev tools element inspector and start looking at how things react when you change the position from 'absolute' to 'relative'.
Understanding how to position elements and how widths/heights are affected using CSS will save you a lot of headaches - like the one you are having now :)
document.getElementById("mydiv").offsetWidth
This will return the width, including padding.
Related
I'm loooking for some advice concerning the following problem.
I want to position several elements inside a flexbox since the feature shall adapt to its surroundings.
Below one of these items I want to position a computed element which will use the size of the element above it. So in essence it has a fixed (but calculated) size.
I tried solving the issue by placing the calculated element into the flexbox, but this destroys the overall behavior.
It is supposed to look roughly like this:
<Label w/o shrink> <input element, can grow> <Label w/o shrink>
<some rectangle, calculated size>
desired layout - a link since I'm not allowed to post images
In the attached example jsfiddle example of problem I'm using an input element in combination with two labels and a computed rectangle to describe the behavior. Think of the rectangle as a generic example for the problem.
Resizing of the window in terms of enlarging the window works like a charm.
Issues occur when decreasing the size.
Flex can only decrease the size of elements with a non-fixed size, such as the input element. My computed rectangle has a fixed size. So this size prevents any shrinkage of the input+rectangle container.
Idea 1: Make the calculated item a little smaller than the related input so the container itself can shrink since there is space. The input will shrink and thus the calculated rectangle will shrink as well.
See jsfiddle with a smaller rectangle
This works to some degree. If the mouse moves slowly enough when resizing the window / the changes in size happen slowly, everything is fine.
As soon as the shrinkage happens too fast for the rendering to keep up, the issue as described above occurs again.
Idea 2: Ignore the calculated element by positioning it absolutely.
See here: jsfiddle with relative and absolute positioning
I defined the outer element to be positioned relatively and the inner (the calculated element w/ "constant" width) to be positioned absolutely.
By doing this the element will be taken from the flow and everything works fine.
Almost.
Since now the rectangle is ignored, the remaining layout gets broken as well. This is not acceptable due to the usage of this feature as a component in a bigger context. In the example the last label gets positioned too high up since the div won't take into account the rectangle.
My question now is if you have further advice. If at all possible I want to avoid any calculations in javascript and solve the issue using css-related options. (Otherwise using further info of getBoundingClientRect() - such as the x position - might have been an option in some way (?) -> this way I could remove the rectangle completely from the flexbox and just position it "by hand" at the desired position).
I am happy about any further ideas.
The issue appears to be caused by using the width of the input someInput to calculate the computed-element-container width. If you use the flex item width instead then it should work.
I've updated your jsfiddle to show this - I've created a second flex container above the original, that has the same three items. I then calculate the width based on an element with id: content-box. Hopefully this will assist you with finding a solution:
https://jsfiddle.net/jamarmstrong/h9rz1t4b/
For people who might have a similar issue here's another approach I came up with while trying to adapt James solution.
See this jfiddle: jsfiddle using overflow and min-width
What I changed about my first solution:
The issue with the shrinkage is some chicken-and-egg issue: The flexbox cannot shrink further than the elements inside allow for shrinkage, but then my computed element only shrinks if another element shrinks which in turn is prevented by the flexbox itself being unable to shrink, which brings us back to the beginning.
So in my question I tried to make the flexbox ignore the element by positioning it absolutely - which messes up the overall layout.
A solution I came up with in order to allow shrinkage: Make some of the elements be able to overflow the flexbox and allow for a min-width different to auto.
This way I allow the calculated element to overflow the flexbox (which makes the flexbox kinda ignore the item). Note that you also want to adjust the min-width of certain elements.
So in the end I introduced a second flexbox which encapsulates the computed element. Both this element as well as the items inside allow both for overflow and shrinkage. (One might be able to simplify the elements a little).
The computed element can thus breach/overflow its boundaries and the overall construct can shrink. The shrinkage causes the computed element to resize right away - so temporary overflow gets fixed immediately.
You can compare this approach to James idea and decide which one suits your troubles better.
I have a question on a big # of dom elmenets and performance.
Let's say I have 6000 dom elements on a page and the number of the elements can be increased as a user interact with the page (user scrolls to create a new dom element) like twitter.
To improve the performance of the page, I can think of only two things.
set display to none to invisible items to avoid reflow
remove invisible items from the dom then re-add them as needed.
Are they any other ways of improving a page with a lot of dom elements?
We had to deal with a similar problem on FoldingText. As the document grew larger, more line elements and associated span elements were created. The browser engine just seemed to choke, and so a better solution needed to be found.
Here's what we did, may or may not be useful for your purposes:
Visualize the entire page as a long document, and the browser viewport as the lens for a specific part of the long document. You really only have to show the part within the lens.
So the first part is to calculate the visible view port. (This depends on how your elements are placed, absolute / fixed / default)
var top = document.scrollTop;
var width = window.innerWidth;
var height = window.innerHeight;
Some more resources to find a more cross-browser based viewport:
How to get the browser viewport dimensions?
Cross-browser method for detecting the scrollTop of the browser window
Second, you need a data structure to know which elements are visible in that area
We already had a balanced binary search tree in place for text editing, so we extended it to manage line heights too, so this part for us was relatively easy. I don't think you'll need a complex data structure for managing your element heights; a simple array or object might do fine. Just make sure you can query heights and dimensions easily on it. Now, how would you get the height data for all your elements. A very simple (but computationally expensive for large amounts of elements!)
var boundingRect = element.getBoundingClientRect()
I'm talking in terms of pure javascript, but if you're using jQuery $.offset, $.position, and methods listed here would be quite helpful.
Again, using a data structure is important only as a cache, but if you want, you could do it on the fly (though as I've stated these operations are expensive). Also, beware of changing css styles and calling these methods. These functions force redraw, so you'll see a performance issue.
Lastly, just replace the elements offscreen with a single, say <div> element with calculated height
Now, you have heights for all the elements stored in your Data structure, query all the elements that lie before the visible viewport.
Create a <div> with css height set (in pixels) to the sum of the element heights
Mark it with a class name so that you know its a filler div
Remove all the elements from the dom that this div covers
insert this newly created div instead
Repeat for elements that lie after the visible viewport.
Look for scroll and resize events. On each scroll, you will need to go back to your data structure, remove the filler divs, create elements that were previously removed from screen, and accordingly add new filler divs.
:) It's a long, complex method, but for large documents it increased our performance by a large margin.
tl;dr
I'm not sure I explained it properly, but the gist of this method is:
Know the vertical dimensions of your elements
Know the scrolled view port
Represent all off-screen elements with a single div (height equal to the sum of all element heights it covers for)
You will need two divs in total at any given time, one for elements above the visible viewport, one for elements below.
Keep track of the view port by listening for scroll and resize events. Recreate the divs and visible elements accordingly
No experience myself with this, but there are some great tips here: http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5
I had a look at Facebook and they don't seem to do anything in particular on Firefox. As you scroll down, the DOM elements at the top of the page don't change. Firefox's memory usage climbs to about 500 meg before Facebook doesn't allow you to scroll further.
Twitter appears to be the same as Facebook.
Google Maps is a different story - map tiles out of view are removed from the DOM (although not immediately).
It's 2019. The question is really old, but I think it is still relevant and interesting and maybe something changed as of today, as we all now also tend to use React JS.
I noticed that Facebook's timeline seems to use clusters of content which is hidden with display: none !important as soon as the cluster goes out of view, so all the previously rendered elements of the DOM are kept in the DOM, it's just that those out of view are hidden with display: none !important.
Also, the overall height of the hidden cluster is set to the parent div of the hidden cluster.
Here are some screenshots I've made:
As of 2019, what do you think about this approach? Also, for those who use React, how could it be implemented in React? It would be great to receive your opinions and thoughts regarding this tricky topic.
Thank you for the attention!
I am working on a js player and the seek bar doesnt want to play nice. You can see two on pageload, they both work properly. Now click on either first or second div with the play img on it and a bar will appear. When you click there the bar is not precise. Its several pixels off.
this.offsetLeft is giving me 0 instead of 10 which breaks this. How do i fix it?
-edit- i still dont understand why but i decided to look again a min ago and deleted random css i pasted in. i deleted this single line and it worked. I am not sure what that block does but i know without that line it currently looks the same. player is not done yet so maybe i'll need this and revisit the question
position:relative;
The position:relative style is often used to make the element the "origin" for absolutely-positioned child elements. In other words, child elements with position:absolute calculate their positions from the relative parent's position. (instead of the window's) This way child elements follow the parent wherever it is placed.
Relative positioning also lets you use 'left', and 'top' to adjust the position of the element from its normally position.
The style can also be used to fix positioning and scrolling bugs in Internet Explorer.
It maybe too late for this issue but my experience can be useful here.
I had the same problem, i was getting 0, when i called getOffsetLeft() method.
you must add your widgets into container first and then call getOffsetLeft() method.
A requirement for a current project of mine involves "highlighting" an HTML element in the context of a page. That is, I need to provide some sort of visual effect that decreases the brightness of the surrounding page while leaving the element at full brightness.
To achieve this, I'm trying the following approach:
Determining the highest z-index value of any element on the page (using JavaScript).
Creating an element to function as a "backdrop" on top of the page. This is just a <div> with a translucent gray background image, sized to 100% of the width and height of the <body> element, with position: fixed. I set its z-index to 1 greater than the highest z-index I've found on the page, with the intent that it will overlay every other element on the page.
Change the z-index of the "highlighted" element to 1 greater than the backdrop. The intent is to allow it to sit on top of the backdrop, which in turn sits on top of the rest of the page.
I got it working on a quick test page:
http://troy.onespot.com/static/stack_overflow/z_index_test.html
but when I tried to set it up on a few actual Web pages, it didn't work in all cases. For example:
http://troy.onespot.com/static/stack_overflow/z_index.html
Here, I've inserted two "dummy" elements on a copy of a Jacksonville.com article page, both with a class of test (if you're looking at the page source, they're at lines 169 & 859).
I also added some JavaScript (using jQuery) at the very end of the page that functions as I've described above.
The first <div class="test"> does function as I'd expect it to. However, the second one does not - it seems to still be stuck beneath the "backdrop" element, despite having a higher z-index.
I think this may have something to do with stacking contexts, but after reading through the relevant W3C docs (http://www.w3.org/TR/CSS21/visuren.html#z-index & http://www.w3.org/TR/CSS21/zindex.html), I still can't fathom why this is happening. I'd appreciate anyone more familiar with z-index and stacking order than I to take a look at my examples and let me know if anything looks suspicious.
Please note that I've only tested these examples in Firefox v3.6.
Thanks very much for any help!
The problem is that the second test div is inside a bunch of other HTML elements, one of which must be creating a new stacking context (it may be the #wl-wrapper-tier-1 div). Basically, a new stacking context is created whenever an element is positioned and has a z-index other than auto, see this MDC article for more info on stacking contexts.
Ultimately this means you can't achieve your desired effect reliably with this method. I think you're probably better off composing 4 divs to surround the target element.
If the element that you're highlighting is inside a different element (stacking context) with a z-index lower than the backdrop, it will not appear higher than the backdrop, since the element's z-index only controls stacking order within that parent.
The only good solution is to clone the highlighted element and add the clone to the <body> tag.
Beware of inherited CSS styles, which would be lost.
After googling around and finding a lot of ie bugs I still did not find a description of the problem I have.
The initial situation is a standard one. We have a tooltip which is actually a hidden div that will be displayed on mouseover at a given location. The div is hidden with display:none and contains a table with the content. We tried different libraries for showing the div (scriptaculous and jQuery Cluetip) but the effect is the same.
The problem:
Everything is fine as long as the contents fits the width of my window. But when I resize it until the horizontal scrollbar is activated the content of the hidden div will be shown at the end of the page when the tooltip is activated.
This is really strange as it happens only under these premises. When more than one tooltip is involved the browser might even crash (and under Vista takes the whole system with him duh).
I know it's a bit complicated to explain but I hope that someone at least had heard of that bug and can point me into the right direction.
Setting the width css property to "auto" (defined in the W3C standard) in IE will cause the <div> element to take up the entire space allotted to it. If the <body> element does not have a width applied, then this can result in a page miles and miles wide. This often crashes the browser, depending on the operating system. The best option is to just set it to null instead.
(This is based on actual experience coding for IE6 and may not necessarily apply to IE7+).
Another thing to keep in mind is that most browsers do what's called "lazy rendering" which means that if an element is hidden on the page, it won't render it. It won't even acknowledge its existence as a potentially visible object until it is unhidden. This means having no idea how big that object is going to be until you reveal it. This can cause problems if you're trying to figure out how big something will be once you make it visible. Basically the only way around it is to unhide it, read its size, re-hide it, then proceed.
The way that I did my tool tip is to use visibility hidden and visible. Once the mouse is off, I set the x and y to 0 to move the tooltip out of the viewing space.
This only works if the position is set to absolute.
Edit: How did you position the tooltip when showing it:
I positioned the tooltip by changing the css values of "top" and "left".
box.css("left, e.pageX+1);
box.css("top", e.pageY+1);
Where 'e' is my event variable from:
mousemove(function(e){});