One of the best talks at Railsconf was given by John Athayde on Curing Div-itis with Semantic Html, CSS, and Presenters. John was nice enough to redo his talk for me at the conference so I could properly capture it and share it with you. In his talk he goes through several techniques they employ at InfoEther to create beautiful markup in their web applications.
If you dig this talk be sure to subscribe to the RSS feed, I have one other awesome Railsconf talk to crank out.
Useful Links from John’s Talk:
- Download the Slides
- InfoEther
- CSS Cheat Sheet
- HTML5 Cheat Sheet
- Zen Coding
- §508
- WAI Level 1 Checklist
- Using before and after
- Using before and after in IE
- Jay Fields old blog post on Presenters
- SASS
- CSS Sprites
- Sprites with Rails
- toupee
- InfoEther Base App
- jammit
- startups
- Dust Me Selectors
- Deadweight
- Rack::Tidy
Awesome. What a rad talk.
I’m so glad someone has stepped up and started to point out the bad view practices with Rails and semantic markup.
great job!
I meant to ask during the talk, but didn’t. Maybe someone reading this can answer? On the slide “Helpers – Summarization is where they shine” — What approach do you take to keep HTML out of the helpers if you wanted the referrer name in “Referred by XXX” to be a link to that person’s account? How do you not put a link somewhere in a helper behind the conditional determining which info to output?
Gavin -
I’d say that you could use something like a link_to in that instance. The point is to not have say, etc in the helper. It would also be something that perhaps the view itself has the “referred by” text and the helper simply returns the value from logic. then you’d have link_to referrer, user_path(referrer) or something like that. I don’t personally find link_to, etc. bad in helpers but there’s that line you’ll have to determine on your own app as to how you want to standardize your view code.
[...] Beautiful Markup « Envy Labs – John Athayde on Curing Div-itis with Semantic Html, CSS, and Presenters. Redone for Gregg Pollack and luckily put online. [...]
John, thanks for responding. I understand you on the link_to in a helper, but personally I’ve found that once I take that step its easy to go crazy (as I’ve done in helpers in the past) When I find that I’m doing anything more complicated than a one-liner I try to turn those into objects that are easier to manipulate/test but still generate HTML. Its not quite a presenter, but also not a loose collection of helper functions.
[...] Athayde gave this great video of a presentation from Rails Conf 2010 on writing good view code. Filed under: Clips Leave a comment Comments [...]
John Athayde – What is you view on the CSS framework Compass? http://compass-style.org/
Gavin, there are exceptions to every rule. I think a simple link or image tag is fine, especially if you’re factoring out some repetitive display code into a nice method like “link_to_profile_name(person)” or “link_to_avatar(person)”.
Even in his presentation, John says he endorses the “image_sprite” helper that spits out markup, since the payoff is so high. Keep it lean, keep it clean, I think that’s the rule of thumb.
[...] really need to watch this presentation from RailsConf on Beautiful Markup by John [...]
[...] to get two of my favorite talks on video. Two weeks ago I published John Athayde’s talk on Beautiful Markup, and today I’m happy to publish Joe Damato’s talk on Garbage Collection & the Ruby [...]
Gavin – Karle’s summed up what I was going to say. It really comes down to a benefit analysis at a point. Start with guiding principles and then break them when necessary.
Phil – I’m not a huge fan of any framework, mainly because I’ve seen non-techies in larger teams just go cross-eyed when trying to work with them. We had our own (Shway) that was quite powerful and had skins, skeletons, presenters, and ruby-driven CSS. We ended up removing it from all our projects because only a few people in the company could work with it. These things tend to be great for an individual or small team that knows what they are doing with them.
I think there are some cool elements to Compass (and SASS as well) but I personally tend to avoid them. The most important factor is figuring out if your team can use it and that the project will benefit from its use. If either answer is no, I’d think twice before pushing it forward.
Haml produces very clean code which is easy to understand. You can also write view code quicker with Haml. Its also easy to learn. How can this not be beneficial?
Sticking with html just because that’s what everybody knows is not generally a great attitude for moving things forward. Html is damn ugly and I welcome any efforts that allow me to write it quicker.
I use ruby because It allows me to write decent code quickly & easily. I use haml for that same reason.
+1 to what Chris said.
One can apply all the good practices from this talk while using Haml, which will give you a *substantial* increase in readability of your views, for free.
HTML is just too verbose and repetitive. The least that Haml will do for you is cutting out all that redundancy. Tools like “ZenCoder” are a crutch for those cases where Haml is not available (I have nothing against ZenCoder & friends, I think they are quite elegant tools).