Thoughts on CSS 3 Images, CSS 3 Transforms and CSS OM

I am currently implementing CSS 3 multiple backgrounds with linear
and radial gradients and CSS 3 Transforms into my new Web editor,
BlueGriffon [1] [2].

Having those features implemented in a wysiwyg editor, supposed
to hide entirely the complexity of CSS and provide the user with
clean and intuitive UI, is hell for the following reasons:

1. the complexity of linear-gradient() and radial-gradient() functional
    notations.

    Given the complexity of those notations, I had to rely on my
    CSS parser JSCSSP to parse them. In other terms, I had to reimplement
    in JavaScript the whole machinery of the CSS parser because no API
    is exposed to reach the internals of a given gradient. Urgh, to say
    the least.

    Web or app authors should not have to write a parser, even based on
    RegExps, to manipulate a given CSS value since the rendering engine
    already has everything needed for that, just not exposed.

    I then strongly recommend the inclusion in the CSS 3 Images spec of
    a DOM API allowing to reach the individual components of a given
    gradient (angle, position, size and shape for radial gradients,
    array of color stops). I have no religion about where in the DOM
    it should be added and I care only about the feature itself.

2. manipulating CSS 3 Transforms is also difficult because the computed
    value of a very simple and highly readable set of transforms like

      rotate(45deg) translateX(100px)

    is a matrix... Decomposing the matrix to retrieve the various
    components composing the transformation is documented in the spec
    but I really don't understand why this is not implemented somewhere
    in the DOM. It will be faster and safer than hundreds of various
    matrix decomposition codes (and their bugs...).
    In the case of a larger set of individual transforms - let's say
    a dozen of transforms in a row - the "history" of transforms
    chronologically applied by the web author is entirely lost when you
    look at a specified value or the computed value. That loss is
    huge for a web author.
    Of course, it would be MUCH better to be able to preserve the
    original set of transforms above because from a web author's
    point of view, it IS editable in source view. A matrix is NOT
    editable in source view w/o external help.

3. we desperately need Element.getCascadedValue(property) and
    Element.getCascadedPriority(property). I had to reimplement
    them because they're the absolute root of a wysiwyg editor.

4. to be able to automatically manipulate styles in a wysiwyg
    editor, an API to find all rules applying to a given element
    (see inIDOMUtils in Gecko) is needed. An API to retrieve the
    specificity of each selector in the group of selectors
    (possibly reduced to one single selector) attached to a given
    style rule is needed too. Being able to reach the simple
    selectors in a given selector is also needed, I wrote about it
    long ago and even proposed a CSS Editing OM. We're still there.

Think embeddability. Browser vendors, if you really want to make
your rendering engine useful to embedders, you must provide them
with helpers allowing to easily manipulate the languages of the Web.
The suggestions above are nothing less and nothing more than an
attempt to fill a part of the gap.

[1] http://bluegriffon.org
[2] http://twitpic.com/2kt9rx/full

</Daniel>
--
W3C CSS WG, Co-chair

Received on Friday, 3 September 2010 19:12:52 UTC