We Keep Coding

how to detect browser supports HTML5 microdata API

I use the following code to check for HTML5 microdata API support
function supports_microdata_api() {
return !!document.getItems;
}
but this is not working properly. How can I solve this problem?

Use Modernizr, so you can test it like this:
if (Modernizr.microdata) {
// Yay, microdata is supported!
}
Nonetheless Chrome and Safari don't seem to support this semantic syntax anymore.

Fallback for localstorage using modernizr

I am using localstorage for store data and it does not work will on IE7. So I am using modernizr for detecting its support to browser. But I want to add fallback on IE7. In IE7 case where can I find fallback function for localstorage for IE7. I mean what need to done when it falls into false condition.
if(Modernizr.localstorage) {
alert(0)
} else {
//function
}

Modernizr doesn't actually shim anything, it just detects wether or not a feature is supported. You can combine it with yepnope to conditionally load the local-storage-js polyfill to fallback appropriately.

How to get browser "Document Mode"

I am developing some kind of JavaScript library. And i cause the problem that i have some specific issues for:
Browser : IE8 / IE9 and Document Mode : IE7
I found the solution, but i don't want to use it in all situation, and want to use it just when i have the situation described above. I know that I can recognize browser by using:
return navigator.userAgent.toLowerCase().indexOf('MSIE 8') > -1;
But i recognize just browser version in such way but not the document mode, and i don't want to use my solution when I have, for example, browser mode IE8 and document mode IE 8.
Is there a way to get page document mode in IE? Thanks in advance.

You can use document.documentMode to return exactly what document mode IE is using.
Meaning that if you have your browser mode set to IE9, but your document mode to IE8 it will return document.documentMode == 8 (while the userAgent string will still show up as IE9). This is particularly useful if your JS ever includes styling changes as it is the document mode that determines how IE renders a page, not the browser mode. Compatibility mode really just changes the document mode (usually to IE7).
In the few cases I've needed to I've just used something like this to differentiate IE's:
if (document.documentMode == 7) {
doSomethingIn.IE7_only;
} else {
doSomething.everwhereElse;
}
Hope that helps some.

I don't know how to retrieve the document mode1, but it may be wise to address the problem in a more basic way. Let's say you wanted to use document.querySelector in your scripting. That would fail in IE8/document mode IE7 Standards. So an additional check for the existence of document.querySelector itself would be the solution:
return ~navigator.userAgent.toLowerCase().indexOf('MSIE 8')
&& document.querySelector; //=> IE8 and Docmode IE7 => false
1 Found a way to check for document mode: use document.documentMode. It returns an integer (so 7 for document mode IE7 standards), 5 for Quirks mode. It will be undefined for non IE browsers.

how to ensure the browser can support **{get X() {}}**

i refuse to use __defineProperty__ and instead prefer the alternative syntax {get X() {}}
However this will not work on IE.
Aside from browser detection, what is the best way i can detect that a browser supports the newer syntax?
Edit: ok actually im not trying to detect IE in particular but redirect those "browsers that do not support get X(){} syntax" to notsupported.html. I believe that there's some way to do it and am working on it but in case someone already has this problem before and had a solution..
Edit 2: btw doesn't that mean that no one (erm other than me) uses the get X(){} syntax since its not supported by all (or not supported by the 5 major browsers yet) ?

As others have noted, you cannot force older (current!) browsers to accept newer syntax. And what would you do with browser detection? Use the old syntax for the old browsers and new syntax otherwise? Then you're writing the same code twice.
Decide on a set of browsers you need to support, determine what features they can all guarantee to you, then limit yourself to those features. That's how web development works.

You want to use an ES5 feature that is not commonly implemented.
You want to use syntax that common javascript interpreters cannot recognise.
There is no way to emulate it.
I recommend you just use
{
getX: function() { ... }
}
If you check the benchmark. Then you'll see using ES5 is 15 times slower. Just stick with ES3.
There is little you can do about this as there is no way to emulate getters in IE8.

Try this:
function browserSupportsGetterAndSetterSyntax() {
try {
return eval('({ get x() { return 3; }}).x') == 3;
} catch (e) {
return false;
}
}

alternative when an older browser does not accept jquery

I have just been altered to the fact that a user of my website is using a very old browser which does not run jquery (in this case Safari 1.x) and as a result can not access the login panel which uses jquery's slideToggle function.
Can anyone think of a fix which detects whether a browser is able to use jquery - and if not make that link go to a different page rather than showing the login panel?

You could a little conditional check like
if(!'jQuery' in window) {
// jQuery is not available
}
or, if Safari 1.x doesn't know about the IN operator (I'm not sure) use
if(!window.jQuery) {
}

I think there are alternative answers to this, but for me, I would have to weigh up the time it will take you to support his obsolete browser (I'm sure there may be other things inside the site), versus the payback to you...

In the plain HTML source code for the the href= of the login link, set that to a plain HTML login page.
Using jQuery, attach the click handler to the link, if this part fails, thats ok, the browser will just follow the href in the link to the plain login page, allowing your old-browser-user to login still.
$(document).ready(function(){
$('#login_link_id').click(function(){
// Your code here
});
});

If you use javascript/jQuery you should ALWAYS ensure your site works perfectly without it. In this case if you have a login popup box; you probably assign a click event assigned after the DOM has loaded.
What you should do is ensure that if jQuery isn't present the link loads a "normal" login webpage as opposed to the popupbox. I use something similar to this:
Log in
<script>
if(!'jQuery' in window) {
$(document).ready(function(){
//assign on click event to loginlink
});
}
</script>
If jQuery doesn't exist then login.html will be opened normally.

Wow, seriously?! Safari 1.x?? Anyhow, try this...
var isJQSupported = false;
$(function() { //shorthand for document.ready
isJQSupported = true;
//your usual code
});
if (!isJQSupported) {
window.location = "http://www.apple.com/safari/download/";
}

To me it sounds like safari 1.X has problems with jQuery internally. Which means simple checks like whether $ exists in the global space or whether $(function) does anything are not going to help.
The most likely root cause will be that javascript throws an error in loading of jQuery itself which will then stop the rest of your javascript code from execution.
There are four viable options here.
Either make the website work with noscript. Replace your login control with pure HTML and postbacks and ask the user to turn javascript off. This option is useful since you won't be fixing the issue for safari 1.x problems specifically.
You can make javascript check for safari 1.X and other non-supported browsers and only load jQuery through script tag injection or ajax if your user is using a supported browser. If the user is using a browser not compatible with jQuery then you can instead use plain javascript.
Get a copy of safari 1.x and see why jQuery breaks. Then fix it and ask for it to pulled into the release of jQuery 1.5. This relies on the fix being something that does can be done without hacking and that the jQuery team agrees is worth adding in.
Ask the user to use a compliant browser.
There might be some more options. I would personally lean towards asking the user to use a compliant browser because supporting Safari 1.x is ridiculous.

This seems like a case where progressive enhancement is needed.
You have to do multiple checks
see if $ exists
see if $.fn exists
[not sure if needed] check if $.support is a function
check for feature support as needed with $.support() http://api.jquery.com/jQuery.support/
At the end of the check, when jQuery reports that features you need are present - the rest of the script can run.
If you're not sure which features mentioned in the support you use, then this might need a single test on Safari 1.x to see what are the values returned by $.support(), but that is what your nasty old-browser-user can do for you (if you prepare code and publish) and report the resulting text. Then you compare the list with other [old] browsers that are accessible and determine features that are required.
The easy way would be to require everything and cancel all scripts if suport for any feature is missing. This will also rule out IE6 and IE7 and opera below 9.something and firefox below 2.0 or including - I'm not sure.

Use a server side language to detect if it's the old safari based on user-agent and load a different javascript file