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 (http://www.w3schools.com/TAGS/tag_dl.asp); 4) Wrap footer links (Show and Back) in paragraphs. 5) Remove inline CSS from: <p style="color: green"><%= flash[:notice %></p> And wrap it around a html class. What are your point of view for each item?
On Mon, Aug 10, 2009 at 11:56, José Valim <jose.valim@gmail.com> 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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ć <mislav.marohnic@gmail.com>> On Mon, Aug 10, 2009 at 11:56, José Valim <jose.valim@gmail.com> 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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 <mrsimo@gmail.com> 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ć <mislav.marohnic@gmail.com> > > On Mon, Aug 10, 2009 at 11:56, José Valim <jose.valim@gmail.com> 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
Just a note: radio is not generated on scaffold. On Aug 10, 2:31 pm, Albert Llop <mrs...@gmail.com> 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ć <mislav.maroh...@gmail.com> > > > On Mon, Aug 10, 2009 at 11:56, José Valim <jose.va...@gmail.com> 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.
On 10-Aug-09, at 7:34 AM, Mislav Marohnić wrote:> > 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 Mon, Aug 10, 2009 at 9:31 AM, Albert Llop<mrsimo@gmail.com> 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ć <mislav.marohnic@gmail.com> >> >> On Mon, Aug 10, 2009 at 11:56, José Valim <jose.valim@gmail.com> 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. >> > > > > >
> 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 (http://www.w3schools.com/TAGS/tag_dl.asp);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. On 10 ago, 06:56, José Valim <jose.va...@gmail.com> wrote:> 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 (http://www.w3schools.com/TAGS/tag_dl.asp); > > 4) Wrap footer links (Show and Back) in paragraphs. > > 5) Remove inline CSS from: > > <p style="color: green"><%= flash[:notice %></p> > > And wrap it around a html class. > > What are your point of view for each item?
I agree with all said above. I think you should put one more option to choice formats in scaffold. Something like --format=xml,html,json --actionformat=index,rss So, i can choice what format will be present at controller, maybe per action too. Nowadays scaffold put html and xml by default, but i think xml isn''t a good option to be pressent in every action by default. It''s just an ideia.
Here''s my say on the points. 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. Ryan On Aug 10, 2:56 am, José Valim <jose.va...@gmail.com> wrote:> 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 (http://www.w3schools.com/TAGS/tag_dl.asp); > > 4) Wrap footer links (Show and Back) in paragraphs. > > 5) Remove inline CSS from: > > <p style="color: green"><%= flash[:notice %></p> > > And wrap it around a html class. > > What are your point of view for each item?
On Mon, Aug 10, 2009 at 14:31, Albert Llop <mrsimo@gmail.com> 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.Albert, while talking about <b> we were actually talking about markup on "show" page, not the form. Of course that form labels should be marked with <label>; in fact, the generated code should use the label helper. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Aug 11, 5:54 am, Kivanio <kiva...@gmail.com> wrote:> I think you should put one more option to choice formats in scaffold. > > Something like --format=xml,html,json --actionformat=index,rss-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. Ryan
On Aug 10, 5:56 am, José Valim <jose.va...@gmail.com> wrote:> 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 (http://www.w3schools.com/TAGS/tag_dl.asp);Don''t care. Implementer''s judgment call.> 4) Wrap footer links (Show and Back) in paragraphs.Don''t care. Implementer''s judgment call.> 5) Remove inline CSS from: > > <p style="color: green"><%= flash[:notice %></p> > > And wrap it around a html class.+1. Good practice. Dan Croak @Croaky
I know Ryan i have one too. I agree with you however i think xml should be removed. As you said just html will be enough to beginners. Kivanio Barbosa Cel +55 65-8121-4248 Blog: www.kivanio.com.br Company: www.eiqconsultoria.com.br On Tue, Aug 11, 2009 at 10:29 AM, Ryan Bates<ryan@railscasts.com> wrote:> > On Aug 11, 5:54 am, Kivanio <kiva...@gmail.com> wrote: >> I think you should put one more option to choice formats in scaffold. >> >> Something like --format=xml,html,json --actionformat=index,rss > > -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. > > Ryan > > >
> Nowadays scaffold put html and xml by default, but i think xml isn''t a > good option to be pressent in every action by default.This is being handled differently. You should be able to put in your application controller: respond_to :html, :xml, :json And use respond_with in your actions to deal with different formats. No need to handle it in scaffold. More information at: 1) http://ryandaigle.com/articles/2009/8/6/what-s-new-in-edge-rails-cleaner-restful-controllers-w-respond_with/ 2) http://blog.plataformatec.com.br/2009/08/embracing-rest-with-mind-body-and-soul/
On Tue, Aug 11, 2009 at 16:19, Ryan Bates <ryan@railscasts.com> wrote:> > Here''s my say on the points. > > 3) -1 Keep it <p> but use <strong> instead of <b>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 <b> elements to <strong> isn''t a sign of being a good HTML citizen. The <b> 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 <p> 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 <b> is bad because it''s non-semantic, that''s going away in the near future and that it should always be replaced with <strong>. But in fact, <b> 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> 4) +1 Isn''t it invalid markup not to have it in a <p> 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 <div class="actions"> and let users decide what to do with that. --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
José, i saw this last week, it''s amazing. I just mention about formats to document what format will be default. Kivanio Barbosa Cel +55 65-8121-4248 Blog: www.kivanio.com.br Company: www.eiqconsultoria.com.br On Tue, Aug 11, 2009 at 11:06 AM, José Valim<jose.valim@gmail.com> wrote:> >> Nowadays scaffold put html and xml by default, but i think xml isn''t a >> good option to be pressent in every action by default. > > This is being handled differently. You should be able to put in your > application controller: > > respond_to :html, :xml, :json > > And use respond_with in your actions to deal with different formats. > No need to handle it in scaffold. More information at: > > 1) http://ryandaigle.com/articles/2009/8/6/what-s-new-in-edge-rails-cleaner-restful-controllers-w-respond_with/ > 2) http://blog.plataformatec.com.br/2009/08/embracing-rest-with-mind-body-and-soul/ > > >
On Aug 11, 8:10 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:> 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. Regards, Ryan
On Aug 11, 10:37 am, Ryan Bates <r...@railscasts.com> wrote:> 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.Aren''t we moving to HTML5? - Trevor
On Tue, Aug 11, 2009 at 1:29 PM, Trevor Turk<trevorturk@gmail.com> wrote:> > On Aug 11, 10:37 am, Ryan Bates <r...@railscasts.com> wrote: >> 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. > > Aren''t we moving to HTML5? >I would argue that we don''t make HTML5 anything close to a default until at least after October when the "last call" working draft is finished.
On Tue, Aug 11, 2009 at 22:41, Mark Turner <mark@amerine.net> wrote:> > I would argue that we don''t make HTML5 anything close to a default > until at least after October when the "last call" working draft is > finished.Oh, you might wanna take a look at this then: http://github.com/rails/rails/commit/01d92021e69f54def1ec8103b2b99f907dd88ec4 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Aug 11, 2009 at 2:34 PM, Mislav Marohnić<mislav.marohnic@gmail.com> wrote:> Oh, you might wanna take a look at this then: > http://github.com/rails/rails/commit/01d92021e69f54def1ec8103b2b99f907dd88ec4Good point. I''m doing HTML5 stuff on my own, and I guess I haven''t seen any discussions here regarding switching to HTML5 in the scaffolding so I assumed we were waiting until the spec is finished. (Not that the markup Josh added to scaffolding will change at all, that stuff is hammered down).
1) Yes.
2) Yes.
3) Yes.
4) Not sure. Just don''t name it "footer". I''d really
prefer that they
were buttons sitting next to the Create/Update submit buttons.
Speaking of which, the P surrounding those should probably be a DIV,
and should at least have a class added. It would also be nice to have
an HR between the form and the submit buttons.
5) Yes. Although I''d prefer it more the way
http://railscasts.com/episodes/18-looping-through-flash (and comments)
do it:
<%- if flash -%>
<div class="flash">
<%- [:error, :warning, :notice, :message].each do |key| -%>
<%= content_tag :div, flash[key], :class => key if flash[key] %>
<%- end -%>
</div>
<%- end -%>
> Rails 3.0 generators will be customizable per application.
Yay! It''s a pain to override them in 2.3.
Craig Buchek
BoochTek, LLC
It is out of the discussion I think but please, please, make the scaffold generator understand simple nested resources so the controller has a ''load_parent'' before_filter and the views use the correct nested named routes. That would make it way easier for beginners to understand how restful resources work. On Aug 10, 6:56 am, José Valim <jose.va...@gmail.com> wrote:> 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 (http://www.w3schools.com/TAGS/tag_dl.asp); > > 4) Wrap footer links (Show and Back) in paragraphs. > > 5) Remove inline CSS from: > > <p style="color: green"><%= flash[:notice %></p> > > And wrap it around a html class. > > What are your point of view for each item?
Just pushed some changes.> 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.DONE.> 2) Change forms to use <ol> and <li> instead of paragraphs;Forms now use div with class "attribute" for inputs and "action" for buttons.> 3) Change show view to use definition list (<dl>), instead of > paragraphs and bold (http://www.w3schools.com/TAGS/tag_dl.asp);Kept paragraph with bold.> 4) Wrap footer links (Show and Back) in paragraphs.Remained the same.> 5) Remove inline CSS from: > > <p style="color: green"><%= flash[:notice %></p> > > And wrap it around a html class.Changed to: <p class="notice"><%= flash[:notice] %></p> That''s all.
The commits are: http://github.com/rails/rails/commit/5d645c271b350c2a3ed7fd835e539322cda61d8c http://github.com/rails/rails/commit/5096ba961c49e5b419c3400acd7c87373a36d6d4 On Aug 30, 6:11 pm, José Valim <jose.va...@gmail.com> wrote:> Just pushed some changes. > > > 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. > > DONE. > > > 2) Change forms to use <ol> and <li> instead of paragraphs; > > Forms now use div with class "attribute" for inputs and "action" for > buttons. > > > 3) Change show view to use definition list (<dl>), instead of > > paragraphs and bold (http://www.w3schools.com/TAGS/tag_dl.asp); > > Kept paragraph with bold. > > > 4) Wrap footer links (Show and Back) in paragraphs. > > Remained the same. > > > 5) Remove inline CSS from: > > > <p style="color: green"><%= flash[:notice %></p> > > > And wrap it around a html class. > > Changed to: <p class="notice"><%= flash[:notice] %></p> > > That''s all.