- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 15 Apr 2008 10:40:29 +0200
- To: "Mike Wilson" <mikewse@hotmail.com>, "'Boris Zbarsky'" <bzbarsky@mit.edu>
- Cc: "'Www-style'" <www-style@w3.org>
The reverse engineering happened quite a while ago. On Tue, 15 Apr 2008 10:07:14 +0200, Mike Wilson <mikewse@hotmail.com> wrote: > 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): http://annevankesteren.nl/2006/05/offset http://annevankesteren.nl/2006/06/offset-attributes > 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 http://dev.w3.org/csswg/cssom-view/#background 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 www-style@w3.org. 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 <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Tuesday, 15 April 2008 08:40:27 UTC