These are the changes introduced between 1.4.3 and 1.4.4

• Double slider widget
  

  Add a DoubleSlider widget to the touch widget library. This widget has two independently movale thumbs. Close #489

  See #489

• Easy loading of templates in iframe
  

  Provide a simple and reliable interface to load and test a template inside an iframe. This also attempts at deprecating the usage of iframeLoaderOs, see #435 Close #471

  See #471

• Enhancements in DomElementWrapper
  

  1. Added support for WAI ARIA (`aria-*`) attributes in `getAttribute`
  2. Added support for custom `data-*` attributes in `getAttribute` (previously they could have been retrieved only with `getData`)
  3. Added support for expandos with multiple dashes (`data-foo-bar`) in `getData`/`getAttribute`
  4. Added `setAttribute` Close #486

  See #486

As usual, we also pushed some bugs fixing, just head over to the milestone report on Github

Userscripts are a powerful way to enhance and personalize your browsing experience and also help in some specific debugging purposes (without the power of the Fiddler, but much easier to use).

The implemention of the idea started off in 2004 as an extension to Firefox browser and caught on really well. As of 2013, Greasemonkey is the 4th most installed ever Firefox extension (giving way only to such stars as AdBlock Plus and Firebug)  – with over 2 millions of downloads, and over thousands of userscripts available for one-click installation. Along the way, other browsers (Opera, Chrome) have implemented limited built-in support for userscripts and Tampermonkey project was created to offer a fully equivalent extension for Chrome.

If all that sounds interesting, you may have a look at the presentation on userscripts that I performed recently during our in-house Web Talks session, and see the sample GitHub assistant userscript that adds some code-review capabilities to GitHub on-the-fly while you browse the page.

Changes are mainly about code cleaning and removing old features.

But first let’s see what’s new

• History enhancement
  

  Singleton class aria.utils.History provides a cross-browser implementation of HTML5 native history API. With respect to the previous version, this one is more compliant with the standard behaviour:

  • the onpopstate class event is not raised after a pushState or replaceState.
  • the state property is available on the singleton and it corresponds to window.history.state.

  support for page reload and external navigation is supported also in browsers for which hash-based navigation fallback occurs (with the exception of IE7, for which the previous history is not kept after reloading, but only the current state is available). However, the new version is backward compatible with the previous one. In order to disable backward compatibility, set aria.utils.History.isBackwardCompatible to false right after loading the class.
  
  
  See #441

• Ability to use Aria Templates without skin
  

  If you do not use widgets from @aria Library, you no longer have to include the Aria skin in your application – you may load only the framework. However, this will mean that you’ll probably have to manually add some CSS if you want to preserve the site’s look and feel, as font settings etc. naturally won’t be loaded if you don’t have a skin.
  
  
  See #427

• Bindable popup state
  

  This feature allows to programmatically open the drop down of the following widgets in the standard aria library: Select (not in simpleHTML mode), SelectBox, MultiSelect, AutoComplete (with expand button) and DatePicker. The state of the drop down can be bound to the data model. close #411 close #413
  
  
  See #413

• Focus not visible on buttons
  

  Two new states (normalFocused and msoverFocused) are now available on @aria:Button widgets so that the focused state is visible to the user. Any skin can now define specific background images for those new states. The skins provided with Aria Templates (atdefskin, atskin, atwiki and epiphany) are now updated to display a 1px dotted black border when the button is focused.
  
  
  See #437

Removed features

The following deprecated features are now removed

• (deprecated in 1.0.x)
  The setEnvironment method in aria.core.environment.EnvironmentBase and aria.core.environment.Customizations .

  Please use aria.core.AppEnvironment.setEnvironmentinstead.

• (deprecated in 1.0.x)
  getWidgetLib and getWidgetLibClassName methods in aria.widgets.environment.WidgetSettings.

  Consider using aria.widgetLibs.environment.WidgetLibsSettings.getWidgetLibs and Aria.getClassRef instead.

• (deprecated in 1.0.x)
  aria.widgets.environment.WidgetSettingsCfgBeans.defaultWidgetLib

  Use aria.widgetLibs.environment.WidgetLibsSettingsCfgBeans.AppCfg.defaultWidgetLibs instead.

• (deprecated in 1.0.x)
  aria.widgets.AriaLib.registerWidget and .getBeanConfig methods were removed
• (deprecated in 1.0.x)
  the aria.utils.Event.getElement method was removed (it was marked as protected, so you likely haven’t used it)
• (deprecated in 1.0.x)
  _formatCache in aria.utils.Number (it was marked as private, so you should have not relied on it)
• (deprecated in 1.0.x)
  onvalidate callback in the config of @aria:TextInput and @aria:Select widgets
• (deprecated in 1.0.x)
  objects in interface definition are no longer represented as {}

  Use either as {$type: "Object"}
  or a shortcut notation "Object"

• (deprecated in 1.1-5)
  color property in the config of @aria:Link widget
• (deprecated in 1.1-18)
  DomElementWrapper.getData() no longer internally checks for expandos prefixed with ‘_’.

  Please use ‘data-’ prefix for expandos in your HTML instead. (Note: most of related code was already removed in 1.3.1)

• (deprecated in 1.1-25)
  aria.resources.DateRes.firstDayOfWeek

  Please use it through aria.core.AppEnvironment.

• (deprecated in 1.1-31)
  aria.widgets.frames.OldFrame, the old type of frames corresponding to sprType 0,1 and 2.

• (deprecated in 1.2-5)
  whole aria.utils.FormatFactory class
• (deprecated in 1.2-4)
  This release introduces also some changes in the skinning system and CSS.

  The following skin property is no longer supported:

  • general.colors.bkg

  You should also make sure that the skin you’re using, has defined the following properties, which were using the fallback value of the now removed general.colors.bkg if not defined

  • Calendar.<sclass>.generalBackgroundColor
  • Calendar.<sclass>.dayBorderColor
  • Calendar.<sclass>.unselectableBorderColor

  (they’re all defined in atdefskin and epiphany skins for “std” sclass, set to white).

  The following global CSS is no longer added by Aria Templates (consider adding it manually if you need it):

  body { padding: 0; margin: 0; cursor:default; }

  Additionally, due to internal changes, you may need to include aria.core.CmlClassLoader in a bundle in your application build configuration (only needed if you use skin).

Deprecated features

The following features are now deprecated but still supported.

• aria.widgets.IconLib class
• {bindRefreshTo} statement
  {bindRefreshTo} statement will be removed in Aria Templates 1.5.1. Please use bindRefreshTo property of a {section} statement instead. See the samples below:
  Old (deprecated) syntax:
  

  {section "foo"}           {bindRefreshTo data.value/}           ... content ...       {/section}

  
  Easy replacement suggestion:
  

  {section {           id : "foo",           bindRefreshTo : [{inside : data, to : "value"}]       }}           ... content ...       {/section}

  
  Recommended:
  

  {section {           id : "foo",           macro : "mySectionMacro",           bindRefreshTo : [{inside : data, to : "value"}]       } /}       {macro mySectionMacro()}           ... content ...       {/macro}

• History API cross-browser implementation enhancement
  Singleton class aria.utils.History provides a cross-browser implementation of HTML5 native history API. With respect to the previous version, this one is more compliant with the standard behavior:
  the onpopstate class event is not raised after a pushState or replaceState.
  the state property is available on the singleton and it corresponds to window.history.state.
  support for page reload and external navigation is supported also in browsers for which hash-based navigation fallback occurs (with the exception of IE7, for which the previous history is not kept after reloading, but only the current state is available). However, the new version is backward compatible with the previous one. In order to disable backward compatibility, set aria.utils.History.isBackwardCompatible to false right after loading the class.

Playing with timezone in javascript can be problematic not because of the timezone offset calculation, which can easily be done with the getTimezoneOffset method of a date object, but because of the DST (daylight saving time) policy of the local countries/states.

Let’s take New York and Paris as an example. The official timezones for these two locations is UTC-5 and UTC+1, but because of the DST policy, the « real » New York time is UTC-5 before beginning of March and UTC-4 after. For Paris it’s UTC+1 till end of March then UTC+2 is used.

So if you have to convert a time from one timezone to another, you will need to know what are the local dates for both, depending their own rules, not with only their official UTC offsets.

The IANA Time Zone Database

An official and public database has been created to reference all the rules used over the world, for any moment in the history (don’t forget that the rules can change depending on politician decisions).

You will find on Wikipedia the detailed information about the tz database, which is the reference information for any language which wants to deal with the timezones.

Timezonejs

Unlike some server side languages as Java or PHP, which have internally an API to get the timezones information, javascript can’t retrieve it with its own API.

The most known javascript library to deal with the timezone is timezonejs. Its open source code contains the IANA information, and it’s usage is better driven in two steps: the first one is to preprocess the database to a json, based on the timezones you plan to use, the second one is to load the library and the json on the client in order to use them.

Compile the IANA database to a json file

This process is done with nodejs, and is quite straitforward. node-preparse.js will be found in the src directory, and can be used with node to compile the information in the tzdata directory. For example, if you want to compile all the timezones, you can run the following command line from the src directory:

As a result, you will obtain the file tz.json that you will place on an acessible location of your server. Some optional syntax exists in order to generate a subset of the whole timezones.

Loading and using timezonejs in Aria Templates

Now you have timezonejs (in src/date.js, that you could rename timezonejs.js, for example) and your json information accessible on your server, it’s time to load it and use it in Aria Templates. Timezonejs doesn’t have a “transport” to get the json file (by default, timezonejs tries to use jquery if available).

This operation can be easily achieved in Aria templates, without using any third party:

The first step is to use aria.utils.ScriptLoader.load to load the library itself, and then aria.core.IO.asyncRequest is used with expectedResponseType: ‘json’ to get and evaluate the json. As a result, the json data are injected in timezonejs and the library is ready.

Now a new date can be created through timezoneJS.Date (note the extra timezone parameter in the previous code), and can be changed with the setTimezone method to finally get any local time according to the country rules.

• CSS Animations
  

  Add CSS animations, like slide, fade, pop and flip, using the utility aria.utils.css.Animations
  
  
  See #414

• Error tool tip enhancement
  

  Currently the logic for the error tool tip is contained within aria.widgets.form.Input, the aim of this enhancement is to share code efficiently between multiple types of widgets. Specifically for the requirement of this feature, this means making the code for the error tool tip not only available for "Input" type widgets, but also for "Action" type widgets. In addition, it must also be possible from within a template to have a new widget property called errorTipPosition that will be used as the preferred position for the error tool tip, if there is not enough available space the framework will automatically calculate the best position for the error tool tip. The property will be added for both "Input" type widgets and also "Action" type widgets.
  
  
  See #405

• improve ModuleCtrlTestCase
  

  Improve ModuleCtrlTestCase by providing automatic creation and disposal of tested module. By specifying $controller in the test’s $prototype an instance of that class is generated before running the test. The tester can then access the two variables $moduleCtrl and $moduleCtrlPrivate. The public interface is also registered for asserting its logs, so there’s no need to call anymore registerObject.
  
  
  See #407

• Using atpackager
  

  The packager used during the open-source build of Aria Templates is now separated in its own project called atpackager. Templates are now pre-compiled to JavaScript classes during the build. Grunt version is updated from 0.3 to 0.4.
  
  
  See #400

• improve logging in tests
  

  1. Added Assert.assertEqualsWithTolerance(num1, num2, tolerance)
  2. Formatted output in Assert.assertJsonEquals Instead of dumping minimal JSON strings in failed JSON comparison, pretty-print them.
  3. Log to browser console in JSUnit in verbose mode

  Currently, the SilentArrayAppender is the appender used in our JSUnit. This means that things like $logError or $logWarn will not be displayed in Firebug console. However, the appender is changed from DefaultAppender in the middle of the execution, which results in some logs actually being available in the browser console, but the rest (after changing appender) not. For debugging purposes, it’s useful to see the errors and warnings directly in the browser when running the test. This commit adds the possibility to see all the logs if the URL of the test page contains ‘verbose=true’ part.
  
  
  See #404

• Gestures
  

  Support more gestures: double tap, single tap, long press, drag, pinch.
  
  
  See #385

• Utility class to load standard css files
  

  It is possible to programmatically add/remove css files by using the aria.utils.CSSLoader singleton. Tags of type "link" are created and appended to the head of the document.
  
  
  See #393

GH-218 –

• Better stack traces in Firebug and Safari dev tools

  Now almost all the functions (both from core AT code and user template scripts / module controllers) will have names displayed in the stack traces in Firebug and Safari dev tools, using Function.displayName feature. Previously many of the functions were displayed as anonymous.
  
  See #218

As Aria Templates team, we provide a JavaScript framework used by numerous web applications in Amadeus. We may not be deeply familiar with some of that applications, and do not have them installed on our development machines, yet since they use our framework, we’re frequently asked for support to help on debugging some of the applications’ problems.

Debugging rich internet applications that are not served from your local webserver, and especially on a browser that you don’t have physically on your computer (e.g. IE9 or IE10, while you’re on Windows XP) might be a challenge. However there are tools like Fiddler which help greatly, and if configured properly, give us the possibility to work directly on our computers to debug, fix and test the problems without redeploying anything on the staging servers.

What is Fiddler

Fiddler is a (Windows-only) web debugging proxy with extended capabilities to alter the traffic for debugging purposes. You can create ad-hoc local files that will be returned for certain HTTP requests (e.g. altering specific file), or write a few lines of JScript.NET code (Microsoft’s flavor of JavaScript with some classical-OOP additions) to redirect requests matching certain regex to another URL / machine / possibly your localhost server.

To start with, you can install Fiddler on your machine, and once enabled, whole traffic from proxy-aware programs will go through it. Regarding the browsers: Chrome, Safari and IE integration is seamless; for Firefox there comes an add-on with Fiddler; Opera must be started only after Fiddler is started and activated.

This is all good, but there comes a moment when you need to test a browser you don’t have on your machine – e.g. debugging on a virtual machine with a particular version of Internet Explorer. You can obviously install Fiddler on all of your virtual machines, but once you develop your specific set of extensions, Fiddler scripts etc., maintaining them on all of those machines (and choosing same custom redirection settings from the Fiddler menu for all those instances — especially painful after a change in Fiddler script, which resets the hand-activated settings to defaults) becomes not that handy.

Luckily, since Fiddler is in fact a proxy server, you might configure your external virtual machines to target Fiddler on your machine as a proxy. That way, after properly configuring all the VMs, you can edit your JavaScript / HTML / CSS on your development machine, and change various Fiddler’s settings only once, and then only refresh a page on all remote browsers!

Let’s see an example how we can facilitate debugging in Internet Explorer running on a remote machine.

Configuring Fiddler as a remote proxy

First, you’ll need to alter Fiddler’s settings and restart Fiddler.

Check from your local machine and a remote machine that you can access Fiddler’s web server:

On a remote machine, open “Tools” > “Internet Options” in Internet Explorer to set up a proxy:

That’s it! Now open any page on a remote machine, and you will see the traffic in Fiddler window on your local machine. The only drawback is that for remote traffic, process name will not be displayed.

One of the useful things you can do with Fiddler is injecting a debugger; statement in a part of JavaScript code you may want to inspect. This might be a lot easier than looking for a proper place to put a breakpoint while in a browser (and you will need to do it in each of the instances of the browser).

Creating a simple autoresponder in Fiddler

Let’s get our hands dirty and try it out.

I’ll create an ad-hoc webserver on my machine at jakub:8000 serving a demo.htm page which loads a script from demo.js (Hint: you can use python -m http.server command to start a web server on port 8000 serving a current working directory if you have Python 3 installed). This is to simplify things for the demo sake, but think of it as an external webserver – let’s pretend I don’t have access to that code on my machine.

I’ll make a deliberate mistake there which creates a syntax error in IE7: add a trailing comma in an object literal:

Let’s launch it in IE7 on a virtual machine:

Now let’s have a look at Fiddler sessions list. First I launched a page in a local instance of Chrome, then in IE7 on virtual machine (it’s remote hence process name field is empty):

I can create an autoresponder (above, right hand side section), to intercept the request coming for demo.js and serve my own file instead. To do that, I can drag an entry from session list to the Autoresponder tab (make sure to tick “Enable automatic responses” and “Unmatched requests passthrough” in the Autoresponder tab first), and then choose “Generate file” from context menu. Let’s create an autoresponder file and change our code, getting rid of a trailing comma in the array, and refresh the page in the browser:

As you can see, the traffic going through autoresponder has a different background color. Let’s get back to our IE7:

We’ve just fixed a remote problem, playing on a local development machine without redeploying anything. Of course this was just a trivial example, but same flow applies to much complex problems.

The problem has been solved for IE7, but will the fix not break things in other browser and other versions of IE? Just keep the autoresponders, configure the proxy accordingly on virtual machines, and launch the page in other browsers. No regressions? Head to your IDE / command line and check-in the fix!

That’s cool, I want to know more!

For more info on Fiddler, check out the tool’s website and Eric Lawrence’s blog.

• Bindable width and height for containers
  

  A possibility to bind width and height for some of container-based widgets (Div, Dialog, Fieldset, TabPanel) has been added. The bound size is a subject to min/max size constraints for all of those widgets.
  This change lifts the requirement for widgets to have width/height = -1 for min/max width/height to work. So this is backward-incompatible change in some way, but the behavior of width & maxwidth etc. when provided together was undefined earlier, so it should not have relied upon by anyone. Pull request #347

• Maximizable Dialog
  

  Dialog can be now maximizable. If configured so, it will have a button to maximize/unmaximize next to the close button. It also reacts to the change of the data model property `maximized`. That property takes precedence over `center`, `xpos`, `ypos`, `width`, `height` changes (if you want to change those properties, you should first unmaximize the Dialog); moreover, `maxHeight` and `maxWidth` are ignored when the Dialog is in the maximized mode.
  When Dialog gets maximized, the scrollbars of the page are removed, the Dialog occupies the whole viewport and is not movable/resizable. After unmaximizing, it returns to the original position, size and restores movable/resizable capabilities. Pull request #358

• $description is no longer mandatory in bean definitions
  

  This change allows to improve the package size by removing the descriptions in bean definitions as part of the build process. Nevertheless, the use of these descriptions is still encouraged for documentation purposes. Pull request #342. Being now optional it’s also possible to remove the descriptions from the production packaged version, pull request #330

• Add a custom image to Iconbutton widget
  

  This feature allows users to define their own image path for IconButton/Icon widgets. Pull request #324

• Orientation change detection
  

  Add a utility class to detect orientation change events and register callbacks to such events. Pull request #351

• Animation/Transition Event callbacks
  

  Allow to register to animation and transition events from a template through on statement. Pull request #350

• Detecting Mobile Device Properties
  

  Utility class to detect some properties of mobile devices like being a tablet or mobile, the support of 2D and 3D transforms or whether the application is running inside PhoneGap. Pull request #292

• Testing improvements
  

  Thanks to #339 and #337 it’s now possible to run Robot tests inside PhantomJs and configure the number of PhantomJs instances used by attester.

Aria Templates is based on client-side templating: as templates are stored client side, if a piece of data changes, there is no need to manipulate DOM elements to update the UI, it is only needed to refresh a template or a part of it.

When a template is refreshed, the Aria Templates framework erases the DOM structure and creates a new one with the updated data. This works fine in most cases. However, it is not always desirable to get rid of the previous DOM structure, especially for components, such as iframes, which contain some state to preserve, or which are heavy to reload.

This blog post explains how to integrate iframes seamlessly in an Aria Templates application, while preserving the refresh feature, thanks to the @embed:Element widget. The same technique can also be applied for similar components.

1 – The problem

Consider the following template:

This template properly displays the iframe, and it is naturally possible to navigate inside the iframe. However, as soon as the template is refreshed, the current state of the iframe is lost and the iframe displays the original http://ariatemplates.com page.

Of course, we could say: let’s avoid refreshing this whole template, and only refresh parts of it. That strategy would probably work for very small applications. But if the iframe is supposed to be inside a tab panel or a dialog and the state of the iframe is supposed to be kept when hiding and opening again the panel or the dialog, or if the iframe is contained in a template used as a sub-template of another template in a big application, it will become harder and harder to fight against the concept of refreshes, on which Aria Templates is built.

Fortunately, the @embed:Element widget was designed to solve this kind of issues, as explained in the next section.

2 – A first (nearly working) solution

The @embed:Element widget is expecting in its configuration a reference to a controller. The controller is called just after the widget is inserted in the DOM (onEmbededElementCreate), and just before it is removed from it (onEmbededElementDispose). As a consequence, it seems easy to create a controller which manages the iframe DOM element, and makes sure it is reused across refreshes. Let’s consider the following code:

For simplicity, each instance of this controller manages a single iframe DOM element. The DOM element is built in the $constructor. When the @embed:Element widget is inserted in the DOM, we simply append the iframe to the domContainer element, which is the DOM element of the widget. When the widget is about to be removed from the DOM (for example: on refresh), we simply do the reverse (removing the iframe from the domContainer).

Now, here is the template which uses the @embed:Element widget and our new controller. Note that the embed widget library needs to be included in the template header:

And here is the associated script:

An instance of the controller is created the first time it is needed and then it is stored in the data model.

Unfortunately, among the browsers I tested, this solution only works as expected in Internet Explorer, surprisingly. Other browsers (Firefox, Chrome and Safari) reload an iframe when it is moved in the DOM with removeChild and appendChild. This behavior is reported as a bug in Mozilla and in Webkit, but it will probably not change soon, as bug reports were opened in 2004 and 2007.

3 – A second (working) solution

So, how to improve our previous solution to make it work in all browsers? Simply by making sure the iframe always stays at the same place in the DOM structure. We can append it directly to the <body>, and then visually position it absolutely with the appropriate CSS style. When the widget is displayed we compute the position and size of domContainer and apply it to the iframe, and when the widget is disposed, we use the “display:none” style to hide the iframe. Let’s have a look to the updated controller:

This controller uses the getGeometry method to get the position and size of the domContainer in the viewport, and it adds the current scroll position to get an absolute position (no longer relative to the viewport).

Note that in order to use the new controller, it’s now necessary to specify a size in the attributes of the @embed:Element widget directly:

With this controller it is now possible to include persistent iframes in templates.

4 – Improving the solution for dialogs

Now, when trying to include an iframe with the controller of the previous section in a dialog, it does not display anything. Why? Here are the reasons and how to solve the issue:

• Before displaying a dialog, Aria Templates first checks its dimensions, and this is done out of the viewport (with negative coordinates). So, at the time onEmbededElementCreate is called, the domContainer is not yet correctly positioned. To fix this, it is necessary to delay a bit the call to updateStyle with setTimeout:

  onEmbededElementCreate : function (domContainer) {     if (this._domContainer) {         this.$logError("The iframe controller is used in multiple places!");         return;     }     this._domContainer = domContainer;     setTimeout(aria.utils.Function.bind(this.updateStyle, this), 1); }

• Another reason is that the dialog is displayed with a high z-index value, so it appears above the iframe, hiding it completely. To fix this, it is necessary to apply a z-index value to the iframe. Even if the following method does not take into account the special behaviors of z-Index (see this interesting article), it allows to compute a z-Index value that will probably work for common use cases:

  _computeZIndex : function (element) {     var zIndex = 1;     var body = Aria.$window.document.body;     while (element && element != body) {         var elementZIndex = parseInt(element.style.zIndex, 10);         if (!isNaN(elementZIndex)) {             zIndex = elementZIndex + 1;         }         element = element.parentNode;     }     return zIndex; }

• In case the dialog is movable, it is important to update the position of the iframe when the dialog is moved. However, as the iframe is not included in the dialog DOM structure, and because of the way the dialog is currently implemented, it is probably best for the user experience to simply hide the iframe when the user starts dragging the dialog and make it visible again when he drops it. This can be implemented simply with a setVisible method on the controller (see the next section for the code to download).

Source code

Here is a zip file containing the source code of the 4 previous sections. To try those samples, you can simply put the iframes folder at the root of your web server. Then you will probably have to update the /iframes/index.html file so that it contains the correct reference to the Aria Templates framework files installed on your web server.

Conclusion

This blog post explained how to use the @embed:Element widget to display persistent iframes with Aria Templates. The same technique can be applied for other components as well. Note that the first solution is working well for maps, and it is used internally by the @embed:Map widget.

If you found this blog post useful, or if you have any interesting remark, please do not hesitate to leave a comment below.

Among the changes done in this sprint there are few new features:

• HTML checkbox widget
  

  ew simple checkbox widget in the HTML library with a bindable checked property. Pull Request #285.

• Array of listeners in aria.html.Element
  

  Gives the ability to add multiple event listeners on widgets extending from Element. Pull Request #320.

• Vertical splitter implementation
  

  Now its possible create splitter in both horizontal and vertical direction. See GH Pull Request #311.

See you in 3 weeks!

• Performance enhancements for Flow Controllers and Interceptors
  

  There has been a refactoring of Interceptors, specifically in relation to Flow Controllers which has greatly improved performances for all browsers and most notably for IE. Pull request #270.

• Enhancement of the TextInput widget of the html library
  

  The following features have been added to the html TextInput widget:

  • Possibility to set the type “password” on it (by setting property “password” of the widget configuration to true) (GH pull request #265).
  • Possibility to call $focus providing an id. (GH pull requests #267 and #268)
  • Introducing the autoselect feature. (GH pull requests #272)
  • Introducing cross browser support for placeholder attribute. (GH pull request #288)