Hey all! Has there been any discussion about transitioning the Rails and/or Ajax helpers that generate HTML / JavaScript code so that they avoid using onClick events? I''m attempting to create valid XHTML 1.0 Strict code to improve cross-browser interoperability, but I never get valid results when using a lot of the included helpers, and a lot of examples I see on this list still resort to ''onClick'' events. A good example would be using JavaScript code that adds the onClick events on the client side.... Your XHTML code remains valid, but this link <a id="clickme">Click here for more information</a> Becomes <a href="#" onClick="clickme()">Click here for more information</a> Again, the reason for doing this is that your application can 1. still be used by devices that don''t completely support Javascript 2. you can provide valid documents (very helpful when creating accessible applications) 3. You can separate your content from your events 4. You can reduce code (see unobtrusive table sorting) 5. You can still use JavaScript and Ajax!!! 6. It promotes web standards! It seems a shame to me that Rails is so far ahead of the curve on so many other things, and yet it still tends to do things in a way that''s not standards-compliant. That''s why I was wondering if this has been given some consideration by the core team. As a developer (and a user) of sites that must adhere to various accessibility and standards regulations, this is a concern to me. Thanks for your time. Brian Hogan Web Development Learning & Technology Services Schofield 3-B University of Wisconsin-Eau Claire 715 836 3585 hoganbp-VnAisaAFmHY@public.gmane.org _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
hi,> A good example would be using JavaScript code that adds the onClick > events on the client side…. Your XHTML code remains valid, but this > link > > <a id="clickme">Click here for more information</a> > > Becomes > > <a href="#" onClick="clickme()">Click here for more information</a>i fear i don''t get your point. how would that help? you''d have to a) add the code for adding the onclick() event somewhere (thus not making the code any shorter) and if a client does not fully support javascript, it will not matter very much *where* he does not understand the js... maybe i just seriously misunderstood you?> 2. you can provide valid documents (very helpful when creating > accessible applications)how is that helpful? i''d say the most important thing is that the code you generate is understood by the application you want to support (pragmatic view of things, i know) and if i think about the fact that the most-widely-used browser - alas - still cannot fully deal with css2.0, i don''t see how standard-compliance on the web-application side can further accessibility :-)> 3. You can separate your content from your eventsgood point, but that depends on the developer, not on the standard-compliance of the framework, i''d suggest.> given some consideration by the core team. As a developer (and a > user) of sites that must adhere to various accessibility and standards > regulations, this is a concern to me.this is a very valid and true point. and considering that you have to follow certain standards and regulations, most of the things you wrote above now appear in a different light (to me, at least). i''ll post that mail nevertheless, maybe thus triggering a fruitful discussion :-D maybe you could point out to me what i did not understand (see above). best regards, t _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Thanks for the reply.
"i fear i don''t get your point. how would that help?
you''d have to a)
add the code for adding the onclick() event somewhere (thus not making
the code any shorter) and if a client does not fully support javascript,
it will not matter very much *where* he does not understand the js...
maybe i just seriously misunderstood you?"
Well let''s say for example that you wanted to have hyperlinks that open
popup windows. Since "target="_blank"" is deprecated,
you''d have to do
a javascript popup.
But, let''s say you''ve got a blind user using a screen reader.
Many
screen readers just don''t understand JS, and popups can be confusing.
So you might just have the link point to the page by default, and use
client-side js to "apply" the popup by changing the href from
''foo.htm''
to ''javascript:popup(''foo.htm'')''.
The same can be true for "show/hide" elements on a page.... Show them
all when no javascript is enabled, and use client-side js to create the
"show / hide all" link on the page as well as hide elements on the
page
load.
I also might find that instead of using the same "onclick="foo{params,
parsms, params)", I have a common file that I could reference.
Just like prototype.. Why do
''getElementByID(''foo'')'' when you can do
$(''foo'');
2. "how is that helpful? i''d say the most important thing is that
the
code you generate is understood by the application you want to support
(pragmatic view of things, i know) and if i think about the fact that
the most-widely-used browser - alas - still cannot fully deal with
css2.0, i don''t see how standard-compliance on the web-application side
can further accessibility :-)"
Accessible means accessible... By anyone on any platform. Those with low
vision might require screen readers.... Those with old browsers still
want to buy your product. Those with fine motor skill impairments have
difficulties using the mouse, so you''re careful how you make things
appear and disappear based on events.... Etc.
A great start to achieving this is to ensure that your XHTML and CSS is
valid. If you''ve got "onClick" all over the place,
you''re not going to
have valid docs... And you''re going to skip validating because you
*know* it won''t be valid.
I would say that your application (especially if you''re attempting to
reach the largest audience possible) is not useful unless it can be used
without css or javascript enabled. It''s not going to be a *fun*
experience, but it doesn''t have to frustrate the user who
happens to be using a 320x240 smartphone to do some quick work.
Finally, as a person who supports (and occasionally has to use)
assistive technologies, I want to do what I can to make the Web a little
more friendly and accessible.
3. content separation: "good point, but that depends on the developer,
not on the standard-compliance of the framework, i''d suggest."
I agree, but if the majority of the community is using the built-in
helpers, the framework is negatively contributing to
standards-compliance.... Just like developers who use FrontPage or some
of the .Net widgets out there and thus only support Internet Explorer on
Windows.
I recommend the following reading for some more examples and strategies:
http://www.alistapart.com/articles/eatcake
http://www.onlinetools.org/articles/unobtrusivejavascript/
http://www.kryogenix.org/code/browser/
Thank you! I really appreciate your interest in this conversation. If I
can be involved any more, please let me know. I hope I''ve helped make a
few things more clear.
Regards,
-Brian
-----Original Message-----
From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On
Behalf Of Tobias Witek
Sent: Thursday, December 01, 2005 11:08 AM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] JavaScript, rails, and the W3C
hi,
> A good example would be using JavaScript code that adds the onClick
> events on the client side.... Your XHTML code remains valid, but this
> link
>
> <a id="clickme">Click here for more information</a>
>
> Becomes
>
> <a href="#" onClick="clickme()">Click here for
more information</a>
i fear i don''t get your point. how would that help? you''d have
to a) add
the code for adding the onclick() event somewhere (thus not making the
code any shorter) and if a client does not fully support javascript, it
will not matter very much *where* he does not understand the js... maybe
i just seriously misunderstood you?
> 2. you can provide valid documents (very helpful when creating
> accessible applications)
how is that helpful? i''d say the most important thing is that the code
you generate is understood by the application you want to support
(pragmatic view of things, i know) and if i think about the fact that
the most-widely-used browser - alas - still cannot fully deal with
css2.0, i don''t see how standard-compliance on the web-application side
can further accessibility :-)
> 3. You can separate your content from your events
good point, but that depends on the developer, not on the
standard-compliance of the framework, i''d suggest.
> given some consideration by the core team. As a developer (and a
> user) of sites that must adhere to various accessibility and standards
> regulations, this is a concern to me.
this is a very valid and true point. and considering that you have to
follow certain standards and regulations, most of the things you wrote
above now appear in a different light (to me, at least). i''ll post that
mail nevertheless, maybe thus triggering a fruitful discussion :-D
maybe you could point out to me what i did not understand (see above).
best regards,
t
On Thursday 01 December 2005 20:15, Hogan, Brian P. wrote:> A great start to achieving this is to ensure that your XHTML and CSS > is valid. If you''ve got "onClick" all over the place, you''re not > going to have valid docs... And you''re going to skip validating > because you *know* it won''t be valid.Are you suggesting, that onclick(!) attributes cause documents to be non-conforming to the XHTML 1.0 recommendation? I can assure you that this is not the case. Michael -- Michael Schuerig I am the sum total of the parts mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org I control directly. http://www.schuerig.de/michael/ --Daniel C. Dennett, Elbow Room
Hi all, 2005/12/2, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org>:> Are you suggesting, that onclick(!) attributes cause documents to be > non-conforming to the XHTML 1.0 recommendation? I can assure you that > this is not the case.He said "onClick", not "onclick" :) -- Juan G. Hurtado [ Juan.G.Hurtado-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org ] [ http://armonia.spiral-static.org/ ]
Slight distinction.... onclick = valid.... onClick == invalid. This was fixed in some spots... But I believe it pops up in other spots. http://wiki.rubyonrails.com/rails/pages/ReleaseNotesForEightFive Changed link_to with Javascript confirmation to use onclick instead of onClick for XHTML validity [Scott Barron] That said, validation is only one part of accessibility. -----Original Message----- From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Michael Schuerig Sent: Friday, December 02, 2005 4:38 AM To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org Subject: [Rails] Re: JavaScript, rails, and the W3C On Thursday 01 December 2005 20:15, Hogan, Brian P. wrote:> A great start to achieving this is to ensure that your XHTML and CSS > is valid. If you''ve got "onClick" all over the place, you''re not > going to have valid docs... And you''re going to skip validating > because you *know* it won''t be valid.Are you suggesting, that onclick(!) attributes cause documents to be non-conforming to the XHTML 1.0 recommendation? I can assure you that this is not the case. Michael -- Michael Schuerig I am the sum total of the parts mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org I control directly. http://www.schuerig.de/michael/ --Daniel C. Dennett, Elbow Room _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
> onclick = valid.... onClick == invalid. > This was fixed in some spots... But I believe it pops up in > other spots.Just curious, if passing a machine-test is important, why use a DocType (XHTML 1.0 Strict, was it?) that doesn''t provide a lot benefit for all the hoops one would have to go through? Unless you really need to serve XML documents, HTML 4.01 seems to be a better choice?> That said, validation is only one part of accessibility.''Absolutely. Underscore that valid mark-up != accessibility.
Some other good sites that advocate unobtrusive javascript: http://www.bobbyvandersluis.com/ http://www.quirksmode.org/ Thanks graeme On 12/1/05, Hogan, Brian P. <HOGANBP-VnAisaAFmHY@public.gmane.org> wrote:> > Thanks for the reply. > > "i fear i don''t get your point. how would that help? you''d have to a) > add the code for adding the onclick() event somewhere (thus not making > the code any shorter) and if a client does not fully support javascript, > it will not matter very much *where* he does not understand the js... > maybe i just seriously misunderstood you?" > > Well let''s say for example that you wanted to have hyperlinks that open > popup windows. Since "target="_blank"" is deprecated, you''d have to do > a javascript popup. > > But, let''s say you''ve got a blind user using a screen reader. Many > screen readers just don''t understand JS, and popups can be confusing. > So you might just have the link point to the page by default, and use > client-side js to "apply" the popup by changing the href from ''foo.htm'' > to ''javascript:popup(''foo.htm'')''. > > The same can be true for "show/hide" elements on a page.... Show them > all when no javascript is enabled, and use client-side js to create the > "show / hide all" link on the page as well as hide elements on the page > load. > > I also might find that instead of using the same "onclick="foo{params, > parsms, params)", I have a common file that I could reference. > > Just like prototype.. Why do ''getElementByID(''foo'')'' when you can do > $(''foo''); > > 2. "how is that helpful? i''d say the most important thing is that the > code you generate is understood by the application you want to support > (pragmatic view of things, i know) and if i think about the fact that > the most-widely-used browser - alas - still cannot fully deal with > css2.0, i don''t see how standard-compliance on the web-application side > can further accessibility :-)" > > Accessible means accessible... By anyone on any platform. Those with low > vision might require screen readers.... Those with old browsers still > want to buy your product. Those with fine motor skill impairments have > difficulties using the mouse, so you''re careful how you make things > appear and disappear based on events.... Etc. > > A great start to achieving this is to ensure that your XHTML and CSS is > valid. If you''ve got "onClick" all over the place, you''re not going to > have valid docs... And you''re going to skip validating because you > *know* it won''t be valid. > > I would say that your application (especially if you''re attempting to > reach the largest audience possible) is not useful unless it can be used > without css or javascript enabled. It''s not going to be a *fun* > experience, but it doesn''t have to frustrate the user who > happens to be using a 320x240 smartphone to do some quick work. > > Finally, as a person who supports (and occasionally has to use) > assistive technologies, I want to do what I can to make the Web a little > more friendly and accessible. > > 3. content separation: "good point, but that depends on the developer, > not on the standard-compliance of the framework, i''d suggest." > > I agree, but if the majority of the community is using the built-in > helpers, the framework is negatively contributing to > standards-compliance.... Just like developers who use FrontPage or some > of the .Net widgets out there and thus only support Internet Explorer on > Windows. > > I recommend the following reading for some more examples and strategies: > > http://www.alistapart.com/articles/eatcake > > http://www.onlinetools.org/articles/unobtrusivejavascript/ > > http://www.kryogenix.org/code/browser/ > > > Thank you! I really appreciate your interest in this conversation. If I > can be involved any more, please let me know. I hope I''ve helped make a > few things more clear. > > > Regards, > -Brian > > > > -----Original Message----- > From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > [mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On Behalf Of Tobias Witek > Sent: Thursday, December 01, 2005 11:08 AM > To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > Subject: Re: [Rails] JavaScript, rails, and the W3C > > > hi, > > > A good example would be using JavaScript code that adds the onClick > > events on the client side.... Your XHTML code remains valid, but this > > link > > > > <a id="clickme">Click here for more information</a> > > > > Becomes > > > > <a href="#" onClick="clickme()">Click here for more information</a> > > i fear i don''t get your point. how would that help? you''d have to a) add > the code for adding the onclick() event somewhere (thus not making the > code any shorter) and if a client does not fully support javascript, it > will not matter very much *where* he does not understand the js... maybe > i just seriously misunderstood you? > > > 2. you can provide valid documents (very helpful when creating > > accessible applications) > > how is that helpful? i''d say the most important thing is that the code > you generate is understood by the application you want to support > (pragmatic view of things, i know) and if i think about the fact that > the most-widely-used browser - alas - still cannot fully deal with > css2.0, i don''t see how standard-compliance on the web-application side > can further accessibility :-) > > > 3. You can separate your content from your events > > good point, but that depends on the developer, not on the > standard-compliance of the framework, i''d suggest. > > > given some consideration by the core team. As a developer (and a > > user) of sites that must adhere to various accessibility and standards > > > regulations, this is a concern to me. > > this is a very valid and true point. and considering that you have to > follow certain standards and regulations, most of the things you wrote > above now appear in a different light (to me, at least). i''ll post that > mail nevertheless, maybe thus triggering a fruitful discussion :-D > > maybe you could point out to me what i did not understand (see above). > > best regards, > > t > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails