The child would often be a textNode, but that wouldn't always be the case. [*Originally, onscroll scanned left to right along the 11th row (in pixels) until it found an element with just one child. When the window is resized, it simply positions topNode at the top of the screen.
#Slickgrid responsive resize window trial#
(Figured this out through trial and error.) It doesn't scan along the 1st row, because when IE does scrollIntoView, it pushes the element down a couple pixels, making the top-most screen element the previous element. The function scans the screen left to right, along the 3rd row: document.elementFromPoint(x,2)* TopNode maintains the screen's top-most element as the window scrolls. Note that the onscroll timer is required in IE, because elementFromPoint returns null when it used in onscroll event. But both tend to obfuscate the code, so here's another version, which may aid in understanding.
#Slickgrid responsive resize window code#
The code's closures make variables private, and the timers prevent the code from running constantly during scrolling/resizing. This works in Chrome, Firefox, IE, and Safari. But resizing the width would generally cause reformatting. We could handle that if only the height of the window were resized. Note that this doesn't take into account the scrolled position of the element's textNode. onbeforeresize() function, this would be more straightforward. If (topNode.getBoundingClientRect().top >= 0) ,10) Updated fiddle (see fullscreen result) based on Rick Hitchcock's solution's solution.
The notion of top-most element I've mentioned is not very well-defined :(Īlso rather than a problem of responsive design in general, instead it seems to me like this is a problem with the default scrolling behaviour of web browsers? Or perhaps I am missing some circumstances where the current behaviour is desirable. The top of our current view might be cutting off the top portion of some elements, not to mention that there's usually more than 1 element layered on top of one another at any point within the page.
There's also the problem of refering to the top-most element in current view. I don't know how this will affect the performance, however, especially in bigger pages. Then automatically scroll the page to the top-most element that was in our view on event fire. I am thinking that we could at least start with javascript and put an event on window resize. maintain our current view of the page regardless of what happens to the contents above it when we resize the window. Then shrinking/expanding the window a sufficient amount moves the bit we were reading down/up the current view. indesign smart guides, smart guides indesign shortcut, smart guides indesign greyed out, smart guides disappeared indesign, indesign make guides from shape. jQuery extension to the jQuery UI library to create drag and resize elements using smart visual guides while dragging and resizing. Suppose we were to look at the Helper classes section in this page. jQueryUI smart guides for drag-and-drop objects. Then as we resize, whatever content we are looking at will get pushed down the page accordingly. Suppose also that we resize the browser window to a smaller size and that some content above get extended down due to the thinner width, hence making the whole page longer. Suppose we are reading the content somewhere down the page that is built to be responsive.
0 kommentar(er)
