David Chelimsky wrote: > On Fri, Jul 25, 2008 at 8:08 AM, Joseph Wilk <[EMAIL PROTECTED]> wrote: > >> To handle this I wrote a patch which delivered the styles in the html formatters output. In much the same way as the html spec formatter does. >> I know Aslak Hellesøy has been looking at the editable html stories. Is it acceptable to have stories have styles embedded in the html formatter until Aslak's editable stories project evolves? >> I could imagine there are some arguments that the HTML output of stories >> is something people might want to control the look and feel of, more so than specs as they are seen more frequently by customers. >> Perhapes by default the styles are embedded in the html formatter but if >> a CSS stylesheet is passed to the formatter than it will suppress this output and use your custom css. >> something like: >> ruby stories/all.rb --format html --css my_own.css >> > That all sounds reasonable to me. Sensible defaults, yet configurable. Other opinions? >
I like that idea. I haven't wanted to push back any of my changes to the HTML formatter because I knew that Aslak's goal was to create a customer facing editable HTML page. However, for CI builds it is more useful as a programmer to not have that functionality and inline the backtrace as well (which is something most customer's wouldn't want to see.) I vote for inlining the basic styles and providing the way to configure it as suggested above. I think the HTML formatter should include the backtrace and then JS can be used to hide it for a customer-facing version. Which brings up the other question.. how do we want to handle the JS? Due to how the HTML is written out JS is required to change the Story's and Scenario's styles when a step fails or is pending. I did this with lowpro for the rspec-story-tmbundle: http://github.com/bmabey/rspec-story-tmbundle/tree/master/Support/resource/rspec.js (The JS commented out in the file was the original JS that Aslak did for the editable version.) My JS is untested though (and only works for rspec 1.1.4), so I don't know if you want to incorporate it into rspec, plus it would require the additional lowpro.js lib. The bigger question, I think, is how to handle the required JS files. I don't think inlining the whole prototype lib is a good solution. So, maybe we could default to generating full paths to the JS files which reside in the rspec lib folder? Then we could allow options to be passed in to modify the JS path, just like the CSS option above? Any other suggestions/ideas of how to handle the external JS files? -Ben _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
