RobG a écrit : > I don't think consistency is the issue. If you want a certain set of > functions to accept only a single element, then make that well known > either in the call or the documentation. Then you can say something > like "all the Element methods accept only a single element as an > argument" or such.
How about this in the CHANGELOG for rc1: "For consistency, Element.toggle, Element.show, Element.hide, Field.clear, and Field.present no longer take an arbitrary number of arguments." There are also other consequences and related behaviors detailed in the CHANGELOG for rc1 and rc2. > Which seems to be implied but not stated. How does someone using > Prototype know whether they are using a DOM extension or not? Are they > just the ones prefixed by Element? And Form.Element, yes. As for knowing about it, it does require reading some docs, most of which are absent so far, I agree. But that issue is going to be fixed pretty soon. > So the point of using $() is purely to resolve whether a form element > or a form name/id has been passed to the function. In that case, the It's also to guarantee the resulting form is extended with Form.* methods. > use of a typeof test followed by use of the forms collection is faster > and doesn't have problems with IE's name/id confusion. Again, name/id confusion wouldn't occur if the markup didn't confuse both. These attributes have entirely distinct semantics. Should they be used on the same element with the same value, as is too often the case, that won't be a problem either. But using same-value ID and NAME on distinct elements is misguided IMHO. > It also indicates to anyone scanning the code (probably because they > got an error after passing an array) that the function only accepts a > form or form name/id. Actually, the error message you get, which varies from browser to browser, can be pretty obscure :-( > "Proper"? There is nothing improper about having some elements with a > name that is the same as some other element's ID. That issue arises Ah. Our philosophies of semantics in a web page differ then. Although I can see contexts in which your statement is obviously valid, but I'll always use workarounds (e.g. prefixing IDs when there is such an impending conflict). > Documentation is for whatever purpose you wish it to serve. Any script > in a web page will have its internals inspected; where it is intended > to be distributed as a library for others to use, suitable comments > should be included (see below). You'll find a lot of people stating that inline-doc'ing a library intended for such wide use will bump up its download size by a factor of 2x or 3x... So it should have to remain in some ref' version of the script, which is better done with separate doc altogether, I guess. This latter approach has the advantage of being more accessible to entry-level web developers, which are legion. -- Christophe Porteneuve a.k.a. TDD "[They] did not know it was impossible, so they did it." --Mark Twain Email: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
