I can't say that I feel strongly about it, but having both seems sort
of redundant.
It's marginally non-redundant for languages where casting is explicit,
since one gets you the AbstractView interface, and the other gets you
Window.
I'd say that that is a pretty marginal usefulness. However, if all else
is equal I'd say that parentWindow is better since I'm betting Windows
are used a lot more then AbstractViews.
What is the advantage over having just one of the two? If we add both
only opera is going to be conforming in this regard, if we just add
one then the number of browsers that work out of the box is going to
be greater.
I think the spec already has seemingly simple and obvious requirements
that make at least one existing browser implementation non-conformant,
and there will probably be at least one of these for each browser.
Opera, Safari and Win IE and Mac IE already fail at least some minor
things on the test suite. So in terms of requiring things that not all
browsers already conform to, we have already crossed the Rubicon.
I don't mean conformant to the spec as a whole, but rather to this one
feature. Basically, what is the point of giving dangling a redundant
feature in front of author that doesn't work in a lot of browsers.
I guess a possible answer to that question is that the point is that
this is something that browsers should implement in order to be
conformant to the content that is already out there.
Is that really the case with either of these properties though?
/ Jonas
