Hi string I'm cool
You are right, in everything you said
I don't have your knowledge, my gadgets are very simple
The problem is I use de GGE to check and test my gadgets, and they
look and work fine,
but when I use them in igoogle they are modified, some missing parts
and distorted
This is very easy to see in igoogle.com/ig (english) and you can even
use them, but you can't in igoogle.es (spain) they are useless

On Jun 22, 11:13 am, String <[email protected]> wrote:
> OK, we all know that Google rolled out some changes to iGoogle a
> couple of weeks ago that broke a bunch of our gadgets. Unfortunately,
> they've been silent about what those changes were, and to make matters
> worse they've not been rolled out universally - meaning that we have a
> shedload of users complaining that our gadgets are broken, but often
> we developers can't see the problems, and therefore can't even try to
> fix them.
>
> Finally, I have a bit of good news. This morning I was able to get my
> hands a "new" version of one of my gadgets, figure out what Google had
> done to it, and implement a fix. This is a long post, but stick with
> it if you've been burned by this change, and hopefully it will help
> you out.
>
> Here's a simplified gadget that will demonstrate the problem:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <Module>
>   <Require feature="dynamic-height"/>
>   <Content type="html"><![CDATA[
>     <h1>
>       My Gadget
>     </h1>
>     <p id="text"></p>
>
>     <style type="text/css">
>       h1,
>       p {
>         font-size: 80%;
>         text-align: center;
>         margin: 2px 0 0 0;
>       }
>     </style>
>
>     <script type="text/javascript">
>       _IG_FetchContent('http://example.com/ajax.php', function (text)
> {
>         _gel('text').innerHTML = text;
>         _IG_AdjustIFrameHeight();
>       });
>     </script>
>   ]]></Content>
> </Module>
>
> Simple enough, it dynamically loads some content into an HTML element
> from an AJAX call . Up until recently, this gadget would have run (and
> formatted) fine. In the iframe on iGoogle, the <body> would have
> looked just like the <Content> above.
>
> However, here's the big change: with the new iGoogle renderer, the
> Content gets "minified" before it gets sent to the client, presumably
> to decrease latency. So, the new body content looks like this:
>
> <h1>
> My Gadget
> <p id="text">
> <style>h1,p{font-size:80%;text-align:center;margin:2px 0 0 0;}</style>
> <script type="text/javascript">
> _IG_FetchContent('http://example.com/ajax.php', function (text) {_gel
> ('text').innerHTML = text;_IG_AdjustIFrameHeight();});
> </script>
>
> Several things have happened here:
> - Leading whitespace has been trimmed.
> - The closing HTML content tags have been removed (</h1> and </p>).
> - Virtually all whitespace has been removed from the <style> element.
> - Most whitespace has been removed from the <script> as well.
>
> In theory, this should all be fine - the whitespace is superfluous,
> and the browser should assume the closing HTML tags. And in fact, the
> gadget will render fine when it first loads.
>
> The problem comes in the callback for _IG_FetchContent(). In my code,
> the _gel('text').innerHTML call would replace everything between the
> opening <p id="text"> and clsoing </p> tags. However, because there's
> no closing </p> tag, EVERYTHING after <p id="text"> gets replaced -
> including my <style> and <script>!
>
> Boom, the gadget falls apart. The CSS no longer exists - in this case,
> it'll just make my content look crappy, but for a more complex gadget
> it could break much more seriously. Worse, my JavaScript is also gone;
> this means the _IG_AdjustIFrameHeight() call never happens (sound
> familiar?), and any other functionality I might have put in there is
> also out the window.
>
> And this innerHTML bug is only one specific problem that I
> encountered. I have little doubt that there are other, equally bad
> side effects to this new iGoogle code. For example, what if I'd left
> off some semicolons in my JS? If it had still been minified in the
> same way, it would have broken too.
>
> What's the solution?
>
> Obviously, Google should (1) roll back the changes, (2) stop minifying
> our code so aggressively, and (3) deploy a new version in the
> developer sandbox before the live environment. But they seem to have
> abandoned us on this issue, so we need to take matters into our own
> hands.
>
> My first recommendation to other developers is to move all <style> and
> <script> blocks to the beginning of the <Content> section, BEFORE any
> visible HTML content tags. This should fix the specific innerHTML
> problem described above.
>
> Second, try removing all your closing content tags (like </p> and </
> div>) manually, and see how your gadget works. Ideally, you'd also
> strip all your whitespace - but that's a real PITA, both to do
> initially and to try to maintain.
>
> Third, post back here with your own findings. Since we've all been
> hung out to dry by Google on this, we might as well hang together. :^)
>
> Good luck!
>
> String
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"iGoogle Developer Forum" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/Google-Gadgets-API?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to