Prev: Albenza. Nouvelles de la médecine!
Next: Puissant un antibiotique! Amoxil
From: khinester on 6 Jul 2010 15:23
i have this code: http://paste.lisp.org/+2EKJ instead of having to
type &aqoon on the navigation bar, how do i display the widget if
active is true.

is there a way to improve the code?

thanks
From: Stefan Weiss on 6 Jul 2010 16:19
On 06/07/10 21:23, khinester wrote:
> i have this code: http://paste.lisp.org/+2EKJ instead of having to
> type &aqoon on the navigation bar, how do i display the widget if
> active is true.

replace the line

if (location.href.indexOf("&aqoon") != -1) {

with

if (active) {

> is there a way to improve the code?

* The person who wrote the code should read up on "feature detection"
versus "browser sniffing".

* The last comma (after promotionPrice:"") should be deleted.

Other than that, I can't say much, because I can't read the script at
http://aqoon.local/aqoonWidgetMin.js


--
stefan
From: khinester on 6 Jul 2010 17:00
On Jul 6, 10:19 pm, Stefan Weiss <krewech...(a)gmail.com> wrote:
> On 06/07/10 21:23, khinester wrote:
>
> > i have this code:http://paste.lisp.org/+2EKJinstead of having to
> > type &aqoon on the navigation bar, how do i display the widget if
> > active is true.
>
> replace the line
>
>   if (location.href.indexOf("&aqoon") != -1) {
>
> with
>
>   if (active) {
>
> > is there a way to improve the code?
>
> * The person who wrote the code should read up on "feature detection"
>   versus "browser sniffing".
>
> * The last comma (after promotionPrice:"") should be deleted.
>
> Other than that, I can't say much, because I can't read the script athttp://aqoon.local/aqoonWidgetMin.js
>
> --
> stefan

thank you for the reply, i inherited the code, so i will need to read
up on the feature detection versus browser sniffing.
From: Richard Cornford on 7 Jul 2010 08:54
On Jul 6, 10:38 pm, Garrett Smith wrote:
<snip>
> <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>
>
> ... . The latter, Dav Glass' blog, is a classic example of bad
> feature tests and used as a straw man for justifying browser
> detection.
<snip>

That is exactly how it reads to me. This section, for example:-

| In my opinion, isn’t this the same thing as browser sniffing?
| Aren’t you checking something that you know is unique about a
| particular browser and leveraging it? Doesn’t that also qualify
| as browser sniffing? If you are looking for some flaw in a
| browser to determine a course of action, wouldn’t it be easier
| to just read the User Agent and work from there? You can
| process that info one time and use it everywhere.

- attempts to assert equivalence between browser sniffing and feature
detection; that in both cases you are "checking something that you
know is unique about a particular browser and leveraging it". Which
disregard one of the main issues with UA string based browser
sniffing; that there is no technical reason for expecting the UA
string to be anything in particular (the pertinent specification is
RFC 2616, section 14.43), let alone unique to a particular browser/
version. And it is a statement made in relation to code addressing an
IE "bug" (actually a misconception), when if any browser's UA string
has been seen to be fully spoofed as a matter of course it is that of
IE.

The feature/bug/characteristic tested may or may not be unique to the
browser, but it will always be unique to itself. Hence the feature
detection principle that the test applied should always have as near
to a one-to-one relationship with whatever the test is supposed to
determine as possible.

UA strings are not supposed to be anything in particular, and have
been observed to be indistinguishable between browsers. Predicating a
script on the assumption that they will be unique to a particular
browser/version goes against reason and empirical evidence; it is the
act of a madman.

Richard.
From: David Mark on 11 Jul 2010 02:51
On Jul 10, 11:31 pm, David Mark <dmark.cins...(a)gmail.com> wrote:
> On Jul 7, 8:54 am, Richard Cornford <Rich...(a)litotes.demon.co.uk>
> wrote:
>
>
>
>
>
> > On Jul 6, 10:38 pm, Garrett Smith wrote:
> > <snip>> <http://blog.davglass.com/2009/01/browser-sniffing-vs-object-detection/>
>
> > > ... . The latter, Dav Glass' blog, is a classic example of bad
> > > feature tests and used as a straw man for justifying browser
> > > detection.
>
> > <snip>
>
> > That is exactly how it reads to me. This section, for example:-
>
> > | In my opinion, isn’t this the same thing as browser sniffing?
> > | Aren’t you checking something that you know is unique about a
> > | particular browser and leveraging it? Doesn’t that also qualify
> > | as browser sniffing? If you are looking for some flaw in a
> > | browser to determine a course of action, wouldn’t it be easier
> > | to just read the User Agent and work from there? You can
> > | process that info one time and use it everywhere.
>
> Yes, that is thoroughly laughable (like the example by Zakas).  As is
> his comment about IE being "off by 2".

I don't see where anyone explained this, but it is a very common
misconception. MS invented getBoundingClientRect, so their definition
of it is what matters (i.e. the only way they could be off is if they
failed to meet their own defined expectations).

http://msdn.microsoft.com/en-us/library/ms536433(VS.85).aspx

"This method retrieves an object that exposes the left, top, right,
and bottom coordinates of the union of rectangles relative to the
client's upper-left corner. In Microsoft Internet Explorer 5, the
window's upper-left is at 2,2 (pixels) with respect to the true
client."

Dammit. The MSDN documentation is horribly vague (not to mention out
of date). The "client" they refer to is either the HTML or BODY
element (the latter in quirks mode and IE5). The "upper-left corner"
includes the element's border, the width of which is controlled by the
OS (2 by default). The OS controls it as the element is the viewport
in MSHTML. And the method and behavior are not exclusive to IE5 (it's
the same for all versions since).

So, as is usual, the browser sniff turns out to be a "solution" posed
without understanding what the problem was in the first place. And
not unexpectedly, it is a solution that only "works" in the default
configurations of a handful of browsers (in this case IE and many
variations).

And as noted, due to the faulty UA inference, the code will fail if
the "problem" is every fixed by MS, as well as for virtually any non-
MSHTML-based browser that appears to be IE, but does not exhibit the
(un)expected behavior.

The punch-line is that the million-dollar question has a two-cent
answer. From My Library:-

if (ce.clientTop) { y -= ce.clientTop; }
if (ce.clientLeft) { x -= ce.clientLeft; }

Why subtract the border? Presumably because the coordinates will be
used to position an element. And as the dated MS documentation
indicates, this answer has been valid since 1999 (and unlikely to ever
be invalid).

If you can manage to avoid quirks mode and don't mind some degradation
in IE5, then add this:-

var ce = document.documentElement;

But if writing a GP script, add one more line:-

if (!ce.clientWidth) { ce = document.body; }

Not very complicated. When the HTML element is not rendered (as in
quirks mode and IE5), it has no client portion and therefore no client
width. Even though this is based on (over a decade of) observation of
MSHTML-based agents, as with most good inferences, it makes logical
sense. And it's sort of documemted by MS as well. But like the
getBoundingClientRect 2-pixel "quandary" this one is often addressed
with voodoo based on faulty anecdotes found on dubious blogs (or sites
like StackOverflow). I recently saw advice that only IE6 uses the
BODY, so sniffing for that version might help. This was dated last
week. :(

Here is the documentation for clientTop:-

http://msdn.microsoft.com/en-us/library/ms533565(VS.85).aspx

"The difference between the offsetTop and the clientTop properties is
the border area of the object."

Like hell it is, MS! :( The difference between the offsetTop and
clientTop properties is the offsetTop minus the top border (for what
that's worth).

Inaccurate documentation aside, there are countless examples on the
Web demonstrating how to use getBoundingClientRect (some dating back
to the nineties).

But what about the other browsers that now support the method? That's
their problem. The browser developers dealt with it when they copied
it. IIRC, whether or not the HTML element is the viewport or not (the
BODY never is outside of MSHTML), they set clientLeft/Top to zero and
return coordinates that exclude the border. So, everything evens out,
even if the abstraction makes less than perfect sense outside of the
MSHTML model (see also clientHeight/Width of HTML and BODY). There
may well be worse copies out there that actually break code like the
above, but I haven't encountered them (and have been using similar
logic since the turn of the century).
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Albenza. Nouvelles de la médecine!
Next: Puissant un antibiotique! Amoxil