I'm a novice of JS and I'm trying to get this result (https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js_popup) but I've got some problem with the mobile view of this code...it works good on every other devices but not on iPhone (x, 8, etc). How is it possible?
function myFunction() {
var popup = document.getElementById("myPopup");
popup.classList.toggle("show");
}
If the problem happens exactly on Safari, it might be due to the missing cursor: pointer; in your CSS.
Safari doesn't like to fire your functions on HTML elements that don't follow certain conditions.
By the way, even if they do (according to my personal experience) it's not guaranteed that your listeners will actually fire.
It happens due to the fact that browsers like Safari or IE seems to be more about a good joke than a good browser.
How do we deal with that?
Well, IRL we mostly use some libraries (for instance, Vue or React) that perform cross-browser optimization better than we do.
For your simple use case, you might want to convert your "myPopup" element into a zero-styled button.
All major browsers tend to work more or less ok with buttons.
Related
EDIT by Phrogz: This appears to be a problem with the framerate of jQuery animation when this particular complex CSS is applied. See the video at the bottom for an example of the problem.
I think is hard to copy and paste the whole code here. So I've create a fiddle for this.
To be honest, CSS is not so important on this (I putted it for have a decent grid). I also removed many functions from my original version, in fact they aren't so important.
The only one that works is by clicking on the buttons + Tracks (which call addTrack()) that adds a new track/line in the grid. Tested on Chrome, IE, and Firefox < 4 version. There isn't much problem. It's really rapid and fluid.
The problem is on Firefox 4 or 5. It's really slow to add the new track/line. It's fast like a turtle.
What the function done is to clone (copy with handler) an element trackOn, which is already written in a hidden field (tracklistOff) and add it (insertAfter) applying a fade effect. (thats means a new line in the grid).
Why this behaviour on Firefox? Too many elements to browse on the DOM I suppose. I need to get rid about this slow attitude... so what can I do?
EDIT
You can hear the difference about Chrome and Firefox (5, last version) on this video. Try to hear/see the difference between clicking on mouse and add new line (with the effect). It's too frozen (also when I try to add more tracks quicly).
Still a problem for me, any suggestion will be appreciate :)
This is not very slow for me. On my computer running Firefox 5 I can add many tracks in less than a second. What performance are you seeing? ("Fast like a turtle" is not a very quantitative measurement. :)
When you have trouble with JavaScript speed, profile it, using the Developer tools for Chrome/Safari/IE or Firebug for Firefox. Here's what I see when I run the profiler on your JSFiddle and click on the +Track button twice:
From this we can see that most of the time is spent in some set function from a mootools library. Since I don't see this library included in your code, I'm assuming the profile is tainted by JSFiddle.
So, we create a standalone test case without the unnecessary CSS and profile that. Now we see this (for several presses of the +Track button):
Almost all of your time is spent in the clone() function.
So what can you do about it? You could try pre-creating the HTML string (in JS) for a template row, and instead of using 'clone' try creating that with:
$(templateString).hide().insertAfter(...).fadeIn(600);
would it be ok if you get just the last element?
something like:
$('.tracklistOff div:last-of-type')
.clone()
.hide()
.insertAfter(($(param).parents('.trackOn')))
.fadeIn(600);
or you could addClass(last) to the last element to get only one
I just tested your fiddle on the following browsers and they all worked well: FireFox 5, Opera, Google Chrome, Safari & IE9.
There were no speed issues but each browser handled the fade slightly differently however everything else seemed to work fine. Not sure what the problem is here. It could be your computer speed but as you're on this site I presume it's decent.
Where do I place this script in my HTML for it to work? And what changes do I have to make to it?
<script type="text/javascript">
var browser=navigator.appName;
if(browser="Microsoft Internet Explorer")
{
document.getElementById("html").innerHTML="\
<body><p>Your browser is IE.</p></body>";
}
</script>
Could I make a slightly alternate suggestion, skipping the spoofable UA string, and using a Microsoft-implemented (and standards-compliant) strategy:
<!--[if ie]>
<script type="text/javascript">
document.getElementyId("html").innerHTML = "<body><p>Your browser is IE.</p></body>";
</script>
<![endif]-->
To use this put it in the head of the document. I don't think it can be placed inside script tags (since it's based on html comment syntax, not JavaScript).
This uses conditional comments (Quirksmode.org link).
If at all possible, I would suggest avoiding direct browser detection.
Almost every case where someone wants to detect a specific browser (usually IE), it is because there is a particular feature that they want to use which isn't available in that browser, or has bugs.
But browser detection fails as a strategy here for a number of reasons:
You don't know whether a future version of that browser may correct the problem, in which case your code to fix the issue may itself cause problems.
If another browser also has a problem with that feature, you would have to detect that browser as well. Taken to the logical extreme, since no two browsers have exactly the same set of features, you end up having to detect every possible combination of browser, version and operating system.
Browser detection is virtually impossible to guarantee to be accurate. Most browser detection scripts are based on hacks that trigger quirks that only affect a particular browser, and most are pretty un-reliable.
Even just IE detecting isn't good enough. There is a big difference between IE6, IE7 and IE8. And IE9 is just around the corner, which will be massively different again.
So what should you do instead of browser detection?
Detect the feature. There are a number of ways of doing this, but the best solution I know of is a script called Modernizr. Place this script in your site, and your page will be given a bunch of CSS classes and Javascript properties which you can use to determine whether a given feature is available or not.For example, if you want to use gradients on your site, most browsers can use CSS for this, but IE and older versions of other browsers cannot. For these browsers you easily can use a background image instead. Modernizr will give you a CSS class of either cssgradients or no-cssgradients, and you can style these two classes accordingly.
Add the missing features to the browser. This is more tricky, but for certain features it can be done, particularly for IE. A good example is CSS3Pie which is a hack that allows IE to use the CSS border-radius feature (and one or two other features too) which is available in all other browsers. There are whole range of other little scripts like this which can improve the functionality of IE.
Use a library like JQuery which does all this work for you. With JQuery, you can be much more confident that most of your Javascript code is going to work across all browsers.
If you must use browser detection to tell if the user is running IE (and I accept that there are some occasions when it is necessary), then use conditional comments, as per #David Thomas's answer. But do so sparingly, after considering any other ways around it.
if(browser=="Microsoft Internet Explorer")
== for comparison, = for assignment
Place it in the head tags.
I just found out about ie7-js ;
IE7 is a JavaScript library to make
Microsoft Internet Explorer behave
like a standards-compliant browser. It
fixes many HTML and CSS issues and
makes transparent PNG work correctly
under IE5 and IE6.
http://code.google.com/p/ie7-js/
It looks like it's really good, but is it really working (the current issue list looks quite scary)? Have you already worked using this with success?
Another question is how slow the script will make the website in IE ?
In static pages it works pretty well. If you designed a couple of static html pages using modern browsers and standards and want it to be shown correctly in IE6 and 7 this script is gonna help you.
But, and it's a big but, if you add a little javascript to the recipe, this method shows its weaknesses. Anything added later to them DOM or any event triggered afterwards will NOT be affected by this script.
That's it. my one line recommendation is if you have simple and light pages use it. otherwise try solve your problems by looking at the roots!
I think the best answer is: try it on your website and see if it works for your particular code. If it works, and doesn't impact the speed, great, you're done. If it doesn't work, then you're going to have to spend the time to make your site work in IE.
Uhm I'm not sure if anyone has encountered this problem
a brief description is on IE6 any <select> objects get displayed over any other item, even div's... meaning if you have a fancy javascript effect that displays a div that's supposed to be on top of everything (e.g: lightbox, multibox etc..) onclick of a certain element and that div overlaps a <select> your div get's to be displayed as if it's under the <select> [on this case a max and minimum z-index doesn't work ]
I've tried googling and found the iframe shim solution
but I wanted some pretty clean alternatives
or better yet has anyone found a better solution?
since the method using iframes uses around 130mb of ram might slow down poor people's machines
You don't have to hide every select using a loop. All you need is a CSS rule like:
* html .hideSelects select { visibility: hidden; }
And the following JavaScript:
//hide:
document.body.className +=' hideSelects'
//show:
document.body.className = document.body.className.replace(' hideSelects', '');
(Or, you can use your favourite addClass / removeClass implementation).
There is a plugin for jquery called bgiframe that makes the iframe method quite easy to implement.
Personally, as a web developer, I'm to the point where I no longer care about the user experience in IE6. I'll make it render as close to "correct" as possible, and make sure it's functional, but as far as speed goes, too bad. They can upgrade. IE7 (though still quite slow, compared to every other browser) has been out for 2 years (almost to the day!). IE8 is going to be out shortly. Firefox is available for every platform. Safari is also an option (and super fast). Opera is available for most/every platform.
IE6 was released in over 7 years ago. IMHO, there is no reason to still be using it, other than lazy users and incompetent IT departments (or if you're a web developer).
in case anyone is interested, here's some IE shimming code.
* html .shimmed {
_azimuth: expression(
this.shimmed = this.shimmed || 'shimmed:'+this.insertAdjacentHTML('beforeBegin','<iframe style="filter:progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0);position:absolute;top:0px;left:0px;width:100%;height:100%" frameBorder=0 scrolling=no src="javascript:false;document.write('+"''"+');"></iframe>'),
'inherit');
}
ref: this gist by subtleGradient and this post by Zach Leatherman
Prior to IE7 the drop down list was a "windowed" control meaning that it was rendered as a control directly by Windows rather than the browser synthesizing it. As such, it wasn't possible for it to support z-indexing against other synthesized controls.
In order to appear over a DDL, you must use another windowed control, like IFRAME. You can also use a little known IE-only feature called window.createPopup() which essentially makes a chromeless popup. It has limitations, like unstoppable click-out, but they are actually kinda helpful if you are building a hover menu system.
The simplest and most elegant solution to that annoying IE bug is found at: http://docs.jquery.com/Plugins/bgiframe using jQuery.
I reached that conclusion after trying for 2 days to make it work with WebSphere Portal / Portal Applications where everything is dynamic, including the fly-over menu.
There's also the activex method, which I'm starting to explore. It requires creating conditional code to use an activex control instead of a select box for ie6. There's a demo script showing the technique, which is discussed in more detail here.
Update: it appears that MS Office is required for the active-x control to be on the user's machine. In theory, it might be possible to include that somewhere, somehow, but that's getting a lot messier.
I know many people suggested their own tips, but in my case, I just simply hide select using jquery like the below.
$(':date').dateinput({
format: 'dd/mm/yyyy',
onBeforeShow: function(event) {
$('select').hide();
},
onHide: function(event) {
$('select').show();
}
});
I'm trying to create web applications that use JavaScript. I'd like to be able to use animation in these applications. I've tried to use basic JavaScript, but I've decided that the best thing to do is to use a library (such as YUI or jQuery).
I'm running into a problem. On Safari, when I run animation scripts, the animation is very chunky, very blocky. This happens with YUI as well as basic JavaScript. Why does this happen? Are there any good libraries that don't create this problem in Safari, but are also good for Internet Explorer and Firefox (and, hopefully, Opera)?
I have found MooTools to be pretty slick for animations, just a little smoother than jQuery.
I generally prefer jQuery, which I find to be a little more intuitive (in my head anyway), but I would use MooTools if slick animation is the most important requirement.
JQuery has animation, but I don't know what it is like on a Mac (I don't have a mac). If things are going slow, then you are probably making the animations too complicated. Remember, JavaScript is a slow language, and DOM is not designed for animation, so try to limit yourself with respect to the number of animations at the same time. Always ask if the animation is really necessary.
Well, for starters you could use CSS Transformations if the application is Safari-specific. Otherwise JQuery got some built in animations and a big community behind it (and thus, a large plugin repository).
You can download some sample code and check locally to make sure that things are supposed to work. For example, you can get the source code for B&K's jQuery book at http://www.manning.com/bibeault/ (check out the source link) and try out the samples for Chapter 5. If those pages work (locally) for you on Safari, then at least you know your basic environment is sane.
I'm having similar problems, and I suspect there are Safari bugs that jQuery is tripping over. But I haven't yet figured out whether it's me writing sloppy code (with FF perhaps being more forgiving than Safari), or if it's Safari, or if it's jQuery. I'll post more if I get any wiser.
Strange, WebKit (the JavaScript engine that Safari uses) is supposed to be pretty fast. Make sure that you have the latest version, there have been great progress for the JavaScript engines in the Safari and Firefox releases in recent time. Also, I think Dojo and MooTools have faster animations than jQuery, at least in my experience.