On 1/23/07, RobG <[EMAIL PROTECTED]> wrote:
> Why does Prototype use its
> lengthy and (to me) very clumsy method rather than the elements
> collection?
Beats me.
> > > One solution is to use the form's elements collection, but since that
> > > is unreliable in IE with dynamic forms,
> >
> > It is? Interesting. Do you have a reference for this?
>
> When using DOM methods to add form controls, IE doesn't properly add
> the name attribute so you can't use it to reference them with the
> elements collection.
Well, anyone not using builder.js or some other lib should know to use
the createNode(string) IE-method.
But: The form control does not need a name attribute to be part of
elements, if I read my sources correctly. Or is this another IE bug?
> > I don't know, that looks like overkill. How far should that go? As a
> > real-live case, a container with a label and the input whould be made
> > hidden, not the input alone, so you would have to check for this as
> > well.
>
> No, you need to check the computed/current style of the element.
And how would you do this without walking the DOM?
document.defaultView.getComputedStyle() will tell you if the element
is visible according to its own style declaration. But it will not
tell you that the element is not visible becaue one of its parents is
not visible. At least according to my quick tests.
> > > and finally ignoring those that are readonly.
> >
> > There is a "!element.disabled" condition present.
>
> readonly != disabled.
Oh yes, my bad. Should be checked as well.
> There are
> proably good reasons to not skip disabled or hidden elements - if you
> use it to disable the first element in the form, it will subsequently
> skip that element if you try to use it to re-enable the element.
You are speaking about findFirstElement(), right? Yes, the way the
function is described currently this is the case. It is a function
that is very specific in its scope.
There is no design documentation describing the intention behind the
function, so it is rather difficult to tell right from wrong. "Return
the first input where the user can enter some data" or something.
findFirstElement() by the letter of the name would be
form.elements[0].
And I wonder if anyone actually uses findFirstElement() somewhere and
to what purpose (why one wants a reference to the first form control?
And without a iterator like findNextElement?). Real life usage, not
hypothetical cases. IIRC, it was introduced during a refactoring of
focusFirstElement() and looks designed specifically for
focusFirstElement().
> > - As the original poster requests, to focus a button at the top of the
> > form. ("creative use" of z-index instead of a introducing a "include
> > submits" option to focusFirstElement() )
>
> No, the request was to focus on the first text input and skip the
> button.
I mixed that up. Well, then it would be a substitute for a "do not
include submit/reset/button" option.
> I don't think any general
> function is going to provide such fine control without a large number
> of paramters and good documentation.
Agreed.
> > The tab-index would basically be used as a override for cases where
> > focusFirstElement() does not do the right thing.
>
> But how does anyone know what "the right thing" is?
Documentation. Once the default case is specified, addressing
readonly, disabled, input type, etc.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
