I need to make an if statement using Ruby that checks to see if the client's browser support HTML5 or not.
Short version: you won't be able to, nor should you.
Long version: It may be possible, if you do some user-agent sniffing, to identify whether or not the user's browser supports HTML5 or not. But this would take a fair amount of effort to get right. The better solution is to use something like Modernizr (http://www.modernizr.com/) to do your feature detection on the client-side.
It's possible to read the browser info based on the HTTP_USER_AGENT string, but, as mentioned above and many other places, it's also really easy to spoof that info. On the server-side we only cared because it gave us an overall view of the client browsers being used to access our sites.
Trying to react to a browser on the backend and present different content was tried by sites for a while, but it fails because of how browsers spoof other browsers, but don't have the same bugs.
As #Stephen Orr said, CSS is a better way of dealing with it. Sure it's hell and still error-prone, but it's better than sniffing the browser's signature. We used to cuss every release of IE because it broke the previous fixes. Luckily things seem to be getting better as the vendors creep toward toeing standards.
Most features can be detected (with JavaScript), but some kinds like the form-date-feature field is a problem: http://united-coders.com/matthias-reuter/user-agent-sniffing-is-back
It is possible to do Feature detection on HTML5, to detect single features from HTML5 as you need them. There is, however, no way to detect if a browser supports HTML5 as one big chunk - as there is no "official" way to tell if a browser supports all of HTML5 or just parts of it.
< [html5 element] id="somethingtobedazzledby">
Upgrade your browser
</ [html5 element] >
Related
Why HTML5 rocks now ?
If just use one word to answer, I think probably it will be "cross-platform".
You can build products using HTML5 one time , distribute for different platform such as Web and iPad etc.
But after some research, I found that several problems with HTML5 family tech
Not robust : there are a lot of randomness , and not easy to control
Storgage limited : even no clear answer for max size (?) , and sure there are limitation of storage
Not best user interaction : compared with native iOS app
Any other problems you think ?
And if you are HTML5 guru,maybe you will correct some wrong understanding of mine.
The biggest problem for me is that right now HTML5 is not a standard. It's not even a complete specification.
But this has always been the problem with building web applications; everyone implements them to different degrees of completeness, and you have to be constantly vigilant of implementation variations.
If I end up having to maintain multiple versions of the same code for each browser anyway, I start to question whether the "it works everywhere" argument is even sound anymore.
Is there any way or best practice around device fingerprinting for a rails app? In other words. Given that all cookies are blocked, is there any way, with a relatively good degree of certainty, who the person is before they log in?
My assumption: IPs are unreliable for obvious reasons.
We've setup device fingerprinting in our rails app using ThreatMetrix.com
They are sort of expensive, but used by a number of large sites on the web and have built some good technology around this.
I have seen some Jquery open source released for this crop up: https://github.com/carlo/jquery-browser-fingerprint
But have not tried it.
Check out Fingerprintjs2. It is quite useful in trying to uniquely identifying a browser.
Even if all cookies are blocked, javascript can pick up plenty of device attributes.
I'm looking to revamp our mobile site with something simple for phones below the ambiguous smart phone category and something a little more interesting for the phones above this category. I'm not interested in WAP/WML for this project. I'm building a ASP.Net 4 MCV 2 app and using MBDF
What I'd like to know is how best to define this differentiation when using MBDF? Screen size, Javascript, SpportsTouchScreen etc. are all in MBDF along with others but I'm not sure where to draw the line and where the data is most accurate for the broad number of devices.
What do those of you out there developing for this spread of hardware & software split on?
Thanks,
Denis
P.S. I've done my research on xHTML MP1.0 - 1.2 and the best practises for implementation to ensure broad coverage but I don't want to restrict the newer phones out there to what the base line can see.
I personally use simple mobile browser dedection script and limit max screen width to 240px. I also use simple AJAX and JavaScript calls too.
Above setup works fine for 90% of my visitors but my sites aren't business critical sites.
You can try http://wurfl.sourceforge.net/ but .net api is not as good as PHP one
So after a bit of testing myself I think I'm going to stick with testing if they support JavaScript and Touch using the MBDF. This line in the sand isn't perfect but it seems like the best out there to me.
Here is a neat little tutorial on Browser Detection using JavaScript
Browser Detection
this is quite a difficult topic by all accounts. I am building a website that requires users to upload large (multi-GB). What is the best way allow users to upload a file on a website and allow the file upload to be resumed should it fail? What is the way to write this in rails?
Any ideas greatly appreciated.
Max.
No browsers support resuming uploads.
From my Googling, Flash doesn't seem to, either.
Though I don't know enough about Java to say it's impossible, there don't seem to be any pre-rolled upload solutions that support this method.
In short, you would have to code your own out-of-browser/plugin solution. If that is not feasible, you may have to abandon this feature. Sorry!
EDIT: Actually, after using a better search query, here's a Java solution that seems to support this through partitioning the initial file: JumpLoader. Here is the documentation page for resuming downloads. Best of luck! (You will note that there are purchase links - this is only for an unbranded version, and for the source code. You can use the JumpLoader branded version for free.)
No browser support this, In fact this cannot be done over HTTP.
You will have to write your own java applet, ActiveX control or WPF browser application to achieve this. Any of this will speak to a TCP server listening on the server side to achieve pause-and-resume upload of file.
Six years since you asked, but for future viewers, take a look at ResumableJS. It uses HTML5 File API to break uploads into chunks. They also include a RoR example for accepting the upload.
I'd like to use a non-standard web font to improve the appearance of my HTML.
Is it preferable to embed a web font or use something like sifr?
My understanding is sifr is a flash-based viewer for vector fonts but I've been reluctant to try it because it seems somewhat complicated.
There does not seem to be a lot of encouraging talk about web font embedding (because of legal issues) so maybe sifr is more of a standard way to do this?
Any feedback would be appreciated. Thanks.
Web fonts are supported in Safari 3.1, the upcoming Firefox 3.5 and the upcoming Opera 10. Internet Explore has supported a (different) format since IE4.
At this point, the biggest problems with the implementation in Safari, Firefox and Opera is that they require you to upload the original font file to your web server. For many fonts, this would constitute a violation of the license you received from the type foundry. Therefore, web fonts right now are not an appropriate solution if the type foundry has not given you permission to use them. However, there are freely licensed fonts available.
This leaves us with roughly three other options: images, Flash, and JavaScript-based solutions. Images are often preferable in that they have minimal impact with regards to browser quirks and performance, however dynamic image generation in, say, PHP often does not look as good as other solutions. You could of course manually create images in Photoshop, but that would usually defeat the purpose.
sIFR uses Flash to render the text, and is quite flexible in that you can select the text, change it dynamically, and have some control over the styling of nested HTML elements. Hoefler & Frere-Jones has given sIFR the OK, provided you pay for a server license and take all possible measures in limiting the sIFR Flash movie to your domain name.
Cufón is a purely JavaScript solution that has implemented its own rendering engine, which is insanely clever. At this point its not as flexible as sIFR, and its legal issues are still unclear.
That said, images, sIFR and Cufón are all hacks, and we need proper web fonts yesterday.
(Disclaimer: I'm the lead developer of sIFR, so I might be somewhat biased.)
You could also consider the JS alternative(s). However, for best cross browser compatibility you're better off using images and perhaps a background-image and text-indent CSS trick to replace static text with your images.
The technique I mentioned above (and others) can be read here: http://css-tricks.com/nine-techniques-for-css-image-replacement/
Something to consider:
For every visitor who sees your 'better looking' fonts, there are just as many who won't due to having an incompatible browser or disabling that feature. Having just the right font probably isn't the most valuable design change you could work on.
Written from my mobile browser which doesn't do embedded fonts.
Note that CSS3 Web Fonts module, which defines font embedding is still a Working Draft. Indeed, the practical support of font embedding isn't good. I'd say it's better to wait another 2-3 years.
Also worth nothing: TypeKit, a service that gives you a line of JavaScript to abstract all of this away.