Anyone using Core/Browser.js?

Written By Olmo Maldonado, on Thursday, February 6th 2014, 6:12pm

On our road to Version 1.5, we’re trying to eliminate some bad practices from our code. One of the things we’ve just gotten rid of, is that a few last pieces of our libraries still depended on Browser UA detection. This has all been eliminated in favour of feature detection. To help us reach a decision on where to go with the Browser module, here’s a quick survey. Reply via @mootools or leave a comment here.

Are you using the Browser module? If so, what are you using it for?

Cheers!

17 Responses to “Anyone using Core/Browser.js?”

  1. Andreas says:

    Yes. Use it to filter code for different browsers.

  2. barryvan says:

    Yep — we use it to display an unsupported browser warning (but not to disable functionality or anything).

  3. Christopher says:

    Same as barryvan. Sometimes also to enable/disable functionality for mobile OS; btw, Windows Phone is not detected.

  4. xrado says:

    I use it to check browser platform and if IE9+

  5. Shrike says:

    Unfortunately sometimes exceptions are necessary for compatibility across multiple browsers

  6. Kristian J. says:

    We are using it in some legacy code.

    Would propably not be a major hassle for us to stop using it.

  7. mcfedr says:

    We use it to show different themes for different mobile devices.

  8. Luis Tar Quince says:

    Not any more, for a year now.

  9. ibolmo says:

    Thank you both.

    @barryvan, by unsupported was it that a feature was missing? If so, what feature was it that you couldn’t feature detect it?

    @Shrike, that’s what we’re trying to find out. I’ve seen some Browser usage that is legitimate, but we’ve been finding a lot of people could/should have done a feature detection. What was your example?

  10. Jade Ohlhauser says:

    We have some code that needs to apply different styles based on IE versions. We have extended Browser to include parameters like .touch which we use a lot to change UI behavior on touch devices. We set that using server side detection.

    Here are 10 examples from many:

    if (Browser.ie) { strText += ’ ‘; } // Case 3211

    if (Browser.ie8) { var event = new Event(event); event.stop(); } // Case 3619

    if (!Browser.touch) { this.stack = new Rpm.Drag.Stack(this.elTable, this.save.bind(this), true); $$(‘.box’).each(function (el) { this.stack.addElement(el, el.getElement(‘.boxTitle’)); }, this); }

    if (Browser.firefox) { sizingModel = el.getStyle(‘-moz-box-sizing’); }

    if (Browser.phone) this.phoneLink(el);

    if (Browser.touch && Browser.Platform.android) { // a long fix for scrolling on android

    if ((Browser.ie) && (h < 1)) { var arrChildren = el.getChildren(); if ($isNonEmptyArray(arrChildren)) h = arrChildren[0].getSize().y; }

    if (Browser.ie8) { // Drag and Drop starts failing on IE8 after a while so let’s reload window.location.reload(); }

    if (Browser.phone) { this.elDiv.setStyles({ ‘left’: 0 }); }

    allowed: function() { return (  !Browser.touch // Case 9907 ) },

    And we use Browser.Request as part of our file upload by drag & drop

    (function(){

    var progressSupport = ('onprogress' in new Browser.Request);

    Request.File = new Class({

    Extends: Request,
    
    options: {
        emulation: false,
        urlEncoded: false
    },
    
    initialize: function(options){
        this.xhr = new Browser.Request();
        this.formData = new FormData();
        this.setOptions(options);
        this.headers = this.options.headers;
    },
    

  11. Graeme says:

    The only bug I’ve ever fixed with browser is a colour one because some old IE8 confused white with transparent

    if(Browser.ie && colour === “255,255,255”) colour = “255,255,254”;

    Also I’ve seen others use this before - any comments on this for a Mootools request

    Browser.ie && Browser.version < 8 && request.setHeader(“If-Modified-Since”, “Sat, 01 Jan 2000 00:00:00 GMT”

    I’ve also used a Browser.isMobile to not load some features, though I question its correctness

    Browser.isMobile = !(Browser.Platform.win || Browser.Platform.mac || Browser.Platform.linux);

  12. Aaron says:

    We use it to often set a class to the body, for IOS/Android and IE which allows us to do CSS overrides where required. It is probably not required for “Core”, but I think it should always be available as a “More” package.

  13. Shrike says:

    Mostly with internet explorer there are rendering problems (different problems with different versions too) working on dynamically created interfaces, that are tricky or impossible to fix with only css (for example sometimes a delay is needed, or an effect doesn’t run smooth)

  14. dreadcast says:

    Though it seems hard to believe, some people are still using MooTools (and loving it). Browser is still used in Element, Drag, Cookie, Request and some of my stuff. For example: * displaying different download links depending on user’s platform, * adding browser/platform name to html tag

  15. Adidi says:

    Can you tell us why did you ask this question ? Of course we are using this feature for many reasons, as part of the all mootools lib we care and love.

  16. Paul says:

    Yes, for example: if(Browser.ie11) { quicksearch.addEvent(“input”, timeoutFn); } else { quicksearch.addEvent(“keyup”, timeoutFn); quicksearch.addEvent(“focus”, timeoutFn); }

  17. ibolmo says:

    We’re taking your input, code from the plugins in the forge, and our own code to understand the use of the Browser API. IE11 team has asked us to consider deprecating the API since IE11 APIs have a complete departure from <IE10. Not to worry, though, we’ll find the best solution that is backwards compatible.