A couple of things.
1) You can track page load; you can't reliably track CSS load, *except* if
you drop an arbitrary class into the CSS file, and execute a function on
domready
that will periodically check (every 40ms or so?) to see if an element on the
page with that class has the class' style applied. When it's there, you can
trigger a 'css ready' event on the page.
2) Figured I'd PSA on this one: Morph is great. But it's a little strict.
Make sure that both of your classes that you are transitioning from/to have
fully defined the css transitions and don't depend on inherited style. (i.e,
Morph won't use the computed style for the transition, it will use the
declared inline style.) Unless somethings changed in 1.3.
A grotseque example:
a {
background-color: red
}
.active{
border: 2px solid black;
}
.inactive:{
border: 2px dashed gray;
background-color: blue;
}
Transitioning from active to inactive will change the link from red to blue,
but transitioning back to active will only modify the border, not the
background color.
3) Evaluate if you need the @import statement at all. Really. There are some
reservations about it. See
http://www.stevesouders.com/blog/2009/04/09/dont-use-import/ for starters.
There are other posts. It's basic dependency/style loading management, and
it can usually be handled elsewhere, most of the time in your back end. If
you are just using static HTML, you can still just include more than one
<link> tag at the top of your browser.
On Tue, May 3, 2011 at 10:32 AM, hairbo <[email protected]> wrote:
> I think I'm about to feel like a fool. I had forgotten that CSS isn't part
> of the DOM, so of course domready could be true before all CSS is loaded.
>
> Perhaps the larger issue here is that for code like this, which relies on
> the presence of CSS, you can't/shouldn't use window.addEvent('domready'),
> but rather window.addEvent('load'). I'm so used to using domready that I
> didn't give it a second thought. I'll run a few tests...
>
