Ruby and Standards

**ChestRockwell** · Jan 11, 2006, 13:33

Hi everyone,
I am wondering how well does ruby comply with web standards. I watched part of that video where the guy creates a weblog in 15 minutes. That is great, but if the html that is created is total crap, then I know for me, its totally worthless. So, can I develop with Ruby apps using standards based design. Just to clarify, when I say standards I mean strict XHTML, tableless design using CSS and all of that stuff.

Joe

**vgarcia** · Jan 11, 2006, 13:48

That's all easily doable with Rails, since the functions that return HTML tend to comply with XHTML.

You do have to watch out for ugly Javascript though. Using Rails's built-in functions like link_to_remote can leave you with a link like this:

HTML Code:

<a href="#" onclick="new Ajax.Request('/test/123');">Test</a>

This is pretty easy to get around though, especially if you're somewhat handy with Javascript to begin with.

**Dr Livingston** · Jan 11, 2006, 14:18

In this day and age, you really shouldn't attach an event handler to an element in that manner; Instead what you do is to attach the event handler to the element from within javascript, via the DOM is needs be,

Code:

<head> ...
// my javascript is a bit rusty, but...
a = document.getElementsByTagName( 'a' )[0];
// then attach event handler this way

I believe using

Code:

<a href="#" onclick="new Ajax.Request('/test/123');">Test</a>

Is sematically wrong yes?

**vgarcia** · Jan 11, 2006, 14:55

Originally Posted by Dr Livingston

In this day and age, you really shouldn't attach an event handler to an element in that manner; Instead what you do is to attach the event handler to the element from within javascript, via the DOM is needs be,

Code:

<head> ...
// my javascript is a bit rusty, but...
a = document.getElementsByTagName( 'a' )[0];
// then attach event handler this way

I believe using

Code:

<a href="#" onclick="new Ajax.Request('/test/123');">Test</a>

Is sematically wrong yes?

It's not necessarily semantically wrong (but I wouldn't call it "right" either), it will just fail if Javascript isn't available. Unfortunately, that's the way Rails's AJAX functions work by default, but as I said earlier it's easy to get around (use regular links/link_to Rails functions and define event handling elsewhere, like in a separate .js file).

**bonefry** · Jan 11, 2006, 15:17

Originally Posted by Dr Livingston

In this day and age, you really shouldn't attach an event handler to an element in that manner; Instead what you do is to attach the event handler to the element from within javascript, via the DOM is needs be

Not true.
Manipulating the DOM tree for such simple things as event designation is worthless and error-prone.

And when you see a link like:
<a href="javascript:void(0);" id="myLink">Test</a>
What does the link tell you about its destination ?
Wouldn't you have to look in another file. where the javascript is, and search for the piece of code that assigns to element `myLink`the onclick event ?
And yes, in this day and age the javascript has to be in another file because that's the way search engines like it.

**lirux** · Jan 11, 2006, 16:26

They recently added RJS templates, which I haven't tried out yet, but seem to address this problem.

An intro to RJS templates: http://www.codyfauser.com/articles/2...-rjs-templates

**Luke Redpath** · Jan 11, 2006, 17:53

RJS templates don't completely solve the problem but you can forgo the built in AJAX helpers like link_to_remote and integrate using your own scripts and something like the behavior library.

**Dr Livingston** · Jan 12, 2006, 10:29

Bonefry,

My comments were in reference to web standards, from what I can recall the W3C suggest that putting event handling within HTML is wrong; That is why I suggested the alternative. Consider the oft debated topic of putting PHP within HTML - it's the same principle really, and for the same reasons actually

Weather or not the Javascript resides in a separate file is not here nor there, if like me you build up the page dynamically, you can put functional Javascript for that specific page, and no other, within the HEAD of that template fragment, ie

PHP Code:


<head>

<?php echo( @$nodes['header'] ); ?></head><body>...

On the otherhand, if there is Javascript that is required over a number of pages, yes you separate that Javascript to a separate file, obviously. Since when has search engines got anything to do with it anyway?

Does anyone know of any search engines that actually search a Javascript file? I don't... The major engines usually ignore the <script /> tag. The reason you use a separate file is for the same reasons CSS is a separate file; definitely not because of search engines

That isn't really the point anyway, the point is complying with web standards, and following them standards.

They suggest don't embed your Javascript, you of course, can suggest something else

**Fenrir2** · Jan 12, 2006, 11:06

I suggest that you do the simplest thing. You don't embed javascript in your HTML because it will be hard to maintain. If you are using link_to_remote it makes it easier to maintain than having javascript in your head-tag.

I think that you should not just follow web standards because they are webstandards, and therefor right. You should do what fits best, and link_to_remote fits perfectly most times.

But what is the bad XHTML in the video? The HTML that gets generated by link_to/etc is XHTML strict. Tables are used for tabular data, correct. And you can alter all HTML that is outputted, even the HTML of built-in functions like link_to().

**lirux** · Jan 12, 2006, 11:46

You can always decide not to take advantage of rails' built-in javascript helpers, and do it your way. You can even still take advantage of rails routing while doing it, for instance, instead of link_to_remote, you can use

Code:

<a href="<%= url_for :controller => "bla", :action => "bla" %>" id="bla">

And then put your javascript/dom calls on an external file (or wherever you want).

**Fenrir2** · Jan 12, 2006, 12:41

But that would produce the same HTML as link_to ;-)

**lirux** · Jan 12, 2006, 13:22

Originally Posted by Fenrir2

But that would produce the same HTML as link_to ;-)

Indeed, serves to proove there are many ways to reach it, however I thought using url_for was easier to understand for the uninitiated than

Code:

<%= link to "bla", {:action => "bla", :controller => "bla"}, {:id => "bla"} %>

the {}s make this code slightly more difficult IMO.

**rossriley** · Jan 18, 2006, 14:50

I'm with the Dr on this.
having onclicks in your html is the equivalent of wrapping font tags around your html.
the three layers of separation are content, presentation and behaviour. The only way to produce valid html documents at the moment is to use the behaviour library and link behaviours to CSS selectors.

A list apart did an article about a year ago which suggested creating a custom attribute.... ie.
<a href='link' behaviour='behaviour'></a> but to get that to validate you have to create your own DTD. So in my opinion, behaviour library is the best way to go at the moment.

**Luke Redpath** · Jan 18, 2006, 17:12

Also, there isn't really a valid reason for creating a custom attribute as there isn't anything that says class cannot be used to indicate behaviour. Its simply used to classify elements whether that be by behaviour or style.

**Fenrir2** · Jan 19, 2006, 05:06

This is interesting:

http://bennolan.com/behaviour/

Use classes and hook up Javascript with CSS selectors.

**Radley** · Jan 21, 2006, 19:22

There was a big discussion about Rails's inline JS helpers on the mailing list:

http://thread.gmane.org/gmane.comp.l...by.rails/15668

The conclusion was that the core team didn't think that it was worth the necessary effort.

**MiiJaySung** · Jan 22, 2006, 17:51

Going back to the point, The markup you produce is totally independant of Rails it's self and you have total control when you edit the templates. You will find most rails applications do spit out good quality CSS / XHTML as most Rails users are web-standards aware.

While Rails has scaffolding which again produces reasonable quality XHTML, you will want to move code away from scaffolding, as many suggest for reasons totally unrelated to markup.

The onclick stuff that's mentioned abover can safely be ignored. 99% of the time you will not want to be using AJAX, and any well designed application should be able to be functional without the use of AJAX (unless it's something very unusual). You will probably only need to use AJAX for more demanding interfaces, which generally speaking tend to be restricted to admin backends etc, where it's not so bad to expect users to have JS to be enabled (likewise I'm not quite as fussed in admin backends about markup, as I'll use the odd table here if it makes life a lot easier)

The SitePoint Forums have moved.

User Tag List

Thread: Ruby and Standards

Thread Tools

Display

Ruby and Standards

Bookmarks

Bookmarks

Posting Permissions