Loading ...
Sorry, an error occurred while loading the content.

Re: [ydn-javascript] Re: use Element.on for change event of SELECT?

Expand Messages
  • Satyam
    ... You can try inputEx: http://javascript.neyric.com/inputex/ ... The YUI team is quite small and can t do all. They have their priorities and, since the
    Message 1 of 5 , Jun 30, 2008
    • 0 Attachment
      ledelste wrote:
      > Thanks for the quick response, Satyam. Indeed it makes a certain
      > amount of sense for the base Element class to support only the basic
      > DOM events, and these are those.
      >
      > I guess in order to support an HTML SELECT, I'll roll it myself.
      > Wouldn't it be a good thing if the toolkit fully supported this and
      > other plain old HTML elements?
      >

      You can try inputEx: http://javascript.neyric.com/inputex/

      > Let me give you my perspective.
      > The reason I'm turning to YUI is that the dev group I've started
      > working with is already using it.
      >
      > When I looked at the list of YUI components, notable in their absences
      > were anything called "Form" or "Select". So I dug around for a bit
      > and decided I could use Element and such to support plain-old HTML.
      > Because why should I start using these new controls when the native
      > HTML controls work so well for me? Why should I use "Menu" when HTML
      > SELECT is good enough?
      >
      > Oops - Element doesn't support SELECT. OK, I am not afraid of writing
      > my own framework elements, so maybe I'll do that. I've read part of
      > your article and will read more. I'm glad it's there to turn to!
      >
      > But I just don't really "get it". YUI's been around for a while now.
      > It's 2.5.2. Is it not really for working with native HTML guis? Do
      > you expect, say, that everyone who uses YUI will use Menu instead of
      > HTML SELECT? That would be reasonable (although I might not care much
      > for it).
      >
      > I'd like to understand where it's going, so I can help my dev group
      > make good decisions.
      >

      The YUI team is quite small and can't do all. They have their
      priorities and, since the major user of their components is Yahoo
      itself, what Yahoo doesn't need it is hard to raise in their list of
      priorities. Yahoo has to reach all sorts of people with all sorts of
      browsers and with JavaScript enabled or not. This means that, regarding
      forms, they have to come already built in the HTML page, they can't be
      build dynamically because someone might not have JavaScript enabled.
      For those users, pages have to stand on their own without JavaScript.
      If JS is enabled, then they can be enhanced with extra features, a few
      fields might have some extra interaction, some validation but otherwise,
      Connection Manager's setForm method is quite enough to get the form
      submitted via XHR instead of old GET or POST. Anyway, none of these
      enhancements involves building the control, just enhancing an existing
      one, which you can do quite well by using Element alone though most of
      the time Dom and Event will be quite enough.

      Eric Miraglia has announced that starting version 3 external developers
      will be able to add to YUI. Then, other priorities will start counting
      as the number of developers expands. This also coincides with a huge
      reorganization of the library. YUI has grown a step at a time.
      Different components behave in different ways. Older components don't
      use Element, which is quite new. This is understandable from a
      historical perspective but can't go on forever. Version 3 will bring a
      greater standardization of components and clear guidelines on how to
      build them, which can be conveyed to external developers so all
      components look and behave alike. That's going to be like YUI leaving
      home to go to college.

      Satyam
    • ledelste
      ... Like most people I had a lot of fun in college, and sort of wish I could go back. So I am jealous of your upcoming YUI experience! Coming up with a
      Message 2 of 5 , Jun 30, 2008
      • 0 Attachment
        > ...Version 3 will bring a
        > greater standardization of components and clear guidelines on how to
        > build them, which can be conveyed to external developers so all
        > components look and behave alike. That's going to be like YUI leaving
        > home to go to college.

        Like most people I had a lot of fun in college, and sort of wish I could
        go back. So I am jealous of your upcoming YUI experience! Coming up
        with a process for letting the external community contribute to the core
        YUI library will be very interesting for all involved.

        > ... Yahoo has to reach all sorts of people with all sorts of
        > browsers and with JavaScript enabled or not. This means that,
        regarding
        > forms, they have to come already built in the HTML page, they can't be
        > build dynamically because someone might not have JavaScript enabled.
        > For those users, pages have to stand on their own without JavaScript.

        I understand. It poses a question, though, for my group, because at the
        moment we are developing internal applications, where we have a lot of
        control over the browser. For the time being, we really don't need
        progressive enhancement. When we open our internal applications to our
        users, then it may very well be very important to us.

        Anyway, it gives me a lot to think about. Thanks!

        --- In ydn-javascript@yahoogroups.com, Satyam <satyam@...> wrote:
        >
        > The YUI team is quite small and can't do all. They have their
        > priorities and, since the major user of their components is Yahoo
        > itself, what Yahoo doesn't need it is hard to raise in their list of
        > priorities. Yahoo has to reach all sorts of people with all sorts of
        > browsers and with JavaScript enabled or not. This means that,
        regarding
        > forms, they have to come already built in the HTML page, they can't be
        > build dynamically because someone might not have JavaScript enabled.
        > For those users, pages have to stand on their own without JavaScript.
        > If JS is enabled, then they can be enhanced with extra features, a few
        > fields might have some extra interaction, some validation but
        otherwise,
        > Connection Manager's setForm method is quite enough to get the form
        > submitted via XHR instead of old GET or POST. Anyway, none of these
        > enhancements involves building the control, just enhancing an existing
        > one, which you can do quite well by using Element alone though most of
        > the time Dom and Event will be quite enough.
        >
        > Eric Miraglia has announced that starting version 3 external
        developers
        > will be able to add to YUI. Then, other priorities will start
        counting
        > as the number of developers expands. This also coincides with a huge
        > reorganization of the library. YUI has grown a step at a time.
        > Different components behave in different ways. Older components don't
        > use Element, which is quite new. This is understandable from a
        > historical perspective but can't go on forever. Version 3 will bring
        a
        > greater standardization of components and clear guidelines on how to
        > build them, which can be conveyed to external developers so all
        > components look and behave alike. That's going to be like YUI leaving
        > home to go to college.
        >
        > Satyam
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.