Background screws up on .show() - javascript

http://www.heuvel-folie-serres.com/Veestal_v2/?pagina=foliestallen_projecten
There are links on this page saying Foto's... which trigger a div being shown using jQuery (.show()). This works perfectly on Google Chrome, but on IE something strange happens (even stranger than usual I mean). When someone clicks the link, the div shows... and the background suddenly... well.... let's just say it screws up. In the top left corner it's still a bit visible, but on the rest of the page it has seamingly dissappeared... I don't really know how to describe this problem, neither do I have a clue how to solve it.
By background I mean the transparent overlay where the whole website is on (div#website).
Any brilliant ideas?

All I can say is, that Internet Explorer (at least beyond 8) has a huge problem with little transparent gif's and/or png's. You have a 1px * 1px transparent png there. Try resizing it to 10px * 10px or even 25px * 25px (seems to perform better)

Related

Box Shadow disappearing on a div, when deleting list elements inside it

To test or see the bug:
(Note: Bug has been replicated on the link in Second Update, since the question was first posted)
go to sukritchhabra.com/importr
Type Bootstrap in the search bar.
Select bootstrap from the suggested list (Note: If you do not select from the list but press enter in the search box, the page will break and you'll have to refresh)
Once Bootstrap loads, press the green button 6-7 times (until a scroll bar appears)
Now delete a few of them, and the box-shadow will disappear.
I've tried a couple of things so far. Tried logging the box-shadow property of .importrLinks after every delete to catch where it is changing but no change is actually happening.
Also tried explicitly assigning box-shadow after each delete, and that doesn't help either.
During my search for a solution, alot of somewhat similar bugs were because of the z-index but I tried assigning custom z-index's and that didn't help (although I still believe this is something I haven't tested completely since I was assigning random, i.e., altering higher and lower, z-index's just to detect changes).
UPDATE
As suggested in the comments, I should've provided sample code instead of the complete website and I agree. But, as I have mentioned in the comments, I wasn't able to replicate the bug, on a fiddle.
Nevertheless, here is a link to the jsfiddle: https://jsfiddle.net/sukritchhabra/d3xfyc6t/5/
The bug still doesn't take place in the fiddle but, is still there on the website. The code I've used to create the fiddle is picked from the website. Instead of getting arguments for the addLink function, I've just passed constant strings for testing.
Second Update (Bug Replicated)
Figured out the bug is happening because the container has a float: left;. Have changed it on the fiddle and the bug is now replicated on this fiddle.
Link to fiddle: https://jsfiddle.net/sukritchhabra/d3xfyc6t/6/
Third Update (OS issue?)
I had been working on a Mac so far. I just tested it on a Windows machine, and the bug seems to be only on Mac. Am not a 100% sure if that is the root cause, but I'll definitely be testing it on other machines just to be sure.
Meanwhile, if anybody can see the bug on a Mac and not Windows, please do let me know here.
Confirmed the bug in Chrome on OS X on your fiddle. I checked and the same seems to happen to other CSS properties, not just box-shadow. For example, if set, border is affected in the same way and disappears when you remove items. I think it's got something to do with the combination of CSS properties on the container when overflow is set to auto. So for example I noticed that if you remove float: left, box-shadow stops disappearing. So to me it seems to be a browser rendering issue, I'm not sure why it's happening only on OS X.
Anyway, if you need to keep CSS exactly as it is, here is a solution that is far from elegant, but it works:
https://jsfiddle.net/d3xfyc6t/8/
It involves doing a browser repaint on the container every time you remove an element:
$('.importrLinks').hide().show(0);
This technique is taken from here:
https://stackoverflow.com/a/8840703
Oddly, if you remove the float on the container DIV, it fixes the problem: https://jsfiddle.net/d3xfyc6t/10/
You should also add the box-shadow vendor prefixes for other browsers:
box-shadow: 0 0 10px 1px #e2e2e2;
-moz-box-shadow: 0 0 10px 1px #e2e2e2;
-webkit-box-shadow: 0 0 10px 1px #e2e2e2;
Edit: Mimic a left float by replacing float: left with position: absolute; left:0; this gets rid of the problem. You may also need to set any outer containers that contain the code you posted to position: relative; https://jsfiddle.net/d3xfyc6t/11/

Split Button Formatting Off Depending on Browser

I have a jQuery splitbutton on my page that I am having a formatting issue with. Per my company's design standards, I am basically transforming a link into a button. Everything works fine, functionality is perfect, but depending on which browser you are using (I'm testing with IE and Chrome), the right side of the split button is just a little bit longer than the main button.
I think my issue is in this CSS class:
.default_button.medium_toggle {padding: 14px 5px 10px;}
If I change the 10px to 9px, it works in IE. The way it is, it works in Chrome. (Side note, in Chrome, if you zoom in on the page, it's off, but I'm not too concerned with that)
Any suggestions? All of my code is at jsfiddle.net/lwisdom43/6ErCs/3/. I placed it here because I didn't want to copy all of my CSS for these two buttons in this post. Again, this is all based on company design standards. Thank you for any help you may be able to provide.
If you put some text inside the second a-tag, you will notice that the source of your problem actually is another problem.
You set height and width in .default_button.dropdown_toggle and padding in .default_button.medium_toggle but not in .default_button or .medium_button.
Remove height and width from .default_button.dropdown_toggle and padding from .default_button.medium_toggle and it will have the same height (it will probably work if you set the height in .default_button)

Is there a "good practice" way of detecting Firefox?

If I were to read the title of this question, having never seen it before, my first response would be, "Don't! Use feature detection instead!", which makes perfect sense, however, it is not a feature I am trying to detect, but instead how Firefox renders colors.
For some reason all other browsers I have tested so far render a certain hexadecimal color that appears between images beautifully but it appears lighter in Firefox.
I have read about possible reasons why (i.e. something about color profiles, which I am just now exploring the topic of) and the "about:config" file here:
http://support.mozilla.org/en-US/questions/774152
http://jorgebernal.info/2008/03/08/whats-wrong-with-colors-in-firefox/
http://www.maketecheasier.com/28-coolest-firefox-aboutconfig-tricks/2008/08/21
Knowing why is fine, but there seems to be nothing on the topic of how this should be handled by a web-designer (also, it is possible that I am confusing the issue here, because they seem to be talking a lot about images, and the color rendering I am having trouble with is not an image, but just a simple hexadecimal color code value).
Here are a couple of screenshots showing the difference between the correctly displayed colors (shown first) and how Firefox renders the colors (shown second). Note the colors between each "button" image (which is actually just a 'mousover' drop down box). Also note that the little color that shows between the images are not images themselves, just standard CSS rendered hexadecimal colors:
IE 10:
Firefox 21.0:
I am fine with any solution that could get Firefox to display colors the same way that IE and Chrome do (tested on both 32-bit and 64-bit, and still only Firefox does this [on both]), but I know I'm not going to change the "about:config" file for the whole world, so if I could just reliably detect Firefox, perhaps I could just adjust its colors to a darker shade. Unfortunately, I (probably very wisely) never use browser detection, as I know how unstable and unreliable it is.
Is there a reliable (not to mention, future-proof) way to detect Firefox for a web designer? I simply use JavaScript/jQuery for client side scripting.
--------------------UPDATE---------------------
Okay, here is the CSS that renders the border colors. The red-is buttons have two classes: DDL and visType, while the grey-ish buttons have the DDL and groupType classes.
.DDL.visType
{
background-color: #bb9191;
border-right: 2px inset #ba8c8c;
color: #1a5c17;
}
.DDL.groupType
{
background-color: #e7e7e7;
border-right: 2px inset #989898;
color: #0b3773;
}
So, you can see there is nothing wrong with this CSS as far as FireFox is concerned. In fact when looking at the true color rendered in Firebug's and Chrome's developer tools both say that the actual color rendered is the same for the red-ish buttons' right borders (in rgb it translates to 186, 140, 140).
For this scenario, the problem apparently was how differently Firefox renders the 'inset' border style. Why I had it as inset to begin with is kind of a blur. I was probably testing the various looks on such a thin (2px;) border (differences that are barely, if at all, noticeable given the very narrow width).
Once I had changed this style to solid;, the color differences were much less drastic:
Chrome 27.0.1453.110 m:
Firefox 21.0:
The same CSS code shown above with the new changes (Only changed both occurrences from inset to solid):
.DDL.visType
{
background-color: #bb9191;
border-right: 2px solid #ba8c8c;
color: #1a5c17;
}
.DDL.groupType
{
background-color: #e7e7e7;
border-right: 2px solid #989898;
color: #0b3773;
}
A simple solution for a somewhat obtuse problem that should never have occurred in the first place, I suppose (why use inset for such a thing anyway?), but narrowing it down was quite difficult.

Text renders inconsistently in Safari (5.0.5)

I'm having a hard time resolving this.
I'm working on http://movingwineforward.com, but it renders text inconsistently, as you can see in this screenshot:
When the page loads, the text in the main menu looks thin (left), and is consistent with every other OS and Browser. But when clicked, it becomes a bit heavier as in the right side of the screenshot.
I checked every CSS property, both in the stylesheet and in Safaris (and Chrome) DOM Inspector, and they both are identical.
When I disable scripts in Safari, the text loads like heavier version (right), so I guess that is interfering. (I'm loading some Vimeo flash players, among other scripts).
For added mistery, this site is a copy of http://daf.cl, and they both have the exact same stylesheet, DOM (markup), font files, and Javascript. Only colors and content change. But in http://daf.cl the text loads initially in the heavier version and stays like that.
I've been able to reproduce this behaviour on Safari 505 running in OSX Leopard.
By clients request, the text has to look like the one on the right (heavier).
I've tried forcing -webkit-font-smoothing and text-rendering in CSS, but none did the trick. Font weight does not look good, as it forces the typeface.
Update 1:
I know now when this ocurrs: only when there is a Vimeo flash player behind the menu, the text renders thinner. If there is no video behind, it looks heavier (as it should). Perhaps this brings new light. (I tried disabling jQuery Froogaloop for Moogaloop, but didn't work)
First, do this:
opacity: .99;
Applying this to the object containing your text will initialize it looking 'lighter'. So it wont't fix the issue in your preferred way (stick to 'regular' thickness), but will instead prevent the subsequent 'bounce' to the lighter looking variant.
Now, let's do some tweaking:
text-shadow: 0 0 1px rgba(255, 255, 255, 0.75);
Additionally applying a subtle text-shadow in the exact same color as the font will result in the text looking almost exactly like you want.
Though not a real solution, you could try adding something like
text-shadow: 0 0 1px rgba(0, 0, 0, 0.3);
to the text.

I think I have a CSS/JavaScript problem?

I have two problems... I've tried altering my CSS file, the JavaScript files and all kinds of other things. A google search yielded no remedy to these problems, so I come to the awesome site of answers!
This page -> http://students.cmps.subr.edu/aaron.chauvin/misc/test2.html
has some issues in Chrome and Safari. Only when my CSS is in effect, the pictures that are supposed to be side-by-side aren't, but when the CSS is off, they are. This problem isn't evident in FF/IE9. I'm thinking it has something to do with the   but I'm not totally sure. Edit Edit: Thanks for the fix Genzer!
Also on that page, even if all my CSS/JavaScript isn't linked, I have a small gap between the bottom of the images that are links and the dotted link border... I want to get rid of the gap. What's causing this gap? This happens in all browsers.
Thanks in advance.
Edit: Here's the CSS: http://students.cmps.subr.edu/aaron.chauvin/misc/style.css
Edit Edit: Fixed the side-by-side image link problem, now trying to figure out what's causing the variation in the display of the custom a:focus border (non-existent in IE9, partially encases image link in Webkit browsers) and the gap between it and the bottom of the image link (all browsers BUT IE9).
The problem is you're wrapping all your column's info in a span: <span class="reg">...</span>
IE9 and FF figure out that you want it to display as a block element, but Webkit (Chrome and Safari) don't. Set display:block on the "reg" class and you should be set. (I think this fixes the "dotted border" issue as well, but i'm not quite sure what you meant there)
To get the orange border to show up in IE9, make sure to set outline-style to something like "solid" or "double" in the a.piclink:hover css class, in style.css. Once i did that, the border shows up.
I'm still not entirely sure why your links and nested images are behaving like they are, but I found a little tweak (tweak = almost a hack) to get it to work: Set display:inline-block; on a.piclink and set a fixed height on it. Note that inline-block tacks on 4px, so the height should be 4px taller than the height of the image; in your case: 47px. It's a bit of a hack, but it's valid and it works. Unfortunately IE7 doesn't like this, but zoom:1; *display:inline; get it working.
Adding following CSS code in your style will make Chrome display your TestPage the same as IE8.
span.reg a {
display: inline;
}

Categories

Resources