Inputs like textboxes and checkboxes work extremely slow in the bootstrap modals. When user types some text, cursor is moving but the letters appear only in several seconds. The same behavior with checkboxes, checked/unchecked state changes only in several seconds.
Can be reproduced only IE8 and Vista machine.
does anybody has an idea why it happens.
here is a video with an example.
you can try it here in the login dialog.
not 100% why, but ie8 has extreme problems rendering sites using position:fixed in their layout process. on random element(s), position:fixed shouldn't be too much of a problem, but typically when this issue arises it is because it is being applied to elements that are used as wrappers or containers, that usually are full of content.
for whatever reason(s), ie8 has a mighty difficult time rendering here...its best described as delayed response(s), where the user isn't sure if they actually interacted with the site, because nothing happens after their action(s).
changing fixed to absolute is the best answer in these cases, most of the time. i know there are situations where this will not apply, but everytime i've faced this issue, the element(s) had wrapper element(s) with position:relative set, and swapping out absolute for fixed could not have been easier.
ideally for me, is to serve up the different setting in conditional comments, which also is quite useful just in case changing from fixed to absolute breaks something(s)...you can target them in ie(s) and ie(s) alone with the cc's.
Related
This is a rather odd question, particularly hard to search, as I'm not quite sure what's happening. I've designed a page with bootstrap and prepared it to scale accross many devices using the lg, md and sm prefixes and all that jazz.
The issue happens when I try to scale it in small screen sizes. The buttons, usually are list items, links and buttons. I have a section of tabs as well.
When they scale to a smaller screen they simply stop working, the tabs won't change... etc...
I figured it out, turns out I had the footer covering the rest of the page... that's why I couldn't click anywhere except the nav...
When in doubt alway use the inspect element... I guess that's the lesson to take away from this.
So I've been working on browser compatibility. Unfortunately, when I first designed my site, I desigend the CSS aesthetically for Firefox only. Now I'm having all sorts of trouble trying to get it to look good in the other major browsers. However, when I fix the CSS positioning such as floating a box object to the right, IE8 forces it left. I checked my code on W3C and it's okay semantically. I use little to no javascript. It's a portfolio website. The screensize shifts everything around no matter what browser, yet there is no perfect CSS for this so how does one get things to stay in place? I'm not too familiar with JQuery, but this seems to be the closest I can get to an answer. Where would I plug this into my site to see if this works?
I just found out about this really cool plugin (new for me, old for some of you maybe) and it works like a charm upon implementation, but only in regular computer browsers. When I try it on my android phone, the css3 animation of the dropdown moves really really choppy, just like its dropping frames. How can I fix this problem?
Here is the plugin I am reffering to:
http://responsive-nav.com/
They seem to have done a really nice job with the plugin, I would say the largest cause of the drop of frame rate may be because you are repainting the entire screen. If you would like, roll your own side navigation but make it go over the existing web page rather than move all the elements on the screen.
EXAMPLES OF SIMPLER MOBILE NAV without repainting
http://fringewebdevelopment.com/
http://www.sony.com/index.shtml
As a further step you can also get rid of the javascript and just do plain CSS and see how that works for you, an example of using checkboxes and labels to control the side nav can be found on my site (just inspect the code) - www.aktof.ca . Hope this helps!
I am using text-shadow for all p and headline tags (2px white glow for better readability), everything works fine until page is scrolled and javascript changes absolute positioning on one element to fixed - which I want to stay visible.
Is there any way apart of changing style for opera to make it scrolled smoothly? overflow:auto is not working in this case...
Thanks
it's hard to say 100% without seeing the code, but I guess that the way you've styled this page makes Opera do a lot of reflowing and painting when it is scrolled, and the combination of styles will make this a very expensive operation. (It would be nice to see a jsfiddle or get a link to the actual page, this would also make it simpler to advice on possible workarounds).
There are various fixes you could try - like keeping the element you want on-screen styled with position:absolute and move it from JavaScript after scroll events, or simply avoid setting position:fixed in Opera and letting the element scroll away for better scroll performance.
However, I'd strongly recommend that you first report a bug to Opera. Why?
The reason and the genesis of the web is collaboration. It may not be obvious to (understandably) frustrated web developers struggling with browser bugs, but they have a responsibility for helping browser vendors improve when they find problems, thereby contributing to moving the web forward. A minority browser like Opera admittedly has less development and QA staff resources, but to some extent support from the user community and "normal" web developers makes up for this and makes it possible also for smaller players to develop in the Web ecosystem. I think that's one of the web's strengths and the real reason why no single corporation has been able to dominate it.
So please report your issues and problems :)
This is a problem with Opera, not any way you've written the code. Opera is a gigantic steaming pile of doo-doo with almost no market share, and you should use another browser.
That's basically all anyone could tell you here, unfortunately. I understand that everyone loves their browser of choice but some just don't handle these things well. Other examples: browser with a poor javascript engine rendering animations erratically and jerky, etc.
On a dynamic site of mine I faced a problem that consists in the following:
In Internet Explorer 6 after changing the size of the div element with the help of JavaScript, its child elements that are 100% in height do not refresh right away (ie. do not stretch to their new size) but only when the parent div is clicked. It seems to me that the document needs some update. I'd like to ask if there is sort of a command (like that in Flash) that updates the document after some dynamic changes get happened? In brief, how can this problem be settled?
Requiring reflow in IE6 is a very common problem with a massive CSS/JS base. Usually all you have to do is change a parameter on the element that requires a reflow, like, for example, set display:none and then back. This will cause browser to reflow objects in and around current object. Most of the time you will have to do it from JavaScript. If you don't want to do display, try changing height/width or add/remove flow or clear parameters. They all will cause reflows of the page.
However, most of the time if you are running into reflow issues in IE6 it usually means that either you have way too much CSS on the page, or you are using CSS for things it shouldn't be used for (like laying out elements on the page that in HTML go in a wrong order, i.e. element1, element2, element3 in HTML; element2, element1, element3 in display). I would suggest cleaning up your CSS and most of the times, reflow problems will go away.
If you have to click on it to refresh, then why no try to simulate a click, after the size update. Simulating mouse clicks in JavaScript
I know that I have been burned (more than once unfortunately) to have returned invalid xml for an ajax response. IE in particular is very non-forgiving in this respect. It might be worth validating the response just to be sure. In some of my cases, the bad XML caused JS to fail and not "seem to work".