Transition from Javascript Evolution to Cross Browser

Question

I see this need, that people like me self-taught, try to understand.

The point is - Nowadays some Features are already supported by major browsers HTML5, CSS3, DOM, Apis and Ecmascript... being very used by programmers Javascript, not my case, but you can be one of them. However, I always come across some answer here using them.

There is always a need to transition(transcribe) this functionality(s), to some method flatly compatible. But as always I am an apprentice, today I open an indifferent question of the others made by me.

The idea presented here is to give a list of comparisons of what can be replaced by another native Javascript method, in the absence of browser support.

Example

In HTML 5, we have as native praceholder to text field. That clears the text defined in value when focu.

This same effect can be achieved with Javascript pure as follows:

 <input value="digite aqui" type="text"
 onblur="if(this.value == '') {this.value = 'digite aqui';}" 
 onfocus="if(this.value == 'digite aqui') {this.value = '';}" />

In short - means to use the method and own properties of the Javascript instead of fancy Apis and such.

I think that, HTML5, CSS3, DOM, Apis and Ecmascript... in a general way would be better applied in a specific project(APP) and/or certain device, type user of Android, Windows Phone or iOS, but not for a whole like the Web, remembering that not all have fast computers and last generation, and over time Firefox, Google Chrome, Opera and Safari among others less, update your Browsers periodically, arriving at a given time that, we have to make a Purchase of a new Micro Computer, because the new actualization can no longer run income on the old PC, sometimes nor install.

As far as it goes, Ngos, not-for-profit entities are unable to buy a new appliance, they survive on donations, correct?

That’s why I’m on set. If I am developing a web project and wish to impact the largest amount of netizens in contact with the site/blog, how will I give up cross browser language. I can’t!

If anyone understood the Question leave your answer or comment.

Answer 1

From what I understand your question, you would like a list of features and which are the browsers (with version dictated) that that functionality is implemented. There is a site that does just that, including it says whether a feature is partially implemented.

http://caniuse.com/

Answer 2

Diego, I know that it is important to support the largest possible share of users, on the other hand it is difficult to maintain compatibility with older browsers.

An example of this dilemma is jQuery, that for some time maintained two versions, 1.x and 2.x, the main difference between them being the support for versions of IE that are even more maintained by Microsoft.

But maintaining this type of compatibility has its price, the 1.x version of jQuery is larger and heavier than the 1.x version, as a result it requires more time to be downloaded and more customer processing.

In this case it is really worth penalizing ~96% of users because of the ~4% remaining, remember that officially neither the Microsoft supports the IE 6~8 and soon only give support to the most current version (Edge or IE 11, depending on the OS).

Then I advise you to draw a line and define the minimum version of each browser you plan to support.

Now to the question of features, then before using a feature, you should check if it is comparable to the minimum version of the browser you have just defined, and if it is not compatible, you should make the decision, give it up or add a script to Polyfill.

In my opinion the best way to implement a polyfill script is to create a IIFE (Immediately-invoked function expression), at the beginning of the same make a detection of the feature, if it is not found, then implement the same.

Example, you decided to support the IE9 and found it cool to use the tag template on your website, but found that it does not support it, in this case you will have to give up the <template> or use a Polyfill so that your system understands this tag.

follows an example of Polyfill to the tag template HTML5 taken from the following repository.:

(function () {
  if ('content' in document.createElement('template')) {
    return;
  }

  var templates = document.getElementsByTagName('template');
  var plateLen = templates.length;

  for (var x = 0; x < plateLen; ++x) {
    var template = templates[x];
    var content = template.childNodes;
    var fragment = document.createDocumentFragment();

    while (content[0]) {
      fragment.appendChild(content[0]);
    }

    template.content = fragment;
  }  
})();

Answer 3

You’re going the other way. Think first of the user (read: target audience) then define the technology.

Want to deliver software to Ngos in remote places that have precarious equipment, slow internet and technologically poorly trained staff?

Don’t use advanced features. Think pure HTML without much freshness.

You are making a software to be used by a bank’s customers, so security is a concern?

Strictly define which browsers and which versions can be used and use the resources available in them.

You are making a website for web in general (news, recipes, etc.)?

Analyze the site’s user profile.

Google Analytics, for example, provides charts that show the percentage of users who access your site from each browser, desktop/mobile, etc. You can then focus, for example, on writing code compatible with 95% of the browsers in that report.

The other 5%? They will probably have a partial use and will have to be patient.

Filling in the gaps

By defining the list of supported browsers, you can basically adopt three strategies for each resource you need to use:

1. Use the features available in newer versions and leave the feature missing from older versions. It would be the case to have the placeholder in Chrome, but not in certain versions of IE, for example.
2. Use new version features and provide shims or polyfills, that simulate those features using some magic.
3. Rely on older versions and only use the features that are available in all browsers.

Option #1 is interesting because it benefits those who have the newest browser. Who does not have, does not see the best functionality, but can use the site without problems. They will not be upset, because "what the eyes can’t see, the heart can’t feel". :P

Option #2 provides the same more advanced features for everyone, but it involves more work and will probably slow down the site to load, as there are additional scripts to account for the extra work that the browser does not do.

Option #3 is the safest, but can negatively impact user experience.

The decision

It’s up to you - or the architects/project leaders, or the person who decides whether she’ll pay you more or less for the work. :)

The important thing is to know that all options, or a mixture of them, are valid for different contexts.