The first part is to implement an atpackager visitor which converts aria templates files to browser specific code removing the unnecessary code which is not used by specific browser. This should generate multiple AT code specific to a browser.

The second part is to implement the javascript code which will be loaded first and depending on the browser, AT code will be provided to the browser

2.Technical Solution

This specification is for the first part of requirements. We need to implement a visitor which tranforms the javascript files to browser specific code.The browser is provided as an input to the config object as below.

I think that many usecases have to be taken into account for the generation of browser-specific code. For example, consider class aria.utils.History. Inside of it, there is a lot of browser-specific code, but the detection is not based explicitly on the user agent, but on feature detection (in this case, the choice is also due to the fact that the detection is done before calling the Aria.classDefinition method, so that no assumption on the presence of class aria.core.Browser can be done).

In my opinion, we should have a more generic visitor that is able to cut code paths depending on a list of conditions, or even on a boolean expression. For example:

I never followed any discussions about this feature, but i clearly don't get the point related to what we want to achieved....

First I think that browser specific computations are far more complex than that.

Second, we need to be aware that it is going to (again) increase the size of the code in terms of number of files, kilobytes, ... that the user will have to deploy to it's server, and to my humble opinion, we already are today too big in terms of size, number of files .. when we compare with all other libraries where you just need 1 or 2 files...

The ratio gain vs time invested in that direction is clearly not worth it for me !

This US is a first step where the aim is to be able to build a lighter version of the framework by removing useless code for a particular application.
IE7 specific code is a good example as it is not needed by many existing projects, mainly the mobile ones.

For the technical approach, I agree with what Francesco propose.
Let's do a POC to see if it is doable and what can be gained with that.
Then, we'll see if we can go for a more advanced solution (e.g. tagging some blocks of the source code with comments).

For sure, as pointed by Benoit, it shouldn't impact te size of the framework for applications which do not use this feature!

Browser specific code that can be magically detected is a tiny fraction of the code, probably only few lines of code.

And honestly I believe tagging is simpler than automatic detection.

More than browser specific code we should talk about profile specific code.

Some profiles:

* Aplications that need to support IE7 and will never use any touch specific feature (don't want to make names). You can get rid of delegated gestures from `Delegate`.
* Mobile (only) applications, which don't need any IE stuff, XHR, File transport and probably NavigationManager (at least the part that deals with keymap)
* Production code, in production you might not be interested in certain logs (remove all calls to $logWarn, $logInfo, $logDebug), you don't want the Aria.memcheckMode (~100 LoC in Aria.js), you might want to disable checking the correctness of classpaths (other ~100 LoC), you might want to avoid completely IOFilters (thus removing some code in IO)
* You might as well opt out from some features that are time consuming and active by default, like VisualFocus (to support it, the delegate raises the events elementFocused and elementBlurred every time something gets focused /blurred), FlowControllers (~50 LoC in ModuleCtrlFactory), liquid layout (and Layout class which is mostly used for handling page resizing)
* There are also advanced features that might be disabled like customization, localization, macro libraries, css templates

I tried the automatic detection way by adding a new visitor which does some cleaning.
With it, the full minified framework goes from 1721.4kB to 1718.0kB ...
So clearly more advanced work would be needed, but I'm not even sure it is worth the effort.

I think we may gain a bit more with the more aggressive minification like I've suggested some time ago:
1) removing all $logWarn / $logError calls the error message strings altogether (though this would require some effort to identify the string in $statics which are error messages and the ones which are needed in the UI - perhaps establishing some naming convention would be useful),
2) making somehow UglifyJS shorten the names of private / protected methods (i.e. the ones starting with _) if at all possible

I think in 1) we may gain quite a significant bit - since the unique strings are gzipping poorly, in 2) perhaps not that much, and mostly just in minified code, but in Gzipped the difference could be even smaller. Also making 2) assumes that class Foo doesn't use private methods of class Bar, and I'm not sure if this contract is in place everywhere

Regarding Fabio's post, it would be great to have several profiles. If we want to go mad, we may create some kind of custom build generator like http://modernizr.com/download/ (not providing every possible build ourselves naturally).

However I'm afraid this would add a lot of complexity and would add a big potential for PTRs on our side... (release testing all the possible combinations on IE7 anyone?)

Since we're discussing things... I somehow feel in the air that the usage of flow controllers and liquid layout is generally discouraged, but no one has the courage to write it down officially So the new AT users don't know that unless they explicitly ask. Maybe we should deprecate those features? (not saying about removal right now, they will probably be needed forever in SECO, but let's say honestly, in the world of HTML5/CSS liquid layout is hell complicated and error-prone, at least that was my last experience with it).