The Flex tile containers will create and remove tiles as the data changes and seems good to use in areas where the content is dynamic. How to implement this functionality in HTML? I guess that we need to use some JS and/or CSS. Any inputs?
You can ignore CSS altogether (for layout) and do this the same way that flex implements it. Without providing code itself, here's the basic idea (assuming horizontal layout):
When you add a child, add it to the right of the previous sibling. (c.y = s.y+s.width).
Check if current child exceeds the width of the parent. (c.y + c.width > p.width). If so, drop it to the next "row".
Of course, things get more complicated depending on whether you want to do a TileContainer or a FlowContainer. Should the layout look like a grid, or should it be more organic like paragraph wrapping? (if all you want it paragraph wrapping, I think making everything "float:left" will do that for you, but correct me if I'm wrong.). Assuming the TileContainer idea, you just need to iterate over all the children and make sure they have the same height/width (== max child height, max child width), and then do the layout steps mentioned above. You may want to place each child in a container div for easier control of elements that don't resize nicely.
And lastly, just make sure you listen for any window resize events so you can run your layout algorithm.
Check out the algorithms in "TileBase.as" in Flex if you want tips, but it might be easier just to roll your own.
Related
Use case
I want to detect if html tables get too wide, and if so, I want to flip the table header cells to become vertical (e.g. with writing-mode: vertical-lr;).
I want to update this on resize: If the viewport gets bigger, the text in the cells might become horizontal again.
The flip condition is whether the original table with horizontal labels would be wider than its container.
Question
How do I determine the width a table would have with horizontal labels, without changing the table itself?
Thoughts
My current idea would be to make an invisible copy of the table with horizontal labels, and use it as a "sensor". But I am afraid this will pollute the DOM and cause side effects somewhere. Also I would need to keep this copy updated all the time.
Is there a "best practice" or a known pattern to solve this problem?
It is actually quite simple:
We can change the css on the table during the script run. Once we query a property like element.width, this will cause a reflow during the script execution, but it won't cause a repaint. So this means we can do the test without the need for a cloned DOM element, and without visible changes.
See https://developers.google.com/speed/docs/insights/browser-reflow
Even though my DOMContentLoaded event is fired at ~500ms, the first paint happens around 3.5s due to a very long layout phase.
Can anyone advise me as to why this might be happening, and how I can fix it? Currently the page does have ~350 nodes, but I've seen other sites with similar nodes and a 50-100ms layout phase.
What am I doing wrong?
P.S. This is a universal React app and I'm using Heroku Standard 1x and Fastly CDN to serve it.
Use the following steps to minimize the number of nodes that need layout:
Use relatively positioned containers with absolutely positioned children to handle bookend and centering layout needs:
Absolutely positioned elements are removed entirely from the document flow. That means they have no effect at all on their parent element or on the elements that occur after them in the source code. An absolutely positioned element will therefore overlap other content unless you take action to prevent it. Sometimes, of course, this overlap is exactly what you desire, but you should be aware of it, to make sure you are getting the layout you want!
Avoid animation based on the positioning of an element:
The handler computes each image's left property based off of the image's offsetTop value. This forces the browser to perform a new layout immediately to make sure that it provides the correct value. Forcing a layout during every animation frame is the cause of the janky animations on the page.
Avoid calculations that depend on computed values of DOM elements:
As a general rule of thumb, if you ask for a geometric value back from the DOM before a frame is complete, you are going to find yourself with "forced synchronous layouts", which can be a big performance bottleneck if repeated frequently or performed for a large DOM tree.
Replace float with inline-block if possible:
Any content in the current line before a floated box is reflowed in the first available line on the other side of the float.
Use display: flex instead of display: table or JavaScript based layout if possible:
The new flexbox code has a lot fewer multi-pass layout codepaths. You can still hit multi-pass codepaths pretty easily though (e.g. flex-align: stretch is often 2-pass). In general, it should be much faster in the common case, but you can construct a case where it's equally as slow.
That said, if you can get away with it, regular block layout (non-float), will usually be as fast or faster than new flexbox since it's always single-pass. But new flexbox should be faster than using tables or writing custom JS-base layout code.
Only use bottom as a value for the vertical-align property:
The inline boxes are aligned vertically according to the 'vertical-align' property value for source inline elements. If an element has the values 'top' or 'bottom' for this property, only the height of the generated boxes affects the line box height calculation; the boxes cannot be aligned until the line box has been fully constructed.
Note that if all the boxes in the line box are aligned along their bottoms, the line box will be exactly the height of the tallest box. If, however, the boxes are aligned along a common baseline, the line box top and bottom may not touch the top and bottom of the tallest box.
Use inline-block with a fixed height for numerous inline elements that need to be vertically positioned:
The height of each inline-level box in the line box is calculated. For replaced elements, inline-block elements, and inline-table elements, this is the height of their margin box; for inline boxes, this is their 'line-height'.
Use shouldComponentUpdate to optimize rendering:
In practice, anything complicated probably requires shouldComponentUpdate for acceptable performance. Writing reasonably efficient shouldComponentUpdate in turn requires underlying data that can be compared quickly, hence for example the current interest in immutable data structures that can be tested for equality by checking a single reference. And so the choice to use React for rendering does have implications for how the underlying data is stored as well, which undermines any claims about truly separating the view logic from the business logic.
References
React Fiber Architecture | Hacker News
CSS absolute and fixed positioning - W3C Wiki
The render tree relation to the DOM tree
Diagnose Forced Synchronous Layouts | Web | Google Developers
Analyze Runtime Performance | Web | Google Developers
CSS Visual formatting model details, Section 10.8 - Line height calculations: the 'line-height' and 'vertical-align' properties
CSS Visual formatting model, Section 9.5 - Floats
Twitter Bootstrap Issue #17915: Use display:inline-block instead of float
How to use inline-block for layout • iamsteve
An inline-block intervention – Really Good Work!
CSS Box Model and Positioning - CodeProject
Flexbox layout isn't slow | Web | Google Developers
Comparing Flexible Box Layouts | Neil's Place
Avoid Large, Complex Layouts and Layout Thrashing | Web | Google Developers
browser-perf
Here is the website I've been working on: Comotional - test site
I am using flipping cards within "Who we are" section and have problems with z-index. Whichever z-index and css combination I tried (even added additional divs on the back side), I can't fix the flipped content appearing below other cards. If you hover over these, you will see what happens and will see where the problems happens. Is there anyway to get this working via js?
It's limited by your container height, not the z-index. Set the height auto and find another way to set up the grid - perhaps making something like a row container along with a clear div while setting height to the front side of the card.
i think the problem is that you have lots of nested elements so changing the z-index of a nested element does not make them appear above on the stack unless until you make the z-index of the parent container greater than other parent containers that are blocking the view.
you can use hover event to change/increase the z-index of parent container on mouse-in and default on mouse-out
link to justify what I am saying
How do I create a div which will act like a relatively positioned div (as in it cannot allow elements behind it) and still will also act like an absolutely positioned div (as in it can freely be positioned)? I am willing to use javascript and jQuery if needed.
Example: or a similar effect
I don't think you can do what you're asking for in the way you're asking for it. You should be able to fake it adequately though.
Say you wanted to "insert" a sidebar that pushes all the main content on a page over by 200 pixels (the width of the sidebar). You could increase the left margin of the page/container by 200px (animate it if you wanna be flashy) and then absolutely position your div where you want it (you could animate it sliding in from off screen if you want it to appear as if it is "pushing" the other content over). If I understood the question correctly, then this should accomplish the visual effect you're going for.
I think you mean Draggable elements, you can use jQuery User Interface:
http://jqueryui.com/demos/draggable/
I have this problem where I am trying to show multiple graphs (based on jsPlumb) on a single page. Since I want each graph to be side by side on one row no matter how much space is available I am using a table (if I used divs with float:left, if not enough space is available some of the divs move down on a separate row).
Now each table cell contains a main div which in turn contains two or more node-divs. The way jsPlumb works is by creating a separate div for each node. I need to position each node at a particular top/left relative to its parent div.
The problem I have is that the main graphDiv in each table cell does not expand to fit its content. Some of the graph-node divs are outside of it. I understand that when you have "absolute" positioned divs they are not taken into account. But I am using "relative" positioned divs with top/left coordinates. Does the same thing apply?
If so, what would be the best way for me to expand the table-cell/graphDiv to cover its content? (i have tried all the clear fixes and went thru all stack-overflow related posts but could not find a solution).
Here is a link to the jsfiddle page I set up: http://jsfiddle.net/7QkB2/28/
I'm a little rusty but I share your pain in trying to get divs to properly expand to contain their contents.
As explained by this page http://reference.sitepoint.com/css/relativepositioning when you use relative positioning you're actually leaving behind a hole where the content used to be. I'd think of it almost as an optical illusion - The object is still reserving an invisible block in its old position, but it appears as if it has moved.
So in your case, the 3 nodes are still stacked in the upper left corner of the graph even though they look like they're floating outside of it. If you get rid of all the absolute and relative positioning on the nodes you'll see the table is sized to be big enough to fit their original positions.
I'd recommend usually only using position relative if you're only moving your content by a few pixels. Why they designed the css to work this way is a mystery to me, but maybe its something to do with the limitations of the rendering engines? When you use position absolute the object no longer has a "box" taking up space in the document. It's easy to position, but won't affect the spacing of anything else as you observed.
I'm not sure your exact application, but you may need to get creative with how you specify the spacing. If you know the dimensions you can always specify them, but I'm guessing you're not that lucky. Do you really want to set the position relative to the top-left corner, or just relative to the other nodes? I'd probably just use old-fashioned margins. That should allow you to specify the positions of the content that needs to fit in the table while maintaining the block model. Then if you need one of the nodes to overlap, position it using absolute positioning.
Have you tried displaying each div as an inline-block and turning off line wrapping on the enclosing div? You don't have to resort to tables if you want content with a dynamic width to display horizontally without wrapping.
div.graph {
display: inline-block;
}
div.graph-container {
white-space: nowrap;
}