[dojo-contributors] Tentative agenda for today meeting
neonstalwart at gmail.com
Wed Oct 3 10:38:34 EDT 2012
On Oct 3, 2012, at 9:26 AM, Christophe Jolif wrote:
> On Wed, Oct 3, 2012 at 4:05 PM, Adam L. Peller <adam at peller.org> wrote:
>> Could your team take another look at
>> http://trac.dojotoolkit.org/ticket/15901 whether for 1.8.1 or 1.8.2?
>> It's a blocker for Maqetta, and we had to fork the repository to get
>> around it.
> Maybe Eric will have a different stance on this. But to me from our
> past experience this is really not a good idea to load that piece of
> future if we are able to get notified on CSS loading but as of today
> this might well end up in initialization nightmare, especially when
> running in a container like Cordova) so I'm wondering why Maqetta
> seems to be reluctant to use it as recommended which, if I'm not
> mistaken, would solve the issue without having to change Dojo?
i agree with christophe, i've had exactly the same experience. this file does not work when loaded asynchronously via a loader.
if you have never seen this issue, the things i found that exacerbated the problem was to do a build and try to load an alternative theme to iPhone (which is the default so iirc sometimes it seemed like it was working) - i was using android.
the only way this file works consistently is to add it as a separate script tag. although this is inconvenient, i don't think changing it to suit static analysis is going to help - if anything it just makes it easier to use it in a way that doesn't work.
as christophe eluded to, this file can't be loaded reliably by an asynchronous loader without knowing when the css is fully loaded - perhaps by using some kind of css plugin. i believe zazl has difficulties with plugins (maybe i don't understand and it might be able to handle this case) so this doesn't seem like it would move you forward either.
More information about the dojo-contributors