I have really simple HTML code
<img class='star' src='' alt='★'/>
With really simple style
.star {
position: absolute;
cursor: pointer;
font-size: 40px;
color: black;
}
.star:hover {
color:red;
}
My idia is this. If there is no image on server, I show unicode star symbol ( or if user will switch off all images ). And if a user
It works perfectly in FF ( tested on FF25 ) but fails really hard on WebKit browsers. Hover state dosn't trigger or triggers ones and then stay in that state forever.
I have only one question.. WTF is that? o_O Where am I wrong, or it's just a WebKit bug?
It would be nice if someone told me how to fix this. But mostly i want to understand what is going on here.
PS: Example http://jsbin.com/UMIrAJI/3/edit
UPD:
This example is working http://jsbin.com/UMIrAJI/5/edit but the only difference is 'background' color changed on hover. As soon as we remove 'background' - hover stops working. LOL.
So my question is still valid. What is going on here?
UPD2:
I found another workaround. If we add border: 0px solid white; (but only on hover) example will also start to work http://jsbin.com/UMIrAJI/6/edit . So it's something about repainting.
UPD3:
It looks like a bug to me so I reported it. I'll wait for some comments from developers.
https://code.google.com/p/chromium/issues/detail?id=323545&thanks=323545&ts=1385479799
Instead of alt, which should describe the content of the image, for browsers without image support and for accessibility tools, use the title property
<img class='star' src='' title='★'/>
Related
I have a strange issue and I am not sure where to look for a fix. Googling is not leading to any answers.
I have some CSS to make the selected radio button purple. Easy right? However, it is blue. Even though the CSS is clearly in the inspector as purple. Even trying to force style in the browser just to change it doesn't work. Why would this be? I've never seen where it clearly is using the right CSS but not actually rendering. This is happening on multiple browsers.
My code is in Elementor:
selector input[type="radio"]:checked, input[type=reset], input[type="checkbox"]:checked, input[type="checkbox"]:hover:checked, input[type="checkbox"]:focus:checked, input[type=range]::-webkit-slider-thumb {
border-color: #9710A6 !important;
background-color: #9710A6 !important;
box-shadow: none;
}
Which shows up perfectly in the inspector:
.elementor-1202 .elementor-element.elementor-element-f11e2ef input[type="radio"]:checked, input[type=reset], input[type="checkbox"]:checked, input[type="checkbox"]:hover:checked, input[type="checkbox"]:focus:checked, input[type=range]::-webkit-slider-thumb {
border-color: #9710A6 !important;
background-color: #9710A6 !important;
box-shadow: none;
}
And shows as what is being computed in console.
background-color
rgb(151, 16, 166)
#9710A6 !important.elementor-1202 .elementor-element.elementor-element-f11e2ef input[type="radio"]:checked, input[type=reset], input[type="checkbox"]:checked, input[type="checkbox"]:hover:checked, input[type="checkbox"]:focus:checked, input[type=range]::-webkit-slider-thumb
And yet when I look at it is is blue. Using a color selecting tool it returns:
0075FF - I think it is the default browser blue.
Is there a way to have maybe some JS running or something changing it that would not show up in the console? If it was JS changing it wouldn't the result "computed" value change?
So strange, any ideas or help you can offer would be really appreciated. Thanks so much!
Thanks to Carlton Lindsay for the answer.
It appears you cannot change the radio button directly with CSS. Instead, hide the default button and create a new one using :before to add one back in it's place.
This seems like really strange way to do it. But it is how it is done for now. Hopefully things change soon in the browsers so you can directly manipulate the style through CSS.
This is a learning exercise for me, so thanks in advance for not telling me why I don't want to do to the following. I don't want to do, I want to understand.
Given the following CSS:
input[type="file"]:focus,
input[type="radio"]:focus,
input[type="checkbox"]:focus {
outline: thin dotted;
outline: 5px auto -webkit-focus-ring-color;
outline-offset: -2px;
}
input[type="checkbox"]:focus {
outline: none;
}
The specificity for both shows as 0,2,1, and everything I read about CSS says the second style should override the first as it comes last. If I get more specific about the second style, it wins. But as posted, Chrome doesn't display the outline, but IE11 and FF28 do. This seems to me to be such a fundamentally simple application of CSS. Does anyone have any insight into what the underlying issue is, so that I can pull it into my thinking as I'm developing stylesheets?
EDIT: Chrome also doesn't display the outline if I delete the second style. In Chrome, the outline: thin dotted are overridden by the following outline line. So it appears that per the spec, Chrome is playing by the book and FF and IE don't? Could it be a union vs. override difference in how browsers interpret CSS?
With apologies, the error was mine. When I switched from bootstrap.min.css to bootstrap.less, I didn't remove the former from loading so it was loaded last and overrode my Site.less -> site.css. I figured it out after I tried to create a fiddle, which I should have done in the first place. Feel free to down-mod this post to hell in the way that it deserves.
So i have some html:
<a class='clicktext'>...read more!</a>
and i want to give it a :hover animation, as so:
.clicktext{
}
.clicktext:hover{
text-decoration:underline;
}
.clicktext:active{
text-decoration:none;
}
Suffice to say, it does not work in Mozilla Firefox 5, even though it works perfectly well in Chrome and Safari. However, if i change it to
a{
}
a:hover{
text-decoration:underline;
}
a:active{
text-decoration:none;
}
It works perfectly fine in Mozilla Firefox 5! I have not managed to find anything regarding this online.
I could, of course, just change my styles to apply to the a rather than the .clicktext. The problem with that is that it would screw up my conventions, which is (as far as possible) apply all the styles to classes rather than to the tag names. After all, I have many other tags for which i do not want this underline-on-hover thing to appear.
Has anyone bumped into this, and perhaps found a nice solution?
edit: these also do not work
.clicktext a:hover{...}
a .clicktext:hover{...}
I had these kind of problems with Firefox and solved it by adding the tag name to class name:
for example I had this which worked in Chrome but not in Firefox:
.content .sidebar:hover{
background-color: red;
}
and fixed it by making it more specific like this:
div.content div.sidebar:hover{
background-color: red;
}
http://jsfiddle.net/rE8xU/
I do not see the issue, when moused over it does include an underline.
A possible cause of this issue is the level of importance that the class has.
Such as styles that are set by their identification tag will take over any class styles and so forth.
http://htmlhelp.com/reference/css/structure.html
check out cascading order
Lastly, make sure that the css file is properly linked and or embedded
you can use firefox to check as well.
You need to add href="#" to your . the :hover meta tag needs the link to have the href property set.
use <p></p> tag if you are not hyperlinking the text.
<p class='clicktext'>...read more!</p>
then for styling the text.
p.clicktext {
color: #ccc;
}
p.clicktext:hover {
text-decoration:underline;
}
Hope i Helped ;)
There's a big chance that you have a conflict somewhere in your CSS, because the jsfiddle with this exact code works fine in Firefox 5. You might want to check for ID-selectors with the hover-pseudoclass that could possibly overrule this line of styling. Inspect it with firebug to see what css is inherited.
You might be getting this problem for
1: not specifying the class which is clicktext in your case, or.
2: object a is associated with some other class not compatible with clicktext class!
I am saying this because my website
is running perfectly without any problem, in both Chrome and Firefox!
I am using hover to produce an overlay effect! This is what I am doing:
.container{
//your specifications
}
.image{
//your specifications
}
.text{
//your specifications
}
.container:hover .text{
//your specifications
}
I also think that the answer marked as "correct answer" is not correct.
I had same problem, was just not working on Firefox, quick close and restart app and was working again.
Daniel
Does anybody know how to remove the dotted outline on buttons in Opera?
I have done it.
Here you go: http://jsbin.com/oniva4. [tested on Opera 10.5/11]
The secret is using outline-offset:-2px; (effectively covering the dots) and the background's color for the outline. outline-offset is supported since version 9.5.
The introduction of the article Do not lose your focus
For many web designers, accessibility conjures up images of blind users with screenreaders, and the difficulties in making sites accessible to this particular audience. Of course, accessibility covers a wide range of situations that go beyond the extreme example of screenreader users. And while it’s true that making a complex site accessible can often be a daunting prospect, there are also many small things that don’t take anything more than a bit of judicious planning, are very easy to test (without having to buy expensive assistive technology), and can make all the difference to certain user groups.
In this short article we’ll focus on keyboard accessibility and how careless use of CSS can potentially make your sites completely unusable.
And the list of test given by the article on outline management.
Update 2011-02-08
I can confirm that it is not possible for now. There is an open bug for it.
I say this with the clear proviso that you shouldn't remove the outline unless you replace it with something else that indicates focus state ...
If you apply a transform to the element, it kills the outline in opera; it doesn't even need to do a visible transform, merely applying the property is enough. So this will do the job:
#myButton:focus
{
-o-transform:rotate(0);
}
But I can't promise that wouldn't be considered a rendering bug, and consequently something that may change in the future.
I believe the problem lies in where you specify the outline properties. Try this:
*:focus, *:active {
outline: none; (or possibly outline: 0)
}
I researched this more and it looks like on input fields and buttons it will not work unless you edit the browser's config, like Firefox's about:config page. It seems to be done for accessibility reasons so that a keyboard can be used to fill out and send a form without using a mouse.
I used that trick above for my text area and worked fine! Using a Text Area with an id "itens", here it goes!
#itens:focus, #itens:active{
outline: 1px solid white;
outline-offset: -2px;
}
So, you can play with that:
#itens:focus, #itens:active{
outline: 1px solid lime;
outline-offset: -2px;
}
Are you looking for:
button{
outline:none;
}
or if your button is an input...
input[type=button]{
outline:none;
}
Just read this forum post on the opera website
http://my-beta.opera.com/community/forums/topic.dml?id=712402
There seems to be no fix for it
Further to my tip above -- with experience I've found that it doesn't always work, and isn't always appropriate anyway, since it can change the way the element is rendered in subtle and sometimes unpleasant ways.
So, if that doesn't work, another thing you can do which often does, is to specify the outline color as "rgba(0,0,0,0)"
if you attached css-reset in your stylesheet should solve the issue.
Remove outline for anchor tag
a {outline : none;}
Remove outline from image link
a img {outline : none;}
Remove border from image link
img {border : 0;}
This is less of an answer, and more of an explanation as to what seems to be going on:
The story
My reason for removing opera's outline was to add an outline of my own. To add an outline I used:
:focus{
outline:1px dotted #999;
outline-offset:-3px;
}
This works perfectly fine in every other browser... except Opera. Opera instead gives you this weird interference pattern, which looks like a dotted-dashed outline:
now if you remove your outline, you still have the standard outline that Opera provides, a nice simple 1px spaced dotted line:
Since I have no way of adding a style to every browser except Opera, I instead decided on removing Opera's outline before adding my own. Using brothercake's solution, -o-transform:rotate(0); to do this and then applying my own outline:
Voila!
An Explanation?
From what I can tell, Opera adds it's own secondary outline on top of any outline defined by CSS.
This secondary outline seems to have an independent color, width, style, and offset.
Color is the opposite of the background,
Width is 1px,
Style is dotted,
and the offset is 2px smaller than the border.
sorry there is no style image, the upload didn't work correctly
one interesting thing is that the dotted style of the Opera outline is not the same as the CSS outline's dotted, otherwise there would be no interference pattern with both:
Conclusion:
As I stated above, I am using brothercake's solution which is to nullify the opera border with:
-o-transform:rotate(0);
As he mentioned in his later comment this 'fix' does have some issues as it is a rendering bug:
I have noticed that when returning window or tab focus to the page containing the button, if the button previously had focus, the Opera outline will reappears until the button loses focus or is hovered over.
better:
outline: solid 0;
for all web browsers
The styles:
h2 {
color: #71D0FF;
font-size: 11px;
font-weight: bold;
margin: 0px 0px 5px 0px;
}
a.box {
color: #FFFFFF !important;
cursor: pointer;
display: block;
padding: 10px;
text-align: justify;
}
a.box:hover {
background-color: #0C0C0C;
}
a.box span.down {
display: block;
color: #D04242;
float: right;
font-size: 11px;
margin-left: 5px;
}
a.box span.up {
display: block;
color: #71D013;
float: right;
font-size: 11px;
}
span.noob {
color: #FFA142;
}
span.pro {
color: #A142A1;
}
The HTML (this is basically repeated for each link):
<a href="/library/blaze" class="box">
<span class="down">-0</span>
<span class="up">+0</span>
<h2><span class="noob">NOOB</span> BLAZE</h2>
HAS CREATED 0 MAPS, WON 0 BATTLES, AND LOST 0 MAPS
</a>
What I'm not understanding is why it renders differently in Firefox occasionally. Sometimes it shows up like it's supposed to and sometimes it shows up in this weird format as seen here:
I've never had anything like this happen before, does anyone know what's causing it? Does it even do this for anyone else? Like I stated before, sometimes it loads just fine (exact same HTML, CSS, and everything) and sometimes it doesn't. It seems kind of random. It loads just fine in IE with no weird problems at all.
Interesting. I can definitely reproduce it on FF3.6, actually I'm getting the broken version more often.
I can't get my head around it right now, but looking at it in Firefox, there is something broken with the link. If you open "inspect element" in Firebug, you will notice that the rendered DOM definitely changes between the intact and broken view. Firebug will also add _moz-rs-heading to the link, which is sort of explained here.
The first step should definitely be making the markup W3C valid and checking whether it still occurs.
I am a bit surprised that it doesn't act up more than it does.
You have put a block element (h2) inside an inline element (a). The markup is broken, and different browsers will do different things to try to make the best of it. One thing that can happen is that the browser adds an ending tag for the link before the block element.
Us an inline tag instead of the h2 tag, and use CSS to style it to look the way you want.
I'm having the same problem.
http://www.jameshughbanks.com/
I've narrowed it down to this. It ONLY happens when I put a link around multiple elements (in my case it involves one (or more) block element(s) and one (or more) in-line elements.
It is very odd as in it seems to only affect "every other" "error" you create using the method I described above. It will modify the first and third div output but not the 2nd. (at first it affected the 2nd one only, but I partially fixed the problem (it used to mess up the H2's also, but putting the link around the h2's only removed them from getting the error.
So it comes down to only being able to put a link around 1 block element, I haven't tested the error with more than 1 block element, only the mis-match of a block element and multiple in-line elements.
If anyone has any work-arounds for this issue in firefox please let me know. It does not appear to happen in IE, Opera, or Chrome.
Also for those that think this is bad markup, it is included to be valid in the next revision of html5, and it is the only way (without javascript/etc) to do these types of links. Firefox is obviously coded to show this markup properly but for some reason has some type of bug that makes it render it differently sometimes due to unknown reasons. Regardless it needs to be fixed or a work-around developed, I could make each element its own individual block and probably fix it, but that's a lot of extra unnecessary code.
Works fine for me in Safari, Chrome, and Firefox 3.5.
I've tried refreshing repeatedly. No luck in duplicating your problem. Have you tried clearing your cache?
Inspecting the element in Safari or Web Developer (FF plugin) does not reveal anything unusual either.
Is N00B BLAZE always the one that messes up every time you see an issue or is it random?
For me, sometimes Firefox doesn't properly load CSS, it's usually all of it, not partially like it's happening to you. For me tho it's loading correctly. Have you recently changed it by any chance and didn't allowed to properly refresh?
When I buzzed your site, the problem occurred for me in FF3.6. Using Firebug to peek at the HTML, the problem was that the lines that display incorrectly have an extra <a> wrapped around the text, within the <span>. Maybe some HTML included in your DB where it should only be text?