Re: [cssom-view] small update

The reverse engineering happened quite a while ago.

On Tue, 15 Apr 2008 10:07:14 +0200, Mike Wilson <>  
> The resulting CSSOM spec is the sum of all the above steps and
> no information is given about the intermediate steps. So, when
> the spec makes unexpected suggestions it is not possible to see
> whether there is a good reason for it, or an error has been
> made. I think this is what both Garrett and I have been trying
> to find out during this very long mail discussion. Honestly,
> I still don't know but this is what I have grasped so far from
> Anne's responses about offset* (referring to my numbering above):
> 1) Great weight has been given to other browsers than IE. [I
>    would have expected mainly IE as input.]

All browsers have been given more or less equal input.

> 2) There is no information that tells me whether a complete
>    reverse-engineering of IE has been done. [Garrett's and my
>    findings rather suggest the opposite.]

I have tried to base it on Internet Explorer. There are some blog posts  
that document a small piece of that process (and also contain some errors):

> 3) The prioritized goals seems to be achieving compatibility
>    with IE's quirks mode (but not standards mode!) and to have
>    non-IE vendors having to change as little as possible in their
>    cloned implementations (see 3d). Compatibility for deployed
>    content and old installed base is a non-priority. [Negate
>    everything in this paragraph and you have my expectations.]

The main goal is achieving Web compatibility. When it became clear that  
having no differences between quirks mode and standards mode became  
feasible that became a secondary goal.

> 4) Currently it is not evident whether the spec is making wise
>    decisions, although this would be clearer if more information
>    from steps 1-3 would be presented.
> So, referring back to your expectation that the spec is really
> about reverse-engineering IE: I think this is exactly what the
> problem is here. Most readers will have this expectation, and as
> the opposite is not mentioned in the spec they will continue to
> believe this.
> Ideally, the spec (or a separate report) should describe the
> findings of the IE reverse-engineering and the deviations from
> this model chosen by the spec. Or maybe just add a clarification
> that the offset* properties in the spec are not intended to
> mirror the IE model. (But then everyone interested in the IE
> behaviour will have to reverse-engineer themselves.)

Do you think this section  
is clear enough on that or do you want me to add a sentence saying  
explicitly that it doesn't match current implementations?

> To me it looks like CSSOM will add yet another code path to web
> scripts.

I don't follow.

>> An ideal issue e-mail would be short, and would say up front
>> what the problem is, then have evidence as needed....
> Yes, I agree this is a nice model of working. The reason that I
> (and maybe Garrett too?) haven't reported my issues in this way
> yet is because not having information and goals for the
> intermediate steps mentioned above. There is no issue to report
> if the main goal is to be NOT IE compatible f ex, as this goal
> is well fulfilled by the spec ;-).

That's not the main goal, but it's also not the main goal to be compatible  
with IE.

> Also, I have actually searched and neither found an existing
> issue list for CSSOM or a special mailbox for posting issues.
> Could someone please enlighten us?

The discussion list is There's no concrete issue list  
for this draft (yet, we'll have one for Last Call comments I suppose).  
There are also no known open issues for this draft.

I have a couple of suggestions from the past threads noted for future  
drafts, such as contentWidth, a better box model API in general, and a way  
to get the viewport width excluding the scrollbar width.

Anne van Kesteren

Received on Tuesday, 15 April 2008 08:40:27 UTC