I have The Next Big Idea: Typically, one could have the following setup:
- in app/views/something/_form.html.haml: .something_form %input.whatever .... .... - in public/stylesheets/sass/something/_form.sass: .something_form :border 1px solid black ... THE PROBLEM (with the above approach and/or with *not* using the above approach when styling partials) - That "something_form" HTML class name needs to be cleverly thought out to make sure it's easy to remember *and* no other CSS (Sass) files use it. - The same name must be used in the Sass file as the Haml file, a source of typos. - Naming conflicts typically lie under the radar for ages, at which point completely separate styles are mingled and separating them is a chore. - One must remember to put the classes in both Haml and Sass files. - The entire Sass file is indented more than it need be, assuming the convention that anything in public/stylesheets/sass/something/ _form.sass is *only* meant to apply to the partial app/views/something/ _form.html.haml In summary, there is no stylesheet namespacing and it is cumbersome to enforce it through best practices. THE SOLUTION Imagine, if you will: In app/views/something/_form.html.haml: ...whatever you want... In public/stylesheets/sass/something/_form.sass ...whatever you want... And without any extra code, you are guaranteed that your styles in something/_form.sass apply *only* to the something/form partial. (This strategy would probably work very well with mix-ins, e.g., something/ form's inputs would mix-in a global "fun_looking_input_box" as would something_else/form's input.) Brief summary: namespacing by filename conventions. THE IMPLEMENTATION I want to implement this, and will try to get my company to let me go the open-source route. I suspect the easiest method would be to patch haml/sass directly. Here's what I'm thinking: - CONCEPT - Every template Haml renders will have a unique class name, based on its path, applied to all root elements. For instance, if something/ _form.html.haml looks like this: .some_div ... %span.other_div ... The HTML spit out would look like this: <div class="some_div something___form"> ... </div> <span class="other_div something___form"> ... </div> (The convention is to replace "/" in the path with "__", which is arbitrary and likely inconsequential.) These extra class names are almost certainly conflict-free in any project, and there is next-to-no real harm in adding them when unnecessary. - PATCHING HAML Hack Haml::Buffer.open_tag to check if options[:namespacing] is set and, if so, use options[:filename] to generate the namespace HTML class name and add it to 'attributes', iff '@real_tabs == 0' - PATCHING SASS In Sass::Tree::Node.to_s, instead of calling child.to_s(1) on RuleNodes, call child.to_s(1, namespace_html_class_name_derived_from_filename), iff Sass::Engine was initialized with options[:namespacing] set (an option which would have to be passed to Sass::Tree::Node from within Sass::Engine). IN CONCLUSION Does this idea sound helpful enough to get buy-in from other users? Does it sound simple from an end-user point of view? (one would need to set one Haml option and one Sass option, plus Capistrano rules for deploying Sass.) I get the impression it would work better if all the Sass files were nested into a particular subdirectory of public/ stylesheets/sass, e.g., public/stylesheets/sass/namespaced, which would differentiate auto-namespaced stylesheets with "global", un- namespaced ones. And lastly: is my coding approach a good one, or are there other places in the code I should be looking to best implement my design? Adam Hooper --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" 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/haml?hl=en -~----------~----~----~----~------~----~------~--~---
