2006-11-21 Matt Lilek <pewtermoose@gmail.com>
authorbdash <bdash@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 21 Nov 2006 11:58:36 +0000 (11:58 +0000)
committerbdash <bdash@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Tue, 21 Nov 2006 11:58:36 +0000 (11:58 +0000)
        Reviewed by Maciej.

        http://bugs.webkit.org/show_bug.cgi?id=11652
        Bug 11652: Mailing list address and URL are incorrect

        This also removes a lot of bit rot from the KWQ-era.

        * coding/contributing.html:
        * contact.html:
        * projects/css/index.html:
        * projects/editing/index.html:
        * projects/forms/index.html:
        * projects/html/index.html:
        * projects/portability/index.html:
        * projects/xslt/index.html:
        * quality/lifecycle.html:
        * quality/testwriting.html:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@17868 268f45cc-cd09-0410-ab3c-d52691b4dbfc

WebKitSite/ChangeLog
WebKitSite/coding/contributing.html
WebKitSite/contact.html
WebKitSite/projects/css/index.html
WebKitSite/projects/editing/index.html
WebKitSite/projects/forms/index.html
WebKitSite/projects/html/index.html
WebKitSite/projects/portability/index.html
WebKitSite/projects/xslt/index.html
WebKitSite/quality/lifecycle.html
WebKitSite/quality/testwriting.html

index a3cb610..bd583f8 100644 (file)
@@ -1,3 +1,23 @@
+2006-11-21  Matt Lilek  <pewtermoose@gmail.com>
+
+        Reviewed by Maciej.
+
+        http://bugs.webkit.org/show_bug.cgi?id=11652
+        Bug 11652: Mailing list address and URL are incorrect
+
+        This also removes a lot of bit rot from the KWQ-era.
+
+        * coding/contributing.html:
+        * contact.html:
+        * projects/css/index.html:
+        * projects/editing/index.html:
+        * projects/forms/index.html:
+        * projects/html/index.html:
+        * projects/portability/index.html:
+        * projects/xslt/index.html:
+        * quality/lifecycle.html:
+        * quality/testwriting.html:
+
 2006-11-18  Mitz Pettel  <mitz@webkit.org>
 
         Reviewed by Maciej.
index 5a59426..9bd499a 100644 (file)
@@ -21,7 +21,7 @@ They go beyond the capabilities of the <tt>patch</tt> tool by handling files add
 
 <p>Once you have a patch file, it must be reviewed by one of the approved WebKit reviewers.
 To request a review, attach the patch to the bug report, and mark the patch with the flag <tt>review:?</tt>. This will automatically
-send mail to <a href="mailto:webkit-reviews@opendarwin.org">webkit-reviews@opendarwin.org</a> on your behalf. The 
+send mail to <a href="http://lists.webkit.org/mailman/listinfo/webkit-reviews">webkit-reviews@lists.webkit.org</a> on your behalf. The 
 <a href="../quality/lifecycle.html">WebKit Bug Life Cycle</a> page
 has more information about the stages of a WebKit Bugzilla bug.</p>
 
index 00b1a84..fd2bf4c 100644 (file)
@@ -5,18 +5,16 @@ include("header.inc");
 <h2>Keeping in Touch</h2>
 
 <h3>Mailing Lists</h3>
+<p>There are a number of mailing lists for WebKit related topics.  Archives for all the lists as well as information on joining them are available on the individual list page.</p>
+<p><a href="http://lists.webkit.org/mailman/listinfo/webkit-dev">webkit-dev</a> is for general discussion of WebKit development.</p>
 
-<p>There is a mailing list for discussion of WebKit open source
-development at <a
-href="mailto:webkit-dev@opendarwin.org">webkit-dev@opendarwin.org</a>.  You can sign up for
-the list <a href="http://www.opendarwin.org/mailman/listinfo/webkit-dev">here</a>.
+<p>If you would like help with development of an application using WebKit (as opposed to development the WebKit engine itself), the right list is the <a href="http://www.lists.apple.com/mailman/listinfo/webkitsdk-dev">webkitsdk-dev list</a>.</p>
 
-<p>If you would like help with development of an application using WebKit (as opposed to
-development <em>of</em> WebKit), the right list is at <a
-href="mailto:webkitsdk-dev@lists.apple.com">webkitsdk-dev@lists.apple.com</a> 
-with <a href="http://lists.apple.com/archives/Webkitsdk-dev">archives here</a>.
+<p><a href="http://lists.webkit.org/mailman/listinfo/webkit-reviews">webkit-reviews</a> is a list for notification of review requests.  Bugzilla automatically notifies this list of all patches awaiting review</p>
 
-<p>Our new bugs are assigned to the webkit-unassigned mailinglist by default. Check out the <a href="http://www.opendarwin.org/mailman/listinfo/webkit-unassigned">list info</a> and the <a href="http://opendarwin.org/pipermail/webkit-unassigned/">archives</a> for it.
+<p>New repository commit information is automatically sent to the <a href="http://lists.webkit.org/mailman/listinfo/webkit-changes">webkit-changes</a> mailing list.</p>
+
+<p>New bugs are assigned to the <a href="http://lists.webkit.org/mailman/listinfo/webkit-unassigned">webkit-unassigned mailing list</a> by default, which is notified of the new bugs, as well as their updates and changes.</p>
 
 <h3>IRC</h3>
 
index a1c96d9..451639b 100644 (file)
@@ -24,7 +24,7 @@ Complete support is measured by passing the CSS1 test suite.
 
 <dt>Finish CSS2.1 Support</dt>
 <dd>Most of CSS2.1 has been implemented in WebKit, but a few holes remain.  The new white-space values <tt>pre-wrap</tt> and <tt>pre-line</tt> are not yet
-supported.  In addition counters are not supported.  Some of these features have been implemented in the current KHTML tree, and a merge may be possible for
+supported.  Some of these features have been implemented in the current KHTML tree, and a merge may be possible for
 some of these features.
 
 <dt>Finish CSS3 Selectors</dt>
index a2264f7..c744cdd 100644 (file)
@@ -11,7 +11,7 @@ editing can also be used in Web pages using WinIE-compatible APIs like <i>conten
 
 <p>Architecturally the editor operates as a series of commands that are executed on a document's object model tree.  Each command
 can be undone and redone just by performing the appropriate set of DOM operations.  The implementation of these commands and
-other editing infrastructure can be found in the WebCore framework in the <tt>khtml/editing</tt> subdirectory.</p>
+other editing infrastructure can be found in the WebCore framework in the <tt>editing</tt> subdirectory.</p>
 
 <p>Editing operations are also part of the WebKit API, and so there is some overlap with that project.  Up until now our
 focus has mostly been on editing for applications that embed WebKit, but we plan to focus in the future on improving the
index 5c12178..66229ca 100644 (file)
@@ -7,10 +7,7 @@
 <h3>Overview</h3>
 <p>Welcome to the project page for the HTML form controls.  Form controls are the various widgets that can be used in an HTML form and that can 
 participate in form submission.  The code in the engine that talks to the controls is in the <tt>WebCore</tt> framework.  The DOM elements are
-under the <tt>khtml/html</tt> directory, and the rendering objects are under the <tt>khtml/rendering</tt> directory.  At the moment the controls are
-all grouped together into single files, and one change we plan to make is to split these out into one class per file in order to make it easier to
-locate each control's implementation.
-</p>
+under the <tt>html</tt> directory, and the rendering objects are under the <tt>rendering</tt> directory.</p>
 
 <h3>Get Involved!</h3>
 
@@ -22,16 +19,8 @@ View bugs in the HTML Forms component in Bugzilla.
 </p>
 
 <dl>
-<dt>Use WebKit to implement the controls</dt>
-<dd>
-<p>The HTML form controls are currently implemented without using the WebKit engine.  Right now WebKit talks to Qt interfaces that represent the controls.
-On OS X our implementation of these Qt interfaces uses App Kit.  The major architectural change that we are planning for form controls in the coming year
-is to re-implement the form controls using the WebKit engine itself to render.  This will allow us to support more CSS properties for form controls, make
-our code more portable to other platforms, and - most importantly - will improve our performance significantly on pages with a large number of controls.
-
-<p>For input fields and text areas, we plan to use <a href="../editing/index.html">HTML editing</a> to implement these controls, and for the other controls custom
-renderers will be made.  A new theme abstraction will be used to encapsulate the rendering of a native look on the platform with <tt>NSCells</tt> being used to
-determine the correct appearance of controls like checkboxes and buttons on OS X.</p>
+<dt>Stabilize the new form controls</dt>
+<dd>Form controls have recently switched from using standard AppKit controls to being rendered within the engine itself.  This allows us to support more CSS properties for controls, and makes our code more portable to other platforms.  Because this is such a major architectural change, we ask that you scrutinize the new controls closely and <a href="http://webkit.org/quality/reporting.html">report any bugs</a>.
 
 <dt>Implement Web Forms</dt>
 <dd>The <a href="http://whatwg.org">WhatWG</a> has outlined extensions to existing HTML forms.  We are interested in supporting these extensions (along with Opera
index 7e8968e..ffdd3ad 100644 (file)
@@ -17,7 +17,7 @@ View bugs in the HTML component in Bugzilla.</a>
 
 <dl>
 <dt>Complete HTML4 Support</dt>
-<dd>There are a handful of HTML4 issues remaining, including implementing the LABEL element, adding support for a few more attributes for legacy HTML
+<dd>There are a handful of HTML4 issues remaining, including adding support for a few more attributes for legacy HTML
 to APPLET and OBJECT, implementing the BDO element, and implementing alignment inheritance in table columns.</dd>
 <dt>Improve XHTML</dt>
 <dd>We want to improve our XHTML rendering, making it as incremental as HTML and making sure entity support and scripts work properly.
index 9725204..20ee4ce 100644 (file)
@@ -24,11 +24,6 @@ frameworks are open source, we would like to move as much of this code as possib
 Objective-C to make the code more portable.  Ultimately we would like WebKit to be nothing more than the embedding APIs for a given platform and infrastructure/glue 
 code that is needed to tie into a specific platform.  All of the remaining logic should move to WebCore.
 
-<dt>Implement form controls using WebKit</dt>
-<dd>Currently there is a dependency on all of the various Qt interfaces for form controls like checkboxes, buttons and text fields.  We would like to re-implement
-these controls using WebKit itself.  This will eliminate many Qt classes from the platform layer (KWQ) and make the porting job easier when moving to other platforms.
-See the <a href="../forms/index.html">forms project page</a> for more details.
-
 <dt>Implement missing components</dt>
 <dd>Not all platforms have code for handling cookies, authentication, SSL, caching, network loading, or image decoding.  We would be interested in implementations
 of these capabilities that could optionally be used on platforms that do not have this support.  On platforms that do, the implementation of the cross-platform
index 181502a..c68c546 100644 (file)
@@ -29,24 +29,13 @@ View bugs in the XSLT component in Bugzilla.</a>
 </p>
 
 <p>Below is a sampling of interesting open issues with WebKit's XSLT support.  If you wish to sign up for any of these tasks, send mail
-to <a href="mailto:webkit-dev@opendarwin.org">webkit-dev@opendarwin.org</a> or comment in the appropriate bug.</p>
+to <a href="http://lists.webkit.org/mailman/listinfo/webkit-dev">webkit-dev@lists.webkit.org</a> or comment in the appropriate bug.</p>
 
 <dl>
 <dt><a href="http://bugs.webkit.org/show_bug.cgi?id=3273">XSL transformations block the user interface</a>
 <dd>The XSLTProcessor that performs the transformation using libxslt does so on the UI thread.  Therefore a transformation that takes a long time
 to complete will block the UI of a WebKit application.  The code should be restructured so that both synchronous and asynchronous transformations are
 allowed, since until JavaScript can be suspended/resumed a synchronous transformation mode must be possible in order for a JS API for XSL transformations to work.
-
-<dt><a href="http://bugs.webkit.org/show_bug.cgi?id=3274">The document() function is not supported</a></dt>
-<dd>The <tt>document()</tt> capability of XSLT is not supported.  XSLT's loader API (the one used to load stylesheets) 
-needs to be used in order to synchronously load and hand back an XML document.  This code could be 
-similar to (or possibly reuse) the sync code for XMLHttpRequests.
-
-<dt><a href="http://bugs.webkit.org/show_bug.cgi?id=3275">Implement Mozilla's XSLTProcessor JS object</a></dt>
-<dd>Right now the only way XSLT can be used in WebKit is through the use of client-side processing instructions in the source XML.  Mozilla offers a programmatic
-API for performing transformations from JS through an <tt>XSLTProcessor</tt> object.  The following <a href="http://www.mozilla.org/projects/xslt/js-interface.html">document</a> 
-on the Mozilla Web site describes this JS API.  We would like to match this API exactly.
-
 </dl>
 
 <?php
index 0b934de..c283b28 100644 (file)
@@ -1,6 +1,6 @@
 <?php
-       $title = "WebKit Bug Life Cycle";
-       include("../header.inc");
+    $title = "WebKit Bug Life Cycle";
+    include("../header.inc");
 ?>
 <h2>WebKit Bug Life Cycle</h2>
 
@@ -57,7 +57,7 @@ the requested reviewer's email address in the <tt>Requestee</tt> field. Otherwis
 this point; it isn't changed to <tt>FIXED</tt> until a fix has been checked into the source tree.</p>
 
 <p>When the review flag's state is changed, or when a comment is made in the Edit form for an attachment, email is automatically sent to
-the <a href="http://www.opendarwin.org/mailman/listinfo/webkit-reviews">webkit-reviews</a> mailing list. The reviewers all subscribe to
+the <a href="http://lists.webkit.org/mailman/listinfo/webkit-reviews">webkit-reviews</a> mailing list. The reviewers all subscribe to
 this list, and anyone else is free to do so as well.</p>
 
 <p>If the submitter of a patch changes their mind about wanting a review, they should clear the <tt>review</tt> flag by choosing the
@@ -85,7 +85,7 @@ submitter should also clear the <tt>review</tt> flag. This would happen automati
 should change the state of the bug to <tt>FIXED</tt>; generally the assignee is left unchanged at this point.</p>
 
 <p>All of the
-people with commit privileges should be subscribed to the <a href="http://www.opendarwin.org/mailman/listinfo/webkit-reviews">webkit-reviews</a>
+people with commit privileges should be subscribed to the <a href="http://lists.webkit.org/mailman/listinfo/webkit-reviews">webkit-reviews</a>
 mailing list, and so they will receive email when a patch is approved and thus ready to be committed. If an approved patch has not been committed for what seems to be an inordinately
 long time, the patch submitter could send email requesting status to this mailing list. As a last resort, the patch submitter could contact the
 reviewer directly. Due to everyone's busy schedules, some delays in getting patches reviewed, and then in getting them committed, are inevitable.</p>
@@ -113,5 +113,5 @@ change the resolution to <tt>REOPENED</tt> and assign it to the person who submi
 the resolution is changed to <tt>CLOSED</tt>.
 
 <?php
-       include("../footer.inc");
+    include("../footer.inc");
 ?>
index 928c4fb..e3c3645 100644 (file)
@@ -1,6 +1,6 @@
 <?php
-       $title = "Writing New Tests";
-       include("../header.inc");
+    $title = "Writing New Tests";
+    include("../header.inc");
 ?>
 
 <h2>Writing New Tests</h2>
@@ -30,9 +30,8 @@ for the output to be written out as plain text rather than as a render tree dump
 This is useful for tests that are testing something other than layout. The event creation test mentioned above is a good example of 
 how to do this and when it makes sense.</p>
 
-<p>The CSS working group has an excellent document on <a href="http://www.w3.org/Style/CSS/Test/guidelines.html">test writing guidelines</a> for CSS tests.
-</p>
+<p>The CSS working group has an excellent document on <a href="http://www.w3.org/Style/CSS/Test/guidelines.html">test writing guidelines</a> for CSS tests.  <a href="http://trac.webkit.org/projects/webkit/wiki/Writing%20Layout%20Tests%20for%20DumpRenderTree">This wiki article</a> has more information on writing good tests and the DumpRenderTree tool.</p>
 
 <?php
-       include("../footer.inc");
+    include("../footer.inc");
 ?>
\ No newline at end of file