<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Robertdot, A Web Design Blog &#187; Browser Compatibility</title>
	<atom:link href="http://robertdot.org/tags/browser-compatibility/feed/" rel="self" type="application/rss+xml" />
	<link>http://robertdot.org</link>
	<description>A web design blog for designers that develop or developers that design.</description>
	<lastBuildDate>Fri, 05 Mar 2010 15:59:57 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Site Specific Hacks</title>
		<link>http://robertdot.org/2009/04/08/site-specific-hacks/</link>
		<comments>http://robertdot.org/2009/04/08/site-specific-hacks/#comments</comments>
		<pubDate>Wed, 08 Apr 2009 14:18:03 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Web Design]]></category>
		<category><![CDATA[Web Development]]></category>
		<category><![CDATA[Browser Compatibility]]></category>
		<category><![CDATA[Browsers]]></category>

		<guid isPermaLink="false">http://robertdot.org/?p=186</guid>
		<description><![CDATA[
 The other day, I finally got curious about the Site Specific Hacks option in the Develop menu of Safari.  It turns out that browsers do their own hacks to certain known problem sites to make them work.  Safari allows developers to turn off these hacks in the event that the developer is [...]]]></description>
			<content:encoded><![CDATA[<p>
 The other day, I finally got curious about the <samp>Site Specific Hacks</samp> option in the <samp>Develop</samp> menu of Safari.  It turns out that browsers do their own hacks to certain known problem sites to make them work.  Safari allows developers to turn off these hacks in the event that the developer is fixing a site that has hacks in Safari.
</p>
<p>
 Opera, on the other hand, has <a href="http://my.opera.com/core/blog/show.dml/3130540">a very advanced method for dealing with site specific hacks</a>.  It&#8217;s worth a read just so to know what kind of stuff goes on in the browser that most people, including developers, never think about.  They also link to how other browsers deal with the problem.</p>
]]></content:encoded>
			<wfw:commentRss>http://robertdot.org/2009/04/08/site-specific-hacks/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Browsers and Form Collection</title>
		<link>http://robertdot.org/2009/02/18/browsers-and-form-collection/</link>
		<comments>http://robertdot.org/2009/02/18/browsers-and-form-collection/#comments</comments>
		<pubDate>Wed, 18 Feb 2009 21:19:09 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Web Design]]></category>
		<category><![CDATA[Web Development]]></category>
		<category><![CDATA[Browser Compatibility]]></category>
		<category><![CDATA[Firefox]]></category>
		<category><![CDATA[Forms]]></category>
		<category><![CDATA[Internet Explorer]]></category>
		<category><![CDATA[Opera]]></category>

		<guid isPermaLink="false">http://robertdot.org/?p=175</guid>
		<description><![CDATA[
 I&#8217;ve been writing a new form hijacker.  Since this one is a pretty big deal for me, I wanted to make sure it was properly implemented.  I implemented against my interpretation of the HTML 4 specification and did a pretty good job since I&#8217;m exactly compatible with Firefox, Opera, and Internet Explorer [...]]]></description>
			<content:encoded><![CDATA[<p>
 I&#8217;ve been writing a new form hijacker.  Since this one is a pretty big deal for me, I wanted to make sure it was properly implemented.  I implemented against my interpretation of the <abbr title="HyperText Markup Language">HTML</abbr> 4 specification and did a pretty good job since I&#8217;m exactly compatible with Firefox, Opera, and Internet Explorer 8.  Safari, Internet Explorer 6, and Internet Explorer 7 seem to have some bugs.
</p>
<p>
 Safari seems to send the values of un<code>name</code>ed <code>select</code>s, despite these elements being invalid.  So, you may get a query string like <samp>text1=test&amp;=selval</samp> if your <code>select</code> that contained an <code>option="selval"</code> doesn&#8217;t have a <code>name</code>.
</p>
<p>
 Internet Explorer 6 and 7 both mishandle <code>button</code>s.  Internet Explorer 6 sends all <code>buttons</code> with <code>name</code> attributes set, even though it should only send the <code>button</code> if it was clicked.  Internet Explorer 7 doesn&#8217;t send unclicked <code>buttons</code>, but any time Internet Explorer 6 or 7 sends a <code>button</code> it sends the <code>button</code>&#8217;s <code>innerHTML</code> instead of the value.
</p>
<p>
 So, given the deficiencies above, here&#8217;s how to compensate.  If you&#8217;re using PHP, you don&#8217;t need to worry about Safari sending <code>name</code>less <code>select</code>s as PHP seems to ignore them (or at least in <code>parse_str</code>).  If you plan to use <code>button</code>s, never give them names or values.  Use <code>radio</code> controls if you have to do conditional actions based on what the user clicks.
</p>
<p>
 I still have some other testing to do, but these findings should help you cover your bases if you&#8217;re working with forms.</p>
]]></content:encoded>
			<wfw:commentRss>http://robertdot.org/2009/02/18/browsers-and-form-collection/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
