-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Gregory wrote: > Understand, please, Marius, that it's not as simple as "attach an > observer" OK, maybe "simple" is not the right wording, but essentially that is the way to twist that focusing behavior: attaching a focus observer. :) And please remember I was not mentioning this in the context of Andrew's issue, but rather in the general context of what I was trying to clear up - a HIG [1] issue.
> --because there is no element to attach to on page load, and no good hook > after the element is created. Your sample code acknowledges this. OFC, if we come back to the specific issue, it's obvious that I peeked through Ajax.InPlaceEditor's code and hooked that observer at the right point (after that input element is created). Absolutely, I'd like too having some kind of "onEnterEditMode" hook for Ajax.InPlaceEditor (or maybe an "afterEnteringEditMode", in order to not disrupt current practices), could come handy. Something similar could/should be provided for "onLeaveEditMode" too ;-) > What Andrew is doing is request either a patch be implemented to make > text selection an option (should be trivial), or directions to > documentation demonstrating how it could be accomplished. Saying "It's > easy", then posting a demo demonstrating the functionality by overriding > the S.a.us library functions--while helpful to some degree--didn't > really help answer his question. [I skipped this part, I guess you know why] > All behaviour can be overridden in that manner, and it may not be the > most architecturally sound solution, as it's overrides potential changes > in future upgrades. Agreed, it was just a quick hack trying to fix a particular problem in a timely manner, nothing architectonic there. As I said, I'm on your side on this one, adding two more hooks sounds like the obvious way to go. Speak it up and let's see what SAU core team members have to say about it. Seemingly this would be a 4 lines addition to controls.js. > Yes, it is the default behaviour in some browsers to perform the > selection automatically (in Firefox for input text but not textareas) > when elements are tabbed through. Why can't it be a specified option? Why > can't the page developer specify behaviour left ambiguous in W3C > specifications? (Back to the "general" context) I guess my text-field-focusing example made you miss its point. I chose to use "browser" applications simply because those are commonly used by everybody in this community. Replace them with _any_ application available on those platforms which provides a "single line text field". You'll observe the same behavior. As for changing settings, each vendor chooses how/what settings can be modified. For instance - related to Andrew's issue - sometime ago Gnome/Gtk used to offer a "gtk-entry-select-on-focus" setting, but for some reason nowadays they decided to not support this setting anymore. BTW, their current guideline regarding this issue is [3]: "When the user gives focus to an entry field using the keyboard, place the text cursor at the end of the existing text and highlight its contents". [1] http://en.wikipedia.org/wiki/Human_Interface_Guidelines [2] http://www.gtk.org/api/2.6/gtk/GtkSettings.html#GtkSettings--gtk-entry-select-on-focus [3] http://developer.gnome.org/projects/gup/hig/2.0/controls-entry.html cheers - -- Marius Feraru -----BEGIN PGP SIGNATURE----- iD8DBQFF3L17tZHp/AYZiNkRAjg0AKDxyyuL92O3gPi53/cdW5MiMJtNvgCeMqSe 83Y3cMesVFtmaGEmDbwq8fI= =CNbH -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-spinoffs@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
