Motivation
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.
Implementation
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:
<smartsprites>
<fileset dir="assets/css">
<include name="to-sprite*.css" />
</fileset>
</smartsprites>
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.
Discussion
- 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.
Ah i see. Yes this would avoid any possible inclusion of the wrong files or subfolders if that restriction is required.