On Mon, Aug 10, 2009 at 9: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>
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. Cheers, -foca > 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. >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
