Is there reliable a way to detect such browser capability from the user agent string?
HTML5 isn't a server-side language.
Anyway, there isn't a way to reliably detect UA capabilities, for instance they could have Javascript turned off, addons installed, etc. etc.
You could use some SS methods such as PHP's Browser Detect, but aside from that there's nothing more you can really do. This is not at all comprehensive at all, though!
Everything such as this should really be done client side in Javascript, as you can easily detect what's available and what isn't. There's a number of libraries out there that will do this, but it's very simple to do yourself if you know what you want so using one shouldn't really be required. Furthermore, you should never want to do this based on User Agent strings, as I mentioned before there's addons available that can modify behaviour etc. You should literally just check for the feature you wish to use rather than restricting yourself to a certain version of the browser.
Not reliably — you’re stuck with figuring out the browser version from the user-agent string, and maintaining a list of which browser versions support the API.
You could, however, detect it on the client side using JavaScript:
Modernizr
Mark Pilgrim’s suggested History API detection code
and then do a redirect via JavaScript (i.e. by setting window.location) to let the server know whether the API is available or not. That would be the usual way to redirect to a URL starting with # (as per your comment on rudi_visser’s answer.
This is not server side (so it probably does not answer your question, I thought it would be helpful though):
Have you looked at Modernizr
It is a javascript file you include in your HTML page. You can then use its properties to detect if a particular HTML 5 tag is supported by the browser.
Related
Every now and again I get asked to install something like this on a customer web server, or we're asked if we support BrowserHawk (which we don't).
I'm wondering if Modernizr is something I can point my customers at and tell them to use instead?
I've not used Browserhawk (in fact, I'd never heard of it until now), so please don't take my opinion as infallible.
However, I do know about browsecap.ini, and having taken a few moments to read the Browserhawk website, I'm fairly certain it's also a server-side browser detection tool.
If that's the case, then the answer is 'Yes'. Current best practice says to avoid using server-side browser detection, and to use client-side feature detection instead. And this is exactly what Modernizr does.
Feature detection allows you to do much finer-grained tuning of your site according to what the user's browser is capable of, rather than simply blocking users who have (or don't have) a particular browser. It also allows you to implement specific fall-back solutions for specific features, if required.
Detecting the user's browser from the server-side is a problem because of the rapid pace of change in the browser market; you would need to be constantly updating your browser detection script to cope with new versions.
In addition, users of slightly more unusual browsers or browser shells may not be detected properly by a browser detection script, so they may have trouble with sites that use it, even though their browser should be capable of displaying the site. Also, some users may not provide the user-agent string required to correctly detect their browser; it is blocked by some proxies, firewalls, etc, and some browsers also allow it to be modified, so it can be spoofed easily if a user wants to.
But having gone to lengths to promote feature detection over browser detection, I need to point out one exception to all of this, and that's IE.
Older versions of IE have a lot of bugs. This is different to simply having missing features, because you can't actively check for bugs so easily. If you're having specific issues with IE bugs, then it is legitimate to do browser detection to avoid them. (feature detection is still valid if you're only worried about what the browser supports, rather than actual bugs)
But even in this case, a tool such as browsercap.ini or Browserhawk is unnecessary. IE helpfully supports Conditional Comments which allows you to add specific code for IE without having to go out of your way to detect it.
I need a webpage to display if its being viewed on a PC/Mac, iphone, etc and also what browser its being run on. Anyone know how I would go about doing that?
You typically get this information through the User-agent: HTTP header sent by your browser. If you were using PHP, you'd get this by reading $_SERVER['HTTP_USER_AGENT']. PHP also has a higher level [get_browser][1] API to read this data.
If you're using another scripting language in your web app, you'll need to look up the equivalent.
You can do it using server-side code if the page is dynamically generated. For example, if you're using PHP you can use the get_browser() function. Other language should have similar capabilities, via the User-Agent header sent by the browser.
You can also do it client-side in Javascript. Some details on this process can be found here: http://www.quirksmode.org/js/detect.html
I think this is what you need!
http://plugins.jquery.com/plugin-tags/useragent
http://jasonlau.biz/userinfo/test1.html
The easiest way is to use Javascript, and the easiest way to use Javascript is to use a library like jQuery. jQuery has .browser detection flags that'll give you what you're looking for.
jQuery.support: browser-specific CAPABILITIES (preferred)
jQuery.browser: browser identity (deprecated)
NOTES:
You can try to determine "browser type" on either the client (web browser) or the server (e.g. IIS or Apache; in .Net or PHP).
Simply reading "browser type" (e.g. from an http return variable) is quite often inaccurate. A better strategy is to "probe" for browser type, using different heuristics. jQuery simplifies this for you.
A better strategy still is to determine browser CAPABILITIES, rather than "browser type". jQuery simplifies this, too.
'Hope that helps!
I would like to implement/embed a notes area where people can write some notes on my website.
is this possible with some simple html script? And if yes, does someone know where to find?
Here you can see what I mean: http://bwmbroadcast.org/player/flash?stream=MP4BW489-3A.mp4
Any help would be appreciated.
Thanks
If i were you i would implement a HTML-5 local storage system, http://net.tutsplus.com/tutorials/html-css-techniques/building-persistant-sticky-notes-with-local-storage/
You cannot do this by simply using HTML+CSS.
You have several options:
Use a simple HTML form that submits data to the server and save the notes to a database (you can use PHP and MySQL for this). Form submission can happen through AJAX. This seems to be the right way to me.
Use Javascript and save the notes in a cookie (this way you do not tie it to a user but a browser, I don't recommend this)
Use benhowdle89's solution, you need Javascript for that too, and HTML5 local storage support is not in every browser right now (still, notes will be tied to the browser, so if I visit your site from a different computer/browser, I won't be able to access them).
UPDATE: If you don't want to store notes at all, and only want it for printing, you could check out contenteditable. No need for Javascript here. See: http://html5demos.com/contenteditable
I've just stumbled upon the websockets feature coming in HTML 5, here. At first glance it seems that once Firefox and IE get on board with the spec ajax may be redundant. My question is, in your opinion will ajax (using jquery $.ajax() or even with straight XMLHttpRequest/other) be replaced by this new ws:// protocol?
If so, when should we start changing our development methodologies?
Websockets address a different need than XMLHTTPRequests. The latter is what its name says: a request: You know that you need something (ie. because the user clicked a link, scrolled or whatever) and you retrieve it - and XHR does a fine job doing just that.
Trouble starts when certain events can be triggered on the serverside that are supposed to be pushed to the client in realtime. The only thing that you can do right now is to poll the server on a regular basis - which is a hack that comes with a set of problems. And this is exactly the problem that Websockets are made for: To provide a backchannel to the browser for realtime notifications.
I think Ajax XOR Websockets is kind of a false dichotomy. They address different needs and can coexist peacefully.
When browsers start to implement web sockets.
I'm somewhat skeptical. All major browsers started supporting ajax in 1999, and it gained popularity somewhere around 2005, after the launch of gmail. And we've not even reached that point yet, where major browsers support websockets (add another couple of years).
There's a simple reason behind that delay in ajax adoption: need for websites to support older browser versions. (Remember, how many people still use IE 6&7?)
I would like to know if it is possible to modify Chrome or Firefox display settings, so that it would only show rectangles of HTML DOM objects? What I want to do is to decrease rendering engine job amount as much as possible, so it would only build layout of the page.
People usually refer to this mode of operation as "headless" (i.e. without UI).
Usually there's an additional requirement - to be able to run it server-side without the usual for client software installed. If you're running it client-side, I wouldn't bother about optimization, it shouldn't give you a big win anyway.
Otherwise, try searching using that term. I've seen it asked for several times, but haven't seen a working out-of-box solution.
[edit] just saw http://hg.mozilla.org/incubator/offscreen, which seems to be a headless version of Mozilla.
I wouldn't go as low-level as modifying the renderer. Instead, I suggest you use Firefox's Greasemonkey to replace the elements from the page with whatever it is you need. You'll need to know a bit of JavaScript, but it's not that hard.
However, this will only work on client side. If you want to do this on server-side ( so that it will work on any page a user requests through your own ), my guess is you'll need to grab the page's content in a string, and then modify it using a HTML parser.