Fwd: [cssom-view] small update

bump.


---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, Apr 15, 2008 at 11:23 PM
Subject: Re: [cssom-view] small update
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Mike Wilson <mikewse@hotmail.com>, Www-style <www-style@w3.org>


On Tue, Apr 15, 2008 at 7:57 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
 >
 >  Mike Wilson wrote:
 >
 > > 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.
 > >

 That would make sense, doing what IE does, but browsers have mistakes
 from attempted rev eng'ing IE's implementation. Mozilla tried to copy
 IE, but it had a mistake (or unintentional deviation, or "bug").

 IE's documentation is really bad on these properties, and the
 properties are engineered in a way that they do something that is
 somewhat useful most of the time.

 So we have now mistakes in other implementations' of offset*, and now,
 finally, we get a standard of offset* (which the original is only
 somewhat useful), yet the spec is largely based on the bugs.

 The reasoning (AFAICT) behind standardizing a not-so-useful property
 in an even less useful, actually buggy way, is that there are pages
 that expect the new, quirky, buggy behavior of Mozilla, Safari, Opera.
 Major Ajax libraries that have code geared towards none other than an
 environment that matches something in navigator.userAgent. This is
 harmful. The bugs introduced by other browsers have caused harm.

 A standard based on harmful quirks/bugs is also harmful, but in a
 different way. It is harmful because it requires change on something
 that has a lot of dependencies (pages). If it changes, the pages
 break. Unstable dependency.

 To me, this is just Wrong. Pages should not have ever had to rely on
 the buggy version of IE's offset*. They never ever should have used
 browser detection because it locks them in to browsers. If a browser
 changes, it will break pages.

 But CSSOM Views proposes just such changes. There's no way to make a
 happy compromise between implementations. If you're a browser, you
 either you change and break pages, or you don't. There's no way for
 any browser to implement offset* w/o breaking pages. Not one browser
 can do it. Opera gets the least negative impact with CSSOM, but will
 still suffer due to recent changes in offsetTop/Left which now do not
 include clientTop/Left. This change will likely break some pages in
 Opera, should Opera implement the change.

 Other implementations are different. Different from the spec,
 different from Opera, different from IE, and different from each
 other, depending on the case.

 New implementations might just consider picking one browser and
 copying it's implementation. Personally, I'd rather suggest copying
 IE's implementation because it doesn't violate the Principle of Least
 Astonishment as much as the other browsers' implementation of offset*
 (e.g. IE doesn't have the buggy, copied implementation of offset*).
 Browser vendors could write a test suite for the purpose of rev
 eng'ing, and page authors could then use that for a live reference
 (what works/doesn't work in [browser_x])

 If implementations change to match the CSSOM Views standard they may
 break millions of pages which rely on this property. Who wants to do
 code metrics on a use case that is based on current implementations
 and how/where they'll break with the new CSSOM Views spec of offset* ?

 Offset* can't be standardized without breaking pages.

 Offset* isn't really stable. Standardizing it would introduce change,
 which would make offset* less stable.

 There should be a new property; one that Works.


 >
 >  Of course a lot of content has the "IE" and "everything but IE" branches,
 > since these methods report the size of CSS boxes and those are different
 > sizes in IE6 and various other browsers...
 >
 >  It's a hard call whether, for a browser that closely follows CSS2.1 and
 > doesn't identify as IE, matching IE6 exactly will in fact be
 > site-compatible.
 >
 >
 > > The resulting CSSOM spec is the sum of all the above steps and
 > > no information is given about the intermediate steps.
 > >
 >
 >  Yeah, if there were a way to get that information, that would be very
 > nice...
 >
 >
 >
 > > So, referring back to your expectation that the spec is really
 > > about reverse-engineering IE
 > >
 >
 >  Well.  It's about reverse-engineering what web sites expect.  Which may be
 > IE or not, depending on the situation....
 >
 >
 >
 > > 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".
 > >
 >
 >  If that's the case, that's unfortunate.  The latter should be the goal,
 > imo.

 The issues have actually been clearly pointed out in examples provided
 by Mike and me.


 http://lists.w3.org/Archives/Public/www-style/2008Mar/0198.html

 Is one clear example that I'm still harping on, (my hands feel like a
 broken record). It's a special case for both Opera and CSSOM. It is
 useful to have position: relative on BODY to force it to be a
 container, but it won't make it an offsetParent (only in Opera/CSSOM).
 It's a clear deviation from what other browsers do. Other browsers'
 implementations have been based on IE quirks mode offsetParent.

 The test case cannot be run from a link; you have to copy-paste it
 from the text I posted to the group the test case:-


 http://lists.w3.org/Archives/Public/www-style/2008Mar/0198.html

 - clearly shows that Opera is the only browser that complies with
 CSSOM and that the other 3 (FF/Saf/IE) fail when BODY has position
 relative and the last positioned element has position.

 That's just one. I posted I don't know how many times about that one
 and ended up with: "That list subscribers do not always get what they

want doesn't mean there's a communication breakdown."

 Then there's a follow up with:

"If there's a better algorithm for offset* available that meets the constraints"

 But as Mike Wilson pointed out, this behavior is divergence, and I
 followed up pointing out that it makes more sense to use HTML.

http://lists.w3.org/Archives/Public/www-style/2008Mar/0198.html

 It was pointed out that not allowing BODY to be an offsetparent would
 be more consistent with quirks mode . That quirks mode gets weighted
 as such, to me, seems to be a Bad Idea. I asked a few moons ago: "Why
 standardize a quirks mode?"

 We can see that clearly only Opera and CSSOM favor this behavior. Even
 quirks mode on FF/Safari/IE:

 <body style='position:relative' onload="alert(a.offsetParent ==
document.body)">
 <div id=a style='position:relative'>a</div>
 </body>

 So if BODY has position: relative, it can be an offsetParent, yet
 CSSOM and Opera says no, BODY cannot be an offsetParent.

 So, it would seem to make more sense to specify that BODY can be an
 offsetParent, if it has position: relative, or, more specificially,
 that the nearest positioned ancestor is the offsetParent, and, if none
 found, [something_else], is used, where something _else, ideally,
 would match IE in standards mode, and be HTML.

 Garrett

 >
 >  -Boris
 >
 >

Received on Monday, 21 April 2008 01:55:07 UTC