RE: [cssom-view] small update

Hi Boris, and welcome to the discussion!

> > I'm sorry, but Mozilla had over 4 years to fix this bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=255754 
> > Is CSSOM Views is going to fix that?
> 
> That bug's fix is waiting on a thorough reverse-engineering 
> of IE, which is what Anne is working on, as far as I can tell. 

It seems you have the same expectation as I had when starting
to look at this spec. I expected the CSSOM activity to base
the offset* properties handling on IE due to its IE origin and 
the (supposedly) resulting large base of deployed content 
compatible with the IE scheme.

Though, this is not what is being written in the spec at the
moment. It takes more inspiration from the cloned offset*
implementations of Mozilla and other standard browsers, which
was unexpected by me.

Note that I cannot judge how thorough an IE reverse-engineering 
has been performed, I can just see that it hasn't made it into 
the spec. This brings on the following reasoning:

My impression of how the CSSOM activity has been aimed to be 
performed is something like this:
1) Decide what browsers to use as input to the activity
2) Reverse-engineer browsers' behaviour/design
3) Evaluate designs against prioritized goals:
   a. Backwards compatibility with deployed content
   b. Old installed base compatibility with future contents
   c. Simplicity for web authors
   d. Simplicity for browser vendors
   ...etc...
4) Make wise decisions

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.]
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.]
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.]
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.)

> Any time we say "X is useful", that's a shorthand for "X can 
> by used by Y to accomplish Z".  The real question is what X, 
> Y, and Z are.

This is an excellent analysis that is perfect to apply to this
very spec. We all agree that the goal of the CSSOM spec is to 
be useful. But what are Y and Z?
My understanding so far is it's rather "CSSOM is useful for 
non-IE browser vendors to gain standards compliance without much 
work", and not "CSSOM standardizes the existing offset* model to
line up all browsers with majority of deployed content and make 
life easier for web authors".

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

> 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 ;-).

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?

Best regards
Mike Wilson

Received on Tuesday, 15 April 2008 08:08:13 UTC