Confirm, emeritus
419
edits
Changes
→Major Areas Of Development
= Major Areas Of Development =
There are several major areas of development for Gecko 1.9, intended to serve both the applications built on top of it (chiefly Firefox 3) and applications built on the web which need or would benefit from improvements in web technology. Many of these web-facing enhancements will be implementation implementations of existing standards, in whole or in part, but not all. Some will be new standards.
A rough attempt to categorize these development areas can be found below. Some elements could reasonably be categorized multiply, which is why so tags would be better than categories, so please . Please bear with our taxonomy.
== Graphics and layout capabilities ==
Graphics and layout changes represent some of the most invasive work proposed for the Gecko 1.9 development cycle. They form the core of the architectural shifts in 1.9, and are considered to be the most difficult and riskiest elements. To that end, this roadmap proposes that they -- especially the cairo-substrate and reflow-branch changes -- be scheduled as early as possible. Both of these work items have meaningful development behind them as of this writing (October 2005), but both will also require significant additional work to reach a level of completeness (including performance) that will allow them to be made default on the trunk.
The changes most graphical in nature (SVG, Canvas, XUL2D) depend on a switch to the cairo graphics library as the fundamental display architecture for Gecko, work on which is already well underway. The aim of shifting to cairo is to bring modern, hardware-accelerated 2D graphics capabilities to the whole of the web, without requiring proprietary plugins or rendering obsolete the broad and rich set of web authoring techniques developed over the past decade. The layout changes -- see also the "XUL' and XBL2" section of this roadmap -- center around David Baron's "reflow branch", the aim of which is to eliminate reflow commands and types, and significantly reduce the complexity of the Gecko layout model. This is the first change to global layout architecture in several years, and it is hoped that it will address many problems related to incremental reflow. In addition, it should simplify some problems which that are not practically soluble with the current architecture, such as support for inline-table.
=== cairo substrate ===
== JavaScript 2 ==
The development of the Mozilla suite of applications, from the earliest days of Seamonkey to the current Firefox 1.5 release, has demonstrated the promise of developing significant infrastructure and application logic in JavaScript, rather than the fragile world of Mozilla's minimal portable C++ dialect. Over the course of that development, though, many limitations in the language and our implementation have come to hinder our development efforts, and the JavaScript 2 work in Gecko 1.9 seeks to address many of them.
Building upon the "Edition 4" proposals before the ECMA-262 technical group responsible for standardizing the ECMAScript dialect of JavaScript, this work will cherry-pick, for early implementation, elements that are key to developing in JavaScript at the scale required for applications like Firefox. (N.B. that this is not a wholesale adoption of the JavaScript 2 proposal written several years ago by Waldemar Horwat, though the current Edition 4 design is similar in many elements are retainedways.)
== Python for XUL ==
== XUL' and XBL2 ==
The XUL and XBL languages have served Mozilla development very well, and are often taken as a model for XML-based UI development in other circles. In some cases, however, our implementations or the (incomplete) their old specifications are incomplete, inconsistent, insufficiently robust, or not amenable to some important use cases (including remote XUL applications or rich mixing with other content types such as HTML or SVG). We seek to address these limitations, and generally improve the XUL and XBL development experience, with work in Gecko 1.9.
The XBL work is largely drawn from based on an existing design by Ian Hickson's and David Hyatt's work on sXBL and XBL2, currently being developed in the mozilla-xbl list. Further investigation is required to determine how much Pending the complete specification, we can't be sure that all of the XBL2 draft will be necessary or implementable implemented in the 1.9 timeframe, but some pieces such as we are committed to at least an improved attachment model, clearer lifecycle semantics, and language neutrality . These are prerequisites for desired 1.9-era application or and platform features.
XUL work in Gecko 1.9 will not undertake to create a shining XUL2 jewel, but will instead work to preserve compatibility with "XUL1" where practical, and make clean breaks where unavoidable. Improvements to the XUL box model, based on the specification work done, again, by Hickson and Hyatt should provide a more consistent and flexible layout model for XUL developers, and help to rationalize XUL's interactions with other content types. This box-model work has been proposed for standardization, and Mozilla may participate in that at the W3C, WHATWG, or other appropriate venue. (In fact, most of the gain sought by a "shining XUL2 jewel" plan will likely be delivered by these box-model improvements and cross-content rationalization, rendering the former not only a non-goal but also a non-issue.)
