One of the most annoying thing with Rails has always been how it provides for convenience at the expense of uncertain (and sometimes shady) abstraction implementations. It’s a great framework for prototyping, yet there are reasons why quite a few people are skeptical about it.
Nevertheless, in the truest tradition of Ruby, Rails provides a pretty clean way to do web application development. Rails 3, the latest incarnation of the framework builds upon a solid foundation, offering great improvements in many areas. But not everywhere.
Take for example the html_safe string escaping that supersedes ‘h’. In Rails 3, all input strings are automatically escaped, unless the developer passes the string through raw() before the string. That’s fine, as it’s bound to make sloppy developers safer by forcing them to go out of their way to leave the string unescaped. One of the issues with this, however, is how the old way of escaping, ‘h’, is still around in some cases: say when you want to render a link using link_to and you use raw to provide formatting to your link (via span) and include some part of user provided input (as found in the example provided in the xss and scripting screencast at 02:20), then you have to resort — once again — to using ‘h’.
This is confusing and inconsistent; if all strings are automatically escaped, you’d expect input variables to be automatically escaped too, even if included in strings using raw().
