Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
    XASD is on a distinguished road

      0  

    Default HTML5 native input elements support(phonegap+io6 inspired rant)

    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.
    So...
    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.
    I'm right?

    Thanks.

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,812
    Vote Rating
    834
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    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
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Ext JS Premium Member
    Join Date
    Apr 2007
    Posts
    228
    Vote Rating
    4
    XASD is on a distinguished road

      0  

    Default


    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.

    Thanks.

Thread Participants: 1