Prev: DOM ready, window.onload, etc.
Next: Chrome, canvas, PNG, Save Image As
From: GTalbot on 29 Dec 2009 14:41
On 29 déc, 04:03, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com>
wrote:
> Garrett Smith <dhtmlkitc...(a)gmail.com> writes:
> > OffsetTop and offsetParent are really bad legacy features. They're
> > defined using circular definition. See MSDN:
> > | OffsetTop:
> > | Retrieves the calculated top position of the object relative to the
> > | layout or coordinate parent, as specified by the offsetParent
> > | property.
> >http://msdn.microsoft.com/en-us/library/ms534302(VS.85).aspx
>
> > | OffsetParent:
> > | Retrieves a reference to the container object that defines the
> > | offsetTop and offsetLeft properties of the object.
> >http://msdn.microsoft.com/en-us/library/ms534302(VS.85).aspx
>
> That's not a circular definition. The two definitions say the *same*
> thing: An object has a layout/coordinate parent (referenced through its
> offsetParent property), and a position relative to the layout/coordinate
> parent (referenced through the offsetTop and offsetLeft properties).
>
> The "offsetParent" definition is a little vague in that it confuses
> the offsetTop/offsetLeft properties and their values.
>
> > Other borwsers, desparate to get sites to work, copied the badly
> > defined features differently.
>
> > In addition to the cases you mentioned, the OP's function will fail
> > when offsetParent has a border (in most browsers).
>
> That should probably be specified in the definition as well - which
> point of element is positioned at the offsetTop/offsetLeft point -
> in this case the top-left point of the border, if any), and what
> point of the layout parent is it relative to (the top-left point of
> the padding).
>
> I admit that it's not a great definition, but it's not circular.
>
> /L 'and if that's the best one can say of a definition ...'
> --
> Lasse Reichstein Holst Nielsen
>  'Javascript frameworks is a disruptive technology'

Circular, same thing, vague, confusing... It really sound similar to
me. 4 years ago, I created this test

http://www.gtalbot.org/BrowserBugsSection/MSIE6Bugs/OffsetValues.html

and said that the definitions were "circular, mutually inter-dependent
on each other" and I still believe they are circular today.

The "relative to the layout or coordinate parent" words do not mean
much by themselves. Only after a lot of testing (trials and errors)
and examining empirical results, you could figure out what that means.

e.g.:
a.b
"a" is an object that defines the property "b" of object "a".
"b" is the property defined by the object "a".
is very much circular to me.

Finally, MSDN has lots of editorial problems of this sort. Missing
important info (like border in this offsetParent case), missing good
useful+meaningful examples, always missing valid+compliant examples,
all kinds of mistakes, sometimes (deliberate?) exaggerations, IE-
centric code (eg named form controls accessed unshamelessly in global
scope), IE-specific code (eg document.all), missing required
attributes everywhere in examples, no doctype decl., over-excessive
redundance and emphasis on using X-UA meta-tag to trigger IE8
standards mode, etc.

MSDN is often the abbreviation for misunderstanding or the
abbreviation for MisunderStanding Developers Network.

Regards and season's greetings, Gérard
From: David Mark on 29 Dec 2009 15:24
On Dec 29, 4:15 am, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com>
wrote:
> Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> writes:
>
>
>
> > Garrett Smith <dhtmlkitc...(a)gmail.com> writes:
>
> >> OffsetTop and offsetParent are really bad legacy features. They're
> >> defined using circular definition. See MSDN:
> >> | OffsetTop:
> >> | Retrieves the calculated top position of the object relative to the
> >> | layout or coordinate parent, as specified by the offsetParent
> >> | property.
> >>http://msdn.microsoft.com/en-us/library/ms534302(VS.85).aspx
>
> >> | OffsetParent:
> >> | Retrieves a reference to the container object that defines the
> >> | offsetTop and offsetLeft properties of the object.
> >>http://msdn.microsoft.com/en-us/library/ms534302(VS.85).aspx
>
> > That's not a circular definition. The two definitions say the *same*
> > thing: An object has a layout/coordinate parent (referenced through its
> > offsetParent property), and a position relative to the layout/coordinate
> > parent (referenced through the offsetTop and offsetLeft properties).
>
> > The "offsetParent" definition is a little vague in that it confuses
> > the offsetTop/offsetLeft properties and their values.
>
> >> Other borwsers, desparate to get sites to work, copied the badly
> >> defined features differently.
>
> >> In addition to the cases you mentioned, the OP's function will fail
> >> when offsetParent has a border (in most browsers).
>
> > That should probably be specified in the definition as well - which
> > point of element is positioned at the offsetTop/offsetLeft point -
> > in this case the top-left point of the border, if any), and what
> > point of the layout parent is it relative to (the top-left point of
> > the padding).
>
> Well, that was based on guessing from the quoted text. Reality is
> a little more complex.
>
> Internet Explorer(8) and Opera calculate offsetTop/offsetLeft as the
> distances from the top-left point of the border of the layout parent
> to the top-left point of the border of the child.

Some versions of Opera have that deviation. If 8 introduced that, I'm
blissfully unaware (feature testing takes care of that for me).
From: Garrett Smith on 29 Dec 2009 18:21
David Mark wrote:
> On Dec 29, 3:19 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> David Mark wrote:
>>> On Dec 29, 1:35 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>>>> David Mark wrote:
>>>>> On Dec 29, 12:05 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>>>>>> David Mark wrote:
>>>>>>> On Dec 28, 9:53 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>>>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>>>> moha297 wrote:
>>>>>> [...]
>>>> [...]
>>>>>> function documentClicked(ev){ }
>>>>>> JSLint doesn't allow that perfectly valid, easily understandable program
>>>>>> to pass.
>>>>> Bad style. Makes it more confusing than it needs to be (for beginners
>>>>> who may have to maintain it). And you can turn that one off I think.
>>>> It is fine that way; nothing really confusing about it. It is
>>>> syntactically valid, standard code for any js engine.
>>> You know exactly what I mean.
>> I got that you think it is bad style, but I don't see it like that. I
>> see it as potentially *good* style, depending on how it is used.
>>
>> I use that a lot in defining modules.

[snip example]

>>
>> I find this way is nice for me because it is declarative from the top of
>> the file. I know right away what is being added to APE.dom. I can look
>> further down to see that.
>
> Why? Look up instead.
>

Most of us read top- down.
>
> I don't see why you want those declarations _after_ the mixin call.
> Seems backwards to me.
>
Those examples are kind of toy examples.

I do prefer that style, though, yes. I prefer the public exports as
close to the top of the file for the last few years, at least.

[...]

>> I know beginners are sometimes surprised to see that, but they are also
>> surprised with other things like typeof anArray == "object" or a == b,
>> yet, a !== b, new F().constructor !== F, augmented scope chain in catch
>> clause.
>
> Yes. So I think it is best to alleviate what you can.
>

Sheilding a beginner from observing that something works by describing
that thing that "works" as an error is not only not best, it is
misleading to a beginner.

>> A beginner would probably know that that FunctionDeclaration is added to
>> the variable object upon entering the execution context.
>
> I assume you mean they would _not_ know that.
>
Yes, that's what I meant.
[...]

>>>>> Nothing troubling about using alert. Now, calling it unqualified in a
>>>>> - finally - clause is another story.
>>>> What difference does it make if it is finally clause?
>>> Augmented scope of course. It's best to reference alert as a method
>>> of the window object (that's what it is after all). Then these
>>> questions don't come up.
>> Ah, no, that is not true. There is no augmented scope for a finally clause.
>
> Yes, I was thinking of the catch clause.
>
>> Putting it in the catch clause, there would be an augmented scope, but
>> it wouldn't matter unless the identifier for the catch clause was `alert`.
>
> Why even worry about mix-ups like this?
>

What could I possibly worry about here? Naming the catch clause's
identifier `alert`?

[...]

>>> e = e || window.event; // No good for elements in other frames
>> events, not elements.
>>
>>> So that "error" in JSLint helps to spot these situations as well.
>> That's a long stretch. Is JSLint really encouraging passing around
>> window references?
>
> I'm not saying it is encouraging anything. Just that that "error" can
> come in handy in some contexts.
>
>> I can't say I've tried passing window.event to
>> another frame.
>
> I don't follow. My point is that the above code only works for
> elements of one window. To work for frames, it would need to figure
> the window that contains the target element. For such applications,
> the unqualified window references are few and far between (if any).
> There are none in My Library.
>

I get the point about passing window reference around.

Why are you carrying on about elements wrt an example that uses
window.event?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 29 Dec 2009 19:55
On Dec 29, 6:21 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:

[...]

>
> I get the point about passing window reference around.
>
> Why are you carrying on about elements wrt an example that uses
> window.event?

As I explained, it is an example where the "error" in question is
useful. Its wording is confusing, but its presence can be beneficial.
From: kangax on 29 Dec 2009 21:09
On 12/28/09 9:41 PM, David Mark wrote:
> On Dec 28, 8:53 pm, GTalbot<newsgr...(a)gtalbot.org> wrote:
>> On 28 d�c, 19:33, David Mark<dmark.cins...(a)gmail.com> wrote:
>>
>>
>>
>>> On Dec 28, 6:44 pm, GTalbot<newsgr...(a)gtalbot.org> wrote:
>>
>>>> On 28 d�c, 12:32, moha297<moha...(a)gmail.com> wrote:
>>
>>>>> I want to get the top and left values for a div on the screen.
>>
>>>> As Peter Michaux replied to you, your description of the problem for
>>>> which you require assistance is not accurate, too general. An URL
>>>> would have helped. And maybe, just maybe, you may be wrongly using
>>>> offsetLeft and offsetTop to get the left and top values of a div on
>>>> the screen. We can't be sure of this without a real webpage, URL.
>>
>>>>> I have been using the code to calculate the top and left values.
>>
>>>>> var total1 = 0;
>>>>> var total2 = 0;
>>>>> while(element){
>>>>> total1+=element.offsetTop;
>>>>> total2+=element.offsetLeft;
>>>>> try{
>>>>> element=element.offsetParent;
>>
>>>>> }catch(E){
>>>>> break;
>>>>> }
>>>>> }
>>
>>>> First, the while statement does not make sense.
>>
>>>> You want an element (which is going to execute the controlled block)
>>>> that has offsetTop and offsetLeft values to do the controlled block.
>>>> Therefore, your while statement should be
>>
>>>> while (element.offsetParent) {..controlled block..}
>>
>>> Just don't pass orphaned elements.
>>
>> I do not understand your "Just don't pass orphaned elements." .. or
>> I'm not sure I understand what you mean to say.
>
> Orphaned (removed from the document) elements can become ActiveX
> objects behind the scenes. IIRC, orphaning by innerHTML replacement
> is a sure bet.

Actually, last time time I checked, offsetParent of any element lacking
parentNode would blow up (not necessarily the one orphaned by innerHTML):

In other words, this should be true:

typeof document.createElement('div').offsetParent == 'unknown';

And, interestingly, offsetParent of element that's a child of
parent-less element would just return null. Go figure.

[...]

--
kangax
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: DOM ready, window.onload, etc.
Next: Chrome, canvas, PNG, Save Image As