Hello, Are there any resources or tutorials on how to handle browser differences in Rails? I''m mainly talking about when they render HTML and/or CSS differently. Do people set up groups of partials that are browser specific, and and have the template swap in the appropriate partial? Thanks, Avram -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 31, 1:49 pm, Avram Dorfman <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Hello, > > Are there any resources or tutorials on how to handle browser > differences in Rails? I''m mainly talking about when they render HTML > and/or CSS differently. > > Do people set up groups of partials that are browser specific, and and > have the template swap in the appropriate partial? > > Thanks, > Avram > -- > Posted viahttp://www.ruby-forum.com/.here''s some good backgrounders about IE (and other browsers too!): http://www.positioniseverything.net/ http://www.quirksmode.org/bugreports/ http://www.search-this.com/2007/06/19/browser-testing-made-easy/ http://www.456bereastreet.com/archive/200702/browser_testing_css_and_javascript/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
gene tani wrote:> On Oct 31, 1:49 pm, Avram Dorfman <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > wrote: >> Avram >> -- >> Posted viahttp://www.ruby-forum.com/. > > here''s some good backgrounders about IE (and other browsers too!): > http://www.positioniseverything.net/ > http://www.quirksmode.org/bugreports/ > http://www.search-this.com/2007/06/19/browser-testing-made-easy/ > > http://www.456bereastreet.com/archive/200702/browser_testing_css_and_javascript/Thank you, I appreciate those references, they will be helpful. However, what I meant was looking for was good techniques for feeding tweaked output to different browsers - that is, good DRY ways to do it, and avoid having completely separate sets of templates for each type of browser. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 31, 2007, at 2:30 PM, Avram Dorfman wrote:> gene tani wrote: >> On Oct 31, 1:49 pm, Avram Dorfman <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> >> wrote: >>> Avram >>> -- >>> Posted viahttp://www.ruby-forum.com/. >> >> here''s some good backgrounders about IE (and other browsers too!): >> http://www.positioniseverything.net/ >> http://www.quirksmode.org/bugreports/ >> http://www.search-this.com/2007/06/19/browser-testing-made-easy/ >> >> http://www.456bereastreet.com/archive/200702/ >> browser_testing_css_and_javascript/ > > Thank you, I appreciate those references, they will be helpful. > However, > what I meant was looking for was good techniques for feeding tweaked > output to different browsers - that is, good DRY ways to do it, and > avoid having completely separate sets of templates for each type of > browser.If you stick to using valide XHTML and you push all formating and styling to CSS, then 99% of the time you don''t need to render HTML specific to any browser (there''s some edge cases where you do, but I don''t think they''re common). The challenge is getting your CSS definitions to work universally. Most of the time Safari and FireFox agree, and the challenge is getting IE to work. So, the best approach is do your HTML and CSS so that it is "correct" and what you''d expect to work for Firefox/Safari, then check it in IE (all versions you expect to support) and start applying the CSS hacks that are known workarounds for IE. It can a long time to find those hacks, that''s the aggravating part of web design. If you can keep IE in standards mode, it mostly does OK, but you''re goinng to have to do some reading about IE CSS hacks. Those sites above are a good start. There''s a few mainstream techniques for telling CSS to apply things only to IE. Each has some pros & cons. This is MS''s official take on it: http://msdn2.microsoft.com/en-us/library/ms537512.aspx however, that method fails when someone has more than one version of IE installed in their system. Not too common for sure, and generally only affects the browser nerds, but if you have a nerdy site, that''s a big deal. Here''s some other techniques: http://www.webdevout.net/css-hacks#unrecommended -- gw --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Ok, cool. Sounds like you''re saying most people don''t code their rails apps to pay attention to the browser type and feed customized files. Not needing to do that w/ XHMTL make sense, it''s the CSS differences I was wondering about. One thing I was thinking of was pushing the specific CSS elements browsers treat differently into a set of stylesheets, and then feed the user the stylesheet that goes with his browser. Does anyone out there do anything like this? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 31, 2007, at 3:52 PM, Avram Dorfman wrote:> Ok, cool. Sounds like you''re saying most people don''t code their rails > apps to pay attention to the browser type and feed customized > files. Not > needing to do that w/ XHMTL make sense, it''s the CSS differences I was > wondering about. > > One thing I was thinking of was pushing the specific CSS elements > browsers treat differently into a set of stylesheets, and then feed > the > user the stylesheet that goes with his browser. > > Does anyone out there do anything like this?I have done it where I use scripting logic (i/e/ ruby or whatever language is involved) to determine the browser, and then serve CSS files tuned for that browser. This approach can be used for serving user-selected skins too. Now, you don''t need to do whole CSS definitions that way as 90% of it is all identical, but you can do a base sheet, then based on the browser supplement it with ie_overrides.css, ffx_overrides, opera_overrides, and even treo_overrides, etc. Same with skins. A base plus the parts that vary per skin. Depending on how many browsers you do active testing for, or just how much of the CSS has to be different, separate files can make sense. If you''re really only bothering to test for IE 6+, FFx 1.5+ and Safari 2+ and you have a relatively simple design, then really there''s likely to be so few differences that the CSS hacks in one file is probably best. But if you fine tune for a dozen browsers, or you have some tricky stuff that requires quite a lot of overrides, then it starts to become easier to compartmentalize IMO and use separate files (if you''re clean about the separations), but it''s a matter of preference IMO. -- gw --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 31 Oct 2007, at 23:52, Avram Dorfman wrote:> Ok, cool. Sounds like you''re saying most people don''t code their rails > apps to pay attention to the browser type and feed customized > files. Not > needing to do that w/ XHMTL make sense, it''s the CSS differences I was > wondering about. > > One thing I was thinking of was pushing the specific CSS elements > browsers treat differently into a set of stylesheets, and then feed > the > user the stylesheet that goes with his browser. > > Does anyone out there do anything like this?You could use this: http://rafael.adm.br/css_browser_selector/ Best regards Peter De Berdt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
There are fewer portability problems with HTML 4.01 Strict than with XHTML, so that''s what a lot of authors use. These days you have to send XHTML as text/html anyway so you don''t get the advantages that xhtml could someday provide. When IE8 comes out and has replaced IE7 and IE6 in the field, then you may be able to generally send xhtml as ''xhtml+xml'', permitting use of a real XML parser in the client. Until then, XHTML is still handled as tag soup, not XML. Rails works fine with HTML 4.01 Strict, even though it occasionally produces trailing slashes to close tags (like link tags). See also http://www.hixie.ch/advocacy/xhtml. Using a template language other than erb might give us a point of control that will allow us to make changes automatically. Such as HAML, Markaby, or Malline. In any case, in the controller and the layout, the hash request.env has a name-value pair like this: HTTP_USER_AGENT => ''Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: 1.8.1.9) Gecko/20071025 Firefox/2.0.0.9'' For IE it would be different. You can display this string on a test page with: <p> HTTP_USER_AGENT: <%= request.env["HTTP_USER_AGENT"] %></p> And figure out how to parse it. Or you could dump it using logger. Then write a method to return the header code you like. There is also an request.env["HTTP_ACCEPT"], which includes weird but interesting stuff. fredistic --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Avram Dorfman wrote:> Do people set up groups of partials that are browser specific, and and > have the template swap in the appropriate partial? > > Thanks, > AvramI feel your pain. I''m relatively new to this game, and am going through this with my first major Rails app which is also my first commercial-grade website attempt. On the one hand I have to say that I''ve felt the need for something like you''ve described -- some sort of DRYer way to deal with these issues -- but I''ve decided to just wait it out. I find IE7 to be much much closer to Safari and FF. IE6 is dead except for corporate users who''s IT departments are trying to solve all of the various problems encountered with moving their legacy internal intranet stuff to IE7. That work couldn''t start until IE7 was released, and is ongoing now. As soon as large numbers of companies start to adopt IE7, we can all breathe a sigh of relief as this major PITA drops back to just a minor nuisance. I think for any new project starting after the first of the year, there is a strong case to be made for just including a startup check for IE6 (and earlier) that politely suggests the user join the new millennium. By the time such a new project is ready to launch IE6 should be down below 20 percent and dropping fast. This is especially true for social networking and other such sites that theoretically should have most of their users outside of the workplace (I said theoretically). With IE6 out of the way, dealing with browser issues won''t go away, but will likely drop back to just an hour or two of tweaking some positioning compared to the nightmare it is today. Then web development will be fun. jp -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---