Thank you for reporting this bug. We will make it our priority to review this report.
Ext JS Premium Member
HTML5 native input elements support(phonegap+io6 inspired rant)
As we all know,html5 spec is progressing fast and support on many devices getting better every day.
By definition of 'component' imply some user input,but by 'user input' we mean html5 form elements.
Without input components and corresponding infrastructure stores/binding touch framework would be much less of use.
We all agree that touch framework is most usefull with some kind of phonegap framework-think 'native build'.
But what user expect from 'native' app? That it looks and behaves as "native"-nothing more,nothing less.
Yes,some entertainment companies experiment with UI (most coming from web/social land),but when we're talking about bussiness apps, all is changing.
Users want apps to strictly adhere to device platform UI guidelines will it Apple iOs/Android/Blackberry/Windows or something else,consistency and ergonomic come to the first place, and that not means fun at all.Bussiness apps is all about 'input',it begins about 'input',remember? OK
All these platforms has their own strong UI language carefully developed by design teams.
What promise secha touch? Consistent 'look and feel' on all device platforms supporting html5.
But that's not something users and companies really want and expect...
They want 'native' look and feel,they want 'phonegap',they want 'push',want all these native features,which have 'native' counterparts but... with flexibility and agnostic nature of web.
So,that we really expect as developers?
In short, we want nice functional layer which abstract us away from platform inconsistencies,give us freedom to select individual style-character of web,
BUT preserve 'native' look and feel to begin with !!!
And yes,sometimes I wish to adjust native ios theme there and there,but nothing more in MOST cases,if I do 'build native'.
So,it means same functional layer-different(native!) UI for each platform.
Put it simple,it means, that if I need "select"/"file"/"date"/"tel" etc. list is growing every minute... component and device platform support it natively-I want to use that native component, but not some kind of html abstraction,and I want to use sencha programming abstraction layer simultaneously.
It means,that if and ONLY if,platform does not support corresponding component natively,I want some kind of replacement from sencha touch. But if platform support that component...get out the way and not reinvent the wheel.
Bind you exceptional programming model to existing functionality. Remember,integrational hybrid philosophy is key to survival of touch framework.
I don't like to write native apps, but I like to use most of the time for their responsiveness and consistency-don't make me think,particularly if that's not direct purpose of app.
Select correct layer of abstraction and fine tune level to abstract.
If I see html(even beautifull and perfectly valid html5) mess in place of simple "select"/"file"/"date" native html5 element, and you even don't give me a choice, or give something like- write custom theme/component for device yourself, in response.But I see clearly that component implemented by platform itself, and I see sencha component declared as wrapper...
Don't get me wrong, I want to throw that exceptional/beautifull(no sarcasm here) framework out of window.That's not the target sencha pursue with their touch framework,I suppose.
The framework does make it easy to override parts and style things how you want. New in 2.2.0 we support loading certain CSS files depending on what platform the user is using so you can have different style for blackberry than with iOS
Ext JS Premium Member
That's not about theming,css or component override-all these are nice features showing extensibility of framework. That's about choice and usage of native platform features,if it's available.
I can't use 'selectfield' with native flavour-simple "select" element,without some sort of override,will it be custom css/sass/component dosen't matter really.
If platform support it -bind to existing functionality,as simple as that.
I don't want to override or customize something to use something I already have-native html5 element,supported by platform itself.