There are around 5 tickets on Lighthouse (probably more) about
changing Rails scaffold. I would like to summarize the requests here,
so we can finally agree in a solution.
First of all, in Rails 3.0 generators will be customizable per
application. You will be able to throw your templates in lib/templates
and they will be picked on generation.
This enforces the point of view that Rails default scaffold should be
a starting point, not only for applications, but also for people who
are starting with Rails. This is important to know because we have to
ponder things like:
1) Should we put forms in a _form partial? On the same way this is the
"best practice", we are adding more code for people to grasp at the
beginning.
Another proposed changes are:
2) Change forms to use <ol> and <li> instead of paragraphs;
3) Change show view to use definition list (<dl>), instead of
paragraphs and bold (HTML dl tag);
4) Wrap footer links (Show and Back) in paragraphs.
I agree with the _form partial. All beginner Rails tutorials stress out the DRY convention and here we are, generating duplicate code and not teaching people the power of partials in the very first entry point to the framework that newcomers usually take.
As for semantic markup: I’d definitely get rid of paragraphs—especially if they contain form fields or links that represent user actions (paragraphs are for text)—but I wouldn’t go crazy with “semantic” markup. I would put everything in DIVs since they’re neutral and maybe give them simple classnames. Example:
Name: <%= @[person.name](http://person.name) %>
There’s nothing wrong with element here. We want to bold the word without giving it semantic emphasis (like we would with STRONG).
Take a quick glance at SimpleQuiz archive <http://simplebits.com/notebook/simplequiz/> to understand why introducing semantic markup like (definition) lists is probably a bad idea. Each post from this archive represents a seemingly simple problem and a number of possibilities to lay it out in completely different ways. Also, most posts are followed by tens or even hundreds of comments with other people contributing their ideas and solutions. In the end of the day, no markup style is a clear winner over the alternative.
We don’t want this to happen in the Rails bug tracker with scaffolding markup. Some people prefer to markup their forms with DIVs (like me), others with definition lists, some professionals even mark up form fields with tables because, contrary to the popular belief, they can be accessible as well.
In short: let’s keep this markup simple and neutral by mostly using the non-semantic DIV. The markup doesn’t have to be perfect; it’s just that we should get rid of the really bad things like using paragraphs for everything just because they have default margins in browsers. That is like using BLOCKQUOTE only to indent content.
On mislav’s comment I just have to add that it makes no sense to use when you can use , and if you want the scaffold to have labels show bold, then use css.
Also, personally don’t think you need any extra markup at all, but maybe that’s just me. The simplest form you could have would be something like:
Name:
In my experience you only need extra markup on radio buttons and checkboxes to make it look decent. Decent enough for scaffolding at least:
The other argument for using div’s (vs. dictionary or unordered lists) is that standard error markup wraps the elements in divs. When you use p’s, dd’s or ul’s, the markup rendered back is invalid XHTML.
I agree with the _form partial. All beginner Rails tutorials stress out the DRY convention and here we are, generating duplicate code and not teaching people the power of partials in the very first entry point to the framework that newcomers usually take.
+ 1
As for semantic markup: I'd definitely get rid of paragraphs—especially if they contain form fields or links that represent user actions (paragraphs are for text)—but I wouldn't go crazy with "semantic" markup. I would put everything in DIVs since they're neutral and maybe give them simple classnames.
+ 1. In the absense of a proper semantic tag for form elements, I agree that divs are the way to go.
On mislav's comment I just have to add that it makes no sense to use <b>
when you can use <label>, and if you want the scaffold to have labels show
bold, then use css.
Also, personally don't think you need any extra markup at all, but maybe
that's just me. The simplest form you could have would be something like:
That's invalid HTML, you need block elements inside a <form>.
What block element? I don't really care. If user's will be able to
override the generator templates by putting their own in lib, then,
since *everyone* has a different "Right Way" to solve this, let
everyone solve this their own way markup-wise. I'd probably go with
the most agnostic way (a <div>) and let people override it if they
have a better way of solving it.
Regarding the _form partial, removing inline CSS, and all that, +1.
1) Should we put forms in a _form partial? On the same way this is the
"best practice", we are adding more code for people to grasp at the
beginning.
I think the partial is the best way to keep code DRY, even beginners
would learn partials and it's magic easier and faster than anything
else inside Rails.
2) Change forms to use <ol> and <li> instead of paragraphs;
3) Change show view to use definition list (<dl>), instead of
paragraphs and bold (HTML dl tag);
I agree with everybody, using div's and letting the developer choose
whiatever he wants by changing his own template.
4) Wrap footer links (Show and Back) in paragraphs.
Paragraphs would be nice here, or maybe just div's..
5) Remove inline CSS from:
I agree.. What I see more and more people doing is looping through the
flash hash and create a message for each one, using css classes like
'flash' + 'notice' or 'error'. That would be a nice change to put it
inside scaffold.css.
1) +1 on _form partial. We had this before and I didn't hear anyone
confused by it.
2) -1 Either keep it <p> tag or use <div>
3) -1 Keep it <p> but use <strong> instead of <b>
4) +1 Isn't it invalid markup not to have it in a <p> tag?
5) +1 Since it generates a CSS file it makes sense to keep all styling
in there.
Albert, while talking about we were actually talking about markup on “show” page, not the form. Of course that form labels should be marked with ; in fact, the generated code should use the label helper.
-1 on adding a "--format" option. It will be much easier to add/remove
this afterwards in Rails 3 scaffold. Also I think the built-in
scaffold is intended to be an example for beginners on what is
possible. If you want a robust scaffolding solution which you use in
every-day development there are other generators out there (such as my
nifty_scaffold) or you can create your own.
There are around 5 tickets on Lighthouse (probably more) about
changing Rails scaffold. I would like to summarize the requests here,
so we can finally agree in a solution.
Move the scaffold in the direction of Formtastic, which is the leading
edge of ideas in Rails forms.
1) Should we put forms in a _form partial? On the same way this is the
"best practice", we are adding more code for people to grasp at the
beginning.
Yes, but I've never liked the name "_form". It's used to make the
render :partial line more readable but isn't an intention-revealing
name.
I prefer "_inputs".
2) Change forms to use <ol> and <li> instead of paragraphs;
+1. More like Formtastic, but the point is these decisions shouldn't
matter. Jose / someone on Rails core... just make them. You're going
to get flooded with semantic arguments that aren't helpful.
3) Change show view to use definition list (<dl>), instead of
paragraphs and bold (HTML dl tag);
Don't care. Implementer's judgment call.
4) Wrap footer links (Show and Back) in paragraphs.
Ryan, here you’re encouraging the exact type of cargo cult markup which—in my opinion—Rails should stop teaching, and these changes are the right opportunity to do that.
Blindly changing all elements to isn’t a sign of being a good HTML citizen. The element was there in the first place to give a visual style to the attribute name in order to separate it from attribute value. Is there any reason for turning it into an actual emphasis? If so, why not emphasise the attribute value, rather than name? And if you care about semantics that much, why keep the key-value pairs in
elements which are clearly not intended for that?
I’m not bikeshedding, I just want that each proposal or change in the markup is accompanied by solid arguments about why exactly someone wants that; otherwise it’s just cargo culting. Typical cargo-culting in Rails community and Railscasts is that paragraph should be used for whenever you want to just nicely space out some content. Another example in general web development world is that everyone thinks that is bad because it’s non-semantic, that’s going away in the near future and that it should always be replaced with . But in fact, is perfectly all-right, has valid uses and it’s not going away—here it is in the HTML5 spec http://dev.w3.org/html5/spec/Overview.html#the-b-element
+1 Isn’t it invalid markup not to have it in a
tag?
No, why would it be invalid? If you ask me it’s better not to wrap navigation links than to put them in an element that was definitely not intended for them. I think footer actions should be wrapped in
Blindly changing all <b> elements to <strong> isn't a sign of being a good
HTML citizen.
Fair enough. The <b> tag is fine.
> 4) +1 Isn't it invalid markup not to have it in a <p> tag?
No, why would it be invalid?
It's invalid in XHTML Strict to not wrap inline elements in a block
element (such as a <p> or <div>). But I just realized scaffolding uses
XHTML Transitional so it's not technically invalid there.
