Further info : the button is actually only greying out when I go to use it: on mouse~over it
fades, becomes inactive.
I have swapped the CSS Declaration responsible, to use on another TextArea in a different website, and it is happy there, behaves as expected. However, taking a working CSS declaration from outside, and swapping it into the CSS for the Textarea I am having difficulty with, find that the problem persists. So I conclude it is very unlikely the CSS is at fault; at least as far as the textarea.
What area of code should I examine next to try to pin this down?
Okay, this is strange to me, but the error was related to z-index.
The problem was the z-index applying to the DIV containing the problematic textarea,
was higher than that for the textarea itself. So: some way, the up button was not displaying or behaving rather, properly.
The moment I raised the z-index of the Textarea, to a value higher than the containing div, the problem went away.
Anybody stumbling on this question, who may know why just one element was affected, feel free to add a comment, some insight would doubtless be more valueable, but for now, I stumbled on the (a) solution.
Related
I am using Monaco Editor 0.22.3 in combination with StencilJS and TailwindCSS. Everything works great, except for an annoying visual glitch in the intellisense dropdown as depicted here:
As you can see, the last suggested item is partially obscured.
I suspect it might have something to do with some style coming from TailwindCSS, but I'm pretty much at my wits end here. I tried to use the F12 element inspector to see if I can find some hints, but that is proving to be close to impossible since the intellisense dropdown disappears as soon as it loses focus.
Any hints would be much appreciated!
UPDATE 1
Here's a screenshot with a bigger editor to demonstrate that the dropdown itself does not appear to be clipped:
UPDATE 2
Here's an animated gif showing the issue when trying to debug the HTML elements using the browser developer tools:
As you can see, the dropdown disappears as soon as I click anywhere else.
The issue comes from a fairly common css class being used: .tree. Libraries such as tailwindcss add padding-bottom to it for example. To undo some of its additions for the monaco editor we added the following to our css file:
.monaco-editor .suggest-widget div.tree {
white-space: unset;
padding-bottom: 0;
}
And to get get to that solution for other libraries and styling artefacts:
It should have been quite easy but the suggestion dialog has a tendency to hide when we try to observe it. so a UI guy and I spent a while going through the playbook to try to debug it. The only successful way to inspect it was to abuse the JS debugger by running (which was a hint from a stack overflow post that I'm struggling to find to give credit), and just cause the JS engine to pause:
Run:
setTimeout(5000);
This gives us 5 seconds to get the suggestion window to show (or set to a relative amount of time to the problem). After which, you could mostly inspect it as normal with a quick shortcut:
ctrl+shift+c that brings up the debuggers element selector.
Here we are, the suggestion was from the following post:
How can I inspect disappearing element in a browser?
break on subtree probably would have worked, but we became a bit impatient stepping through the changes. ctrl+ / didn't seem to help in this case, which left the odd setTimout to save the day.
The drop down is clipped at the editor's boundaries. I actually wonder how you can see the last empty part outside of the editor.
For inspection: use your browser's dev tools to see how the containers overlap. This will avoid that the editor hides the drop down.
Update
After your update I think now that somehow the styles are messed up. You will have to figure out a way to show the popup and still navigate the DOM tree in the developer tools. Try to locate the parent and see if that popup is only hidden (it still shows up then in the tree) or if it is dynamically created or is a portal, which lives in a completely different part of the tree.
If that cannot be done then try to disable all CSS you have and see if that solves the issue. If so enable the CSS piece by piece to find the culprit.
I know this has been asked many times, and I have been searching for the answer in a lot of places but I can't seem to fix my code. Thank you for reading this because I'm going crazy here! First I had a different z-index problem with safari, than another with explorer, but now the z-index problem I'm having with mozila I can't fix in any way. I code in chrome, where it seems to work perfectly (for me it seems at least!)
I believe now it works more or less fine in most browsers but not on mozila. The idea of the page is to make (only with CSS because that's the only language supported by the website) a flipping book of several pages. I see some examples around of CSS only flipping cards (only one page), but not a book of more than one page. So I essentially overlap several "cards", in order to give this effect. You can see the demo from codepen here: pkrein/pen/qBOewem
Btw I do know this code is not as clean as it could be, but that's the way I figured to make a fuction like that works only with CSS, and I hope it will make sense for you.
Ok, so the matter is, the content inside the book pages is not "scrollable" on firefox. I guess this is indeed a z-index problem, because when I move any page outside the book, that is, from behind the rest of the content, it scrolls fine.
Let me know if I can give any more info that could help you understand my issue!
I figured a possible solution for this. It's not quite the solution for the problem itself but it's something that can make what I want to do work.
The problem was: (what I had to remove in order to make it work):
(1) The div #content-holder holding all the text inside the flap
(2) The div .preparation-text inside the .preparation (that's the text I want to scroll). That was a scrolling div (.preparation) inside a non-scrolling div (.preparation-text). I always add a scrolling div inside a non-scrolling div in order to hide the scrollbar, by adding a high padding-right to the inside div. I know I can use code to hide the scrollbar but it do not work in all browsers.
How I fixed:
(1) I just removed the #content-holedr divs, since it was not strictly necessary.
(2) I removed the .preparation-text and transformed .preparation into a scrolling div. Then I just covered the scrollbar with an image of the same size and colors as the background (a print of the layout).
I want to completely reset a button's inherited CSS so it behaves exactly like any other inline-block element. However, I've run into a problem where the text of a button is forever stuck vertically-centered.
In the fiddle (and screenshot) below, the button and div have the exact same styles according to the Chrome Developer Console, yet the button's text is vertically-centered, while the div's is not:
http://jsfiddle.net/rgthree/vT3a7/
Anyone know of the property or selector that will completely reset a button, specifically including its label position?
Answer
There's no way in any browser other than Chrome ~25. I reached out to the Chromium project about the it not working in Chrome 27 (see the #winterblood answer & comments). They said this:
The issue is that we now use margin:auto on the anonymous block inside the button to do the centering inside the button in order to get safe-centering. So, unfortunately, there's no way to style it from CSS. That you were able to control this behavior before was really implementation detail leaking out.
So, the true answer is that you cannot style this in any browser, except for Chrome ~25 where -webkit-box-align was inadvertently exposed to, as #winterblood answered.
For webkit you need to override -webkit-box-align with a value of baseline or start.
I have had no luck implementing this in Firefox yet (from a very brief look at it).
Ok, I've been dealing with IE bugs for a long time now, but this one is beyond me. IE 7 and even 8 does it for sure, I've not seen it on FF or Chrome.
So here's a live URL which produces it: http://mog.com/music/America/Holiday
Reproducing isn't easy, it can take a few times to make it happen. Watch your scrollbar to see it change size so you know the page length was suddenly dropped quite a bit.
Here's how you do it:
Hover over any sub-nav link (Main, Albums, Songs, Photos, News, etc.)
Try them until you see the scrollbar change size. Once it does, scroll all the way down and notice the footer has jumped up on top of much of the page content.
Be careful scrolling down that you don't roll over a few other page elements that will suddenly fix this. So far I can see that any of the Play buttons will somehow fix this.
It's just beyond weird. How could a rollover state cause this kind of behavior?
I've tried:
Removing the a:hover style - THIS FIXES IT... WTF? Of course we ideally would keep some hover state, so hoping to avoid this fix.
Reproducing the hover functionality using jQuery hover(). - THIS DOESN'T FIX IT.
I figure the clues are in the elements that somehow magically fix it...and possibly in where the page jumps to, what elements suddenly get obscured by the footer.
Lastly, I didn't produce this site from scratch and it uses a lot of absolute and relative positioning for certain things and I know that is partly what causes these weird bugs. I rarely, rarely use esp absolute positioning to avoid these kinds of bugs, but it's a bit too late now.
Thanks for anyone willing to check it out!!
Well, I figured it out. It was an odd case of the "Guillotine" bug. One I luckily haven't come across before. Turns out the "special" CSS rules on those nav links' hover state (particularly it seemed the border and bg image) were enough to trip this bug. One way around was to drop those styles, but not ideal. The real fix, however, was an unsemantic clearing div placed in just the right spot. More info found here:
http://www.positioniseverything.net/explorer/guillotine.html
Hi just a short note: When did you validate your html the last time?
As you probably know, but might have forgotten, fixing your html can sometimes solve a lot of problems. There are 72 errors seen by http://validator.w3.org
In Internet Explorer, there is unnecessary padding that occurs to the left and right within the button when the button name is large. As a result of this, the known solution is to add "width: auto" and "overflow:visible" to the button style, but doing so will inadvertently make the text in the button disappear when the user scrolls the page down and then back up.
I would very much like to use the style I've included so the padding stays removed, but more importantly resolve the issue with the button text disappearing. It's really an odd one!
I've created this DEMO page for you to test the code where it's happening: http://jsbin.com/uhuze3
Note: You'll need IE7 to see the issue, so for those who don't have it, I create this video for you to see the issue. http://screencast.com/t/MTg0NzY2Zj
I was able to resolve this and improve the code a bit.
You can see the code here:
http://jsbin.com/uhuze3/4
This was the old code:
http://jsbin.com/uhuze3
Edit by Johnny5 :
It seem to be the combinaison of "height" and "line-height" that correct the bug.