W3C home > Mailing lists > Public > www-style@w3.org > April 2008

Re: [cssom-view] small update

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 15 Apr 2008 23:23:58 -0700
Message-ID: <c9e12660804152323i364ff106x92795ba26c523fea@mail.gmail.com>
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 Wednesday, 16 April 2008 06:24:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:05 GMT