«

On Dec 4, 5:07*am, Hans-Georg Michna <hans-
georgNoEmailPle...@michna.com> wrote:
> On Sat, 3 Dec 2011 17:14:27 -0800 (PST), David Mark wrote:
> >... buy the book when it comes out.
>
> Which book? Have I missed something?
>

Not yet.

On Dec 3, 7:38*pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 3, 4:50*pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
>
>
>
>
>
>
>
>
> > On 03/12/2011 00:38, David Mark wrote:
>
> > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > wrote:
>
> > >> OneTipmight be the answer to "I have an on-screen element, of known
> > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > >> [double-]click with respect to a given position in the element itself?"
>
> > > Tricky. *
>
> > > Your best bet is to see thetipof the day related to coordinates.
> > > *From that you should be able to get the coordinates of the element
> > > relative to the viewport (or "window" as I think I referred to it in
> > > that post). *So you will need the mouse coordinates relative to the
> > > viewport. *Ironically enough, it's trivial to find those in the oldIE
> > > versions that lacked pageX/Y properties. *But for everything else, you
> > > have to have to subtract the scroll position as pageX/Y are relative
> > > to the document. *Depending on context, getting the scroll positionis
> > > either trivial (one-liner) or fairly complex. *Frustratingly, it's IE
> > > (all versions AFAIK) that needs most of the extra code in this case.
> > > You also have to consider other factors like whether you will need
> > > this to work in quirks mode (hopefully not)
>
> > > It looks like:-
>
> > > // No quirks mode, frames or other windows (just the one running the
> > > script)
>
> > > var getScrollPosition;
>
> > > if ('number' == typeof window.pageXOffset) {
>
> > > * *// Many "standards-based" browsers feature this non-standard
> > > property
> > > * *// No ambiguity about what this window property means
>
> > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > Opera 10+.
>
> > IE 8 and older browsers in standards-compliant mode (strict mode) woulduse:
>
> > if (document.documentElement && document.documentElement.scrollTop) {
> > * *return document.documentElement.scrollTop;
>
> > }
>
> > But IE in quirks mode (tested with IE would use:
> > if (document.body) {
> > * *return document.body.scrollTop;
>
> > }
>
> So let's finish this off. *If you need it to work in IE 9 and
> virtually every other browser made since the turn of the century:-
>
> if ('number' == typeof window.pageXOffset) {
> * getScrollPosition = function() {
> * * return [window.pageXOffset, window.pageYOffset];
> * };
>
> * // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> "concise" BS.
>
> * // Works for mouse or touch
>
> * getPointerPositionRelativeToViewport = function(e) {
> * * return [e.pageX - window.pageXOffset, e.pageY -
> window.pageYOffset]
> * };
>
> }
>
> Piece of cake (as this context usually is).
>
> Now, what if you need IE 6-8 to join in the fun?
>
> Put this script inside conditional comments (so the others don't
> download it):-
>
> // Last test is to exclude IE quirks mode and IE 5
>
> if (document.documentElement && 'number' == typeof
> document.documentElement.scrollLeft &&
> document.documentElement.clientWidth) {
> * getScrollPosition = function() {
>
> * * // Note: optimize by saving a reference to documentElement (saves
> two dot operations)
>
> * * return [document.documentElement.scrollLeft,
> document.documentElement.scrollTop];
> * };
>
> * getPointerPositionRelativeToViewport = function(e) {
>
> * * // Yes, we would use these in non-IE browsers too if history of
> implementation
> * * // wasn't atrocious. Perhaps in a few years...
> * * // Regardless, you know for sure these work as advertised in
> legacy IE versions
>
> * * // NOTE: the HTML border "issue" is irrelevant as same offset for
> element positions
>
> * * return [e.clientX, e.clientY]
> * };
>
> }
>
> // Detect API features (never changes, regardless of specific
> renditions used)
> // Self-documenting (really, not like jQuery's claims)
>
> if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> * var el = getElementById('johnstockton');
>
> * el.onmousedown = ...
> * el.ondblclick = ...
>
> }
>
> Will leave rest as an exercise.

A solution. This is the "good riddance to bad baggage" environment
context.

// This function fades away in IE 8- and compatibility modes

if ('number' == typeof window.pageXOffset) {

* // Works for mouse or touch

* getPointerPositionRelativeToViewport = function(e) {
* * return [e.pageX - window.pageXOffset, e.pageY -
window.pageYOffset]
* };
}

/*
* Need these two API functions
* See position tip for first function
* Should need the normalized rendition that subtracts
documentElement.clientLeft/Top
* as comparing element position to pointer position results that
don't have the
* client-related quirk (i.e. getBoundingClientRect, clientX/Y not
involved)
* Quirk must be present or absent on both sides of the equation to be
factored out.
*/

if (getElementPositionRelativeToViewport &&
getPointerPositionRelativeToViewport) {
* var el = getElementById('johnstockton');
var pointerPosition;

// NOTE: should only respond to one event type at a time

* el.onmousedown = el.ontouchstart = function(e) {
pointerPosition = getPointerPositionRelativeToViewport(e);
};

* el.onclick = function(e) {

/*
* Make sure a mousedown/touchstart preceded the click on this
element
* If another mousedown listener hid an element that was covering
* the "johnstockton" element, could get click without mousedown
*/

if (pointerPosition) {
var elementPosition =
getElementPositionRelativeToViewport(this);
window.alert([pointerPosition[0] - elementPosition[0],
pointerPosition[1] - elementPosition[1]]);

// One click per mousedown/touchstart

pointerPosition = null;
}
};
}

If wrapped in a function, be sure to set el to null (to break circular
references). As usual, no warranty, may not be appropriate for your
needs, etc.

As mentioned, you can add this to create a legacy IE rendition,
perhaps even putting it inside conditional comments, loading it only
for version 8 and under (which will also catch compatibility mode).

if (document.documentElement && 'number' == typeof
document.documentElement.scrollLeft && 'number' == typeof
document.documentElement.clientLeft &&
document.documentElement.clientWidth) {
* getPointerPositionRelativeToViewport = function(e) {
* * return [e.clientX - document.documentElement.clientLeft,
e.clientY - document.documentElement.clientTop]
* };
}

Note that this is also a normalized rendition as the results will be
compared to the results of the normalized element position function
that accounts for IE's chrome HTML border. Quirk is absent on both
sides of the equation.

It should be mentioned that it is best not to put borders on the HTML
element, otherwise ambiguity is introduced in the relationship between
clientLeft/Top values (normally 0) and element coordinates. Certainly
HTML borders are not part of the Chrome in other browsers that copied
getBoundingClientRect, so it is unrealistic to assume they treated the
HTML borders the same. Last I heard somebody was trying to stamp a
standard on this mess (and good luck to them), but that will only make
a difference on paper.

IIRC, all works out even with HTML borders in other browsers, but why
tempt fate? Probably doesn't need mentioning that putting borders on
the HTML element is crazy anyway. This is the sort of non-issue that
public libraries love to tackle.

I spent hours putting margins and borders on the HTML (body in quirks
mode) element when testing My Library. I suppose I could justify the
waste of time as an academic exercise, but wouldn't recommend using
the results over functions like the above. As soon as you lose sight
of your context, extraneous complications start to appear. This
happens automatically in projects that involve collaboration with lots
of other developers, each likely thinking in the context of their
current (downstream) efforts.

Doesn't take long before the best hint you can give about the
functions is that they pass some tests in some recent versions of
Chrome, Safari, Opera, Firefox and some versions/modes of IE. Other
browsers, which is the what today's browsers will be tomorrow, are
anyone's guess. The oft-heard line: "we don't care about [browser x]"
is truly indicative of a careless, cavalier and ultimately futile
approach to browser scripting.

Unless you want to be on an endless treadmill, "keeping up" with five
(then seven, then nine...) browsers, you want cross-browser code,
which tests features and does *nothing* in environments that fail.
Therefore, during development and testing, it is necessary to load a
script in at least *one* browser that is not expected to pass the
tests (usually an old browser). The jQuery way of wearing blinders
and quoting recent browser version numbers as the starting point of
their caring is a perfectly ridiculous strategy, particularly as rapid
change in browser differences (which jQuery ostensibly buffers) is
what neophytes fear the most. If the library developers are that
focused on Chrome 4+, Opera 10+, etc., you have to wonder how they
managed to screw up Opera 9- or Chrome 3-; probably because they were
so focused on Opera 9+ and Chrome 3+ at the time. This sort of
nonsense has been going on since the late 90's. Just steer clear of
projects with five browser icons lined up to indicate their perceived
"compatibility". Think Dynamic Drive with three more icons.

Nothing is guaranteed, but cross-browser code has the best shot at
lasting from one cycle of browser "innovation" to the next and to fade
away gracefully as today's browsers go the way of Netscape 6.

When you consider mobile users, most are using "other browsers"
today. The browser in Android devices is not Chrome. iOS devices do
not run the same Safari as found on desktops. Then there are the
mobile versions of Opera and Firefox and the new Windows phones, which
are clearly not exactly the same as their desktop counterparts. And,
other than fortune tellers, who knows what's next?

On Dec 4, 4:37*pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 3, 7:38*pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 3, 4:50*pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
> > > On 03/12/2011 00:38, David Mark wrote:
>
> > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > > wrote:
>
> > > >> OneTipmight be the answer to "I have an on-screen element, of known
> > > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > > >> [double-]click with respect to a given position in the element itself?"
>
> > > > Tricky. *
>
> > > > Your best bet is to see thetipof the day related to coordinates.
> > > > *From that you should be able to get the coordinates of the element
> > > > relative to the viewport (or "window" as I think I referred to it in
> > > > that post). *So you will need the mouse coordinates relative to the
> > > > viewport. *Ironically enough, it's trivial to find those in the old IE
> > > > versions that lacked pageX/Y properties. *But for everything else, you
> > > > have to have to subtract the scroll position as pageX/Y are relative
> > > > to the document. *Depending on context, getting the scroll position is
> > > > either trivial (one-liner) or fairly complex. *Frustratingly, it's IE
> > > > (all versions AFAIK) that needs most of the extra code in this case..
> > > > You also have to consider other factors like whether you will need
> > > > this to work in quirks mode (hopefully not)
>
> > > > It looks like:-
>
> > > > // No quirks mode, frames or other windows (just the one running the
> > > > script)
>
> > > > var getScrollPosition;
>
> > > > if ('number' == typeof window.pageXOffset) {
>
> > > > * *// Many "standards-based" browsers feature this non-standard
> > > > property
> > > > * *// No ambiguity about what this window property means
>
> > > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > > Opera 10+.
>
> > > IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> > > if (document.documentElement && document.documentElement.scrollTop) {
> > > * *return document.documentElement.scrollTop;
>
> > > }
>
> > > But IE in quirks mode (tested with IE would use:
> > > if (document.body) {
> > > * *return document.body.scrollTop;
>
> > > }
>
> > So let's finish this off. *If you need it to work in IE 9 and
> > virtually every other browser made since the turn of the century:-
>
> > if ('number' == typeof window.pageXOffset) {
> > * getScrollPosition = function() {
> > * * return [window.pageXOffset, window.pageYOffset];
> > * };
>
> > * // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> > "concise" BS.
>
> > * // Works for mouse or touch
>
> > * getPointerPositionRelativeToViewport = function(e) {
> > * * return [e.pageX - window.pageXOffset, e.pageY -
> > window.pageYOffset]
> > * };
>
> > }
>
> > Piece of cake (as this context usually is).
>
> > Now, what if you need IE 6-8 to join in the fun?
>
> > Put this script inside conditional comments (so the others don't
> > download it):-
>
> > // Last test is to exclude IE quirks mode and IE 5
>
> > if (document.documentElement && 'number' == typeof
> > document.documentElement.scrollLeft &&
> > document.documentElement.clientWidth) {
> > * getScrollPosition = function() {
>
> > * * // Note: optimize by saving a reference to documentElement (saves
> > two dot operations)
>
> > * * return [document.documentElement.scrollLeft,
> > document.documentElement.scrollTop];
> > * };
>
> > * getPointerPositionRelativeToViewport = function(e) {
>
> > * * // Yes, we would use these in non-IE browsers too if history of
> > implementation
> > * * // wasn't atrocious. Perhaps in a few years...
> > * * // Regardless, you know for sure these work as advertised in
> > legacy IE versions
>
> > * * // NOTE: the HTML border "issue" is irrelevant as same offset for
> > element positions
>
> > * * return [e.clientX, e.clientY]
> > * };
>
> > }
>
> > // Detect API features (never changes, regardless of specific
> > renditions used)
> > // Self-documenting (really, not like jQuery's claims)
>
> > if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> > * var el = getElementById('johnstockton');
>
> > * el.onmousedown = ...
> > * el.ondblclick = ...
>
> > }
>
> > Will leave rest as an exercise.
>
> A solution. *This is the "good riddance to bad baggage" environment
> context.
>
> *// This function fades away in IE 8- and compatibility modes
>
> *if ('number' == typeof window.pageXOffset) {
>
> ** // Works for mouse or touch
>
> ** getPointerPositionRelativeToViewport = function(e) {
> ** * return [e.pageX - window.pageXOffset, e.pageY -
> window.pageYOffset]
> ** };
> *}
>
> /*
> ** Need these two API functions
> ** See positiontipfor first function
> ** Should need the normalized rendition that subtracts
> documentElement.clientLeft/Top
> ** as comparing element position to pointer position results that
> don't have the
> ** client-related quirk (i.e. getBoundingClientRect, clientX/Y not
> involved)
> ** Quirk must be present or absent on both sides of the equation to be
> factored out.
> **/
>
> if (getElementPositionRelativeToViewport &&
> getPointerPositionRelativeToViewport) {
> ** var el = getElementById('johnstockton');
> * *var pointerPosition;
>
> * *// NOTE: should only respond to one event type at a time

Didn't make this very clear. I mean you will get dupes with touch
input (both touchstart and mousedown)

>
> ** el.onmousedown = el.ontouchstart = function(e) {

Oops. Didn't use "addEvent" wrapper, so no "e" in IE.

if (!e) {
e = window.event;
}

Normally would use a wrapper and hopefully one that avoids the
circular reference issue as well. Follow the JSPerf link on original
post to find a couple of those. It's ugly to have such IE-isms in the
application code.

> * * *pointerPosition = getPointerPositionRelativeToViewport(e);
> * *};
>
> ** el.onclick = function(e) {

Don't actually need "e" here.

On Dec 4, 7:01*pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 4, 4:37*pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Dec 3, 7:38*pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Dec 3, 4:50*pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
> > > > On 03/12/2011 00:38, David Mark wrote:
>
> > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > > > wrote:
>
> > > > >> OneTipmight be the answer to "I have an on-screen element, of known
> > > > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > > > >> [double-]click with respect to a given position in the element itself?"
>
> > > > > Tricky. *
>
> > > > > Your best bet is to see thetipof the day related to coordinates.
> > > > > *From that you should be able to get the coordinates of the element
> > > > > relative to the viewport (or "window" as I think I referred to itin
> > > > > that post). *So you will need the mouse coordinates relative tothe
> > > > > viewport. *Ironically enough, it's trivial to find those in theold IE
> > > > > versions that lacked pageX/Y properties. *But for everything else, you
> > > > > have to have to subtract the scroll position as pageX/Y are relative
> > > > > to the document. *Depending on context, getting the scroll position is
> > > > > either trivial (one-liner) or fairly complex. *Frustratingly, it's IE
> > > > > (all versions AFAIK) that needs most of the extra code in this case.
> > > > > You also have to consider other factors like whether you will need
> > > > > this to work in quirks mode (hopefully not)
>
> > > > > It looks like:-
>
> > > > > // No quirks mode, frames or other windows (just the one running the
> > > > > script)
>
> > > > > var getScrollPosition;
>
> > > > > if ('number' == typeof window.pageXOffset) {
>
> > > > > * *// Many "standards-based" browsers feature this non-standard
> > > > > property
> > > > > * *// No ambiguity about what this window property means
>
> > > > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > > > Opera 10+.
>
> > > > IE 8 and older browsers in standards-compliant mode (strict mode) would use:
>
> > > > if (document.documentElement && document.documentElement.scrollTop){
> > > > * *return document.documentElement.scrollTop;
>
> > > > }
>
> > > > But IE in quirks mode (tested with IE would use:
> > > > if (document.body) {
> > > > * *return document.body.scrollTop;
>
> > > > }
>
> > > So let's finish this off. *If you need it to work in IE 9 and
> > > virtually every other browser made since the turn of the century:-
>
> > > if ('number' == typeof window.pageXOffset) {
> > > * getScrollPosition = function() {
> > > * * return [window.pageXOffset, window.pageYOffset];
> > > * };
>
> > > * // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> > > "concise" BS.
>
> > > * // Works for mouse or touch
>
> > > * getPointerPositionRelativeToViewport = function(e) {
> > > * * return [e.pageX - window.pageXOffset, e.pageY -
> > > window.pageYOffset]
> > > * };
>
> > > }
>
> > > Piece of cake (as this context usually is).
>
> > > Now, what if you need IE 6-8 to join in the fun?
>
> > > Put this script inside conditional comments (so the others don't
> > > download it):-
>
> > > // Last test is to exclude IE quirks mode and IE 5
>
> > > if (document.documentElement && 'number' == typeof
> > > document.documentElement.scrollLeft &&
> > > document.documentElement.clientWidth) {
> > > * getScrollPosition = function() {
>
> > > * * // Note: optimize by saving a reference to documentElement (saves
> > > two dot operations)
>
> > > * * return [document.documentElement.scrollLeft,
> > > document.documentElement.scrollTop];
> > > * };
>
> > > * getPointerPositionRelativeToViewport = function(e) {
>
> > > * * // Yes, we would use these in non-IE browsers too if history of
> > > implementation
> > > * * // wasn't atrocious. Perhaps in a few years...
> > > * * // Regardless, you know for sure these work as advertised in
> > > legacy IE versions
>
> > > * * // NOTE: the HTML border "issue" is irrelevant as same offsetfor
> > > element positions
>
> > > * * return [e.clientX, e.clientY]
> > > * };
>
> > > }
>
> > > // Detect API features (never changes, regardless of specific
> > > renditions used)
> > > // Self-documenting (really, not like jQuery's claims)
>
> > > if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> > > * var el = getElementById('johnstockton');
>
> > > * el.onmousedown = ...
> > > * el.ondblclick = ...
>
> > > }
>
> > > Will leave rest as an exercise.
>
> > A solution. *This is the "good riddance to bad baggage" environment
> > context.
>
> > *// This function fades away in IE 8- and compatibility modes
>
> > *if ('number' == typeof window.pageXOffset) {
>
> > ** // Works for mouse or touch
>
> > ** getPointerPositionRelativeToViewport = function(e) {
> > ** * return [e.pageX - window.pageXOffset, e.pageY -
> > window.pageYOffset]
> > ** };
> > *}
>
> > /*
> > ** Need these two API functions
> > ** See positiontipfor first function
> > ** Should need the normalized rendition that subtracts
> > documentElement.clientLeft/Top
> > ** as comparing element position to pointer position results that
> > don't have the
> > ** client-related quirk (i.e. getBoundingClientRect, clientX/Y not
> > involved)
> > ** Quirk must be present or absent on both sides of the equation to be
> > factored out.
> > **/
>
> > if (getElementPositionRelativeToViewport &&
> > getPointerPositionRelativeToViewport) {
> > ** var el = getElementById('johnstockton');
> > * *var pointerPosition;
>
> > * *// NOTE: should only respond to one event type at a time
>
> Didn't make this very clear. *I mean you will get dupes with touch
> input (both touchstart and mousedown)

Kind of trailed off there, didn't I? See attachTouchListeners in
Touch add-on. If it gets touch events, it ignores corresponding mouse
events. Doesn't matter so much in this example where the mousedown
listener will just overwrite the previously stored array reference
with a reference to an identical array. ISTM that if "touch" objects
(or just one) present, one is to be used in lieu of the event object.

>
>
>
> > ** el.onmousedown = el.ontouchstart = function(e) {
>
> Oops. *Didn't use "addEvent" wrapper, so no "e" in IE.
>
> if (!e) {
> * e = window.event;
>
> }

So here, if not using a function like attachTouchListeners, would need
to set e to reference a touch object. The touch object is passed to
getPointerPosition*, not the event object. When using that wrapper,
the event object is irrelevant as target and touch object passed to
listeners and returning false prevents the default behavior.

Should have probably left out the touch stuff from this example.
Sorry for any confusion.

On Dec 4, 7:28*pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Dec 4, 7:01*pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
>
>
> > On Dec 4, 4:37*pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Dec 3, 7:38*pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Dec 3, 4:50*pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
> > > > > On 03/12/2011 00:38, David Mark wrote:
>
> > > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> > > > > > wrote:
>
> > > > > >> OneTipmight be the answer to "I have an on-screen element, of known
> > > > > >> size, with an on[dbl]click method; how do I obtain the co-ordinates of a
> > > > > >> [double-]click with respect to a given position in the elementitself?"
>
> > > > > > Tricky. *
>
> > > > > > Your best bet is to see thetipof the day related to coordinates..
> > > > > > *From that you should be able to get the coordinates of the element
> > > > > > relative to the viewport (or "window" as I think I referred to it in
> > > > > > that post). *So you will need the mouse coordinates relative to the
> > > > > > viewport. *Ironically enough, it's trivial to find those in the old IE
> > > > > > versions that lacked pageX/Y properties. *But for everything else, you
> > > > > > have to have to subtract the scroll position as pageX/Y are relative
> > > > > > to the document. *Depending on context, getting the scroll position is
> > > > > > either trivial (one-liner) or fairly complex. *Frustratingly,it's IE
> > > > > > (all versions AFAIK) that needs most of the extra code in this case.
> > > > > > You also have to consider other factors like whether you will need
> > > > > > this to work in quirks mode (hopefully not)
>
> > > > > > It looks like:-
>
> > > > > > // No quirks mode, frames or other windows (just the one running the
> > > > > > script)
>
> > > > > > var getScrollPosition;
>
> > > > > > if ('number' == typeof window.pageXOffset) {
>
> > > > > > * *// Many "standards-based" browsers feature this non-standard
> > > > > > property
> > > > > > * *// No ambiguity about what this window property means
>
> > > > > window.pageYOffset is available as of IE9, FF3+, Safari 4+, Chrome 4+,
> > > > > Opera 10+.
>
> > > > > IE 8 and older browsers in standards-compliant mode (strict mode)would use:
>
> > > > > if (document.documentElement && document.documentElement.scrollTop) {
> > > > > * *return document.documentElement.scrollTop;
>
> > > > > }
>
> > > > > But IE in quirks mode (tested with IE would use:
> > > > > if (document.body) {
> > > > > * *return document.body.scrollTop;
>
> > > > > }
>
> > > > So let's finish this off. *If you need it to work in IE 9 and
> > > > virtually every other browser made since the turn of the century:-
>
> > > > if ('number' == typeof window.pageXOffset) {
> > > > * getScrollPosition = function() {
> > > > * * return [window.pageXOffset, window.pageYOffset];
> > > > * };
>
> > > > * // I suppose jQuery users would prefer gPtrPosRel2Win or some such
> > > > "concise" BS.
>
> > > > * // Works for mouse or touch
>
> > > > * getPointerPositionRelativeToViewport = function(e) {
> > > > * * return [e.pageX - window.pageXOffset, e.pageY -
> > > > window.pageYOffset]
> > > > * };
>
> > > > }
>
> > > > Piece of cake (as this context usually is).
>
> > > > Now, what if you need IE 6-8 to join in the fun?
>
> > > > Put this script inside conditional comments (so the others don't
> > > > download it):-
>
> > > > // Last test is to exclude IE quirks mode and IE 5
>
> > > > if (document.documentElement && 'number' == typeof
> > > > document.documentElement.scrollLeft &&
> > > > document.documentElement.clientWidth) {
> > > > * getScrollPosition = function() {
>
> > > > * * // Note: optimize by saving a reference to documentElement (saves
> > > > two dot operations)
>
> > > > * * return [document.documentElement.scrollLeft,
> > > > document.documentElement.scrollTop];
> > > > * };
>
> > > > * getPointerPositionRelativeToViewport = function(e) {
>
> > > > * * // Yes, we would use these in non-IE browsers too if history of
> > > > implementation
> > > > * * // wasn't atrocious. Perhaps in a few years...
> > > > * * // Regardless, you know for sure these work as advertised in
> > > > legacy IE versions
>
> > > > * * // NOTE: the HTML border "issue" is irrelevant as same offset for
> > > > element positions
>
> > > > * * return [e.clientX, e.clientY]
> > > > * };
>
> > > > }
>
> > > > // Detect API features (never changes, regardless of specific
> > > > renditions used)
> > > > // Self-documenting (really, not like jQuery's claims)
>
> > > > if (getScrollPosition && getPointerPositionRelativeToViewport) {
>
> > > > * var el = getElementById('johnstockton');
>
> > > > * el.onmousedown = ...
> > > > * el.ondblclick = ...
>
> > > > }
>
> > > > Will leave rest as an exercise.
>
> > > A solution. *This is the "good riddance to bad baggage" environment
> > > context.
>
> > > *// This function fades away in IE 8- and compatibility modes
>
> > > *if ('number' == typeof window.pageXOffset) {
>
> > > ** // Works for mouse or touch
>
> > > ** getPointerPositionRelativeToViewport = function(e) {
> > > ** * return [e.pageX - window.pageXOffset, e.pageY -
> > > window.pageYOffset]
> > > ** };
> > > *}
>
> > > /*
> > > ** Need these two API functions
> > > ** See positiontipfor first function
> > > ** Should need the normalized rendition that subtracts
> > > documentElement.clientLeft/Top
> > > ** as comparing element position to pointer position results that
> > > don't have the
> > > ** client-related quirk (i.e. getBoundingClientRect, clientX/Y not
> > > involved)
> > > ** Quirk must be present or absent on both sides of the equation tobe
> > > factored out.
> > > **/
>
> > > if (getElementPositionRelativeToViewport &&
> > > getPointerPositionRelativeToViewport) {
> > > ** var el = getElementById('johnstockton');
> > > * *var pointerPosition;
>
> > > * *// NOTE: should only respond to one event type at a time
>
> > Didn't make this very clear. *I mean you will get dupes with touch
> > input (both touchstart and mousedown)
>
> Kind of trailed off there, didn't I? *See attachTouchListeners in
> Touch add-on. *If it gets touch events, it ignores corresponding mouse
> events. *Doesn't matter so much in this example where the mousedown
> listener will just overwrite the previously stored array reference
> with a reference to an identical array. *ISTM that if "touch" objects
> (or just one) present, one is to be used in lieu of the event object.
>
>
>
> > > ** el.onmousedown = el.ontouchstart = function(e) {
>
> > Oops. *Didn't use "addEvent" wrapper, so no "e" in IE.
>
> > if (!e) {
> > * e = window.event;
>
> > }
>
> So here, if not using a function like attachTouchListeners, would need
> to set e to reference a touch object. *The touch object is passed to
> getPointerPosition*, not the event object. *When using that wrapper,
> the event object is irrelevant as target and touch object passed to
> listeners and returning false prevents the default behavior.
>
> Should have probably left out the touch stuff from this example.
> Sorry for any confusion. *

Should also point out that the window.event substitution is unneeded
unless using legacy IE rendition. If not, "addEvent" wrapper adds
nothing to example. And as performance a non-issue,
attachTouchListeners (or ontouchstart) use unnecessary.

On Sun, 4 Dec 2011 at 18:56:42, in comp.lang.javascript, David Mark
wrote:
>On Dec 4, 7:28*pm, David Mark <dmark.cins...@gmail.com> wrote:
>> On Dec 4, 7:01*pm, David Mark <dmark.cins...@gmail.com> wrote:
>>
>>
>>
>>
>>
>> > On Dec 4, 4:37*pm, David Mark <dmark.cins...@gmail.com> wrote:
>>
>> > > On Dec 3, 7:38*pm, David Mark <dmark.cins...@gmail.com> wrote:
>>
>> > > > On Dec 3, 4:50*pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>>
>> > > > > On 03/12/2011 00:38, David Mark wrote:
>>
>> > > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
>> > > > > > wrote:
>>
>> > > > > >> OneTipmight be the answer to "I have an on-screen element,
<snip>

Please please shorten your quoted text. My scroll wheel is getting red
hot.

John
--
John Harris

On Dec 5, 9:39*am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Sun, 4 Dec 2011 at 18:56:42, in comp.lang.javascript, David Mark
> wrote:
>
>
>
> >On Dec 4, 7:28 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >> On Dec 4, 7:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> >> > On Dec 4, 4:37 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> >> > > On Dec 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> >> > > > On Dec 3, 4:50 pm, "J.R." <groups_j...@yahoo.com.br> wrote:
>
> >> > > > > On 03/12/2011 00:38, David Mark wrote:
>
> >> > > > > > On Nov 11, 4:33 pm, Dr J R Stockton<reply1...@merlyn.demon.co.uk>
> >> > > > > > wrote:
>
> >> > > > > >> OneTipmight be the answer to "I have an on-screen element,
>
> * <snip>
>
> Please please shorten your quoted text. My scroll wheel is getting red
> hot.
>

Yeah, I need to stop responding in mobile browser.

On 03/12/2011 00:08, David Mark wrote:
> On Nov 17, 5:43 pm, Frobernik<nos...@nospam.com> wrote:
>> On 10/11/2011 21:12, Matt McDonald wrote:
>>> On 11-11-10 12:47 PM, Ant wrote:
>>> The biggest blow is marketing. Take a gander at
>>> "HTML 5 Boilerplate"'s website (won't link). It's chock full of
>>> over-the-top marketing speak. The first time I read it, I was
>>> heavily offended by the textual content. I seriously pondered
>>> if it was written by a prepubescent.
>>
>> Well there are people (apart from the punters on here) fighting
>> modernizer,jQueryand other junk (will link)
>
> I see you have almost *one million* posts on here. Punter.
>
> And who is fighting what? Just throw them away.

This should get Platinum Czar Punter post of 2011 I think!

If only it were that simple - most designers and a lot of developers
would rather copy and paste or be hypnotised by Googled bulls**t than
actually get familiar with the browser or even do some work

>> http://nefariousdesigns.co.uk/archiv...browser-the-mo...
> I've seen it. Somebody doesn't like Modrnizer (sp?). I don't like it
> either. Imagine, a monolithic feature detection script that
> pigeonholes browsers according to some predetermined series of
> "standard" tests. Adds a ton of classes too. No thanks!

Moronizers own website is ridiculous. The custom font typefacing has had
to be hidden until the page finishes loading (thats assuming the JS
finishes loading!) *face palm*

Frobernik

On Dec 6, 4:18*pm, Frobernik <nos...@nospam.com> wrote:
> On 03/12/2011 00:08, David Mark wrote:
>
> > On Nov 17, 5:43 pm, Frobernik<nos...@nospam.com> *wrote:
> >> On 10/11/2011 21:12, Matt McDonald wrote:
> >>> On 11-11-10 12:47 PM, Ant wrote:
> >>> The biggest blow is marketing. Take a gander at
> >>> "HTML 5 Boilerplate"'s website (won't link). It's chock full of
> >>> over-the-top marketing speak. The first time I read it, I was
> >>> heavily offended by the textual content. I seriously pondered
> >>> if it was written by a prepubescent.
>
> >> Well there are people (apart from the punters on here) fighting
> >> modernizer,jQueryand other junk (will link)
>
> > I see you have almost *one million* posts on here. *Punter. *
>
> > And who is fighting what? *Just throw them away.
>
> This should get Platinum Czar Punter post of 2011 I think!

That's very colorful, but don't understand a word of it.

>
> If only it were that simple - most designers and a lot of developers
> would rather copy and paste or be hypnotised by Googled bulls**t than
> actually get familiar with the browser or even do some work

Correct. But designers can get away with it as they only need their
proof of concept to work in one browser (the one they use to demo).
Trouble is that inexperienced and overconfident developers think they
can just test the mock-up in a few more browsers and throw it on the
client's server. This poor behavior is positively reinforced by
clients who just don't know any better.

>
> >>http://nefariousdesigns.co.uk/archiv...browser-the-mo....
> > I've seen it. *Somebody doesn't like Modrnizer (sp?). *I don't likeit
> > either. *Imagine, a monolithic feature detection script that
> > pigeonholes browsers according to some predetermined series of
> > "standard" tests. *Adds a ton of classes too. *No thanks!
>
> Moronizers own website is ridiculous. The custom font typefacing has had
> to be hidden until the page finishes loading (thats assuming the JS
> finishes loading!) *face palm*

Yes, that sounds pretty backwards to me. I see lots of sites that
combine that thing with jQuery and jQuery plug-ins. An "HTML5
modernizer" combined with a bunch of old IE6/7 hacks? It's the Sybil
pattern.

As you mentioned, many developers just window shop for these silly
scripts like they were designers. They pile on all everything that
looks cool in their installed browsers and wait for the inevitable
call back when it all falls apart. Their ready excuse is that "nobody
is perfect"; but there is a large gulf between absolute perfection and
gross incompetence.

Just had one of those clods dial in on Twitter. They said that
something was wrong with some of the old My Library examples on the
new Amazon "Silk" browser (Kindle Fire). Their juxtaposition was that
"jQuery UI works".

Of course, jQuery UI is completely inappropriate for mobile devices
(or anything else, really). I wouldn't find it surprising that
whatever jQuery demo they were peering at seemed to "work" in a
browser that the jQuery developers were peering at when they wrote the
thing. The question is whether it should be expected to work in
browsers unknown to the developers (e.g. future versions, new
browsers, new devices, etc.). History and good sense say no as such
projects are always about overreaching to "keep up" with current,
popular browsers, usually at the expense of others (the browsers the
developers claim not to "care" about).

And if jQuery UI works so well on mobile, why is there a jQuery
Mobile? Even more curious, how can anyone even say "jQuery Mobile"
with a straight face? I just saw a blog that mentioned they
"finalized" the thing recently, and it went on to list five or six
browsers (with specific version numbers, of course) that it
"supports". What do you guess it does in every other browser released
this century? Finalized?! For how many weeks? Seems these guys
never learn.

Developers should wake up and realize that relying on bored hobbyists
to ferret out and "fix" bugs, one browser version at a time, is
futile. They should be learning to *avoid* bugs, not trying to find
them. They sure as hell shouldn't be sending out teams of neophytes
to find (and often misinterpret) issues.

Many developers think browsers are far buggier than they are, simply
because they have spent years watching projects like jQuery stumble,
bumble, fumble, etc. This reinforces their perceived need for
jQuery. After all, if the "best minds in the industry" are having
such a time of it... It's a self-perpetuating cycle. jQuery makes it
look really difficult and designers/developers assume such frustration
is par for the course.