New version, with Oxford comma everywhere. I didn’t add the use of “itself”
because I don’t think the sentence is ambiguous as written, given the second
clause. And if it is ambiguous, “itself” would not remove the ambiguity.
Below the diff, there’s the full text of the page as it would appear with these
diffs applied (though without styling).
project-new.html
1111 WebKit is an open source Web content engine for browsers and other
applications.
1212</p></blockquote>
1313<p><img src="/wp-content/themes/webkit/images/webkit.svg" alt="The WebKit
Project Logo" class="aligncenter size-full wp-image-4290" width="33%"></p>
14 <p>We value real-world web compatibility, standards compliance, stability,
performance, security, portability, usability, and relative ease of
understanding and modifying the code (hackability).</p>
14<p>We value real-world web compatibility, standards compliance, stability,
performance, battery life, security, privacy, portability, usability, and
relative ease of understanding and modifying the code (hackability).</p>
1515<h2><a name="project-goals"></a>Project Goals</h2>
1616<h4><a name="web-content-engine"></a>Web Content Engine</h4>
17 <p>The project’s primary focus is content deployed on the World Wide Web,
using standards-based technologies such as HTML, CSS, JavaScript and the DOM.
However, we also want to make it possible to embed WebKit in other
applications, and to use it as a general-purpose display and interaction
engine.</p>
17<p>The project’s primary focus is content deployed on the World Wide Web,
using standards-based technologies such as HTML, CSS, JavaScript, and DOM.
However, we also want to make it possible to embed WebKit in other
applications, and to use it as a general-purpose display and interaction
engine.</p>
1818<h4><a name="open-source"></a>Open Source</h4>
19 <p>WebKit should remain freely usable for both open source and proprietary
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move
to LGPL 3. In addition, we strive to create a courteous, welcoming environment
that feels approachable to newcomers. WebKit maintains a public IRC chat room
and a public mailing list where the ideas of contributors both new and old are
heard and discussed with equal weight.</p>
19<p>WebKit should remain freely usable for both open source and proprietary
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move
to LGPL 3. In addition, we strive to create a courteous, welcoming environment
that feels approachable to newcomers. WebKit maintains a public chat room and a
public mailing list where the ideas of contributors both new and old are heard
and discussed with equal weight.</p>
2020<h4><a name="compatibility"></a>Compatibility</h4>
2121<p>For users browsing the web, compatibility with their existing sites is
essential. We strive to maintain and improve compatibility with existing web
content, sometimes even at the expense of standards. We use regression testing
to maintain our compatibility gains.</p>
2222<h4><a name="standards-compliance"></a>Standards Compliance</h4>
23 <p>WebKit aims for compliance with relevant web standards, and support for
new standards In addition to improving compliance, we participate in the web
standards community to bring new technologies into standards, and to make sure
new standards are practical to implement in our engine. We use regression
testing to maintain our standards compliance gains.</p>
23<p>WebKit aims for compliance with relevant web standards, and support for
new standards. In addition to improving compliance, we participate in the web
standards community to bring new technologies into standards, and to make sure
new standards are practical to implement in our engine. We use regression
testing to maintain our standards compliance gains.</p>
2424<h4><a name="stability"></a>Stability</h4>
25 <p>The main WebKit code base should always maintain a high degree of
stability. This means that crashes, hangs and regressions should be dealt with
promptly, rather than letting them pile up.</p>
25<p>The main WebKit code base should always maintain a high degree of
stability. This means that crashes, hangs, and regressions should be dealt with
promptly, rather than letting them pile up.</p>
2626<h4><a name="performance"></a>Performance</h4>
27 <p>Maintaining and improving speed and memory use is an important goal. We
never consider performance “good enough”, but strive to constantly improve. As
web content becomes richer and more complex, and as web browsers run on more
limited devices, performance gains continue to have value even if normal
browsing seems fast enough.</p>
27<p>Maintaining and improving speed, memory use, responsiveness, and
consistent frame rate is an important goal. We never consider performance “good
enough”, but strive to constantly improve. As web content becomes richer and
more complex, and as web browsers run on more limited devices, performance
gains continue to have value even if normal browsing seems fast enough.</p>
28<h4><a name="battery-life"></a>Battery Life</h4>
29<p>In addition to traditional performance metrics, we aim to minimize power
consumption to maximize browsing battery life for portable devices.</p>
2830<h4><a name="security"></a>Security</h4>
2931<p>Protecting users from security violations is critical. We fix security
issues promptly to protect users and maintain their trust.</p>
32<h4><a name="privacy"></a>Privacy</h4>
33<p>We believe privacy is a human right. WebKit code won't track the user or
otherwise violate their privacy. And we will strive to prevent websites and
other parties from doing so.</p>
3034<h4><a name="portability"></a>Portability</h4>
31 <p>The WebKit project seeks to address a variety of needs. We want to make
it reasonable to port WebKit to a variety of desktop, mobile, embedded and
other platforms. We will provide the infrastructure to do this with tight
platform integration, reusing native platform services where appropriate and
providing friendly embedding APIs.</p>
35<p>The WebKit project seeks to address a variety of needs. We want to make
it reasonable to port WebKit to a variety of desktop, mobile, embedded, and
other platforms. We will provide the infrastructure to do this with tight
platform integration, reusing native platform services where appropriate and
providing friendly embedding APIs.</p>
3236<h4><a name="usability"></a>Usability</h4>
3337<p>To the extent that WebKit features affect the user experience, we want
them to work in accordance with good human interface design principles, and to
mesh well with platform-native HI conventions. Furthermore, we strive to
integrate with platform accessibility features to allow access for all users,
including those with disabilities.</p>
3438<h4><a name="hackability"></a>Hackability</h4>
----------------------
The WebKit Open Source Project <https://webkit.org/project/>
WebKit is an open source Web content engine for browsers and other applications.
We value real-world web compatibility, standards compliance, stability,
performance, battery life, security, privacy, portability, usability, and
relative ease of understanding and modifying the code (hackability).
<>Project Goals
<>Web Content Engine
The project’s primary focus is content deployed on the World Wide Web, using
standards-based technologies such as HTML, CSS, JavaScript, and DOM. However,
we also want to make it possible to embed WebKit in other applications, and to
use it as a general-purpose display and interaction engine.
<>Open Source
WebKit should remain freely usable for both open source and proprietary
applications. To that end, we use BSD-style and LGPL licenses. Specifically, we
aim for licensing compatible with LGPL 2.1+. We do not currently plan to move
to LGPL 3. In addition, we strive to create a courteous, welcoming environment
that feels approachable to newcomers. WebKit maintains a public chat room and a
public mailing list where the ideas of contributors both new and old are heard
and discussed with equal weight.
<>Compatibility
For users browsing the web, compatibility with their existing sites is
essential. We strive to maintain and improve compatibility with existing web
content, sometimes even at the expense of standards. We use regression testing
to maintain our compatibility gains.
<>Standards Compliance
WebKit aims for compliance with relevant web standards, and support for new
standards. In addition to improving compliance, we participate in the web
standards community to bring new technologies into standards, and to make sure
new standards are practical to implement in our engine. We use regression
testing to maintain our standards compliance gains.
<>Stability
The main WebKit code base should always maintain a high degree of stability.
This means that crashes, hangs, and regressions should be dealt with promptly,
rather than letting them pile up.
<>Performance
Maintaining and improving speed, memory use, responsiveness, and consistent
frame rate is an important goal. We never consider performance “good enough”,
but strive to constantly improve. As web content becomes richer and more
complex, and as web browsers run on more limited devices, performance gains
continue to have value even if normal browsing seems fast enough.
<>Battery Life
In addition to traditional performance metrics, we aim to minimize power
consumption to maximize browsing battery life for portable devices.
<>Security
Protecting users from security violations is critical. We fix security issues
promptly to protect users and maintain their trust.
<>Privacy
We believe privacy is a human right. WebKit code won't track the user or
otherwise violate their privacy. And we will strive to prevent websites and
other parties from doing so.
<>Portability
The WebKit project seeks to address a variety of needs. We want to make it
reasonable to port WebKit to a variety of desktop, mobile, embedded, and other
platforms. We will provide the infrastructure to do this with tight platform
integration, reusing native platform services where appropriate and providing
friendly embedding APIs.
<>Usability
To the extent that WebKit features affect the user experience, we want them to
work in accordance with good human interface design principles, and to mesh
well with platform-native HI conventions. Furthermore, we strive to integrate
with platform accessibility features to allow access for all users, including
those with disabilities.
<>Hackability
To make rapid progress possible, we try to keep the code relatively easy to
understand, even though web technologies are often complex. We try to use
straightforward algorithms and data structures when possible, we try to write
clear, maintainable code, and we continue to improve names and code structure
to aid understanding. When tricky “rocket science” code is truly needed to
solve some problem, we try to keep it bottled up behind clean interfaces. In
addition, we make heavy use of automated regression tests as a safety net, to
allow aggressive changes with less risk of regressions.
<>What WebKit is Not
There are a few points that arise occasionally which we consider out of scope
for the project.
<>WebKit is an engine, not a browser.
We do not plan to develop or host a full-featured web browser based on WebKit.
Others are welcome to do so, of course.
<>WebKit is an engineering project not a science project.
For new features to be adopted into WebKit, we strongly prefer for the
technology or at least the use case for it to be proven.
<>WebKit is not a bundle of maximally general and reusable code.
We build some general-purpose parts, but only to the degree needed to be a good
web content engine.
<>WebKit is not the solution to every problem.
We focus on web content, not complete solutions to every imaginable technology
need.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
