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.
-John On Mon, Aug 10, 2009 at 8:31 AM, Albert Llop <[email protected]> wrote: > 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: > > <form ..> > <label for="user_name">Name:</labrl> > <input ... /> > </form> > > In my experience you only need extra markup on radio buttons and checkboxes > to make it look decent. Decent enough for scaffolding at least: > > Do you agree? > <div class="radios"> > <radio> <label for="user_agree_yes">yes</label><br /> > <radio> <label for="user_agree_no">no</label> > </div> > > > -- > Albert Llop > > > 2009/8/10 Mislav Marohnić <[email protected]> > > On Mon, Aug 10, 2009 at 11:56, José Valim <[email protected]> wrote: >> >>> >>> 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 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: >> >> <div class="attribute"><b>Name:</b> <%= @person.name %></div> >> >> There's nothing wrong with <B> 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. >> >> >> > > > > -- John Trupiano President SmartLogic Solutions http://www.smartlogicsolutions.com @jtrupiano --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
