Martin Bialasinski wrote:
> On 1/23/07, RobG <[EMAIL PROTECTED]> wrote:
>
> > The findFirstElement method is unreliable because it is dependent on
> > the results of form.getElements(), which, as pointed out in another
> > thread, does not return results in the order they are coded in the
> > document
>
> 32 return $A($(form).getElementsByTagName('*')).inject([],
> 33 function(elements, child) {
> 34 if (Form.Element.Serializers[child.tagName.toLowerCase()])
> 35 elements.push(Element.extend(child));
> 36 return elements;
> 37 }
>
> That looks like it returns them in order.
The function I looked at was:
getElements: function(form) {
form = $(form);
var elements = new Array();
for (var tagName in Form.Element.Serializers) {
var tagElements = form.getElementsByTagName(tagName);
for (var j = 0; j < tagElements.length; j++)
elements.push(tagElements[j]);
}
return elements;
},
in Prototype 1.5 rc1 which doesn't return them in the correct order -
it seems to have been fixed in 1.5.0. Why does Prototype use its
lengthy and (to me) very clumsy method rather than the elements
collection?
> > 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.
>
> > that you will also check
> > if the elements are visible by looking at their (possibly inherited)
> > CSS visibility and display property values,
>
> 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
just how far you go is exacly my point.
>
> > and finally ignoring those that are readonly.
>
> There is a "!element.disabled" condition present.
readonly != disabled.
>
> > And should elements that can't be successful (e.g. those with no name
> > attribute) be ignored?
>
> Sometimes you want this, sometimes you don't.
Precisely, so how does findFirstElement handle that?
>
> > All that seems an amazing amount of work, and will likely still not
> > identify the "right" element in some cases.
>
> I believe, it does not have to work in all imaginable cases. 80/20 rule.
So how about a comment somewhere that explains its limits? 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.
>
> > The element in the page
> > that should get focus (if it needs to be set programatically) must be
> > known at the time the page is generated or updated.
>
> I guess in most cases you know it and the simple solutions will work.
>
[...]
> Speaking of real world usage: now that I think about it, when would
> tab-index be used?
Rarely, I didn't suggest it.
>
> - 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. The fastest way to do that is to loop over the elements
collection until the first input type text is found
(getElementsByTagName might be faster if there are lots of non-input
elements at the start of the collection). I don't think any general
function is going to provide such fine control without a large number
of paramters and good documentation.
>
> - To focus a submit button at the bottom of a form that got filled out
> with reasonable defaults. Think a delivery address pre-filled with
> data from a previous transaction. The user has to just press return to
> submit.
So the user fills in the first input, hits tab and goes straight to the
submit button. But that has nothing to do with whether
findFirstElement is useful for the OP.
>
> 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? The function is
called "findFirstElement", it seems to return the first non-disabled,
non-hidden element - which may not be the first element in a good
percentage of cases.
--
Rob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
