- 2013-04-04 @ 05:10
Two other browser engines already ship roughly interoperable
implementations in stable or experimental channels. In this situation, the
feature is already a de facto standard. If a de jure standard does not yet
exist, we should help create one.
One other browser engine ships a roughly interoperable implementation in a
stable or experimental channel, we believe the feature to be stable, and
we’ve consulted with the appropriate standards body.
The appropriate standards body considers the feature ready for
implementation. For example, the W3C issuing a Call for Implementations or
publishing a Candidate Recommendation of the feature would meet this
The specification for the feature has been accepted by the appropriate
standards working group (e.g., a First Public Working Draft in the W3C)
and we’ve received positive feedback from other browser engines about the
feature’s feasibility and value.
Some of the other changes we're considering:
Teach WebCore about multi-process history (currently it assumes
same-process synchronous History access)
Delete the Widget tree (a Mac WebKit1 constraint)
Split WebCore into modules
Move code to directly using the sandbox Platform API directly instead of
WebCore/platform where possible
Establish a simpler, stricter tree-gardening system that does not require
2 full time engineers per day
Experiment with moving the DOM into the JS heap
Removing obscure parts of the DOM and make backwards incompatible changes
to obscure parts of the DOM that benefit performance or remove complexity.
Use a modern, faster tcmalloc throughout all of Mac chrome
Experiment with incremental or parallel layout
Fix memory leaks by removing the ScriptValue/ScriptState abstractions now
Bring WebCore up to speed with DOM3 Events / [DOM] UI Events.