I am having a really weird issue and can't seem to figure out if I'm looking at a javascript or css issue. Here is a jSFiddle for some context of what I am talking about. If you type in the input box and don't see a label popup, delete the text and type it again...weird huh?
I have a form that can be viewed either directly, or in an iFrame. On the inputs, I am using jvfloat.js to give floating labels using the placeholder values.
$(document).ready( function() {
$('input').jvfloat();
});
I get different results across browsers (current releases) and also, oddly enough, when in an iFrame or not.
Chrome
In IFrame:
Typing in text field doesn't popup label. Inspection shows "activeLabel" class added successfully, but it doesn't seem to render. Seems like a CSS transform isn't working to move the label up from behind the input.
Outside IFrame:
Works as expected.
Firefox
In IFrame / Outside IFrame:
Works as expected
I haven't tried it in any other browsers. Every now and then the labels don't work and I can't repeat the problem consistently.
In the jsFiddle, can you see any major problems with the javascript or CSS that would cause this weird behavior?
It's a CSS issue.
You're using display, visibility, and opacity to show/hide your floating placeholder. That's overkill, you only need one! I get opacity, you need it for the effect.
I dropped any use of visibility, and it now works:
http://jsfiddle.net/njjZr/3/
Related
I know that this is not a 'good question' to pose—but I'm desperate by now and need to find some inspiration.
I have a questionnaire page/web-app that uses CSS transitions to slide to the next page of questions/options.
It is well-tested and the transitions in question aren't complex.
But the transition to one special page went out of control recently. And although I consider myself well versed in CSS and JavaScript I'm totally lost with this problem.
The construct in question works like this:
I have a 'window' that is positioned absolutely and has its overflow hidden.
Inside that is a page container positioned relative to no left or top values or transforms given.
The pages inside this container are positioned absolutely according to their status classes positioned on the left: 0 (active), left 100% (not yet shown), and left: -100% (already done)
What happens now is that when I switch classes to show a certain page, the page container 'jumps to the left'. In Chrome nearly -100% in Firefox about -70% same in Safari.
Those values are my guess because when I open the dev-tools, nothing is to be found in the styles, in the computed values anywhere.
When I move back to the previous page the container jumps back to its original position, and if I move again to the critical page it stays.
I do no positioning whatsoever with JavaScript anywhere, I only switch classes on HTML elements.
After hours of experimenting back and forth, I found out that the problem is in some way JavaScript-related anyhow.
Using the exact same CSS and HTML with a slightly older version of JavaScript does not show the strange behavior. The changes in the Script are mostly ES2020-module related, and the new version does nothing even remotely related to DOM manipulation different from the older working version.
When not using transitions, the shift of the container does not occur.
Has anyone come across something similar?
Does anyone know of other tools to deeper analyze the current layout state of a page more than the respective developer tools of the browsers?
Any other ideas?
Today I found a solution and at least some kind of explanation, but I still have to investigate some more to truly understand the why and how. I'll post an update if I find a better explanation.
The problem has to do with a text field and focus.
The page in question has a text (search) as its main component.
[I am aware and always was that browsers try to move focused elements into view, regardless of what the author's CSS says.
Therefore, when I decided to give focus to the text field which it does not have on its own, as every page movement required a button to be clicked, I did so on transitionend. This has never changed.
When the issue first occurred, one of the things I tried first was to disable that (auto) focus behavior. It did not solve the problem.
I cannot say what made that change in behavior happen. I change the construction of the page to include a grid some time before the issue occurred. That in itself was not the reason, however (it worked for quite some time with that system, and removing it did not sole the behavior).]
What solved the issue was to initially fully disable the text field and only enable it on transitionend (then focusing it).
The reason browsers moved the page to different positions likely has to do with this situation, as the text fields width is ch based.
The important takeaway (for now) for me is, that there is no hint to be found in the developer tools when the browsers moves - elements in the (in my case unsuccessful) attempt to keep inputs in the viewport.
I think that this should be changed/fixed.
I will as soon as I have the time try to better understand the things that made the problem occur, If someone has information or experience with similar situations pleas add useful hints and background info.
I'm trying to disable text ellipsis ('...' at the end of text) / overflow-wrap so as to be able to read the full text of the option element within the select element. At the moment the text is getting cut off even though there's plenty of white space left. The catch is that I have to do this using Greasemonkey (not written any code so far), just editing in browser console till I find the correct css option. Things I've tried so far:
changing an option/select width to "100%".
changing option/select line-height to "normal"
changing option/select padding to "0"
changing option/select font-size to something smaller.
setting option/select text-overflow to "clip"
setting option/select white-space to "normal"
var menu = document.querySelector('select');
var option = document.querySelector('select option[value="neteng-deployment-agg-pod1-dub-primary"]');
I'll also attach an image to help explain what I mean:
I am not sure but looks like IE problem.
First of all check the same page with Firefox and Google Chrome.
My gut feeling that this is quite browser default specific, and that it would require browser-specific css hacks to change this, can you confirm if this is the same behaviour in all browsers on your machine?
edit: with knowledge that is same in all browsers:
there's a good chance replacing the default select element with some fancy jquery versions that replace select elements with mirror versions using normal html markup may solve it
https://sitepoint.com/13-jquery-selectboxdrop-down-plugins
I'm running into this problem on Chrome. When I use jQuery to focus on an HTML input with part of its text selected, my page jumps to the top instead of the element itself. I've created the following jsfiddle as an example:
http://jsfiddle.net/wzs821jg/3/
I've put margins above and below each input, enough to create a scrollbar. If your resolution is taller than mine (I'm on a laptop) and you have no scrollbar, just add more margin until you do.
Add enough text to the second input to cause it to scroll (overflow on the x). You can just add jibberish, such as "asdfkasdkjfhakjsdhfaksdjhfkajshdkfajshdkfajshdkfjah", which should work fine. Once you've gotten enough text, highlight a portion of it. Now there are two methods you can use to cause the page to scroll to top:
Click the button, which has a short jQuery listener that will focus on the second input.
Focus the first input and then press tab to focus the second input
On Chrome Version 41.0.2272.101 (64-bit) on OSX Yosemite, both of those actions should cause the window to jump to top instead of focusing on the second input. I've tried on Safari, and I can't recreate the issue. I've experienced different behaviors depending on where you select the text (outside, inside, or across the overflow) and the method used to focus. Play around with it a bit.
My question is: is this a problem with Chrome or am I doing something wrong?
Edit: I've filed a bug report with Chrome pointing to this question. Unless someone has an answer, I'm just going to assume it's simply a bug within the browser.
My Problem (Fiddle)
My problem is that on my jquery animated dropdown menu, when you hover over the "Other" link, the sub menu does not appear. When using firefox to 'Inspect Element', I find height is animated, and the width appears to be alright, yet all I see is the left border.
I noticed that if I have that particular section display as a block, when you animate the first menu it is shown, but upon entering the unordered list, it disappears (ex). I imagine it is somehow related to this, but I can not figure out what is causing this.
Any incite into what I'm probably just overlooking would be great, and of course much appreciated.
Notes:
I have had this problem in Firefox, Chrome, Opera, and IE.
It's designed such that it could work with only css. The the first .each is overriding default css hover behavior.
the empty span holds the arrow image.
only relevant code is posted. However, you may view my site here
If you have any tips on making something more efficient, always welcome.
http://jsfiddle.net/sailorob/4cdTV/5/
I've removed your CSS for simplicity's sake and simplified your functions by utilizing jQuery slideUp and slideDown, which essentially handle many of the css properties you were managing with your functions. From here, I think it would be fairly simple to work back in some of your CSS.
When utilizing javascript/jQuery/animation on menus, I highly suggest using timers (setTimeout) for firing mouseenters and 'leaves. This way, your menu is more forgiving when a user accidentally moves their mouse a few pixels out of the menu and it closes.
Well, in debugging the JS and CSS I found that if you remove ALL the JS you have, the drop down menu with sub menus work fine. The Other li opens up the ul below it just fine. Note, it doesn't animate without the JS though.
Here's a forked fiddle.
I tested it in latest Chrome and Firefox.
In IE 6 select control(combo box) is displaying on top of menus. I checked some Javascript menus, mmmenu, but all are getting under select control. It's not fixable by assigning Z-Index. Is there any other solution.
This is a well-known bug with IE6 with trying to absolutely position divs on top of select controls.
There are workarounds involving iframe shims, but there is no good answer. The iframe shim answer is to place an iframe underneath whatever div you're trying to place above a select, with the iframe being the same size. Unfortunately, this is a huge pain in the ass.
I suggest using a javascript menu system which already uses iframe shims, such as YUI menus (and I assume jQuery).
Most of the major javascript libraries have easy to implement solutions to this problem. We use jQuery, and the bgiframe plugin is very easy-to-use and solves the problem.
Daniel is definitely right. This is an ugly issue.
However, there may be another solution. If you are using multi-tiered menus that pop open and closed, it is possible to write JavaScript code that literally hides the problematic SELECT elements when the popup is opened (style the element to have a visibility of hidden). Then when the menu closes you can unhide that same SELECT control.
Then you just have to write code that detects which SELECT objects get in the way of a particular menu before it opens. It's not trivial code, but it's definitely possible to write. Then I'd just wrap the entire chunk of code in a conditional that checks to see if the user is on IE as there's no need to run this on Firefox or Safari.
The problem is that SELECT are "windowed" elements in IE6, and their z-index is above all the other non-"windowed" components. If you absolutely must have something above a combox, you might want to put it inside another windowed compnent, such as an IFRAME, and set the component's z-index to be higher than that of the combobox.
I must admit, this isn't a pretty solution.