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.
Related
I have a small scheduling system that I developed (Look here).
The "date" and "time" entries are showing normally in most desktop and mobile browsers:
But for a reason I don't know! In Google Chrome Mobile, a gray background color appears in the "date" and "time" fields. Also, the default icons are gone:
I tested in all browsers, but this only happens with Google Chrome Mobile. I want to fix this soon, I don't know what's going on and I've been at this for 1 week.
I'm using Chrome version 101.0.4951.41.
This is the project repository on GitHub.
It's the border property on the input: Chrome Mobile is setting the background of the date and time inputs to match the border.
I'm guessing you'd like all your inputs to match, so setting a background colour on inputs within your form will have the desired effect:
background-color: #fff;
I would also recommend not removing the outline, as that is used for accessibility reasons (screen readers).
So your whole style would look like this:
#form-field input {
width: 100%;
padding: 15px;
border: 1px solid #a3a3a3;
background-color: #fff;
margin: 10px 0;
}
Date and time inputs are relatively new and so cross-browser support is tricky (Safari Mobile notoriously didn't support a date picker for years). MDN has some guidance on detecting browser compatibility.
This issue is because of browser native control styles. You can override it by appearance/webkit-appearance:none property. after you need to give your own style to the component.
Please do more R&D on appearance/webkit-appearance and it will resolve your problem.
I have set appearance:none and see the below result. It's remove all arrow and make simple textbox
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/
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.
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)
Duplicate:
What is the best way to create rounded corners using CSS?
I want to create a table with some colums where each column has a rounded corner.
I am not an css expert. I think js solution should be fine too.
If anyone has done it.. I will really appreciate if they can help.
I am not using Jquery.
thanks,
ben
Here is a link to 25 different ways to do it with CSS:
http://www.cssjuice.com/25-rounded-corners-techniques-with-css/
Here is a link to nifty corners to do it with javascript:
http://www.html.it/articoli/nifty/index.html
In safari, chrome (I imagine), firefox 2+ and konquerer (and probably others) you can do it in CSS by using 'border-radius'. As it's not officially part of the spec yet, please use a vendor specific prefix
example
#round-my-corners-please {
-webkit-border-radius: 20px;
-moz-border-radius: 20px;
}
The JS solutions generally add a heap of small divs to make it look rounded, or they use borders and negative margins to make 1px notched corners.
IMO, the CSS way is better, as it looks cool, is easy, and will degrade gracefully in IE. This is, of course, only the case where the client doesn't enforce them in IE.
This is what I'm doing on several projects:
For Firefox and WebKit based browsers (although beware Chrome has bugs in this area), use their CSS border-radius based styles for native rounded corners:
-webkit-border-radius: 20px;
-moz-border-radius: 20px;
These also let you specify values for each corner, just note that the syntax is slightly different:
-moz-border-radius-bottomleft: 10px;
-moz-border-radius-bottomright: 10px;
-webkit-border-bottom-left-radius: 10px;
-webkit-border-bottom-right-radius: 10px;
These are based on the CSS3 border-radius style, more information on the different definitions here: CSS: border-radius and -moz-border-radiuss (note the article is a bit out of date but still relevant). I haven't researched this but I'm not aware of any browsers that implement the native CSS3 border-radius (please corrent me if I'm wrong).
Then for IE, I use DD_roundies which is the most elegant JavaScript solution I've seen and uses native IE VML to draw the corners.
If the user has IE without JavaScript or is using Opera, then tough luck they won't get rounded corners, but in the spirit of Progressive Enhancement this shouldn't ever be a problem.
If you want to stick to CSS the best way is stated already:
-webkit-border-radius: 20px;
-moz-border-radius: 20px;
However you are alienating the Internet Explorer marketshare.
To get around this would be to create rounded images for your div. http://www.roundedcornr.com/ has an image generator and example code.
A javascript alternative would be a jQuery plugin like DD_Roundies. Using the DD_Roundies plugin is by far the easiest way to do this. http://www.dillerdesign.com/experiment/DD_roundies/
You simply tell the div how big you want the radius and on what corners, it will do all the magic (colour, gradient) on its own.
Most of the time I see this it involves using clever image manipulation using css. Tables and other such widgets are defined by the browsers so you can't just use them and guarantee everyone to see the same thing.
http://designworkx.co.nz/
Has a simple coming soon page that is a good simple example of this.
HTML makeup tags, CSS and javascript is a more flexible way.
This link tells the arithmetic to generate the css of round corner in any radius.
http://www.pagecolumn.com/webparts/rounded_corners.htm