Forum: Ruby on Rails RE: JavaScript, rails, and the W3C

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
HOGANBP (Guest)
on 2005-12-01 21:17
(Received via mailing list)
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
michael (Guest)
on 2005-12-02 12:38
(Received via mailing list)
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 S.                  I am the sum total of the parts
mailto:removed_email_address@domain.invalid        I control directly.
http://www.schuerig.de/michael/   --Daniel C. Dennett, Elbow Room
juan.g.hurtado (Guest)
on 2005-12-02 12:47
(Received via mailing list)
Hi all,

2005/12/2, Michael S. <removed_email_address@domain.invalid>:
> 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
[ removed_email_address@domain.invalid ]
[ http://armonia.spiral-static.org/ ]
Graeme N. (Guest)
on 2005-12-04 00:27
(Received via mailing list)
Some other good sites that advocate unobtrusive javascript:

http://www.bobbyvandersluis.com/

http://www.quirksmode.org/

Thanks
graeme
This topic is locked and can not be replied to.