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?
Related
Recently I have been having issues with Firefox compatibility, I was working on a website on chrome and when I tested it out on Firefox my divs got messed up. So after trying to figure out what the issue was, I came upon a thread about my issue! Apparently, Firefox recognizes the whitespaces in my HTML code and spaces out my divs accordingly. So, is there a way to make Firefox ignore the whitespace in my code? I don't really mind dealing with all my divs on one line but it would be much easier to organize if I could space out my code. Also, if this is possible, what are the downsides, if any?
This is the thread I was talking about. Thanks Drkawashima!
You can set the font-size of the divs to 0 and the font-size for every element inside the divs to 1rem:
div {
font-size: 0;
}
div > * {
font-size: 1rem;
}
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.
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.
I'm working on my new online portfolio at http://asbjorn.org/ny/, and I've come across the weirdest issue!
Every time you open the page for the first time, the next and previous buttons for the slideshow don't appear. If I open the inspector, they pop up immediately, and they also appear when reloading the page.
They're pretty standard html elements, not added dynamically, so I have NO clue as to why this happens! Of course I can't have the site visitors reload the page just to see them. :/
I really hope someone can help me! :)
update: seems like it's a chrome only issue. For me it happens consistently in chrome on both Win7 and OSX. A few of my friends also has the same issue (probably in chrome on osx)
So I'll take a stab at an answer. When I see the problem in Chrome 22, and I bring up the inspector, I note that the #previousLink and #nextLink divs have a width of 0 in the broken state. Try setting an explicit width for these in your CSS, or make the nested image use display: block.
#previousLink { width: 31px; }
#nextLink { width: 37px; }
or
#previousLink img,
#nextLink img { display: block; }
I think the combination of these inline items and your overflow: hidden rule are biting you. I think. This is a tricky bug!
A few days ago I re-skinned my website. Development of this skin was primarily done using safari, and as expected, it all renders fine using firefox and opera. I've had to make a few small tweaks for IE7, but nothing much, except for one problem...
The date indicators for a post are cut off in IE. This problem seems to occur only on nested span tags inside a left floating div. I think I need the floating div's in order to layout text on the left and the right side of the screen.
Do any of you know how to stop IE7 from clipping my text?
Edit: I have sort of given up on this problem. My scripts now check for IE7 and feed it somewhat simplified HTML that its limited engine can handle. It works in IE8, so, for now, just the special case for IE7 will have to do...
In most cases where IE6 or 7 clips off the bottom of text, just add:
line-height: normal;
to the CSS rules concerned. Should fix it nicely, but as you'll understand, it expands the box too.
There's a hack I figured out that fixes the problem of cutting off text in IE. I noticed the last line in my headline was the only one being cut off.
My original CSS which was cutting off the last line in IE7 but looked fine in other browsers:
h2 {
font-size: 22px;
line-height: 1em;
}
See image of problem here: https://skitch.com/pablohart/f4g3i/windows-7-x64
The fix I did included simply adding padding to the bottom and then taking that padding back with negative margin. Like this:
h2 {
font-size: 22px;
line-height: 1em;
padding-bottom: 5px;
margin-bottom: -5px;
}
See picture of fix in this image: https://skitch.com/pablohart/f4g4h/windows-7-x64
The problem with line-height: normal; is that it takes on the default line-height for the font, usually 1.3em.
Try adding overflow: visible; to your .postdate class. Maybe that helps.
I had a similar problem. I changed my span to a div and the problem was resolved. I think IE7 might have an issue processing line-height on a span. Haven't confirmed that to be the issue. There were other CSS elements. (Working on someone else's code.) But changing from span to div (block) resolved the issue.
for the .bigdate class, try replacing margin with padding; seems to me that this has something to do with IE's margin-handling.
Adding a specific height to .title fixes it for me (in IE6):
.title {
PADDING: 0 10px 0 0; MARGIN-top: 0.3em; FLOAT: right; height: 1em;
Despite being unable to test it on my current machine: I would suspect that it's a hasLayout bug. The methods of dealing with it are listed in the "properties" section of that link.
In my experience its invariably the bottom of the text that gets clipped and that too basically because of the overlapping divisions. If you are able to ensure that the divs don't overlap then the issue does get resolved . That apart adding overflow: visible does help at times.
Try adding
div.postmeta { height: 100px; }
div.postdate { height: 75px; }
Arbitrary height value... but you'd know the exact height you want. That should keep the text containers from clipping in IE7.
I think the problem is with the padding. I tried removing a "padding: 3px" style and it worked properly. Previously it was not showing anything. Paul Hart's answer showed me that.
Probably also removing/overriding margin properties may also help.