robert.coup at onetrackmind.co.nz
Wed Jun 13 17:22:42 EDT 2007
James Burke wrote:
> Additionally, in 0.9, we need to load the CSS files ourselves,
> specifying URL paths to them. However, I find this lacking, and not
> keeping with the abstraction that dojo.require/dojo.provide loading
> gives me. Our loader allows me to specify a root path once (either via
> the path to dojo.js and/or dojo.registerModulePath()), then not have
> to worry about paths after that. If I change where I load dojo from
> (either different path or an xdomain build) that normally means I just
> have to change that path once, and I'm set. Not so with the CSS files
> in 0.9.
> So to address the async loading issue with stylesheets as well as the
> path abstraction, I'm wondering if we can support something like
> dojo.requireCss(). It would resolve paths like dojo.require() does
> today and also treat the CSS as a resource that needs to be loaded
> before firing the domcontentloaded/onload callbacks. Example:
> which would map to dijit/themes/dijit.css. dojo.requireCss would pull
> in the CSS contents, fix the css paths and inline the CSS via
> something like the old insertCssText. It could process @import calls
> to files that mapped to module-prefixed paths too.
Sounds great to me. I need a CSS-loading facility for the work I'm doing
here, and I guess a few other people do as well. Putting it into the
loader seems to make sense.
Our use case: one of our products is a toolkit that is loaded cross
domain via a single <script> tag. In 0.4, it pulled in CSS and
everything else required. Changing to have two lines (script+css) means
that versions are likely to get out of sync (script points to v2.8 while
css points to v2.7).
More information about the dojo-contributors