[cssom] Update on the CSSOM

[Anne van Kesteren-2]

Hi,

I recently joined the CSS WG to work on a proposal called the Cascading  
Style Sheets Object Model. The intention is that this specification will  
effectively obsolete DOM Level 2 Style by removing the problems it had and  
including some new APIs. The latest version of the editor's draft is  
publicly available:  
http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?content-type=text/html;%20charset=utf-8

Changes can be tracked through CVS: http://dev.w3.org/cvsweb/csswg/cssom/

The proposal basically exists of three parts: "Accessing style sheets  
through the DOM" which supercedes the "Document Object Model Style Sheets"  
chapter from DOM Level 2 Style. "Cascading Style Sheets APIs" which does  
the same for "Document Object Model CSS" and "Layout APIs" which  
standardizes some of the DOM Level 0 APIs found in popular browsers  
related to layout.

(The first part is probably the most stable thanks to Ian Hickson having  
written up the extensions to the DocumentStyle interface.)


Comments welcome (please prefix the subject with [cssom]), but please note  
the status of the draft. It will change.


Kind regards,


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Dave Raggett]

As a matter of interest, does the proposal cover the ability for web
page authors to define application specific CSS properties?

The ability to interpret markup extensions has shown its value when
it comes to trying out new ideas, enabling their effectiveness to be
tested on a wide scale before making any decision on the potential
for standardization. CSS has long lacked this ability and that has
hindered experimentation. In principle, you could edit the browser
source code where available, but this tends to be very hard and
further more greatly reduces the number of people able to try out
the new properties. An example is the difficulty involved in
implementing the CSS3 speech properties.

I would therefore like the CSSOM to include support for registering
a new property name together with a handler for parsing the string
value and returning an object that can then be retrieved using the
interface to accessing the computed styles for any element in the
DOM tree. A more sophistocated option would be to provide the CSS
property grammar using the syntax used in the CSS specifications,
but I would be happy with just the simpler solution. Note that the
registation would also cover details such as inheritance and initial
value.

  Dave Raggett <dsr@...> http://www.w3.org/People/Raggett

On Tue, 16 Jan 2007, Anne van Kesteren wrote:

>
> Hi,
>
> I recently joined the CSS WG to work on a proposal called the
> Cascading Style Sheets Object Model. The intention is that this
> specification will effectively obsolete DOM Level 2 Style by
> removing the problems it had and including some new APIs. The
> latest version of the editor's draft is publicly available:
> http://dev.w3.org/cvsweb/~checkout~/csswg/cssom/Overview.html?content-type=text/html;%20charset=utf-8
>
> Changes can be tracked through CVS: http://dev.w3.org/cvsweb/csswg/cssom/
>
> The proposal basically exists of three parts: "Accessing style
> sheets through the DOM" which supercedes the "Document Object
> Model Style Sheets" chapter from DOM Level 2 Style. "Cascading
> Style Sheets APIs" which does the same for "Document Object Model
> CSS" and "Layout APIs" which standardizes some of the DOM Level 0
> APIs found in popular browsers related to layout.
>
> (The first part is probably the most stable thanks to Ian Hickson
> having written up the extensions to the DocumentStyle interface.)

> Comments welcome (please prefix the subject with [cssom]), but
> please note the status of the draft. It will change.
>
> Kind regards,
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>

[Anne van Kesteren-2]

On Tue, 16 Jan 2007 14:13:07 +0100, Dave Raggett <dsr@...> wrote:
> As a matter of interest, does the proposal cover the ability for web  
> page authors to define application specific CSS properties?

No, as this would go against the CSS parsing rules. The CSSOM provides an  
API after parsing has been done and can't influence that process.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Dave Raggett]

On Tue, 16 Jan 2007, Anne van Kesteren wrote:

> On Tue, 16 Jan 2007 14:13:07 +0100, Dave Raggett <dsr@...> wrote:
>> As a matter of interest, does the proposal cover the ability for
>> web page authors to define application specific CSS properties?
>
> No, as this would go against the CSS parsing rules. The CSSOM
> provides an API after parsing has been done and can't influence
> that process.

Could you please expand on why a CSS parser can't use the CSS
parsing rules to identify the string value for new properties?
My understanding was that the underlying grammar was designed to
give CSS parsers the ability to identify and skip over properties
that they either didn't recognize or couldn't understand the value.

Essentially the underlying CSS grammar is analogous to the notion of
welformed XML, it allows you to parse stuff that you haven't seen
before. That is important as it allows CSS interpreters to recover
when they come across features that were added after the interpreter
was shipped.

I am merely asking for a way to provide web scripts with access to
the CSS extension mechanisms through a means to register new
properties together with the means to parse the values and construct
the corresponding results. I would be happy to provide a more
detailed proposal.

Best regards,

  Dave Raggett <dsr@...> http://www.w3.org/People/Raggett

[Anne van Kesteren-2]

On Tue, 16 Jan 2007 17:01:52 +0100, Dave Raggett <dsr@...> wrote:

>> On Tue, 16 Jan 2007 14:13:07 +0100, Dave Raggett <dsr@...> wrote:
>>> As a matter of interest, does the proposal cover the ability for web  
>>> page authors to define application specific CSS properties?
>>
>> No, as this would go against the CSS parsing rules. The CSSOM provides  
>> an API after parsing has been done and can't influence that process.
>
> Could you please expand on why a CSS parser can't use the CSS parsing  
> rules to identify the string value for new properties?
> My understanding was that the underlying grammar was designed to give  
> CSS parsers the ability to identify and skip over properties
> that they either didn't recognize or couldn't understand the value.
>
> Essentially the underlying CSS grammar is analogous to the notion of  
> welformed XML, it allows you to parse stuff that you haven't seen  
> before. That is important as it allows CSS interpreters to recover when  
> they come across features that were added after the interpreter was  
> shipped.
>
> I am merely asking for a way to provide web scripts with access to
> the CSS extension mechanisms through a means to register new
> properties together with the means to parse the values and construct
> the corresponding results. I would be happy to provide a more detailed  
> proposal.

I'm not saying this can't be done, I'm merely saying this can't be done in  
the CSSOM, which is what you seemed to request (initially). My apologies  
if I didn't comprehend the request.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

[Dave Raggett]

On Tue, 16 Jan 2007, Anne van Kesteren wrote:

> On Tue, 16 Jan 2007 17:01:52 +0100, Dave Raggett <dsr@...> wrote:
>>
>> Essentially the underlying CSS grammar is analogous to the notion of
>> welformed XML, it allows you to parse stuff that you haven't seen before.
>> That is important as it allows CSS interpreters to recover when they come
>> across features that were added after the interpreter was shipped.
>>
>> I am merely asking for a way to provide web scripts with access to
>> the CSS extension mechanisms through a means to register new
>> properties together with the means to parse the values and construct
>> the corresponding results. I would be happy to provide a more detailed
>> proposal.
>
> I'm not saying this can't be done, I'm merely saying this can't be
> done in the CSSOM, which is what you seemed to request
> (initially). My apologies if I didn't comprehend the request.

My apologies if my request wasn't as clear as it should have been.
Let me put it this way, I believe that such an extension mechanism
should be part of should be part of the next draft of CSSOM and
would add real value going beyond what can be done in today's
browsers.  I guess the next step is for me to put together a more
detailed proposal together with example use cases.

  Dave Raggett <dsr@...> http://www.w3.org/People/Raggett

[David Woolley]

> browsers.  I guess the next step is for me to put together a more
> detailed proposal together with example use cases.

I suspect that the only thing such a feature could do is return the
uninterpreted string, as future CSS versions might not be syntactically
compatible with current attribute specifications, as long as the fail
degraded process works properly.

[mikewse]

Anne van Kesteren-2 wrote:

Comments welcome (please prefix the subject with [cssom]), but please note  
the status of the draft. It will change.

About offset*:
"The offsetLeft attribute of Element node A must be the number of pixels that the top border edge of A is to the right of the top border edge of A.offsetParent. If A.offsetParent is null or represents the body element it must be the number of pixels that the top border edge of A is to the right of the origin (0,0) of the initial containing block."

My tests with Firefox 2.0 consistently produces an offsetLeft measuring from A's border edge to A.offsetParent's *padding* edge (and not border edge). Who is right?
(Or do you mean the "inside edge" of A.offsetParent's border? ;-)

Best regards
Mike Wilson

[mikewse]

> My tests with Firefox 2.0 consistently produces an offsetLeft measuring
> from A's border edge to A.offsetParent's *padding* edge (and not
> border edge). Who is right?

Hi Anne,
It would be great to hear your opinion. Would you like me to provide an example snippet?
Best regards
Mike