so do all css 3 shapes not render color correctly in Firefox? I used this generator
http://apps.eky.hk/css-triangle-generator/
to make a triangle but I noticed when using a large value, the edges blur in Firefox so I need to use border-style: inset to make the borders perfectly sharp...however if you use border-syle:inset I also noticed the colors on Firefox become a pantone, or seriously desaturated. in Chrome the colors are fine. Is there anyway to correct the color in Firefox?
border-width: 0 0 351px 5527px;
border-color: transparent transparent #ff0000 transparent;
border-style:inset;
http://jsfiddle.net/P94fm/2/
in this fiddle you can see in FF(on PC!) the color is not red, but a desaturated. In Chrome its fine. If you take off border-style: inset the color becomes perfectly red again in FF but the top border gets shadow / gradient / is not sharp
Actually, this is how the designers of FireFox have intentionally set. Firefox renders it differently than other browsers (like most browsers also do), in this case in a less desirable way
There is no way using CSS or javascript that I can think of which will increase the brightness of the red color without affecting other the space above the red
Although I don't know of a direct fix, you could remove the bland color by accepting a little bit of blurriness only in FireFox and have it work perfectly in the other browsers by using the following javascript
if(navigator.appCodeName == "Mozilla")
document.querySelectorAll("div")[0].style.borderStyle = "solid";
The only other work around I know of is to use a different meant to create the design you want, either an image, <canvas>, or SVG most likely. All of which are solid solutions to your problem, though admittedly slightly less desirable if all browsers rendered the CSS the same way
Related
I've encountered a really strange bug that exists in Chrome only. I've got a list of links with the equivalent of a 1px border-bottom (I'm using Compass Vertical Rhythm to output borders). In the inspector, it says that the border width is 1px, but the border displayed is more like 2px and lighter than the font colour (see image).
If I reduce the height of the window (either by making the browser shorter or opening the inspector) the border goes back to what it should be. I've tried setting the border-width manually as 1px rather than relying on Compass Vertical Rhythm to no avail, so I think it's more of an issue with Chrome.
Here is the code
a {
#include trailing-border(1px, 0);
}
And here is the output in Styles
border-bottom-width: 0.05556em;
Here is the output in Computed
border-bottom-width: 1px;
Has anyone encountered this before? Any solutions?
Apologies for the necro post. But this is the closest post I can find to the problem I am experiencing so thought I would add it here. I am confident this is a bug with chrome though I don't know enough about the border collapse bug that chrome has to be certain that that specifically is the issue..
https://www.ablueman.co.uk/the/testbench/divt.php
Shows correctly in Ie and firefox (see div table widths / heights at the bottom of the page)
But in chrome it seems to screw up the border sizes which adds a less than one pixel value.
i.e. DIV (Width:518.3333332538605px, Height: 22.33333325386048px)
If you turn off the borders, issue disapears.
This looks great in IE9, Firefox and Chrome but in IE8, it's all jacked up looking. Any ideas on this one? I am on WordPress using Thesis Themes. I am using custom.css for my edits.
My site is: http://www.7637olympia.com/
Can you suggest how to make it work with IE8 as well as the other browsers?
I thought that since IE7, there was support for the css rule filter:alpha(opacity=x); to avoid using semi-transparent pngs. Is that not the case?
In your site, you would use:
.custom #page {
background-color: #000;
filter:alpha(opacity=50);
background-color: rgba(0, 0, 0, 0.5);
border-radius: 10px 10px 10px 10px;
padding-top: 5px;
}
As I understand it, IE will ignore the rgba value and use the two higher rules to get a similar effect.
The one downside to using opacity on an element (in newer browsers as well) is that it set it to the entire element, not just the background color, so all text and borders, etc are semi-transparent. But I would at least try out the above to see if it's close enough.
Remember: the only reason people don't upgrade to higher versions of IE (or move to FF or Chrome) is because we go to such great lengths to ensure the design looks good in these obsolete browsers. If enough sites look like dog crap, they will eventually get the idea that it's not the sites, it's their old browser. So don't lose too much time and energy supporting the already-too-slow transition from the bad-old-days of IE pandering.
To simulate RGBA and HSLA background in IE, you can use a gradient filter, with the same start and end color (alpha channel is the first pair in the value of HEX):
filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr='#4cffffff', endColorstr='#4cffffff');
or use a .png image of size 1x2 instead of 1x1.
because Internet Explorer 8 doesn't perform the repeat of a 1x1 pixel semi-transparent background image correctly when any other element on the page is using the "-ms-filter" drective for the alpha transparency
See this link
IE8 doesn't support rgba colors. If you want it to work in IE8, create a small png (any other size than 1x1 pixel) with same opacity and apply it as a background to the div. Or you can use an IE8 only style sheet and set a different background color other than white.
EDIT:
We're in Chrome 19 now, and this still isn't fixed. Just a clarification: this happens in Chrome on Windows, not Linux or Mac. I think it has to do with Cleartype. Google, please fix this.
I've been using CSS3 text-shadow to emulate IE9's font smoothing on other browsers. Basically I've just set the text-shadow of a container's text to the container's background. You can see the behavior by setting text-shadow on a largish font element in anything lower than Chrome 14.0.833. The text looks smooth. Remove the text-shadow and the font looks jagged.
However, in Chrome 14.0.833 (UPDATE: appears it's also "broken" in 14.0.834) this no longer works. The text-shadow property still works, but not in the way it did before. You can see the behavior here (just load it up with diff. Chrome versions)
It seems as if in the older Chromes the text shadow began inside the text just a little and then spread out - which is perhaps why the text-shadow hack worked. In the newer Chrome, it appears the text shadow starts just outside the text, which is why it won't work. See what I mean here.
My question is basically: Is this a bug? Which is expected behavior, if either? Are there any other font smoothing workarounds I can use?
The W3C's spec didn't seem to say what the intended behavior is, though I did see that perhaps I should be using text-outline (which is kinda unsupported, which defeats the purpose)
Okay, i've spend quite a bit of time on this and this is what it comes down to: It's a bug.
First of all, -webkit-font-smoothing:antialiased; only works for Mac, not Windows.
I'm on Windows7, I've created a layered Pixlr image with screen shots of a JSfiddle I made that had 4 different elements with different text-shadow applied to each. You can clearly see that text-shadow has changed since Chrome13 and Chrome 14.0.835. I had to switch between the Beta and Dev channel a couple of times because I messed up, uninstalling etc. ugh.
Download the layered Pixlr image file I made from:
http://dl.dropbox.com/u/7353877/Chrome-text-shadow-v13-v14_0_835.pxd
Then go to http://pixlr.com/editor/ and choose to open file from computer, open the file.
Now in Pixlr, zoom in to the four rows of text, in the layers panel on the top layer click the checkbox and uncheck it, then check it again, do it over and over and see how drastic the change to text-shadow is.
This should be submitted as a bug. A link back to this page could be used to show the effect, if needed.
JSfiddle (The JSfiddle I used in the screenshots)
http://jsfiddle.net/nicktheandroid/Xkp9q/
I put a piece of pie in the microwave an hour and a half ago.... it's cold :(
Well, I've figured it out, sorta. Annoying since I set a bounty, but whatever.
I'm fairly certain this is not a bug and it is expected behavior - especially since we've seen a few more iterations of Chrome and it's stayed the same.
A few different methods work. I wrote up a bit for my blog, you can see the full article here, but here's the bulk of it:
First, I tried the -webkit-text-stroke:1px #000 where #000 is the
color of the text. But this style is meant for use where the color of
the text is different from the stroke, for a nice text-outline. When
both are the same color, it looks...odd. I'm not sure why; I'm no
font-rendering expert. You can see the behavior in the picture after
the article.
Next I tried a simple text-shadow:#000 0 0 1px where #000 is the same
color as the text. Due to the same Chrome 14.0.833+ problem, this
still leaves the font looking somewhat jagged. It's better than just
plain text, however.
Next I tried a combined the two attempts above. This looks a little
bit better, but it bulks up the text as it essentially adds 2 pixels
to the thinkness of the text.
Lastly, I tried applying two text-shadows: text-shadow:#000 0 1px 1px,#000 0 -1px 1px > > where #000 is the color of the text. What this does is
apply two text shadows, one of which is pushed down a little and the
other pushed up. This way, the text shadow covers the jagged edges. It
bulks up the text a little but definitely smooths it out.
Depending on the size of your text, different methods work. Smaller
(but still jagged) text could use the text-shadow, larger text could
use the shadow/stroke method, and very large text could use the
dual-shadow method. Of course the larger the text the less noticeable
the extra few pixels become. You can see all the different methods
here
text-shadow: transparent 0px 0px 0px, #000 1px 2px 1px;
OR
text-shadow: transparent 0px 0px 0px, rgba(0,0,0, 0.75) 1px 2px 1px;
Tested and works fine in different versions of Opera, Chrome, Safari & Firefox.
-webkit-font-smoothing:antialiased;
might work for you
YES! I've found a solution for this problem. It's weird, but it works for me.
So, to make it work, put this style on the element you want to smooth:
-webkit-border-bottom-left-radius: 1px;
text-shadow: 0px 0px 1px rgba(0, 0, 0, 0.01);
overflow: hidden;
I've put up a sample HTML file with just this style so you can quickly test it.
This was indeed how a lot of webfonts (Google Webfonts and also highly professional fonts from Typekit etc.) looked in Firefox (left) and Google Chrome (right) on Windows systems (and eventually elsewhere too). No joke! To clarify this: The only browser that completely messed up Google Webfonts was Google’s browser Chrome. How sick is that ? In 2013 Opera browser has switched it’s rendering engine to webkit (=the rending engine in Chrome), so this problem exists in Opera too.
more : http://www.dev-metal.com/fix-ugly-font-rendering-google-chrome/
Sorry for being a nitwit, but I am getting some really, very big different outcomes visually from the various browsers when trying to get a certain groove effect or inset effect as border style.
when using
{
border: 5px groove #A00;
}
or
{
border: 5px inset #A00;
}
The Firefox 3.6/4.0 look is the one that is what I need and what I think is a correct GROOVE or INSET rendering. All the others look awfully different. Close to SOLID or OUTSET. Apparently there is no real precise definition, which kind of makes it a surprising party for the developers at the browsers to give each their own interpretation of what INSET and GROOVE styling does.
Is there any way I could get the currently ridiculous differences to match up towards one well thought design of mine that might look the same way in the major browsers?
I am not afraid of using some other creative CSS3 stuff if I only know what or how that could be used then.
So any ideas are welcome and code especially too.
From the spec (emphasis mine):
The color of borders drawn for values of 'groove', 'ridge', 'inset', and 'outset' depends on the element's border color properties, but UAs may choose their own algorithm to calculate the actual colors used. For instance, if the 'border-color' has the value 'silver', then a UA could use a gradient of colors from white to dark gray to indicate a sloping border.
Therefore there is no "correct" way of coloring the borders. It's up to the browser vendor how they want their browser to shade the borders.
So, in answer to this:
Is there any way I could get the currently ridiculous differences to match up towards one well thought design of mine that might look the same way in the major browsers?
I guess you could nest elements and play with multiple borders' border-color settings yourself if you need fine-grained control. Make these borders solid, though, for starters.
Firefox/Webkit/IE/Opera all look consistent to me in terms of the pattern they render - that is, a darker color on the outside of border-left and border-top, and a lighter color on the outside of border-right and border-bottom.
The actual colors do seem to differ per browser though. From your example:
Opera
Darker: #7f0000; rgb(127,0,0)
Lighter: #c04141; rgb(192,65,65)
Firefox
Darker: #770000; rgb(119,0,0)
Lighter: #d47f7f; rgb(212,127,127)
Webkit
Darker: #560000; rgb(86,0,0)
Lighter: #aa0000; rgb(170,0,0)
IE8
Darker: #2e0303; rgb(46,3,3)
Lighter: #b80d0c; rgb(184,13,12)
The color ratios are clear and the Webkit one seems to be the only logical one - the specified color for the lighter one, and double the RGB value for the darker one.
The others are quite different, but the pattern is at least the same.
I know you have already accepted an answer, but consider using the "outline" property.
Already discussed here on SO
For things like menubars and headers, a background color is nice.
But a background color that gracefully transitions from say Blue to White is even nicer.
I know this can be done by making a 1-pixel wide, X-pixel tall image file containing the desired fade and repeating it across the div, but does CSS have native support to just define colors and be done with it?
Can any other language handle this?
With CSS3, you can do that. However, CSS3 is not widely supported through browsers, so only the most recent of browsers (and not even all of them) will be able to display the gradient. Unless you're only interested in working with those browsers that can do it, you're going to have to stick with the 1px background image.
http://www.quirksmode.org/css/contents.html
http://www.w3.org/Style/CSS/current-work#CSS3
You mean a gradient?
Webkit browsers(Chrome and Safari), and apparently FF 3.6 now support CSS gradients:
see this link
According to the article, even IE has some proprietory CSS gradient support, I don't know how well that works though. You should always have a fallback to solid color though.