Example website
So when you mouseover the projects you should see an rgba background fade in with some text over the existing image. I cannot duplicate the error in Safari or in Firefox. In fact, I cannot duplicate this for the same ones every time, and I can also say that refreshing the page will not necessarily fix the problem either.
Is this a problem in my code or have we come upon a problem with Webkit and/or Chrome specifically?
UPDATE 1
Originally I thought this was a problem with the RGBA background so I tried using a background: black; to see if it changed anything. This didn't work seeing as the line was still present on mouseover.
UPDATE 2
I have considered this to be a problem due to the display I've been using. I'm on the new Macbook Pro with retina display. This could still be the source of the issue, but I'm not convinced it is. I'm yet to do testing myself on another device that isn't a retina display, but I've been told that the lines are still prevalent.
This image will help:
There's something about your box-model that I don't like for this technique. I've used similar hover/fade scripts, but never utilized a negative margin (because it will jack up the box-model), or made the top layer larger than the bottom.
I found a few things that helped it render better for me (I'm wasn't seeing lines, but I was seeing either rounded white corners peaking out or black chisel points in the parent corners). At any rate, here's the few things:
Nix the -1% 0 0 -1% margin (making something 102% wide, then using a -1% margin seems like 100% to me, but relies on all browsers rendering that math the same).
Set the parent and child to be the same W x H (200px x 410px)
Decreasing the radius of the child by one px hid the oddities of the corners for me (again, I think it's a rendering engine thing FWIW); though not having it set should do the job.
I also add .projectItem a:hover to the .projectItem a's CSS declaration, to allow just the transitions to occur on .projectItem a:hover.
This fiddle does the roll-over effect with all the features above added/removed respectively: http://jsfiddle.net/hd4QM/
HTH.
I can't reproduce le problem in Chrome, but from your screenshot it looks like you are zoomed in. Sometimes browsers round off percentages and you might be ending up with a missing pixel, it's best to make it stick to each edge instead of specifying height and width:
.projectItem {
overflow: hidden;
}
.projectItem a {
display: block;
position: absolute;
opacity: 0;
width: 102%;
height: 102%;
background: black;
color: #F6F8EE;
background: rgba(0, 0, 0, 0.85);
border-radius: 5px;
margin: -1% 0 0 -1%;
}
Also, I'm not sure why you're displaying as table, but this might be compounding the problem. Change it to block.
Related
More detail. I am working with a jcink forum. On the forum there is, for example, an element with a margin: 50px 0 parameter.
On Windows this is centered, but on Mac computers, specifically, it's positioned too high. It's difficult to troubleshoot because it is not a Safari issue or a media query issue, so I can't simply change my browser window (or use developer tools to emulate resolution) to check the issue, as I'm on PC. I have a friend who has an apple computer that I can remote into and occasionally troubleshoot on.
I notice also that if I completely remove margins from the element, on MAC it sets right against the top of the container, but on PC there seems to almost be a 20px or so of padding.
Similar to this issue, in the surrounding element there is less space (margin) on the bottom on PC versus Mac. When I add 25px, for example, it looks fine on PC but adds too much on Mac, respectively.
The overall question is: why is CSS rendering different on Mac than PC and how do I standardize this so that the changes are consistent? Only a few users on this site have Macs but it this should be working regardless of the operating system.
I am adding both the forum this is affecting and the code in question. '
Here is the link (just click the checkmark to get past the first page):
https://colu.jcink.net/index.php?showtopic=5560
The header area with the name "Guy Gardner" is what we are looking at. If you are on a PC it is properly aligned. If you are on a Mac, it is not.
PC, where it is formatted correctly: https://i.stack.imgur.com/lDtPz.png
The container in the top bar with the post header information:
height: 150px;
background: rgba(0,0,0,.8);
background-image: radial-gradient(rgba(255,255,255,1), rgba(0,0,0,1)), url(https://us-east-1-02860049-view.menlosecurity.com/c/0/i/aHR0cHM6Ly9pbWFnZXM4LmFscGhhY29kZXJzLmNvbS85NzQvOTc0NjgyLmpwZw~~?b=GyXJkglY&k=4gWbxECk-JP1jGISJKN_BinYM4QYfjipF4RFQU7liIE~);
background-size: cover;
background-attachment: fixed;
background-blend-mode: multiply;
color: var(--mgroup);
font-family: 'DC Fandom';
font-size: 2vw;
text-align: left;
text-transform: uppercase;
text-shadow: var(--colour4) 1px 0px;
letter-spacing: -1px;
overflow: hidden;
z-index: 3;
border-top: 10px solid var(--mgroup);
}```
```.ecmpost .ectopbar {
padding-bottom: 25px;
}```
One of the issues is that the padding (on the 1920 media query at least) adds too much padding on Mac, though on PC it's perfectly aligned.
Another issue has to do with the name on the left side, for example "Guy Gardner." is to high on Mac but centered (mostly) on PC.
```.topbarname {
padding: 50px 0px;
z-index: 2;
position: relative;
display: inline-block;
letter-spacing: 0px;
margin-left: 120px;
}```
(I don't prefer using absolute/relative positioning, someone else wrote this code, but I did confirm this was not the issue)
I attempted media queries, but this isn't a browser size issue (I thought it was initially). I found it was only affecting Mac users.
I found the solution to the issue at hand. First, I did need to apply a CSS reset. I needed to do this because chrome has a default 8px margin. It took some time to realize that this margin was not displaying on chrome in mac for some reason. I used this reset and studied what each element was doing before applying it: https://github.com/necolas/normalize.css/blob/master/normalize.css
Secondly, I found that there was also an issue with the way the line-height was being rendered with the particular font being used on the website (even though the reset did apply a 1.15 line-height fix as well). As a result it caused space at the top of the font in the PC version of Chrome while it did not render in the Mac version of chrome. This, ironically caused an 8px difference, which lead me to believe it to be a default margin issue, even after I had applied the margin reset to the html/body.
To fix the font issue I ran the font through a web font generator that converts system font for web font use, and made sure to select the "Fix vertical metrics" option which erases the extra line-height space. Transfonter was the site I used to do that: https://transfonter.org
If anyone has anything else to add that I may have missed, please let me know, but these steps fixed my problem. Thank you.
When looking at inconsistent OS or browser issues, remember to check your font and the line-height.
I have this div :
<div id="trees"></div>
Formatted with this css:
#trees {
width: 100%;
position: absolute;
top: 37%;
height: 40%;
background: url("/img/Tree.png") repeat-x;
background-size: auto 100%;
}
It works fine in all the browsers I tested, with this result:
Except in IE/Edge, where it looks like this:
Trees with color glitches:
The weirdest part is that this issue does not affect any other divs with similarly configured background images like the train tracks or the mountains... I have search a lot on this and couldn't seem to find an answer anywhere. I also tried to convert the image from png to gif and I got the same result. How would I fix this for IE/Edge compatibility?
Here is a codepen reproducing the problem in Edge: https://codepen.io/darthmooguy/pen/gmNWwg
I was having the same issue as you, and whilst this doesn't resolve the cause of the issue, I've found that adding transparent padding to the edges of your image and increasing the background size is a usable workaround in many cases.
https://codepen.io/anon/pen/BRwxbR
Adding the following scaled my background, so set it to an appropriate level.
background-size: auto 250%;
background-position: center center;
Please ignore the colour change - I was also wondering if a specific colour triggered it based on your initial problem, but it did not.
I might look at this further as my workaround here does not actually solve my issue. :)
here is the tree image (png) saved from Irfanview (save with transparency, no compression)...I'm not sure if Irfanview has stripped the Adobe meta data though.
as you can see... the colors and transparency color is completely different from the adobe authored source.
I'm attempting to use the CSS clip and clip-path properties to display a floating pager nav for a single-page website layout. I'm trying to get the nav to change colors based on whether it's on a dark or light background. You can see the intended result in Firefox at http://dannymcgee.net/redesign. I've also duplicated the nav and containers with cleaner, lighter-weight code at http://dannymcgee.net/dev/clipnav-prototype/ for troubleshooting purposes.
This is the way the markup is structured for each section with a different background color:
<section>
<div class="clipper">
<ul class="nav">
...
</ul>
</div>
<article class="content">
...
</article>
</section>
This entire section is repeated every time the background changes. Each section is relatively positioned. The .clipper is styled like so:
position: absolute;
top: 0;
left: 0;
bottom: 0;
width: 300px;
clip: rect(auto,auto,auto,auto);
clip-path: inset(0 0 0 0);
The .nav inside the clipper is position: fixed from the top of the page and has backface-visibility: hidden.
The effect works basically exactly as I'd like it to in Firefox, but is buggy in Chrome and IE. In Chrome, the background images act strangely, and the nav isn't interactable past the first section. In IE, the nav simply doesn't appear at all past the first section. I've seen this exact same setup working correctly in Chrome and IE here (actually, I found the link on an old StackOverflow thread that I can't comment on), so I know it's possible, I just can't figure out what they're doing differently. I'd be pretty satisfied using some sort of shim Javascript or jQuery solution if I could find one, but this seems like a pretty unusual case scenario and I'm not even sure where to begin to look.
After some extensive troubleshooting, I've solved the problem. Basically, clip and/or clip-path are really fragile in Chrome and IE. Most of the problems were being caused by having positioned elements inside the fixed nav. Once I removed all position declarations for everything inside the .nav, it functioned mostly as intended in Chrome. IE is probably a lost cause, so I'll have to design a fallback for it.
Caveat: applying CSS3 transforms to anything inside the .clipper seems to break the background-attachment: fixed for the third section in Chrome. No idea why, but it'll be easy enough to just disable those effects for Chrome.
What worked for me is creating a class for the sole purpose of cliping the section (in this case the header).
.clip-path-header {
clip-path: polygon(0 0, 100% 0, 100% 80vh, 0 100%);
}
Then, using jquery and waypoints removed the clip-path class, bypassing the problem:
$(document).ready(function() {
$('.js--first-section').waypoint(function(direction) {
if (direction == "down") {
$('nav').addClass('sticky');
$('header').removeClass('clip-path-header');
} else {
$('nav').removeClass('sticky');
$('header').addClass('clip-path-header');
}
},{
offset:'60px;' /* or your preferred offset */
});
});
You could also remove bg image by creating another class to set bg image opacity to 0 and adding it to your header on scroll for a smoother feel.
I recently noticed in several webpages, and some of my own, that when they are displayed in Internet Explorer 9, when its not on Quirks Mode, it renders a white line, about 1px, in the bottom of the page. It's like the html tag was with padding-bottom:1px and wrapped in another element with white background (but it's not, and it has no padding). It looks like the differences between IE9 standards and quirks mode shows when determining a wrapping element's width, but vertically. It also feels like the content of an element gets pushed 1px by a previous element, like their content, but, not margins or borders, were overlapping the next element dimensions.
I can't determine exactly what causes it. Sometimes, a page contains 2 tables and everything is fine. Then you need to add a third one, and the line shows up. Doesn't even need to be tables btw.
Sometimes, reseting css solves it. Setting the same line-height we have on body to links:
body {
line-height: 1
}
a, links, visited {
line-height: 1
}
fixes it, but not always. Only thing i can do, is check element by element, disabling/enabling their css rules till it's gone.
I noticed that when there are elements like tables, inputs, textareas, this issue is more likely to happen. 'resetting' their attributes, sometimes, solves it too.
I know it would be easier to provide a code as an example, but like i said, i coudn't determine a pattern for it. I can give you some examples of sites/urls i notice that error (you gotta look at the very bottom of the page and see the difference between IE and another browser, like Firefox):
casinosdelmundo.info, gatosabido.com.br, espanol.yahoo.com, en.wikipedia.org/wiki/Bruce_Beutler, ea.com/command-and-conquer-4, facebook.com (the ones with white, or almost white bg, change body background with f12, developer's tool, and you'll see). I found an example even here at stackoverflow (as today, the main page stackoverflow.com is showing that line too, but that can change since, sometimes the issue appears or disappears when new elements show up or are removed):
this question has the white-line:
Make link in table cell fill the entire row height
this one has not:
FireFox 3 line-height
Check this screenshot, if you still didn't see what im talking about:
the presence of this issue on very established (or not) sites makes me feel it's a IE9 bug and the only definitive fix for it is always use white background, so nobody will notice the white line (the line will still be there though). but thats obviously not the best option. I never found this white line in Chrome or Safari.
So, has anyone faced the same problem and got a better solution?
I'm not sure, cause there is no HTML here, but it is very resemble to standard browser behavior, when it displays inline content. It is due to the fact, that when text is displayed browser needs to leave some space at the bottom for letters and symbols such as: "," , "y" , "p" and so on, cause in that letters there is a part which protrudes to the bottom. You can better understand what I'm talking about when you look at this picture:
example of how inline content is displayed
so if you have some markup like
<body>
<div></div>
<textarea></textarea>
</body>
you'll get that extra space at the bottom. To get rid off it you have to use there either block element, or set to your inline-element a css style 'display: block'
I found a solution to the problem, if an idiotic one: set the toggle of your browser window's Maximize/Restore down to Maximize (= tooltip text; this indicates that the window is in a nonmaximal state). Make the browser window actually smaller than screen fit. Press F11 in this state and there is no white line at the bottom of your screen (Win7 x32 & x64). (BTW, FF dose not have this problem and is the best alternative.)
It happens when you use fractional font-sizes.
For example, stackoverflow uses h2 {font-size: 140%;} body { font-size:80%;}, which results in an total font-size of 112% for h2. Apply that to 16px default size, and you get 17.93px (including rounding errors, hooray!)
Try it yourself: getComputedStyle(document.querySelector('h2')).fontSize
Browsers have a hard time rendering fractional pixels, and thus may get confused and add a pixel at the bottom.
By the way, Firefox has some trouble too. The spacing between the footer lines is off by a pixel.
The fix is obvious: Use integer pixels to declare font-sizes.
Another way would be to apply a :after content to your body only for IE and Edge.
This way you will get rid of the extra white line.
We may require some jQuery too so that the content applies only when you are at the bottom of the page.
body{
position:relative;
width:100%;
}
body:after{
content: "";
display:block;
background-color: #000;
height: 1px;
bottom: 0px;
position: fixed;
width: 100%;
}
jQuery
//add a border to internet explorer
if (bowser.name == "Microsoft Edge" || bowser.name == "Internet Explorer") {
//console.log(" iam inside");
$(window).scroll(function () {
if ($(window).scrollTop() + $(window).height() > $(document).height() - 100) {
$("body").addClass("end-border");
}
else {
$("body").removeClass("end-border");
}
});
}
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.