The ::selection { } CSS element selector is supposed to replace the default blue-colored text selection with our own choice of text and background color.
However, this seems not always the case, as I often see websites which has the remaining blue color. It's not completely replaced with our owh choice of color.
======EDIT======
I guess it's easier to see by our own eyes rather than through screenshot.
See this page for example: bleachindonesia.com/2012/05/27/bleach-day
On that page, if you try to select all (Ctrl+A), you would see the text will be blocked/selected with gray color. Yes, because the page CSS employs ::selection, ::-moz-selection { background:#59574b;color:#fdfcf5; }.
However, as you can see with the screenshot below, it leaves some default, blue-colored selection on some part.
http://i.stack.imgur.com/A0aUJ.png
Notice the color difference, and at the same time, the unselected part. There are some parts on the site that gets selected with the default blue-colored ::selection, but at the same time there are also some other parts that doesn't get selected.
Meanwhile, there is also this page: 24ways.org/2005/swooshy-curly-quotes-without-images
Again, try to select all (Ctrl+A) the page. You could see all selection is perfectly maroon-colored. There is no default blue-colored selection. There is only parts that doesn't get selected, but there is no the default blue-colored selection. As pictured by the screenshot below:
http://i.stack.imgur.com/4o6ll.png
The page CSS? ::selection { background-color: rgba(179, 45, 71, .75); color: #fff; }. The only difference with the first page that it uses RGBA and not hex code. I don't think it makes any difference there--it's essentially the same code.
Now what makes me wonder.
Why is on the first page the default blue-colored select persists, but it doesn't persist on the second page? And, how to make it as perfect as the second page?
Frankly, it's very difficult to tell if this is buggy behavior, although I'd surmise that it looks very much like it. ::selection suffered from a lack of proper definition (and thus a lack of proper implementation and testing), so I bet even browser vendors have had trouble figuring out what's wrong.
Worth mentioning is that this rule, from the first site:
::selection, ::-moz-selection { background:#59574b;color:#fdfcf5; }
Seems very much benign, except it incorrectly combines ::selection and ::-moz-selection such that it will never work in Firefox, because it doesn't recognize ::selection and drops the whole rule. 24ways.org doesn't display the selection color properly in Firefox either, not because of combined selectors but because there is no ::-moz-selection selector in the first place.
As to why Chrome and Safari leave blue areas of highlight in certain areas in the first site, I really don't know. However, I think Jared Farrish makes a good point:
This replicates the problem in Chrome (at least): jsfiddle.net/RfPgt It seems to be when an element is nested within another element which itself has selectable elements.
I found what is causing this. It is <br> so if you have <br> in your text try deleting it
I read this question some time ago to find a solution for the same problem but I did not find it. Now, even if the question is old, I want to share the solution that I found.
Just use the universal selector:
*::selection { background:red; }
Related
Just run into something surprising. If you do this:
footer::selection {
color: white;
}
...it also removes the browser-default background-color for the highlighted text. It behaves as if you had also set background-color: transparent. (See demo below.)
Question: How can I retain or restore the system default text selection background-colour when setting a custom ::selection color?
(This answer lists various selection background colours used on different systems. But I don't just want to choose one, I want it to just be whatever the default is for the current system.)
Demo:
body {
background: navy;
color: gray;
}
p.custom::selection {
color: white;
}
<p>Regular paragraph</p>
<p class="custom">Paragraph with text color changed in ::selection</p>
This behavior has been codified in the spec, as follows:
The UA must use its own highlight colors for ::selection only when neither color nor background-color has been specified by the author.
(This used to say "should" until last year, when it was changed to "must". There aren't any browsers implementing some version of ::selection that don't already follow this rule anyway.)
System colors are only exposed to CSS as user-defined values (which may or may not be just the system default), and not the system-defined defaults, so can't be known in advance. Therefore, as CBroe implies, this rule is in place to ensure that changing just one doesn't cause it to clash with the user-defined value for the other, causing contrast issues. The actual codification of this rule in the spec is for legacy reasons, but this rationale for browsers behaving like this in the first place is cited in discussions such as this one.
There are a number of standardized as well as non-standard system colors that exist, but the behavior of these varies wildly from browser to browser, and from platform to platform. Attempting to use any of these may have unexpected results, ranging from unexpected colors used, to being ignored by the browser altogether. Plus, as I mentioned, system colors are only exposed as user-defined values anyway. The CSSWG has discussed potential ways to improve this before; here's a recent conversation.
You are encouraged to apply a custom selection background color that complements your custom selection foreground color.
I'm developing some changes to a page and the current CSS rule is a:focus { color: red }. We don't want that for a page. We just want the focus to do nothing at all. I don't want to override it with a:focus {color: black} to keep it as black (as this then interferes with hover). I just want it to be more like a:focus {color: unchanged}
You might be able to use color:initial instead. It isn't supported in IE, but that's not such a big thing anymore.
Also try all:revert or all:unset. I don't think this is completely cross-browser compatible so maybe try all 3 together.
I would use color:inherit to return it to a normal value, which is what the color property does anyway in elements. It inherits them from parents. "inherit" erases the current assigned value on your element and says "just pass through me the text color every other element inherits and uses". So the text looks like any other text color you are using. Inherit is also supported across all browsers, including Internet Explorer.
Some browsers may assign special colors to anchor element "psuedo-classes" like "focus". But for focus its not so common as the others. If you think you might be needing to see that special color return then you can try "color:revert" (for non-IE browsers only) on an element using the "a:focus" psuedo-class. This should reset an anchor element BACK to its "psuedo-class" browser default focus color, if it exists. But I would not trust that.
To manage resets and defaults, I always assign my psuedo-class anchor elements a custom text link color in my "reset" style sheet so they start with a basic color shared across every browser and version. When I need to return my links back to those values, its very easy to then create selective styles to reset them.
I am trying to hide the autofill style for a password input field that comes in via the user-agent-styles.
When inspecting the element, the computed styles show that the color coming from the user-agent-style is being overridden and #fff is being applied, but the actual computed style is still the one coming from the user-agent.
Any idea on how to get rid of this?
Here is the CSS I am using to try and override it:
.password {
border-right: none;
background-color: #fff !important;
}
#MainContent_txtPassword:-webkit-autofill, input:-internal-autofill-
previewed, input:-internal-autofill-selected, textarea:-internal-autofill-
previewed, textarea:-internal-autofill-selected, select:-internal-autofill-
previewed, select:-internal-autofill-selected {
background-color: white !important;
}
I found an answer that works for me! See https://webagility.com/posts/the-ultimate-list-of-hacks-for-chromes-forced-yellow-background-on-autocompleted-inputs
I had initially come across https://css-tricks.com/snippets/css/change-autocomplete-styles-webkit-browsers/ but that only works for opaque backgrounds, and not transparent ones. The webagility article includes a nice hack for transparent backgrounds too.
To summarise both the articles, the solution I applied is:
input:-webkit-autofill,
input:-webkit-autofill:hover,
input:-webkit-autofill:focus,
textarea:-webkit-autofill,
textarea:-webkit-autofill:hover,
textarea:-webkit-autofill:focus,
select:-webkit-autofill,
select:-webkit-autofill:hover,
select:-webkit-autofill:focus {
-webkit-transition-delay: 99999s;
}
The reason this works is because chrome applies autocomplete styles via a css transition. If you delay all transitions on that input, the styles will never be applied.
This behaviour is seen in Chrome only (it is not in Firefox, I didn't test Edge or others). Chrome applies a pale yellow background (#E8F0FE) and black text to all autofilled inputs. This user agent style for autofilled text has hard-coded priority in Chrome's rendering since Chrome version 74. This behaviour is intended by the Chrome developers.
In Chrome, these hard-coded styles will override anything you can set yourself in the document or via Javascript. In the original question, Style Inspector shows the OP's background-color: white !important style as having precedence over the user agent style input:-internal-autofill-selected. Style Inspector is wrong to show that: it looks like it does not know that the user agent style for autofilled text has hard-coded priority.
I replicated the OP's issue in a (codepen). Note that I even tried to update the input:-internal-autofill-selected user-agent style in the document's own CSS, with the !important suffix. Even with that in the CSS, Chrome still uses the original, hard-coded user-agent style. This codepen also shows you that none of the following methods will be effective to override the user agent style in Chrome.
use CSS with greater specificity
add style to the element in HTML
use an event in Javascript to change the element's style properties (for example backgroundColor) after data is entered
This has been reported to Chrome as a bug. The developers' response is WontFix, citing a security concern. Chrome devs don't say what the security concern is, but I guess it is that a malicious site could create HTML with hidden input boxes (no border, and background and foreground colours matching the page background) and gather some auto-filled data without the user's knowledge.
This "WontFix" attitude is not a great solution. It annoys designers who want to control the appearance of input boxes. The OP wants a pure white background and Chrome changes it to #E8F0FE which is maybe not a big deal, but it's way worse for designers who want to use a dark background. How hard would it be for Chrome to check programmatically that the page has styled the input box with high enough contrast to be visible to the user? Chrome has also not fully solved the security concern, because a malicious site can hide an input box in some other way: it could be outside the visible screen area, or covered by a different page element.
I had a similar problem attempting to style a select option element's background colour when :checked.
I'm using pseudo elements to add checkboxes to a select element where multiple selections are allowed and didn't want to whole row showing as being selected.
I found that changing to another colour had no effect over the User Agent Stylesheet (Chrome) but using a gradient as the background did.
option:checked {
background: linear-gradient(0, #fff, #fff);
}
I'm having trouble with the text underneath the images on the website I'm building:
1) The "Back to home page" changes from the font it's set at (Georgia, 0.9em) to the default in Firefox. It does not do this in Safari (http://ink-12.web5test.terc.edu/img/modelofinteractionfull.cfm).
2) The footer appeared fine before I added images (http://ink-12.web5test.terc.edu/index.cfm). After I added images (inside div class=.submenu), again, the font I set (Georgia, 0.9em) changed to the default in Firefox (http://ink-12.web5test.terc.edu/aboutus/index.cfm).
Another issue that appear after I inserted the images:
1) The footer's vertical bars (|) disappeared between the links, in both Firefox and Safari. You can see that the bars are actually still there when you highlight the text, but for some reason, they do not appear in white anymore so they aren't visible (http://ink-12.web5test.terc.edu/aboutus/index.cfm). But you can see how it's supposed to look on the home page (http://ink-12.web5test.terc.edu/index.cfm).
I wanted to copy my code below, but I'm having trouble understanding how to properly format it on this site, so I'll work on that. In the meantime, any thoughts?? Thanks so much in advance for your help!
For example, regarding question 1, the only CSS rule that sets the font family is
h1,h2,p,p2,li{ /*group codes for many styles*/
font-family:"georgia";
}
It does not affect the link, since it is not inside any of those elements. Similar considerations apply to question 2. And the vertical bars are there, they are just black on black.
Use a markup validator like http://validator.w3.org to find he HTML syntax errors, fix them, and then deal with the CSS syntax errors with http://jigsaw.w3.org/css-validator/ and then analyze the logical problems. Using Firefox with Firebug is a good idea, since then you can click on any element and see which, if any, CSS rules are being applied to it.
I'm not sure if this will help you, but I suggest making sure that "Georgia" is capitalized when you declare it. I might be wrong but suspect that some browsers may not be picking up the name because it doesn't match the font's name perfectly.
Comparing the pipes (the vertical bar characters '|') between your examples shows a small flaw in the CSS. The pipes are not inside of the <a> tags so even if you set all your <a>s to white the pipes will never change. In one example ( http://ink-12.web5test.terc.edu/index.cfm ) the pipes are contained by a <p2> tag, which wasn't a valid HTML tag last I checked but that's besides the point. The <p2> has its color set to white which makes the pipes inside of it white. In the other example ( http://ink-12.web5test.terc.edu/aboutus/index.cfm ) the pipes are contained by a <div> which has its color set to black which makes the pipes black, but the <a>s are set to white. Since your background is also black the pipes disappear.
For the "|" issue add the following
skeleton.css line #161
.footerlinks {
padding-top: 0.5em;
color: #fff;
}
For the link issue it looks to me that the font is becoming bold when you hover. You just need to define your hover state ...
fonts.css line #4
a:hover {
font-weight: normal;
}
Sorry, it was such a simple fix! I"m very new to coding (as I'm sure you could tell by the ridiculous amount of markup I had in my style sheets). I didn't know that links could have all their own font-family, and thought that if you kept it between a heading or paragraph tag, that it would just take that on. But I get it now, thank you!
I'm trying to remove the blue "halo" outline that form elements have in Firefox on OS X. Using CSS, I can remove the halo in Safari on OS X, via:
input {
outline: none;
}
But this seems to have no effect in Firefox, nor does the -moz-outline property.
Another option, that takes care of all of the 'halo' is this:
*:focus {outline: none;}
I guess you could add an !important if you wished, but I haven't run into the need yet.
:focus {outline:none;}
::-moz-focus-inner {border:0;}
I'm going out on a limb since I don't have OSX to test it... but does removing the border work?
input {
border: 0;
}
I believe the style of all the form elements are stored in the forms.css file. In OS X, I think it is located here:
/Applications/Firefox.app/Contents/MacOS/res/forms.css
You may want to browse through that file and see if there is any obvious CSS that is affecting the appearance you are seeing. For example, on Windows the input element has -moz-appearance: textfield;, which I couldn't find any documentation on, so perhaps there is some "native" -moz-* style on those fields that is controlling the glow, something you could possibly override.
The other thing to try might be to override everything in that file by changing the input definitions to input2 or something (after making a copy of course). Then you can see if you can get the glow to stop at all by manipulating the default CSS.
Once you've determined you can make it stop (if you can), you can add styles back in a bit at a time until you find the one that causes the effect you don't want. You can probably speed up that process by eliminating styles from your testing that obviously aren't related (e.g. - line-height: normal !important; is almost certainly not responsible for a blue glow around the fields).
Maybe you have an active user style sheet in your machine creating this behaviour. Some add-ons do this (to make the focus more obvious).
Look into the firefox's chome forder (in your user files)
Alternatively try with
input {outline: none!important;}
Also
The Stylish plugin has a style for this, maybe you have it installed?
There are greasemonkey script that do this. If you have it installed, disable it
They both take precedence over the !important attribute.
So: you have several places to look into
* User stylesheets
* Stylysh
* greasemonkey
* anothes add-on
One of those must be forcing the outline
I went through the various suggestions made here, but none seemed to be able to fully address the problem. By defining a custom border style, i.e.
border: 1px solid #000;
I'm able to get rid of the focus halo, but this obviously alters the look of the input element. border-style: inset; seems to most closely resemble the "native" look, but it's still not quite right, so as far as I can tell right now, you can either suppress the halo, or have a natural looking input.
I believe this is what you are looking for:
input:focus { outline: none; }