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!
Related
I have a problem with a slideshow I coded.
It worked fine before, the website is online since january.
The problem is only when using Firefox 46, other navigators are displaying the elements.
The page with the slideshow : http://www.rotin-file.com/en/accueil
8 buttons appears, in the debugger I can see the 8 containing background images of products, and the absolute containing the title, reference and price, but it doesn't appear in the website...
I tried to change many css properties (with the debugger) to find from where the problem comes (z-index, visibility, display, opacity, ...) but I can't understand why it's ok with Chrome and IE but not ok when using FireFox...
I verified all plugins are desactivated (also adblock is disabled for the whole domain) and tried on other computers with firefox, it never work with it...
Any idea to help me ?
Sorry for my bad english, and thanks for any help.
Two things to do, first remove:
#slideProduits #cntSlide {
perspective: 1200px;
}
Second, you need z-index for your pager, so add:
#ctlSlide {
z-index: 100;
}
But why it does not work in FF46, I have no idea. Guess 'cause css perspective is still an 'experimental technology'.
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 am making a HTML/CSS and jQuery-based file manager aimed at mobile devices. Part of it involves the use of CSS=based modal dialog boxes for various file operations (copy, delete etc.).
I achieve the modal dialog behaviour like this:
<div id="overlay">
<div id="modalBoxControls">[close]</div>
<div id="modalBox">
<div id="modalBoxContent"></div>
</div>
</div>
And the CSS is:
#overlay {
position: fixed;
left: 0px;
top: 0px;
width:100%;
height:100%;
text-align:center;
z-index: 1000;
background: ([semi-transparent png]);
display: none;
}
#modalBox {
width: 80%;
background-color: #fff;
margin: 0px auto;
opacity: 1;
}
I use jQuery to show and hide it by calling .fadeIn() and .fadeOut() on the overlay element.
So far so good - this works great in all the browsers on my dev machine.
However, when testing on my WP7 (Samsung Omnia 7), a rather bizarre thing happens. The modal dialog shows up fine, the page behind it is blacked out. But clicks (or taps) go through the #overlay and activate anything behind it, even though it totally covers up everything behind and it's z-index is 1000.
I also tested this with the well-known "Lightview" plugin from Nick Stakenburg (a well-tested and refined piece of code) and found the same behaviour on IE on WP7.
So it seems like this could be a bug with the browser itself.
Does anyone know any solution for this?
Edit - jsFiddle with example of problem
So, check this out in your WP7 device and see how the files can still be clicked even when there is an overlay over the top of them: http://jsfiddle.net/michaelbromley/CHU76/
If by "activate anything behind it" means input controls like text input then I had the same issue. To be honesty I don't know a good solution. My workaround was disabling input controls during popup is showed and then activating them back by removing disabled attribute. The problem seems not to be related to jqmobile, but supposed to be a general behavior.
OK, so it seems that there may be no "proper" solution to this problem (hey, 24 hours is a long time on SO!), so I have come up with my own hack solution:
I when the modal dialog box is opened, I simultaneously set the "visibility" CSS property of all the elements "behind" the overlay (i.e. links and anything else that would otherwise erroneously respond to taps/clicks) to "hidden" (by using jQuery's .css() function). This means that the page layout is not affected, and that there is now nothing there to be clicked on.
As I said, this is a bit of a hack and will not be suitable for everyone who runs into this problem. However, it works well for me.
Code in jsFiddle: http://jsfiddle.net/michaelbromley/CHU76/1/
Yes, this is clearly a bug in Window Phone 7 and it is not even fixed in Windows Phone 10.
I will report this bug to Microsoft and hopefully it will be fixed.
This is an issue not easy to explain, basically, when you open my site (http://www.securebitcr.com/test/sbcr/) and resize, you can see an "extra" space at the end of the site, is there a way to limit that?
It is like, if I have a div(height:800) but the window itself is sized to 400px, I am able to see the rest of the site, but all the other objects that I'm attaching to the bottom (like the footer) ... you can see all the code at once in my file.
http://www.securebitcr.com/test/sbcr/
Any help is greatly appreciated.
Thanks,
Marco
I didn't test this in any other browser, so you may have to serve these changes to just IE7, by using a stylesheet just for IE7, via a conditional comment.
Set these styles:
html, body { margin: 0; padding: 0; height: 100% }
body { position: relative }
I recommend trying those changes, and seeing if they're fine to apply for all browsers - that might well be the case.
It looks like #content_frame is causing the scrollbar to appear even though you're using overflow: hidden on the parents. I'm guessing position: relative has something to with it, try removing that. It works fine in IE8 and Firefox.
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?