css! plugin will no longer wait for stylesheet rules to be applied to document

[unscriptable]

After playing cat-and-mouse with webkit for a year, I'm thinking it's time to throw in the towel.  

The Webkit committers keep changing their stylesheet loading algorithm.  Each time they do, I have to struggle to find a way to ensure that curl's css! plugin doesn't call back to waiting modules before the associated stylesheet's rules are applied to the document.  (Devs may want this feature if they have written code that relies on css rules in order to compute something like element1.offsetHeight + element2.offsetHeight.)  

To be clear: we can still detect and wait for *onload* to fire in Webkit browsers.  The issue is that in Webkit (and only Webkit) the onload event sometimes fires *before* the css rules have been applied to the document.  All other browsers fire onload after the rules have been applied.  

To be fair to the Webkit folks, the w3c spec implies that the onload event only needs to wait for the stylesheet to be loaded.  Nothing more than that.

I doubt too many people are relying on the rules being applied before the plugin calls back to waiting modules.  My reasoning: only 1 person has complained since Aril 2012 when they really started breaking things.  I think we can suggest a work-around for people who need to wait for the css rules. One possible work-around is to periodically check if a property of an element in the dom changes to an expected value.  

Also: relying only on onload also simplifies the cram css! plugin, as well.

Any objections?  Thoughts?

[johlrogge]

Is it perhaps possible to pass some style to look for. Similar to how the js! plugin works. Basically let the css-plugin implement the workaround and do the polling for styles the user expects to be in the dom before the css-plugin considers itself "done" ?

[unscriptable]

Yes, it's possible.  However, it's more complicated than what the js! plugin's "exports=aGlobal" option does.  The dev would have to specify a node to test, and style property, and a style value.  The css! plugin could periodically test if the node has applied the style value to the node's style property.

function cssIsApplied () {
    return document.getElementById(nodeId).style[property] == value;
}

I imagine the node and style could be encoded in a convenient way: "css!http://mycdn.com/themes/dark.css!nodeId,property,value".

If passed on the AMD config, we could probably make this less cryptic, but possibly bulky.  Hopefully, the dev doesn't need to wait for lots of stylesheets!

curl({
    plugins: {
        css: {
            waitFor: {
                "http://mycdn.com/themes/dark.css": {
                    nodeId: "nodeId",
                    property: "property",
                    value: "value"
                }
            }
        }
    }
});

Honestly, I'm thinking we could just require the dev to pass a function to the config:

curl({
    plugins: {
        css: {
            waitFor: {
                "http://mycdn.com/themes/dark.css": function () {
                    return $('#nodeId').css('height') == 27;
                }
            }
        }
    }
});

We can't really do much else to simplify the problem since the stylesheet may be hosted on a third party CDN (so neither we nor the dev has control of the css rules in it).

Are you using the css! plugin and does your code rely on the styles being applied?  Or are you just interested in this issue, Joel?

-- John

[johlrogge]

I'm mostly interested in the issue. I also thought of the js!-idea when I read this and thought I'd post it in case it would stir up something good (worth a try).
I'm also interested in the principle of packaging styles together with the code that uses it (that css! enables) so I want the plugin to work well for that reason. As an addition I find that the "wait for x" code tends to be nasty so if that kind ow workaround can be internalized in the plugin I think it would lower the threshold somewhat.

I'd be ok with passing a function in the configuration. I'm not sure though how I would be guaranteed that jquery ($) in your example is loaded? The property based config approach also works for me.