RE: [cssom-view] small update

Hi Anne,

Before diving into the previous subjects I'd like to discuss how to 
standardize features that are invented by one vendor and later copied 
by the other vendors, as this seems to be a central question here.

"Post" standardization of a feature should only change things if 
something was obviously broken in the original design, and can easily 
be interpreted to be not in the authors' intent.

If, apart from this kind of corrections, other vendors choose to make 
incompatible changes when copying the feature, then this should render 
bug reports in their respective bug handling systems, and not be input 
for standardization.

The issues we are discussing here with IE's behaviour can not be seen 
as anything else than design choices, and thus should make it into the
spec.

> Thanks! The one piece that seems to be missing here is quirks 
> mode. The specification intents to deal with quirks mode, limited 
> quirks mode, and no quirks mode, as defined by HTML 5.

I'm a bit suprised to hear compatibility with quirks mode being 
presented as a major argument in a standards discussion :-). HTML5 
defines how to detect quirks mode, which is fine, but if any serious 
attempt is to be made to be compatible with quirks mode regarding 
element positions (as is the subject of offset* props) then you also
need to standardize IE's old broken box model, block-displayed IMG:s, 
ignoring padding for IMG:s etc.

It is true that IE has differing behaviour for offset* props between
std and quirks mode, but that doesn't make it more right to 
standardize on the quirks behaviour. The browsers that have copied 
only the quirks mode behaviour regarding HTML/BODY choice should have 
bugs filed. Note f ex that Konqueror is doing the right thing with 
switching HTML/BODY depending on std/quirks.

Being a W3C specification I think these properties should be described 
for standards mode and that other browser vendors should comply to 
this behaviour. Then adding handling for quirks mode is a marketing 
decision to be taken by each browser vendor, and should be handled
outside of W3C as long as other crucial parts of quirks mode is not
standardized.

Alternatively, if these properties are to be regarded as a heritage
from the old dark ages of quirks mode, then the described (quirks)
behaviour can be kept but only when the browser enters quirks mode
(you should reference this in the spec). In standards mode the props
should then be made unavailable.

> > 1) CSSOM differs from IE by letting div1 point to BODY instead
> >    of HTML.
> >
> >    Q: What was the rationale for this change? (I agree that it
> >       is "cleaner" not to special-case children of BODY to
> >       instead point to HTML, but IE is the mother of these
> >       properties so...)
> 
> The rationale is that it's more consistent with non-IE 
> browsers and that it also works for quirks mode.

Fine, I interpret this as compatibility with deployed content and 
deployed browsers is a major goal. Here's my take on that:
- The browsers to mainly consider for compatibility is IE, Firefox, 
  and Safari, due to either having a substantial market share or being
  natively installed in OS installations. Certainly there are a number
  of other fine browsers (including Opera), but these should have
  lower priority.
- IE today has 60-80% of the traffic (depending on who you ask).
- Considering that the offset* properties appeared in Firefox and 
  Safari after year 2000, we can be certain that majority of deployed 
  content using them takes IE into account as being the most used 
  browser since then.
- Firefox's offset* implementation has been broken during most of its
  existence (thanks Garrett for the link!).
- Deciding to change IE's behaviour in favor of compatibility with 
  non-IE browsers gives me the impression that you are counting
  browser implementations instead of deployed installations to 
  achieve compatibility. Using the most important browsers from above,
  this is what we have:
    IE:     inventor of offset* props, both std and "quirks" mode.
    FF:     implements a broken variant of "quirks mode" offset props.
    Safari: appeared in 2003, implements "quirks mode" offset props.
  The net result of the current CSSOM spec is that IE and FF both
  will have to change their algorithms to adapt to Safari (which has
  a market share below 3%).

With these facts at hand I would suggest not taking the risk to 
deviate from IE's behaviour, even though the changes may seem 
harmless to some.

> >    Q: Did you consider using the CB algorithm for offsetParent
> >       and were there any hard problems?
> 
> It would not be consistent with any browser. Even IE deviates 
> from it as you illustrate.

Oh sorry, here I meant keeping IE's special-casing for HTML/BODY
while using CB for remaining elements (which I agree wasn't clear 
from the context I put it in). 
So what I meant is did you find any other deviations from CB
in IE's offsetParent algorithm (standards mode) ?

And if not, don't you see an advantage in reusing an existing 
parent reference instead of inventing a new one, especially when
it is also compliant with IE's behaviour in standards mode?

> >    Q: Have you considered CSSOM's deviation with IE for div3b
> >       above or is it something that needs to be fixed in the
> >       spec?
> 
> I don't consider it a bug in the specification. The specification
> as is works with deployed content and works well in both quirks 
> and no quirks mode. That's really all that matters as far as 
> offset* is concerned, in my opinion.

Wouldn't a closer adherence to IE's behaviour also "work well in 
both quirks and no quirks mode", or even better? As you say, this 
is what matters.

Regarding the deviation for div3b, we get more of this kind of
thing in IE's quirks mode as it is different again:

offsetParent for/in: IE7/std   IE7/quirk  CSSOM   [CB]
HTML                 null      null       null    ICB
 BODY                null      null       null    HTML
  div1(pos=rel)      HTML      BODY       BODY    BODY
   div2a             div1      div1       div1    div1
   div2b             div1      div1       div1    div1
    div3a(pos=abs)   div1      div2b      div1    div1
    div3b            div2b     div2b      div1    div2b

So, while CSSOM is inspired by quirks mode for HTML/BODY it 
breaks its offsetParent behaviour for most lower nested elements,
resulting in not being fully compatible with anything else than
Firefox and Safari (of the major browsers).

I am getting the feeling that the real major goal for the CSSOM
spec is to be compatible with offset* deviations implemented by
non-IE browsers, independently of the impact on deployed content?

> > 3) As can be seen in both tables IE returns useful values for
> >    BODY's offsetLeft property while CSSOM hardwires it to 0.
> >
> >    Q: What was the rationale for this deviation from IE's
> >       behaviour?
> 
> This is because the HTML body element is special and not the 
> HTML html element. (In the CSSOM specification anyway.) If we'd 
> give "meaningfull" results for the HTML body element scripts 
> that try to determine their position would go hopelessly wrong, 
> because when offsetParent points to the HTML body element offset 
> are given with respect to the initial containing block origin 
> and not the padding edge of the HTML body element.

Ah right, this is an effect of having offsetParent==BODY mean ICB.
In IE this is similar but on the |HTML| element instead 
(offsetParent==HTML means ICB and HTML always returns offset=0).

> The root element can be positioned just like any other element.

Right. Currently this has no effect in IE or FF but well, things 
might change in the future.

> >    [Btw it seems everybody is using margin edge instead of
> >    padding edge when measuring from the |HTML| element]
> 
> And that's not inconsistent? 

Of course it is; this is exactly the reason why I mentioned 
it :-/.

And to sum up; please note that I am not an IE fanboy ;-) I swear 
over IE at times just as much as anybody else. But I think the 
"IE bashing contest" gets out of control at times and I encourage 
a more pragmatic approach.

Best regards
Mike

Received on Wednesday, 19 March 2008 10:45:20 UTC