dojo.requireCss?

[jburke]

Consider including some form of a dojo.requireCss for 1.1. There is a good summary on dojo-contributors by Bill of the options. This is just a placeholder ticket for now as a reminder, and as a final design is worked out, post it here.

See

• http://thread.gmane.org/gmane.comp.web.dojo.devel/7590
• http://thread.gmane.org/gmane.comp.web.dojo.devel/7029/focus
• http://dojotoolkit.org/forum/developer-forums/dijit-development/dijit-css-race-condition-a11y-check

[jburke]

Attached a first shot at this. The big blocker right now is Firefox and css files that are loaded from another domain. Normally the linkNode.sheet.cssRules property could tell us if the file was loaded (or at least parsed, not sure about applied). Unfortunately, Firefox complains with a security error if cssRules is accessed when the css file is loaded from another domain. Safari 3 (on mac, haven't tested windows) seems to wait to define linkNode.sheet until the file has been loaded, so that works out in the xd case.

So, just xd css in Firefox is the holdup. Unfortunately I do not see an easy way around the issue yet. I tried in FF 3 beta 2, and same issue as FF 2.

The only thing I can think of is accepting a dojo.query string and a style property that should be set if the css file is loaded, but this is pretty weak: first you have to be sure the queried node will be in the document and match a style in the stylesheet, and since we would be inspecting a node.style.property, *no other stylesheet* should be setting that property. So yeah, very lame.

[bill]

Hi James. Sorry, no bright ideas about FF. We could require every CSS file to have some CSS class name defined, related to the name of the file itself, but that's a bit unpleasant.

Don't forget also that CSS files can include other CSS files (and we do this in dijit -- tundra.css includes dijit.css). Not sure how to handle that.

[bill]

FYI, this would solve #4058 and #5824 in a non-hackish way. (But we have a hack ways to fix them already, so no rush.)

[jburke]

First shot at requireCss, but has issue with cross domain css in Firefox: we cannot determine when it gets loaded.

[jburke]

Test file. Place as a sibling to the dojo dir.

[bill]

Also need to confirm that (for example) doing a dojo.requireCss("tundra.css"); wouldn't be marked as completed until tundra's imports (like dijit.css and TabContainer?.css) had finished downloading.

[jburke]

The issue that is blocking a checkin of this code is outlined in this mozilla bug. If that bug gets traction, we might have something worth trying:

https://bugzilla.mozilla.org/show_bug.cgi?id=185236

[jburke]

Moving to 1.3. Need to see movement on the mozilla bug mentioned above. See if anything happens in the 1.3 timeframe.

[dylan]

Given that this is blocked on a 6-year-old Mozilla bug, what should we do? Can we focus instead on a build system approach to roll-up all import statements? Can we add cssTemplatePath back as a mixin for Dijit (like Templated, and again make it an optional thinger)?

[jburke]

The build system already inlines @import calls inside CSS files, are you suggesting that the build system could process requireCss calls, and inline the CSS as a string in the JS file, then add the file's content to a newly created style node in the page?

I guess that might be an option for this bug: do the normal CSS link tag in non-build scenarios, documenting that it only works for CSS on the same domain, then have a build option that inlines the CSS with the dojo.requireCss call if you want xdomain support.

And/or have the build convert the CSS file into a .js file that can be loaded xdomain, and then take the contents and inject it into the page. That version of requireCss would require an extra param to indicate we are loading a JS file.

This would require a function, probably in loader.js (Dojo Base) that can take a string of CSS and append to head as a style tag, and fixing paths to images in the process.

It would be a lot easier/simpler/less code if FF would fix the bug. :p So much hoping for that.

Marking as future until actual work begins.

[bill]

See also #5136.