<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: GMail and Yahoo! Mail</title>
	<atom:link href="http://brennan.offwhite.net/blog/2004/06/17/gmail-and-yahoo-mail/feed/" rel="self" type="application/rss+xml" />
	<link>http://brennan.offwhite.net/blog/2004/06/17/gmail-and-yahoo-mail/</link>
	<description>My Experiences with Software Development</description>
	<pubDate>Wed, 08 Oct 2008 00:13:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Brennan Stehling</title>
		<link>http://brennan.offwhite.net/blog/2004/06/17/gmail-and-yahoo-mail/#comment-17</link>
		<dc:creator>Brennan Stehling</dc:creator>
		<pubDate>Wed, 19 Jan 2005 16:19:41 +0000</pubDate>
		<guid isPermaLink="false">http://brennanwp.offwhite.net/blog/?p=22#comment-17</guid>
		<description>I have a basic example of a floating box.

http://brennan.offwhite.net/floatingbox/

You can review the Javascript in box.js to see how it is done.


</description>
		<content:encoded><![CDATA[<p>I have a basic example of a floating box.</p>
<p><a href="http://brennan.offwhite.net/floatingbox/" rel="nofollow">http://brennan.offwhite.net/floatingbox/</a></p>
<p>You can review the Javascript in box.js to see how it is done.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Flores</title>
		<link>http://brennan.offwhite.net/blog/2004/06/17/gmail-and-yahoo-mail/#comment-16</link>
		<dc:creator>Flores</dc:creator>
		<pubDate>Wed, 19 Jan 2005 15:59:02 +0000</pubDate>
		<guid isPermaLink="false">http://brennanwp.offwhite.net/blog/?p=22#comment-16</guid>
		<description>Do you know how to do the floating div effect in GMAIL?..i would like to implement... thanks

M. Flores</description>
		<content:encoded><![CDATA[<p>Do you know how to do the floating div effect in GMAIL?..i would like to implement... thanks</p>
<p>M. Flores</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brennan Stehling</title>
		<link>http://brennan.offwhite.net/blog/2004/06/17/gmail-and-yahoo-mail/#comment-15</link>
		<dc:creator>Brennan Stehling</dc:creator>
		<pubDate>Thu, 24 Jun 2004 14:40:32 +0000</pubDate>
		<guid isPermaLink="false">http://brennanwp.offwhite.net/blog/?p=22#comment-15</guid>
		<description>Yeah, I did not trust it so much as assume that the Javascript was doing most of the work in the parent frame.  So I assume that when it gets a refresh it does not transfer web pages, just data which the Javascript can parse and tell each page fragment to redisplay.

Making it work in many browsers is nice, but I am sure they have the resources to test it and make any necessary workarounds.  But these days it is much easier to write standard Javascript against the DOM standard.  Both the current MSIE and Mozilla versions support it pretty well, and it seems Safari keeps up pretty well.  I do not care much about Opera since they are a weak minority and they should ensure they keep up with everyone else.  I would personally do little more than just test in their browser occasionally.  But I really do not bother.

I mainly avoid Javascript, but now I am finding there are better tools to help write Javascript and when I know I have the syntax right, the browsers actually work right.  It is not like when I ran stuff in Netscape 4 and while my code was right, the browser would choke on it.  I was forced to massage it into working.

The cool tricks are when you can combine a CSS and JS solution to cause useful page effects, like causing a floating div to show/hide based on other events.</description>
		<content:encoded><![CDATA[<p>Yeah, I did not trust it so much as assume that the Javascript was doing most of the work in the parent frame.  So I assume that when it gets a refresh it does not transfer web pages, just data which the Javascript can parse and tell each page fragment to redisplay.</p>
<p>Making it work in many browsers is nice, but I am sure they have the resources to test it and make any necessary workarounds.  But these days it is much easier to write standard Javascript against the DOM standard.  Both the current MSIE and Mozilla versions support it pretty well, and it seems Safari keeps up pretty well.  I do not care much about Opera since they are a weak minority and they should ensure they keep up with everyone else.  I would personally do little more than just test in their browser occasionally.  But I really do not bother.</p>
<p>I mainly avoid Javascript, but now I am finding there are better tools to help write Javascript and when I know I have the syntax right, the browsers actually work right.  It is not like when I ran stuff in Netscape 4 and while my code was right, the browser would choke on it.  I was forced to massage it into working.</p>
<p>The cool tricks are when you can combine a CSS and JS solution to cause useful page effects, like causing a floating div to show/hide based on other events.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kevin H</title>
		<link>http://brennan.offwhite.net/blog/2004/06/17/gmail-and-yahoo-mail/#comment-14</link>
		<dc:creator>Kevin H</dc:creator>
		<pubDate>Thu, 24 Jun 2004 03:29:54 +0000</pubDate>
		<guid isPermaLink="false">http://brennanwp.offwhite.net/blog/?p=22#comment-14</guid>
		<description>Hey, you actually are believing firefox's filesize reporting where you shouldn't be.  I think that is the size of the parent document, but all the data is in the frames.

The main body of the program is a 220KB javascript. 

But you are correct that this part probably caches, and that overall they did a super-impressive job writing cross-browser compatible javascript to push all the load off on the clients.  When you  view source on the frame with the list of messages, or with a message body, you will see that they have a series of calls to a function D(); Which I think stands for "Data".  Each call to D() sends along some data to that main js program for processing, markup, and display.  So while they incur a bit of overhead escaping special characters within the datastrings, they really are keeping the data transfers to a minimal size because there is very little html markup being sent.  My inbox view with 6 messages is a svelte 2.1KB.  Using some fancy javascript I determined that the marked-up version of the same data is over 11KB.

Because the javascript caches, they have to be careful about versioning, because any change to the data structure might not be understood by the cached js program.  That's probably why the first call to D() is always with the parameters "v", and then a unique id.  If the javascript doesn't know about this data version, it probably goes and reloads itself.

Overall I'm mighty impressed.  


p.s. if you're interested, the fancy javascript I mentioned is as follows:

javascript:(function(){alert(document.getElementsByTagName("FRAME")[0].contentDocument.getElementById('tlist2').contentDocument.body.innerHTML.length);})(); 

Pasting that into the urlbar of Firefox when you have your inbox open will report back the size of the messagelist html.</description>
		<content:encoded><![CDATA[<p>Hey, you actually are believing firefox's filesize reporting where you shouldn't be.  I think that is the size of the parent document, but all the data is in the frames.</p>
<p>The main body of the program is a 220KB javascript. </p>
<p>But you are correct that this part probably caches, and that overall they did a super-impressive job writing cross-browser compatible javascript to push all the load off on the clients.  When you  view source on the frame with the list of messages, or with a message body, you will see that they have a series of calls to a function D(); Which I think stands for "Data".  Each call to D() sends along some data to that main js program for processing, markup, and display.  So while they incur a bit of overhead escaping special characters within the datastrings, they really are keeping the data transfers to a minimal size because there is very little html markup being sent.  My inbox view with 6 messages is a svelte 2.1KB.  Using some fancy javascript I determined that the marked-up version of the same data is over 11KB.</p>
<p>Because the javascript caches, they have to be careful about versioning, because any change to the data structure might not be understood by the cached js program.  That's probably why the first call to D() is always with the parameters "v", and then a unique id.  If the javascript doesn't know about this data version, it probably goes and reloads itself.</p>
<p>Overall I'm mighty impressed.  </p>
<p>p.s. if you're interested, the fancy javascript I mentioned is as follows:</p>
<p>javascript:(function(){alert(document.getElementsByTagName("FRAME")[0].contentDocument.getElementById('tlist2').contentDocument.body.innerHTML.length);})(); </p>
<p>Pasting that into the urlbar of Firefox when you have your inbox open will report back the size of the messagelist html.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
