W3C home > Mailing lists > Public > public-houdini@w3.org > February 2015

an old proposal for an API to implement properties in script

From: L. David Baron <dbaron@dbaron.org>
Date: Sun, 8 Feb 2015 21:59:40 +1100
To: public-houdini@w3.org
Message-ID: <20150208105940.GA7982@pescadero.dbaron.org>
Since it might be of interest, an old proposal for implementing
properties  from script that I wrote back in 2009 was in
https://bugzilla.mozilla.org/show_bug.cgi?id=188321#c14 :
> So I think the information that a caller needs to provide for a custom CSS property to get implemented correctly through existing APIs would be:
>  * the name of the property (String)
>  * whether the property is inherited (Boolean)
>  * an initial value for the property (V_Spec)
>  * a parse function (Input -> V_Spec or None)
>  * a compute function (V_Spec * DOM Element -> V_Comp)
>  * a function to serialize the specified value type (V_Spec -> String)
>  * a function to serialize the computed value type (V_Comp -> String)
> where V_Spec and V_Comp are arbitrary types, and Input is a type representing a way of accessing CSS token streams.
> That's a pretty complex API, especially since CSS tokenization is not frozen.
> V_Comp could in theory be String (thus removing the need for the second serialization function), although it might be nice to allow it not to be if there were an API for implementors to get to it.
> In theory, we could simplify by merging the parse and compute functions, which would require the single function meet a bunch of constraints:
>  * the function return the initial value when given a specific (perhaps empty) input
>  * the function return a special value to indicate parse failure (at which point it would be called again with a different value, perhaps the magic one for initial)
>  * it could return the computed value in string form (see above)
> We could also simplify the API (although drastically reduce the chances that a property would be implemented correctly per spec -- essentially to zero) by giving the input in string form instead of as a token stream.  This would make the API easier to freeze, though.
> With all these simplifications, we could be down to:
>  * name of property (String)
>  * inherited or not (Boolean)
>  * parse + compute function (String * DOM Element -> String)
> This probably is doable using an API in JS since we could arrange things so that the functions are only called in response to CSSOM API calls in JS.

It's missing anything about handling dynamic changes, since it was
in response to a request to be able to get the values of
unimplemented properties in getComputedStyle.

But it might be useful as an outline of what I think is needed to
implement a CSS property in a spec-conformant way from a script API.
There are clearly tradeoffs between complexity of the API and the
ease of having the implementation be correct per CSS specs; I don't
know what the right balance is there.


𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

Received on Sunday, 8 February 2015 11:47:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 15:47:05 UTC