Develop Reference

Position computed item below element of flexbox

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.

Having to remove and re-apply a CSS property to make it work. Possible bug with CSS?

UPDATE: Before reading into this post and saying you need more code to replicate the issue, the simple question I am asking is:
"Have you ever had to remove and re-apply a CSS property on an element in order for that style to apply when that property was already on that element and should have been working by default? If so, what was your solution or did you know what was ultimately causing the problem?"
UPDATE 2: I'm not 100% sure but this may only be an issue with the font-size property and it being changed dynamically using Javascript. The CSS for the outer and/or inner elements that are being re-sized in Javascript works as it should, this problem seems to only occur with font sizing, in particular. Perhaps the surrounding HTML's CSS doesn't catch font-size on memory intensive style changes (like our resize function). Just a guess.
The rest of this post is a means to clarify what I am talking about.
This problem might be exclusive to Chrome. To clarify, our app is used internally by our sales team and the project was specced out to focus exclusively on Chrome, both for development and field use. Already, the styling is totally off when opening this in other browsers, since we've only had to create our CSS to be Chrome-compliant (how I got so lucky to land such a position, I don't know, haha).
I've only encountered this issue a few times in my coding career which I believe to be a bug in CSS but could just be a rare bug between Javascript making style changes in the DOM and parent container CSS not adapting to the change due to possible memory constraints or slight processing lag between Javascript applying a style to the HTML and the CSS not updating to accomdate. I think this is an important question as I think every front-end web developer has or will come across this at some point in their career.
Situation
To put it as short as possible, we have a container inside our body that we use Javascript to size to a 16:9 aspect ratio relative to the window size. Took a screenshot of the entire window. As you can see, we have the inner container sizing proportionally inside our browser window (the black area, which is the body). The inner container is where all the content for our app displays:
Our CSS is built using percentages, wherever possible. We built a 'resizeUI' function that's mainly used to change the font-sizes based on the current width/height ratio of the inner screen, though there are other elements in that function that get re-sized too, on window re-size. The window always re-sizes perfectly and anything needing specific sizing based on the inner window's width/height pixel ratio works as expected, with the child elements' percentage-based CSS adjusting appropriately. But....
The Problem
When the browser window is re-sized by clicking and dragging (incremental re-sizing) everything on the page re-sizes perfectly. However, when the window size changes drastically, and instantly, fullscreen (Maximize) to small (Restore Down), or visa versa, the font-sizes in the top menu will change BUT the CSS of the parent li will not adjust to accommodate the new font-size unless I un-check (remove) it's padding attribute and recheck it (add it back in). When I do that, it works fine. The li container really just has a padding:1% and, thus, normally adjusts it's size correctly based on the inner span's size which changes with the font re-sizes.
The parent li should automatically adjust to the change of the inner span font-size. I'm positive of this because the parent li container will automatically re-size itself when I modify the menu's font-sizes or text lengths, on the fly, in the inspector.
Here's what it normally looks like either on load or with incremental window size changes:
And here is what it looks like when I go from a small window size to full-screen using Maximize:
My (hacky) Fix
Only way I've gotten this to work is to remove the padding for the <li> elements at the top of the re-size function, then re-apply it at the bottom of the re-size function AFTER the line that re-sizes the font. However, this works 50% of the time. Only when placing a 100ms timeout at the bottom of the re-size function to re-apply the padding have I gotten it to work 100% of the time now.
To help, here's a very basic code example of what i'm working with. The ul sizes automatically to it's inner elements:
Relevant HTML
<ul>
<li class="menu-items><span>Item 1</span></li>
<li class="menu-items><span>Item 2</span></li>
<li class="menu-items><span>Item 3</span></li>
<li class="menu-items><span>Item 4</span></li>
<li class="menu-items><span>Item 5</span></li>
</ul>
Relevant CSS
ul {
position:absolute;
top:0;
right:2%;
text-align:center;
}
.menu-items {
padding: 1%;
}
Relevant Javascript
What works about 1/2 the time
function resizeUI(){
$('.menu-items').css('padding','0');
//Random other elements being re-sized
$('.menu-items span').css('font-size', properRatio + "px");
//More elements being resized
$('.menu-items').css('padding','1%');
}
Works every time
function resizeUI(){
$('.menu-items').css('padding','0');
//Random other elements being re-sized
$('.menu-items span').css('font-size', properRatio + "px");
//More elements being re-sized
setTimeout(function(){
$('.menu-items').css('padding','1%');
}, 100);
}
Ultimate Question
Has anyone else encountered similar issues when working with CSS that should adapt to the re-sizing of an element? I sense it's a memory issue or bug between Javascript and CSS, given that having to set a timeout is the only reliable way I have gotten it to work 100% of the time, and, again, this ONLY occurs on a vast, instant change in window size (Maximize to Restore down, or visa versa) but not on manual, smaller, incremental resizing. Sorry for such a verbose post/question but I have encountered this weird bug a few times before with having to remove and reapply a CSS attribute to get it to work properly and I have no doubt other developers have too.

The padding is actually working. Each unit (div or whatever you are using) is overlapping the one previous evenly because you are over 100% of the view width in total. They are being built from left to right and when it gets to the end of the max size allowed, they will all equally push over the ones previous. Also padding affects elements inside of the div and will not affect divs outside of itself. So they are all the correct size but you have not established a rule that would stop divs from overlapping. Margin can do that but if they are over 100% of the desired size you will have to deal with over flow in some way. You can try to use auto for padding, but margin may be better. Otherwise you will have to play with the sizes and percentages to make it fit to the max allowed width. Checkout the CSS Box Model here.

Have you ever had an issue of having to remove and re-apply a CSS
property on an element in order for that style to apply when it was
already there and should have been working by default?
Yes: https://stackoverflow.com/a/34245989/1529630
What was your solution?
Unsetting the styles and resetting them immediately after didn't work, probably because the browser hadn't updated the page yet, and then it detected that I resetted so at the end it did nothing.
Unsetting and resetting in a timeout worked, but caused annoying blinks.
In my case, the solution was removing the element and inserting it back immediately.
window.addEventListener('resize', function() {
// Force a rerender
var parent = element.parentNode,
next = element.nextSibling;
parent.removeChild(element);
parent.insertBefore(element, next);
});
Warning: this will force the browser to do layout, paint and composite operations, which is expensive.

Get HTML element size

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.

Performance with infinite scroll or a lot of dom elements?

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!

Tricky css/javascript floating task

I have a design that has several divs at varying widths/heights and I need them to float essentially to the top left. A simple css float:left will not work because it does not take advantage of the vertical space once it drops to a new line.
I assume I will need to use jQuery to dynamically position each div but I was hoping someone could lead me in the right direction.
This is what a standard float left would do:
standard float http://www.media1designs.com/poc/superfloat/diagram_float_left.gif
This is what I need it to do:
what I need http://www.media1designs.com/poc/superfloat/diagram.gif
The sizes of the divs will change as the website's content updates so manually entering the positions is not an option.

Have you tried the masonry plugin?

You need to have an algorithm for determining where to place the next element given a set of existing elements and a bounding box (the container width & height). I'd start with plain english and just writing it down with pen and paper first - it's easier than code.
Once you have that, you'll use the jQuery width and height functions to get the sizes of the elements to position and I believe you'll want the css function for setting the top/left. The position of the elements should be "absolute" and the position of the containing element should be "relative". See all jQuery API methods.
Assuming you've written your layout algorithm as the function calculateOffset(element, container) returning an offset literal (e.g. {left: x, top: y}) and that you have a jQuery element list elements and a jQuery-wrapped container, you can do something like this to position everything:
elements.each(function() {
$(this).css(calculateOffset($(this), container));
});
The hard part, of course, is writing calculateOffset. For that I recommend starting with something simple, like finding the highest possible (lowest top) place to put an element, favoring the left side (lowest left), then going from there.

I don't think I've ever heard of or seen a layout engine that would display things in that fashion. Most likely, you'll just have to write it yourself.
You'll need to create an API (at least in the way you think of things). Most likely, you'll end up with a Block (each div to be laid out) and a Container (the area holding the divs). Apply the appropriate methods, properties, and events to each of them, and you'll probably get there rather quickly.