Affects Version/s: None
Fix Version/s: 0.2.4
Currently SmartSprites tries to process every CSS file it finds in the root-dir-path, which may lead to weird results, e.g. processing SVN metadata files stored in the .svn dir. One way of avoiding these kinds of problems would be to pass explicitly a list of CSS files to be processed.
SmartSprites should support processing individual CSS files. Exact implementation would depend on SmartSprites invocation mode:
As an Ant task
SmartSprites task would take a nested resource definition element defining the CSS files to be processed. An example invocation of the smartsprites target would look like this:
As a command line program
SmartSprites would accept a --css-files option that would take a list of CSS file paths to process, e.g.:
Note that SmartSprites would assume that wildcard expansion had already been done by the shell interpreter.
If individual CSS file paths are provided, the root-dir-path parameter becomes optional. If root-dir-path parameter is not specified:
- SmartSprites should process all CSS file paths provided on input
- sprited CSS files should be saved in the same directory as the corresponding source CSS files, with the file suffix as specified in the css-file-suffix parameter
- if css-file-suffix parameter is set to a blank string, SmartSprites should report an error
- if output-dir-path parameter is provided, SmartSprites should report an error
If root-dir-path parameter is specified:
- SmartSprites should process only those CSS file paths that are contained in root-dir-path. For each CSS file path outside of root-dir-path, SmartSprites should report a warning and ignore the file.
- all other processing should take place as in the current version of SmartSprites. In particular, output-dir-path parameter should be available and handled according to the specification.
- Q: should SmartSprites attempt to process all files passed on input or just the ones with *.css extension?
- A: all requested files should be processed. The motivation for this is that there may be designs that for some reason keep CSS in files not ending with the *.css extension, which would cause extra problems if only *.css files are read.
This feature was suggested by Chupa in this thread on the discussion group.