I regularly employ elements and images that are floated beyond the boundaries of their containers - it adds dimension, assists with spacing and adds a bit of flair.
In this instance I am using NyroModal v2 to load html (a div tag containing various other elements) into a modal window. I had planned an image element (within the modal) would be floated just a bit outside the boundaries of the nyromodal but the modal dialog is clipping the element that goes beyond the modal's boundaries despite position absoloute or relative and regardless of very high z-index.
Looking for suggestions... thanks
Ok a bit more digging using chrome debugger: the nyromodal container has a computed style added to it within the _reposition function:
this.elts.cont.css('overflow', 'auto');
I commented it out and my elements float beyond the border but this is not a solution if your modal content needs scrolling - it will need to fit within the screen or you will likely have unpredictable and unsatisfactory results.
There is another function (hideCont) which sets the nyromodal container overflow to hidden when you close the modal:
nm.elts.cont.css('overflow', 'hidden').fadeOut(clb);
I changed 'hidden' to '' and I have the desired behavior.
NyroModal is on github and perhaps a fork that adds this functionality (without breaking scrolling content) would be useful - I don't have the time so above is my solution - it works for me in this instance and hopefully may be a satisfactory quick-fix for others.
Related
I am experiencing problem with white-space which appears after I double click on some of my website elements when I am using IPhone.
Soulika here you can try it on your own if you access from IPhone and zoom with double click you will have white-space which follows you along with further movements.
Mostly happends when I am zooming footer part, but actually might happen everywhere.
I were able to find the problem and soultion.
Problem:
I have hidded html tag scrollbar and moved it to one of my inner containers inside DefaultLayout;
This work complitely fine before we start to talk about IPhone cross-browser compatability.
Once I try to zoom my content inside content container it propagetes zoom event to parent component, but from some reason instead of stoping at the point of my DefaultLayout wrapper - element which has overflow activated and height defined in px( mandatory in order to configure overlow ) it propagetes up to window and zooms window itself.
Solution: I have changed the approach and moved the overflow back to html which is now pretty much content element and window is a wrapper with predifined height. Now everything works complitely fine as zooming accessing my content and do not propagets to parent.
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.
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.
I'm developing a web interface involving a JavaScript scrollbar restyling solution that attempts to hide the browser's default scrollbar behind an HTML/CSS replacement, while preserving support for the browser's default scrolling behavior, a feature many popular JS scrollbar plugins lack. The only issue I've encountered with this method is that some browsers insist on displaying the default scrollbar on top of the one created by the plugin, destroying the desired aesthetic altogether.
In an attempt to solve this problem, I tried wrapping the element containing the scrollbar in a div with overflow: hidden; and using JS to detect the width of the default scrollbar and position the element it controls so that it falls outside the clipping boundary of the parent div. However, as many of you probably know, Content that spans beyond the bottom or right boundary of an element with overflow: hidden can be accidentally scrolled into view during mouse dragging operations like text selection in which the course crosses the bottom or clipping boundary of the concealing parent element (i.e: dragging to the right would bring the default scrollbar back into view).
Luckily, though, this behavior does not occur when content extends beyond the top or left boundary in such a scenario. Knowing this, I'm considering continuing with the approach outlined above, but styling the scrolling element with direction: rtl to flip its scrollbar from right to left, and beyond the boundary of the concealing element, then applying direction: ltr to the child element containing all of its contents to negate the direction change for all of the actual content.
This technique produced the desired result in every test I've conducted thus far. However, I'm wondering if this solution is too good to be true, and I'm overlooking a fatal accessibility and/or compatibility issue with CSS direction for scrollbar placement that should prevent me from using this method.
TL;DR: Is using the CSS direction property to control the position of an element's scrollbar a bad idea?
In terms of correct usage of the property, it is a bad idea. direction: rtl is correctly used to flip the reading direction of text using alternate character encoding e.g. Arabic, Hebrew, etc. Try and find another way around the issue. Try taking a look at the source of some of the aforementioned popular JS scrollbar plugins to see how they do this.
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.