WebKitSite/projects/compat/index.html

<?php
    $title = "Web Site Compatibility";
    include("../../header.inc");
?>
<h2>Web Site Compatibility</h2>

<h3>Overview</h3>
<p>The most important task that we are working on in WebKit is improving web site compatibility.  Web site compatibility is actually
a generic term that covers bugs that may occur in many different functional areas of the code, from CSS to rendering to plug-ins.
Any time you encounter a web site that works in another browser but fails in a WebKit browser you have hit a web site compatibility
bug.
</p>
<p>These bugs can range from minor rendering defects to showstoppers that make an entire site inaccessible.  The causes of these bugs
are also wide-ranging, from bugs in the way the web page is coded to bugs in the engine itself.  For this reason reduction of web site
compatibility bugs is a top priority.  Only if the bug is reduced to a minimal failing test case is it easy for a developer to determine the
root cause of the problem.</p>

<p>Web site compatibility bugs fall into several categories:</p>
<ol>
<li>The bug is in the Web site itself.  You can test this assumption by checking the site in other browsers like Firefox and
Internet Explorer for Windows.  If both of these browsers
also fail on the site, it's a safe bet that the site is to blame.
<li>The HTML on the site is buggy, but WebKit's error recovery does not match other browsers.  This is a very common scenario for WebKit
as our error handling is still a bit more strict than other browsers.  In this case the bug is still our responsibility, since whenever
possible we want to match other browsers' error recovery behavior.
<li>WebKit has a legitimate compliance bug.  This is the most important class of compatibility bug, since we especially want valid
HTML to render and behave properly.
</ol>

<h3>Get Involved!</h3>
<p>How can you help us improve web site compatibility in Safari?</p>

<dl>
<dt>Test Test Test!</dt>
<dd>Build the latest WebKit and use it day to day.  Visit all of your favorite Web sites and scrutinize them all closely.  Make sure
they all work as expected, and if they don't then report problems to us.
<dt>File Bugs</dt>
<dd><a href="../../quality/reporting.html">Report bugs</a> to us for any problems you find.  Get bugs into our database so that we
can track the issue and screen the bug.</dd>
<dt>Reduce Bugs</dt>
<dd>Scan the bugs in the <a href="hitlist.html">Compatibility Hit List</a> and the <tt>New Bugs</tt> component and help attach reductions and minimal failing test cases.  Only when bugs are
screened properly will a developer be able to determine the root cause of the problem and move it into the appropriate component.
<i>This is one of the most important ways you can help improve WebKit.</i>
<dt>Create New Tests</dt>
<dd>To help avoid regressions you can make new tests, even for features that WebKit already handles correctly.  The more regression tests
we have covering a specific feature, the less likely it is that the feature will break when we make changes.
</dl>

<?php
    include("../../footer.inc");
?>