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.
Related
Community, Firefox has a new function . Called fingerprinter (settings under privacy).
I know what fingerprinting means. What I like to ask you is: what is Firefox doing exactly when this feature is activated, what data is being changed by this setting?
Because when you do a test on panopticlick.eff.org, in both cases, active/inactive fingerprinter setting, you still get a unique html canvas hash assigned to you.
So, what is firefox exactly "preventing" or "changing" by this fingerprinter setting then?
And can you give your short opinion: is it better to activate this new fingerprint setting, or not? If you like to be "less" easier identifiable during web surfing? I have read differing opinions. There are those who say if you block fingerprinting you look more "unique", and those who say, If you allow fingerprint, you "less unique" in the masses...
Thanks all!
Browser finger printers are a subset of trackers that allow sites to gather a certain amount of information about a visitor’s browser and device, even without the use of a cookies.
Firefox new feature can help you block fingerprinting coming from many ad trackers.
Keep in mind blocking fingerprinting may cause some sites to break or make them look strange, or the layout will be different. It can also slow down your online experience.
Assuming I already have valid code, is there a tool or plugin that I can use to evaluate my website code and highlight areas where different browsers could potentially display the code differently? I am aware of websites like browsershots and I have VMs to test, but I'm wondering if there is something to shortcut the process by looking at the code and warning of well known cross-browser compatibility red flags.
For example, when using CSS which is not universally supported yet. The following is valid CSS 2.1:
display: run-in;
Validators which are aware of CSS 2.1 will pass it with flying colors, but really, a red flag should be thrown, indicating that it does not work in Firefox 3. On the other hand,
border-radius: 10px;
is actually pretty well supported in updated browsers, even though it is CSS3.
This is new in Javascript, but is also passed by validators:
getElementsByClassName();
but it would be better if a warning popped up notifying me it won't work in IE8.
Another example is well known rendering bugs, which can be triggered by weird (valid) situations. I understand there is no replacement for opening up the website in every single browser on every system to really see how it works, but I am just wondering if there is some tool that can help check that I'm writing interoperable code as I go, so that I can test more frequently in the development process and spend less time working out bugs later.
Unfortunately, the answer is no.
I once started looking into creating a tool exactly as you describe. The reality is that most libraries like jQuery actually make use of browser incompatibilities and different interpretations of standards (or ignoring the standards).
So, if you're using any of the standard libraries then you'd receive tons of warnings and actually get very little out of it. The amount of spam simply will shadow the actual bug you might have introduced.
What matters more is whether the incompatibilty actually affects the end result. Hence we went for what-you-see-is-what-you-test method instead of static code analysis.
Is Google Analytics capable of detecting a visiting browser’s level of HTML5 support? I'd like to know what percentage of my visitors browsers are HTML5-ready. Currently the only way of getting this data is to analyse the visitors' browser stats and then try to find support information on each of the browsers own help pages. As you can imagine this is somewhat time consuming and frustrating.
If support for HTML5 tags is high then it will strengthen my case to start migrating to HTML5 semantics - my 'superiors' either don't understand what it is or fear it is witchcraft.
If you read this example code, you can use your own javascript to detect whatever client-side features you want (any specific HTML5 feature), set a custom variable in Google Analytics and then track that from your Google Analytics reports.
Based on the wording of your question, you should realize a couple of things. First, HTML5 is not a winner-take-all thing. It's not there or not there. It's a collection of hundreds of features and different browsers have implemented some of many of those. For example, IE9 has implemented some major HTML5 features, but not implemented others (like CSS3 transitions). So, using the above technique, you would need to figure out which specific HTML5 features you wanted to track, devise a feature test for that feature (the article suggests using modernizr for the feature test since many tests are already built-in) and then record that result to a GA custom variable.
Secondly, most applications that use HTML5 use it as an improvement in the user experience (when available) and will still work with some other mechanism when the HTML5 feature is not available. This allows one to continue to support viewers using older browsers (such as Firefox 3.x, IE, etc...). So, usually you shouldn't really be thinking about all or nothing on HTML5.
If you're waiting for 99% of your viewers to have all the HTML5 features you might ever want to use in their browser, you will wait a long time. But, if you want to start offering a better user experience now to those users who have the desired HTML5 features while still offering a reasonable user experience to those who don't, then you can start using those new HTML5 features now.
As for convincing management, the idea of an improved user experience for those that have the desired HTML5 capability while still continuing to support all the other browsers with the "old" way of doing things is a low risk concept as long as you can show that at least some reasonable percentage of your viewers will benefit from the new improvement.
P.S. I also found another article on the subject of tracking HTML5 in GA.
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.
I am learning how to program and my goal is to build a simple functional prototype...I'm at the very beginning.
I am not concerned with the visual design at this stage, other than as it relates to being able to demonstrate the functionality.
My question is: do I need to worry about ironing out cross-browser bugs in the HTML/CSS, or can I do development on a single browser? (Perhaps a better way of asking this is does the back-end programming have any effect on which browser is displaying it).
If you are at the very beginning and only want a functional prototype, do not worry about cross browser HTML/CSS. In fact forget the CSS altogether and focus on printing just standard HTML. Since the visual design will change, focus on the content, styles can always be applied and switched later.
If you need Javascript/AJAX stuff I would recommend using a library like JQuery that has already solved many cross browser problems for you.
The back-end stuff "Perl, PHP, Python, etc" shouldn't care about the browser as it is simply printing text for the browser to render as it will.
The back-end programming will affect the way a given browser displays your page and there might well be two schools of thought on whether you should be picky about the browser compatibility issues.
On the one hand, if you're just finding your feet in web development it might be asking too much to expect to have a standards-perfect, cross-browser site or application every time. It might be better to focus on actually accomplishing a finished result and learning as much syntax and technique as possible.
On the other hand, it might be argued that it's a good idea to get into the habit of adopting good practices now and recognising the sorts of things that are going to give you headaches... probably when you view your page in Internet Explorer. This takes more time to reach a finished product, but it would teach you good habits up-front.
Really it comes down to your own approach and preferences. Do you want to be detail-oriented and turn out a polished result in a longer period of time, or would you prefer to just get to the finish line and identify issues on a case-by-case basis?
Do car prototypes have a working stereo, leather upholstery, chrome rims, dice, and other random stuff which does not demonstrate the functionality of the newly-designed car?
My rule of thumb is that if it takes you more than 10 minutes to make it look acceptable to others (I'm completely fine with a disgusting design when prototyping), you're spending too much time on the aesthetics and less time on the actual clockwork.
What good does a "pretty-looking" site do if it has no functional layout?
This depends on both your audience and on your tooling. If you are trying to support all users on all browsers, then you will certainly need to do testing on those browsers (although actively developing on those browsers may not be necessary), whereas if you only need to support WebKit-based browsers (Chrome, Safari) or WebKit-based browsers and Firefox, that is less testing that you need to do.
It also depends on your tooling. For example, if you are writing directly in HTML and CSS, then you are much more likely to run into browser compatibility issues. However, if you use a tool such as GWT, which can generate browser-specific output automatically, there are fewer such issues to deal with.
Note that you can use Selenium (aka WebDriver), to automatically test your code on multiple different browsers, even if you only actively develop within a single browser environment. That way, you can know if you've broken something, but not have to constantly manually test in multiple browsers.