I am having issues styling a custom and fancy #font-face on a a link.
The font (Alex Brush) goes outside of its boundaries (by boundaries, I mean the clickable section in this case), which is usually not a problem for browsers. However, I have noticed that when I use a different color for the :hover state, the exceeding section keeps the non-hovered link color.
This appears on Chrom{ium|e} (I am using Chromium 31 on Ubuntu 13.10) but not on Firefox. After further testing, I notice that other strange glitches happen depending on how you play with your mouse and tabs, ...
TL;DR: you can try it online.
Or, here is some HTML you can play with:
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<link rel="stylesheet" href='//fonts.googleapis.com/css?family=Alex+Brush'>
</head>
<body>
<a>!</a>
</body>
</html>
And the corresponding CSS:
a {
font-family: 'Alex Brush';
font-size: 400px;
color: red;
text-decoration: none;
}
a:hover {
color: green;
}
Here is the glitch I get when :hovering the link:
Is it possible to tell the bounding box to include the entire font?
Bonus question: On top of fixing the bounding box for styling purposes, is it possible to fix it once and for all? The use case would be to have a proper clickable section that would include all the text, without using display: block or display: inline-block.
Interesting. I looked at a similar issue last month last month. The exact same bug was addressed there, and I've seen it happen there too.
But in the mean time, this issue seems to be fixed. The current version of Chrome (Versie 32.0.1700.76 m) shows the glyph being properly colored on :hover. Both your example as the example in the link above now work fine. I'm pretty sure the issue will be/has been fixed in Chromium as well.
Check out my original answer if you want to know more about what font-specifics made this bug happen.
Works normally in Chrome
I Don't have Chromium, but I often hear about sites that are buggy on Chromium, I don't know any 'normal' person who uses it which is why I don't test in Chromium
anyway, this is a weird possible solution, but it might work?
a:hover {
color: transparent;
text-shadow: 0 0 green;
}
I had a similar problem in a menu and looked at RoeIn's initial answer, which he linked to, but this put the whole menu alignment out. However, the solution below worked for me:
padding-right: 20px;
margin-right: -20px;
Or whatever dimensions best suit your purpose. As long as the padding equals the negative margin it doesn't put other elements out either.
Ignoring discussions of what a 'normal' person might use for a browser, this problem exists in Safari as well.
Related
EDIT: we found what causes this problem and a solution. Read the choosen answer for more info.
Original question:
I'm experiencing this strange issue where the text is not rendering correctly for some words, displaying totally meaningless words or symbols instead of the words i put in the html, although inspecting the code all is how it should be, no errors in console, no problems of any kind (apparently).
First things first, the problem:
Here is how the text should be displayed on my page:
This is how it is displayed when refreshing:
When i zoom the page in or out it fixes itself until the next refresh.
I use a google web font ("Cabin" for anyone interested) but it seems to not be the issue since i tried different fonts with no luck.
I also include some third party javascript in the page (jquery.js, underscore.js, backbone.js, handlebars.js, foundation.js, jquery.cookie.js, i18next.js) and a bunch of proprietary js files.
I tried to disable them one by one and the problem goes away when i disable all of them.(conflict maybe?)
I tested the page on different pc/laptops in my office, tried locally and online, but the issue persist.
I read a question here on SO (can't find the link) where a user was having text rendering problems and fixed it wit CSS propriety -webkit-transform: translateZ(0); but looks like it's not my case.
For what is worth, here is my HTML:
<div class="footer-story full-width">
<div class="footer-story-row">
<h5>SUGGESTED</h5>
<div class="columns large-6">
<img src="http://lorempixel.com/120/120" alt=""/>
<div class="inline-top">
<h5>This is the title of the article</h5>
<p>by RandomUsername</p>
</div>
</div>
</div>
</div>
And the css involved (not everything):
.footer-story {
width: 100%;
max-width: 100%;
height: 400px;
background-color: gray;
padding-top: 15px;
}
.footer-story .footer-story-row h5 {
color: white;
border-bottom: 1px solid #ffffff;
}
.inline-top .footer-story .footer-story-row h5 {
border-bottom: 0px !important;
}
Now i have no idea how to look for a solution for this problem, because i can't see where the problem generates and can't reproduce it for you to see and play with.
I'm assuming it's a Chrome bug since everything works fine on Firefox, but i can't find anything similar anywhere, so i hope some of you can at least point me in the right direction to find a solution.
Thanks
I was able to fix this by using webfontloader to load Google Fonts.
Instead of:
<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Roboto:300,400,500">
Use this:
<script src="//ajax.googleapis.com/ajax/libs/webfont/1.5.10/webfont.js"></script>
<script>
WebFont.load({
google: {
families: ['Roboto:300,400,500']
}
});
</script>
See: https://github.com/typekit/webfontloader#get-started
Ok so we finally found what was wrong:
Foundation puts text-rendering:optimizeLegibility by default on all <h> and <p>.
Looks like this css property behaves really buggy with chrome, you can read more about the problem here:
Is it safe to use the CSS rule "text-rendering: optimizelegibility;" on all text?
https://code.google.com/p/chromium/issues/detail?id=39017
It looks different from the bug issued above, but it has the same behavior although in different circumstances.
From what we have experienced it happens when:
- you load a custom font from Google Web Fonts
- you load one or more JS files in your page
- you have set text-rendering:optimizeLegibility on text elements and there's an <a></a> inside OR wrapping the text element
it happens really random and it's not easy to reproduce.
The solution was just to set the SASS variables that use this property in Foundation to text-rendering:none !default; and everything went in his place.
Hope this helps.
Wondering if anyone can help with an IE8 issue, I've searched high and low and tried many different things. On a WordPress site for a client, an input text box appears much smaller than it should, and off to the side of the page, as compared with all other browsers I've tested.
You can see a grab of how the page looks on IE8 (on Windows 7) here:
http://perfectitaliano3.fonterra.safecom.com.au/wp-content/uploads/grab2.jpg
If you compare that to the page http://perfectitaliano3.fonterra.safecom.com.au/recipe/potato-rosemary-and-speck-pizza/ in a modern browser you’ll see the width and placement of the search box and filter dropdown menu at the top right is all messed up.
I'm a bit a noob at IE8 issues, but I’ve tried changing the css, patching it with modern.js, html5 shiv, modernizr, all sorts of things, but nothing makes any difference!
If you have any suggestions please let me know, thanks.
Try this
#top #s{
height: 40px;
padding: 0px 47px 0px 5px;
}
Thanks so much for answering #Jenti. I tried your suggestion but it didn't seem to work, although because it's now live I tried it in the developer tools in a virtual machine version of IE8, so one can never be sure ;)
However I've since found a solution, I added the following:
#searchform > div {
width: 500px;
}
#s {
display: table-cell !important;
}
and that seemed to do it. Thanks again and appreciate it.
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='★'/>
I'm working on a site and I have some problems that I hope you guys can help me with :)
If I put bold on my text in the menu it looks too bold in Firefox :S, but it looks fine in Chrome.
In Firefox the double border on the #content container is outside of the shadow effect :S, but looks good in Chrome.
Screen shot on Mac Firefox 5.0.1 and Chrome 13.0.782.112:
This is my project.
I hope some one can help me out with this.
If you have something I better I can do, I will be glad to hear that too :)
Your first issue regarding bold font looking different between the browsers is just because of the way browsers render text differently. There is nothing you can do about it, unless you go the horrible route of using images instead.
Your second issue is not about the border but rather the outline. It is caused because of the way Firefox interprets the outline when box-shadow is applied. It applies it outside of the shadow instead.
You can put the code below in your css to target Firefox and bring the outline back in:
#-moz-document url-prefix() {
#content{
outline-offset: -11px;
}
}
Live example: http://jsfiddle.net/tw16/n8bet/
#1: There differences in font rendering in every browser. You can try numeric values instead of simply bold to narrow the results ( http://clagnut.com/blog/2228/ ). Also read the answer on this SO entry: Same font except its weight seems different on different browsers
#2: remove this line from #content css:
outline: 1px solid #B9BDBE;
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?