Beautiful Markup

6.21.10 by Gregg Pollack

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.

View video on viddler

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:

Related posts:

  1. Rails 3 Beautiful Code
  2. Garbage Collection & the Ruby Heap
  3. No Callbacks, No Threads & Ruby 1.9

39 Responses to “Beautiful Markup”

Comments

  1. MIchael says:

    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!

  2. Gavin Stark says:

    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?

  3. John Athayde says:

    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.

  4. [...] Beautiful Markup « Envy Labs – John Athayde on Curing Div-itis with Semantic Html, CSS, and Presenters. Redone for Gregg Pollack and luckily put online. [...]

  5. Gavin Stark says:

    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.

  6. [...] Athayde gave this great video of a presentation from Rails Conf 2010 on writing good view code. Filed under: Clips Leave a comment Comments [...]

  7. Phil McClure says:

    John Athayde – What is you view on the CSS framework Compass? http://compass-style.org/

  8. karle says:

    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.

  9. [...] really need to watch this presentation from RailsConf on Beautiful Markup by John [...]

  10. [...] 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 [...]

  11. John Athayde says:

    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.

  12. Chris says:

    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.

Leave a Reply

* Required Fields

Additional comments powered by BackType