I've been dealing with the same issue last couple of months. I've googled the same issue but i guess no-one has address this issue before.
previously when i change the hex color transparency, for example #FFFFFF, the Chrome devtools was giving me the option of RGBA version like RGBA(255,255,255,10%) but now when i do the same thing the result is for 10% white color transparency ise rgb(255 255 255 / 10%)
As you can see the RGBA is now gone and the devtool onşy show the strange version of rgb type.
Does anyone issued the same problem before? And do you know how to fix it?
This was an intentional change in DevTools. The comma-based syntax is what the spec now calls “legacy syntax”.
See https://twitter.com/mathias/status/1253242715304857601:
💡 In source code, stop using the old rgb()/hsl() CSS color syntax with commas.
Get used to the modern comma-free CSS color syntax, supported in all modern browsers.
Why? Upcoming new features such as lab(), lch(), and color() use the same syntax (and don’t work with commas).
Spec: https://drafts.csswg.org/css-color/#rgb-functions
[…] for legacy reasons, an rgba() function also exists, with an identical grammar and behavior to rgb().
open chrome developer >> open color picker + shift
Related
I have been using the #enable-force-dark flag (found under edge://flags for Microsoft Edge) for a while, and all websites, including Google Docs, were working perfectly fine then—but ever since Google Docs updated something about how document pages, and their color, are setup this past month I can't get documents to darken (regardless of which drop-down edge://flags/#enable-force-dark selection is made), even if I change the page color to dark on Google Docs. Any workarounds within the website itself, Microsoft Edge, and/or another browser?
Note: if I turn the browser flag off, dark document page colors show up perfectly fine, but I would really appreciate avoiding eye strain both on Google Docs, and in other websites.
According to your description, I tried this feature, and I found that #enable-force-dark works normally in Chrome(verion 96.0.4664.45) and Edge(version 96.0.1054.43). In Google Docs, except for the document part, the background is dark, something like this. So I think this is by design.
If this feature does not work correctly, you can try to reset Edge/Chrome or clear the cache, which may be useful to you.
In addition, I found an extension named Dark Reader, I think it will suit you, you can set the level of background color according to your preference. It also works with the document part in Google Docs, and you can even switch back to the default background without restart the browser.
I'm experiencing an odd rendering problem in SOME versions of Chrome when trying to render the unicode characters U+2795 thru U+2797, the Heavy Plus/Minus/Division Signs. On some versions of Chrome, the sign will render as an ugly gray with some kind of black pseudo-outline, which does not respond to CSS color commands. Here is an image:
For a sample of how it looks on every other browser I've tried, see FileFormat.info - Unicode Character HEAVY PLUS SIGN
By SOME versions, I mean, I can't seem to narrow it down to a particular version of Chrome. The same version of Chrome on two different computers running Win10 will render differently, and I can't find where the difference is.
Is this a bug in Chrome? I can't seem to find where anyone else has run into this problem. I'm trying to include this on a website, but if certain versions of Chrome render it ugly, I need to find another solution.
-- edit --
XY Problem
My purpose is to use the +/- as the "expand/collapse" markers in a collapsible accordion box where the background may be light-colored or dark-colored. I was hoping to be able to color them to match the remainder of the text without needing to resort to images, but based on the comments below I'm starting to think it may be easier to throw together an .svg, recolor it in CSS, and be done with it.
The problem is that the browser is replacing the glyphs with emoji, which will be rendered differently for each browser. Emoji cannot be colored using CSS -- the best you can do is silhouette them and color the silhouette, as described in Color for Unicode Emoji. Unfortunately, this still means that the glyphs will appear differently on different browsers, as the emoji won't render using the font you specify.
There isn't currently a way to force browsers to render glyphs instead of emoji. Appending \FE0E (as described in How to prevent Unicode characters from rendering as emoji in HTML from JavaScript?) will sometimes work, but this is not consistent, not guaranteed, and therefore not recommended.
You can provide a web font which contain the glyphs you need, but this is also not guaranteed to work, as some browsers (especially on mobile devices) will still replace them with emoji.
If you require consistent rendering, the best way seems to be to use an image instead of trying to force the browser not to use an emoji.
I'm trying to implement a color scheme I got from Kuler by using the hex RGB values, and I'm getting some interesting measurements, depending on the monitor I'm using and its calibration.
In Firefox, the color always measures correctly - #e9e8e1 (I'm using Pixelstick for the Mac to eyedrop the color in the app).
In Chrome and Safari, the color measures off by a hair: #e9e8e0 and sometimes #e9e8df, but to me, it's quite noticeable that there's a color difference.
The bizarre thing is that eyedropping the color in the Kuler app in Safari/Chrome is always correct no matter what screen it is on.
I suspect that has something to do with Kuler's Flash app overriding the color management calibrations for the monitor.
Is there a way to force the browser to ignore the color calibration via HTML or CSS code for Safari so that the color specified in the CSS is rendered?
I thought of using a tiled PNG but I'm getting similar measurement variations when I manually select a color in Pixelmator (my graphics editing tool) even though I'm entering the color values manually.
Chrome Version 16.0.912.75 m running on Vista.
I'm trying to apply an rgba background colour to a disabled select element, with the opacity at 0.2.
It works fine in Firefox and Opera, but Chrome ignores the opacity, and just shows flat colour.
I've already tried adding -webkit-appearance: none. This fixes the alpha value, but removes the button part fo the select element from view.
Does anyone know how how to have a background with an alpha value, and not hide the button part of select?
http://jsfiddle.net/EMSmZ/9/ <== I've edited this to confirm that rgba is otherwise working for background colour, but not for select. The two boxes have different background transparencies in Chrome, but the selects don't.
Still nothing, submitted a bug report: http://code.google.com/p/chromium/issues/detail?id=110437
I hate to break this to you, but styling form elements with CSS is just a bag of hurt. There's a reason everyone uses Javascript replacement techniques to change the look and feel of form elements.. (except text and text area essentially)
not working as is in chrome 16.0.912.75 m on XP.
IF you give the disabled 'opacity:.2; it changes the opacity of the whole element.
Not sure what effect you are trying to achieve, maybe show some context to help offer a solution.
I ran into the same problem developing a form for a client. The workaround I ended up using was to set the background-color to a lighter version (#faebe7) of whatever base I color I wanted to use, in this case red, rather than using rgba(255,0,0,0.4).
I am using the following code:
-moz-linear-gradient(top , rgba(255,255,255,1), rgba(255,255,255,0));
But I would like to implement a similar gradient in the `other browsers. My problem is that I don't know if I can use the alpha channel and I don't want to use images I would just like to do it with code only.
Can someone tell me if it's possible.
Hope you can help
you'd have to create partially transparent pngs or look at using the filters MS provide (though they are much maligned I should add...)
'cross' browser gradients
Personally these are decoration facets that IMO don't destroy the exerpince of a site - to that end when possible I wouldn't even bother - IE9 will take up significant market share within 12 months and all the work you are about to do won't be needed anymore
Check out CSS3 PIE, it handles this fairly well for IE, although it requires position to be set, and can break on elements that get hidden, and there's a short delay when rendering the gradient...
Webkit has a different approach to linear-gradient, you can see an example on the link.