Quick question... how do I prevent the text in an InPlaceEditor from being selected once I enter it''s edit mode? Currently when I click on the element, the input/textarea is created and all of the text in it is selected (highlighted). I want the caret to be positioned at the end of the element when the InPlaceEditor is created. Thanks, Andrew --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Kaspick wrote:> Quick question... how do I prevent the text in an InPlaceEditor from > being selected once I enter it''s edit mode?The same way you deal with any INPUT[type="text"] elements being focused. Neither Prototype nor Script.aculo.us do any magic when focusing such elements, its browser''s job to handle it. If you want to twist that, attach a ''focus'' observer on that element to do that (you know, the usual selection/text range operations). ;-) - -- Marius Feraru -----BEGIN PGP SIGNATURE----- iD8DBQFF17NvtZHp/AYZiNkRAkr0AJ444WzqEQY800+5eDLdmws4CSjIvgCbBosO OHokhK58ODjMVf3djXDm9CM=xWHU -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I don''t see a hook for InPlaceEditor to add these observers. Based on your response, I take it that adding the functionality I need is a straight forward task, but I fail to see what it is. Scriptaculous/Prototype deal with various browser details for certain functions, so I don''t see why Scriptaculous couldn''t provide a way to allow no initial selection when the input/textarea elements are created regardless of browser. On 2/17/07, Marius Feraru <altblue-9gptZ63fvgw@public.gmane.org> wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Kaspick wrote: > > Quick question... how do I prevent the text in an InPlaceEditor from > > being selected once I enter it''s edit mode? > The same way you deal with any INPUT[type="text"] elements being focused. > Neither Prototype nor Script.aculo.us do any magic when focusing such > elements, its browser''s job to handle it. > If you want to twist that, attach a ''focus'' observer on that element to do > that (you know, the usual selection/text range operations). ;-) > > - -- > Marius Feraru > -----BEGIN PGP SIGNATURE----- > > iD8DBQFF17NvtZHp/AYZiNkRAkr0AJ444WzqEQY800+5eDLdmws4CSjIvgCbBosO > OHokhK58ODjMVf3djXDm9CM> =xWHU > -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Kaspick wrote:> I don''t see a hook for InPlaceEditor to add these observers.True.> Based on your response, I take it that adding the functionality I need > is a straight forward task, but I fail to see what it is.Repeating: "attach a ''focus'' observer on that element to do that (you know, the usual selection/text range operations)".> Scriptaculous/Prototype deal with various browser details for certain > functions, so I don''t see why Scriptaculous couldn''t provide a way to > allow no initial selection when the input/textarea elements are > created regardless of browser.As I anticipated, the problem in fact is that you have a WRONG impression about this issue and that''s what I wanted to correct in my first message. You''re living under the impression it''s Prototype/SAU''s job to take care about this. IT''S NOT! This is an accessibility feature. It''s your user environment vendor who decides how "focusing a control element" should work, or if it should provide tools for tweaking its default behavior. OK, class adjourned, time to do your homework. ;-) Not nice to let others do it for you, but anyway, here it is: http://rubyonrails-spinoffs.googlegroups.com/web/in-place-editor-test.html enjoy. :) - -- Marius Feraru -----BEGIN PGP SIGNATURE----- iD8DBQFF2oaOtZHp/AYZiNkRAn5fAKCVXWEhKyAZaBj4LZ5ntQ60qsjdOACdHcFd O0f/Sf05cVRE/F3dF0BbRNE=l/XH -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Your initial response was basically summed up as "attach an observer". Sure, sounds great, but you have to "hack" that in since there is no predefined "hook" defined via the InPlaceEditor options, which is what I was simply referring to. If your response included a tad more info (one liner even) on where/how to attach the observer I wouldn''t have been led to believe there was common way to do what I required. I am fully aware on how to go about overriding existing functions on the control as I''ve had to do exactly that for a different requirement. Mentioning that would have been all I needed. I appreciate the example provided, but not the tone in which you present it. Leaving that behind, you''ve still failed to convince me that this is a vendor issue... Are you telling me that the behaviour I''m looking for is an edge case and that everyone wanting this feature should use code similar to that in your example? This is a pretty common requirement I would think for this control. I don''t like the default behaviour and want to change it and the browsers provide a way for me to do so, so all systems go. Why should scriptaculous not make things easy for people and include an (optional) feature for this? Saying that, I''ve never asked scriptaculous to do this, but I did originally ask IF scriptaculous could do this (which it does not). Feel free to ignore my questions, but if you have further information to help me see things your way then please do so without the condescending tone. Thanks, Andrew On 2/19/07, Marius Feraru <altblue-9gptZ63fvgw@public.gmane.org> wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Kaspick wrote: > > I don''t see a hook for InPlaceEditor to add these observers. > True. > > > Based on your response, I take it that adding the functionality I need > > is a straight forward task, but I fail to see what it is. > Repeating: "attach a ''focus'' observer on that element to do > that (you know, the usual selection/text range operations)". > > > Scriptaculous/Prototype deal with various browser details for certain > > functions, so I don''t see why Scriptaculous couldn''t provide a way to > > allow no initial selection when the input/textarea elements are > > created regardless of browser. > As I anticipated, the problem in fact is that you have a WRONG impression > about this issue and that''s what I wanted to correct in my first message. > You''re living under the impression it''s Prototype/SAU''s job to take care > about this. IT''S NOT! This is an accessibility feature. It''s your user > environment vendor who decides how "focusing a control element" should work, > or if it should provide tools for tweaking its default behavior. > > OK, class adjourned, time to do your homework. ;-) > Not nice to let others do it for you, but anyway, here it is: > http://rubyonrails-spinoffs.googlegroups.com/web/in-place-editor-test.html > > enjoy. :) > - -- > Marius Feraru > -----BEGIN PGP SIGNATURE----- > > iD8DBQFF2oaOtZHp/AYZiNkRAn5fAKCVXWEhKyAZaBj4LZ5ntQ60qsjdOACdHcFd > O0f/Sf05cVRE/F3dF0BbRNE> =l/XH > -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Err.. there''s no *documented* hook, and it''s not available via
the
options.
Two callbacks are defined (as empty) and called by the code, which
might be useful to you:
onEnterEditMode: function() {} and
onLeaveEditMode: function() {}
These are not assignable through options (someone submit a patch?),
but can be easily assigned after initialization:
var editor = new Ajax.InPlaceEditor(''product_1'', ... );
editor.onEnterEditMode = function () {
// conquer the world
}
editor.onLeaveEditMode = function () {
// abdicate the throne
}
Oddly, the onEnterEditMode is called before the form element is
created, so you might need to play with timeouts.
TAG
On Feb 20, 2007, at 12:17 AM, Andrew Kaspick wrote:
>
> Your initial response was basically summed up as "attach an
observer".
> Sure, sounds great, but you have to "hack" that in since there
is no
> predefined "hook" defined via the InPlaceEditor options, which is
what
> I was simply referring to.
>
> If your response included a tad more info (one liner even) on
> where/how to attach the observer I wouldn''t have been led to
believe
> there was common way to do what I required.
>
> I am fully aware on how to go about overriding existing functions on
> the control as I''ve had to do exactly that for a different
> requirement. Mentioning that would have been all I needed.
>
> I appreciate the example provided, but not the tone in which you
> present it.
>
> Leaving that behind, you''ve still failed to convince me that this
is a
> vendor issue...
>
> Are you telling me that the behaviour I''m looking for is an edge
case
> and that everyone wanting this feature should use code similar to that
> in your example? This is a pretty common requirement I would think
> for this control. I don''t like the default behaviour and want to
> change it and the browsers provide a way for me to do so, so all
> systems go. Why should scriptaculous not make things easy for people
> and include an (optional) feature for this? Saying that, I''ve
never
> asked scriptaculous to do this, but I did originally ask IF
> scriptaculous could do this (which it does not).
>
> Feel free to ignore my questions, but if you have further information
> to help me see things your way then please do so without the
> condescending tone.
>
> Thanks,
> Andrew
>
> On 2/19/07, Marius Feraru <altblue-9gptZ63fvgw@public.gmane.org>
wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Andrew Kaspick wrote:
>>> I don''t see a hook for InPlaceEditor to add these
observers.
>> True.
>>
>>> Based on your response, I take it that adding the functionality I
>>> need
>>> is a straight forward task, but I fail to see what it is.
>> Repeating: "attach a ''focus'' observer on that
element to do
>> that (you know, the usual selection/text range operations)".
>>
>>> Scriptaculous/Prototype deal with various browser details for
>>> certain
>>> functions, so I don''t see why Scriptaculous
couldn''t provide a
>>> way to
>>> allow no initial selection when the input/textarea elements are
>>> created regardless of browser.
>> As I anticipated, the problem in fact is that you have a WRONG
>> impression
>> about this issue and that''s what I wanted to correct in my
first
>> message.
>> You''re living under the impression it''s
Prototype/SAU''s job to
>> take care
>> about this. IT''S NOT! This is an accessibility feature.
It''s your
>> user
>> environment vendor who decides how "focusing a control
element"
>> should work,
>> or if it should provide tools for tweaking its default behavior.
>>
>> OK, class adjourned, time to do your homework. ;-)
>> Not nice to let others do it for you, but anyway, here it is:
>> http://rubyonrails-spinoffs.googlegroups.com/web/in-place-editor-
>> test.html
>>
>> enjoy. :)
>> - --
>> Marius Feraru
>> -----BEGIN PGP SIGNATURE-----
>>
>> iD8DBQFF2oaOtZHp/AYZiNkRAn5fAKCVXWEhKyAZaBj4LZ5ntQ60qsjdOACdHcFd
>> O0f/Sf05cVRE/F3dF0BbRNE>> =l/XH
>> -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Kaspick wrote:> Feel free to ignore my questions,I will, permission acknowledged.> but if you have further information to help me see things your way then > please do so without the condescending tone.There was no "condescension" intended in any of my prior messages on this group, and neither will this be. It will be just harsh or annoyingly bitter for having to repeat myself (in vain) for the third time.> Your initial response was basically summed up as "attach an observer".No. _Basically_ what I was trying to do was to point that "what to do upon focusing a control element" it''s a HIG issue. More than that, I even provided an answer to your particular issue: to attach a "focus" observer that should change focusing behaviour in the manner you wanted. You replied confirming my supposition that accessibility guidelines are beyond you, so I tried once again to make you understand this is not a Prototype/SAU issue, but yada-yada. More than that, being in a cheerful HTH mood, I took the time forging an example presenting how to "attach a ''focus'' observer on that element to do that (you know, the usual selection/text range operations)". Yes, *THAT*, and NOT an example on "how to go about overriding existing functions" (how low can you go?) :(> Leaving that behind, you''ve still failed to convince me that this is a > vendor issue...Example: focus a single-line-control-element using keyboard under ... a) Microsoft Windows XP - - Run: Internet Explorer -> Tools -> Internet Options -> "General" - - use "Tab" (or/and "Shift-Tab") to focus the input field containing the "Home page Adress" value. b) GTK/Gnome on GNU/Linux - - Run: Mozilla Firefox -> Edit -> Preferences -> "Main" - - use "Tab" (or/and "Shift-Tab") to focus the input field containing the "Home Page" value. c) QT/KDE on GNU/Linux - - Run: Opera -> Tools -> Preferences -> "General" - - use "Tab" (or/and "Shift-Tab") to focus the input field containing the "Home Page" value. etc. Andrew, I''m still not being condescending. Cheers. - -- Marius Feraru -----BEGIN PGP SIGNATURE----- iD8DBQFF226EtZHp/AYZiNkRAuXDAJ9h1dT96RyMnh4v4mDTjtBYIfIyVwCg4R5F I15xtIdQKs/9GjGTYQ7PSlk=p+Kk -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
On 2/20/07, Marius Feraru <altblue-9gptZ63fvgw@public.gmane.org> wrote:> You replied confirming my supposition that accessibility guidelines are > beyond you, so I tried once again to make you understand this is not a > Prototype/SAU issue, but yada-yada.<sarcasm> Yes, stating that accessibility guidelines are beyond me is far from condescending. </sarcasm>> > Example: focus a single-line-control-element using keyboard under ... > > a) Microsoft Windows XP > - - Run: Internet Explorer -> Tools -> Internet Options -> "General" > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > the "Home page Adress" value. > > b) GTK/Gnome on GNU/Linux > - - Run: Mozilla Firefox -> Edit -> Preferences -> "Main" > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > the "Home Page" value. > > c) QT/KDE on GNU/Linux > - - Run: Opera -> Tools -> Preferences -> "General" > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > the "Home Page" value.You''re clearly showing how a control is focused if I tab/shift-tab to and from controls. When doing this in a form, it does what I expect, select all the text in a field. This isn''t part of my initial question, but whatever. It''s still a method of onfocus being activated. Ok, so now I simply click on a text field with my mouse and oh, look at that, it doesn''t select all the text! Again, just what I expect it to do. Also another way of onfocus being activated, but the results are different from the above. Back to InPlaceEditor... I click on text ("mimicking" a click on a form field) and I would expect the text to be unselected in this case as well, which it is not. I guess this expectation is beyond me still and wanting to override the default behaviour to something more sensible is crazy talk. If you''re saying you''re having to repeat yourself, then perhaps your method of getting your point across needs some work. Andrew --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Please, settle down, both of you. Soapboxes and rationalization--as much fun as they are--aren''t terribly useful. @Marius: Whether condescension was intended or not, it did come across that way. @Andrew: A persecution complex is unbecoming. Understand, please, Marius, that it''s not as simple as "attach an observer"--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. (And the undocumented hook, "onEnterEditMode" fires before the form element is created.) 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? 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. 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. Now, go back to your corners, and promise to be nice to each other in the future. At least in public. =) Andrew, now you have a starting point (from Marius'' helpful code) to propose a patch that includes the option. Let''s smile, work together, and try to make this great open source library and community useful and productive. TAG On Feb 20, 2007, at 2:56 PM, Marius Feraru wrote:> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Kaspick wrote: >> Feel free to ignore my questions, > I will, permission acknowledged. > >> but if you have further information to help me see things your way >> then >> please do so without the condescending tone. > There was no "condescension" intended in any of my prior messages > on this > group, and neither will this be. It will be just harsh or > annoyingly bitter > for having to repeat myself (in vain) for the third time. > >> Your initial response was basically summed up as "attach an >> observer". > No. _Basically_ what I was trying to do was to point that "what to > do upon > focusing a control element" it''s a HIG issue. > > More than that, I even provided an answer to your particular issue: to > attach a "focus" observer that should change focusing behaviour in the > manner you wanted. > > You replied confirming my supposition that accessibility guidelines > are > beyond you, so I tried once again to make you understand this is not a > Prototype/SAU issue, but yada-yada. > > More than that, being in a cheerful HTH mood, I took the time > forging an > example presenting how to "attach a ''focus'' observer on that > element to do > that (you know, the usual selection/text range operations)". > Yes, *THAT*, and NOT an example on "how to go about overriding > existing > functions" (how low can you go?) :( > >> Leaving that behind, you''ve still failed to convince me that this >> is a >> vendor issue... > Example: focus a single-line-control-element using keyboard under ... > > a) Microsoft Windows XP > - - Run: Internet Explorer -> Tools -> Internet Options -> "General" > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > the "Home page Adress" value. > > b) GTK/Gnome on GNU/Linux > - - Run: Mozilla Firefox -> Edit -> Preferences -> "Main" > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > the "Home Page" value. > > c) QT/KDE on GNU/Linux > - - Run: Opera -> Tools -> Preferences -> "General" > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > the "Home Page" value. > > etc. > > Andrew, I''m still not being condescending. Cheers. > - -- > Marius Feraru > -----BEGIN PGP SIGNATURE----- > > iD8DBQFF226EtZHp/AYZiNkRAuXDAJ9h1dT96RyMnh4v4mDTjtBYIfIyVwCg4R5F > I15xtIdQKs/9GjGTYQ7PSlk> =p+Kk > -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for the feedback. I will be looking into a patch for this as I believe it''s a useful option to have. Andrew On 2/20/07, Tom Gregory <tomg-PGZyUNKar/Q@public.gmane.org> wrote:> > Please, settle down, both of you. Soapboxes and rationalization--as > much fun as they are--aren''t terribly useful. > > @Marius: Whether condescension was intended or not, it did come > across that way. > @Andrew: A persecution complex is unbecoming. > > Understand, please, Marius, that it''s not as simple as "attach an > observer"--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. (And the undocumented hook, "onEnterEditMode" > fires before the form element is created.) 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? > > 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. 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. > > Now, go back to your corners, and promise to be nice to each other in > the future. At least in public. =) > > Andrew, now you have a starting point (from Marius'' helpful code) to > propose a patch that includes the option. > > Let''s smile, work together, and try to make this great open source > library and community useful and productive. > > > TAG > > On Feb 20, 2007, at 2:56 PM, Marius Feraru wrote: > > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Andrew Kaspick wrote: > >> Feel free to ignore my questions, > > I will, permission acknowledged. > > > >> but if you have further information to help me see things your way > >> then > >> please do so without the condescending tone. > > There was no "condescension" intended in any of my prior messages > > on this > > group, and neither will this be. It will be just harsh or > > annoyingly bitter > > for having to repeat myself (in vain) for the third time. > > > >> Your initial response was basically summed up as "attach an > >> observer". > > No. _Basically_ what I was trying to do was to point that "what to > > do upon > > focusing a control element" it''s a HIG issue. > > > > More than that, I even provided an answer to your particular issue: to > > attach a "focus" observer that should change focusing behaviour in the > > manner you wanted. > > > > You replied confirming my supposition that accessibility guidelines > > are > > beyond you, so I tried once again to make you understand this is not a > > Prototype/SAU issue, but yada-yada. > > > > More than that, being in a cheerful HTH mood, I took the time > > forging an > > example presenting how to "attach a ''focus'' observer on that > > element to do > > that (you know, the usual selection/text range operations)". > > Yes, *THAT*, and NOT an example on "how to go about overriding > > existing > > functions" (how low can you go?) :( > > > >> Leaving that behind, you''ve still failed to convince me that this > >> is a > >> vendor issue... > > Example: focus a single-line-control-element using keyboard under ... > > > > a) Microsoft Windows XP > > - - Run: Internet Explorer -> Tools -> Internet Options -> "General" > > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > > the "Home page Adress" value. > > > > b) GTK/Gnome on GNU/Linux > > - - Run: Mozilla Firefox -> Edit -> Preferences -> "Main" > > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > > the "Home Page" value. > > > > c) QT/KDE on GNU/Linux > > - - Run: Opera -> Tools -> Preferences -> "General" > > - - use "Tab" (or/and "Shift-Tab") to focus the input field containing > > the "Home Page" value. > > > > etc. > > > > Andrew, I''m still not being condescending. Cheers. > > - -- > > Marius Feraru > > -----BEGIN PGP SIGNATURE----- > > > > iD8DBQFF226EtZHp/AYZiNkRAuXDAJ9h1dT96RyMnh4v4mDTjtBYIfIyVwCg4R5F > > I15xtIdQKs/9GjGTYQ7PSlk> > =p+Kk > > -----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
-----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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---