Prev: DOM ready, window.onload, etc.
Next: Chrome, canvas, PNG, Save Image As
From: Garrett Smith on 29 Dec 2009 01:35
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.

A beginner might find it *odd* that a function could be referenced
before it appeared in source order. A beginner might not know about
entering an execution context, what a FunctionDeclaration was, what a
FunctionExpression was, but would just notice that "it works".

A beginner would not know a lot of things, including things about
unicode support, ===, typeof, Host object.

>>> Also, you've got an "unreachable" semi-colon and a couple of implied
>>> globals (the alert one is troubling).
>> What is troubling about using alert?
>
> 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?

>> JSLint parses window.alert(); or alert(); as an Error. See I just don't
>> get that.
>
> He wants it to be fully qualified. There are cases where that message
> is helpful (e.g. generalizing functions for use with frames).
>

What is it that you think he wants to be fully qualified?

>> Now I can't figure out what makes that an error, yet:-
>>
>> document.parentWindow.alert(1);
>>
>> - is perfectly fine in JSLint. No error whatsoever. I don't get it.
>
> That's an implied global for sure. Or perhaps you mean with "assume a
> browser"? Yes, I agree that assuming a browser should allow for the
> user of window (it used to).

It is odd because document is a property of the window.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 29 Dec 2009 01:57
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.

>
> A beginner might find it *odd* that a function could be referenced
> before it appeared in source order.

Especially if they are coming to JS from another language.

> A beginner might not know about
> entering an execution context, what a FunctionDeclaration was, what a
> FunctionExpression was, but would just notice that "it works".
>
> A beginner would not know a lot of things, including things about
> unicode support, ===, typeof, Host object.

So what?

>
> >>> Also, you've got an "unreachable" semi-colon and a couple of implied
> >>> globals (the alert one is troubling).
> >> What is troubling about using alert?
>
> > 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.

>
> >> JSLint parses window.alert(); or alert(); as an Error. See I just don't
> >> get that.
>
> > He wants it to be fully qualified.  There are cases where that message
> > is helpful (e.g. generalizing functions for use with frames).
>
> What is it that you think he wants to be fully qualified?

The window reference of course. He wants to see it referenced as a
property of an object (e.g. the Global object). As for frames,
consider this:-

e = e || window.event; // No good for elements in other frames

So that "error" in JSLint helps to spot these situations as well.

>
> >> Now I can't figure out what makes that an error, yet:-
>
> >> document.parentWindow.alert(1);
>
> >> - is perfectly fine in JSLint. No error whatsoever. I don't get it.
>
> > That's an implied global for sure.  Or perhaps you mean with "assume a
> > browser"?  Yes, I agree that assuming a browser should allow for the
> > user of window (it used to).
>
> It is odd because document is a property of the window.

In a browser (assuming a browser), the Global object has a - document
- property as well. At least, that is the underlying assumption here.
From: GTalbot on 29 Dec 2009 03:03
On 28 déc, 21:41, David Mark <dmark.cins...(a)gmail.com> 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:

[snipped]


> Orphaned (removed from the document) elements can become ActiveX
> objects behind the scenes.  IIRC, orphaning by innerHTML replacement
> is a sure bet.
>
> if (typeof element.offsetParent == 'unknown') {
>     (element.offsetParent); // Boom
>
> }
>
> So you wouldn't normally pass such an element to such a function
> (offset position makes no sense for orphans).  The try-catch hides
> such mistakes.


Ok. I understand now.


> > Ultimately, it's all up to them to decide. But I don't
> > hide (or don't try to hide) to them that IE6 is very buggy,
> > unreliable, not-trustworthy, etc.
>
> That's ridiculous.  If your page is buggy and/or unreliable,


No. The warning/advice/browser support notice they should get is that
the webpage complies with all known mature and stable web standards
(HTML 4, CSS 2.1, WCAG) and that the browser version they use may not
be able to comply accordingly so they may see a strange offset here, a
gap there, an unexpected overlapping over here, etc... which is very
typical of IE6 (hasLayout, broken float+clear model, broken inline
level model, adjoining margin collapsing, etc). If the page has been
tested without CSS enabled, without javascript support enabled,
without image download support and works reasonably correctly or
accordingly, then the web author can calmly and confidently claim that
IE6 *_is_* the problem here and not his work.

I have seen and read dozens, maybe 200 sites which have explained why
IE6 is unreliable, unsafe, not-trustworthy, very buggy, non-compliant,
etc.. and I think often they made a good case. The best ones are the
ones (with a good soft touch) which address the intelligence of users
and are not at all agressive. A scare campain on security is generally
not very convincing (e.g. the swine flu vaccine campain in my country
started first as a scare campain and it created a reverse behavior
than expected when it became time to get vaccinated). An agressive
campain is less fruitful: pure force never succeeds on the internet.

> > They certainly were warned in the
> > past that their applications shouldn't be entirely dependent on
> > Microsoft products and Microsoft Windows platform.
>
> > The top 20 IT mistakes to avoid, November 19, 2004
> > 11. Developing Web apps for IE onlyhttp://www.infoworld.com/d/developer-world/top-20-it-mistakes-avoid-3...
>
> That's another topic altogether.  Some corporate users are simply
> stuck with IE6/7 and will be for years.

If they are stuck with IE6/7 for years, it is because someone
somewhere made a terrible decision at some point. So, they pay now .


> > > Some don't know what a browser _is_.  ;)
>
> > Those (like seniors) are the most difficult portion of the market.
>
> Lots of PC-savvy corporate users are clueless about browsers and/or
> disallowed from making decisions about which browsers to use.


I understand. I think a campain can still be effective when targeting
straight at normal non-corporate users.

> > There's very little you can do ... unless you're a friend of them and
> > you visit them at home.

[snipped]


> I don't think you have time
> to visit every "senior" at home either.

Occasionally, I can give my advice to older friends and seniors that I
know of and help them.


[snipped]

> > If your message is not agressive or on purpose bashing the browser
> > itself, if you invite diplomatically to upgrade or switch and if you
> > address their intelligence, then those who can may do so. Those who
> > can not .. whatever the reasons .. will not.
>
> Nobody wants to hear about it from your site, unless your site is
> about browsers.

A part of my web authoring website is about browsers. One thing I
noticed is how often I get visitors linking to my IE bugs webpages and/
or coming from websites campaining to eradicate IE6 or IE7 or just IE.

regards, Gérard
From: Garrett Smith on 29 Dec 2009 03:19
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.

// Scope.
(function(){
APE.mixin( APE.dom,
{
method1 : method1,
method2 : method2
});
function method1(){/*...*.}
function method2(){/*...*.}
})();

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.

The only trouble is when you have some expressions that need to be part
of the export, and those expressions need variables defined. Then it
gets a little messsy.

// Scope.
(function(){

var x = 10,
y = x + Math.random();

APE.mixin( APE.dom,
{
method1 : method1,
method2 : method2,
y : y
});
function method1(){/*...*/}
function method2(){/*...*/}
})();

To me that is uglier because the variable statement is up at the top. I
prefer to see more like:-

// Scope.
(function(){

APE.mixin( APE.dom,
{
method1 : method1,
method2 : method2,
y : getY()
});
function method1(){/*...*/}
function method2(){/*...*/}
function getY(){
return 10 + Math.random();
}
})();


>> A beginner might find it *odd* that a function could be referenced
>> before it appeared in source order.
>
> Especially if they are coming to JS from another language.
>
>> A beginner might not know about
>> entering an execution context, what a FunctionDeclaration was, what a
>> FunctionExpression was, but would just notice that "it works".
>>
>> A beginner would not know a lot of things, including things about
>> unicode support, ===, typeof, Host object.
>
> So what?
>

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.

A beginner would probably know that that FunctionDeclaration is added to
the variable object upon entering the execution context. He would
probably figure that "you can do that" and "it works", without
understanding the mechanics of it.

If he decided to change FunctionDeclaration around and instead use
FunctionExpression:-

document.addEventListener("click", documentClicked, false);
var documentClicked = function(ev) {};

Whoops, all of a sudden "it doesn't work." Bummer. I guess "you can't do
that."

From a beginner's point of view, it wouldn't be so confusing. It might
seem odd, but once he saw it running, he would know that it works.

>>>>> Also, you've got an "unreachable" semi-colon and a couple of implied
>>>>> globals (the alert one is troubling).
>>>> What is troubling about using alert?
>>> 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.

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`.

>>>> JSLint parses window.alert(); or alert(); as an Error. See I just don't
>>>> get that.
>>> He wants it to be fully qualified. There are cases where that message
>>> is helpful (e.g. generalizing functions for use with frames).
>> What is it that you think he wants to be fully qualified?
>
> The window reference of course. He wants to see it referenced as a
> property of an object (e.g. the Global object). As for frames,
> consider this:-
>
> 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 can't say I've tried passing window.event to
another frame.

>>>> Now I can't figure out what makes that an error, yet:-
>>>> document.parentWindow.alert(1);
>>>> - is perfectly fine in JSLint. No error whatsoever. I don't get it.
>>> That's an implied global for sure. Or perhaps you mean with "assume a
>>> browser"? Yes, I agree that assuming a browser should allow for the
>>> user of window (it used to).
>> It is odd because document is a property of the window.
>
> In a browser (assuming a browser), the Global object has a - document
> - property as well. At least, that is the underlying assumption here.

window is a property of global object and acts as the global object
itself. If using unqualified window is an Error because won't work
across frames, then unqualified document should be, too.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 29 Dec 2009 06:23
Garrett Smith wrote:

> David Mark wrote:
>> Garrett Smith wrote:
>>> David Mark wrote:
>>>> Garrett Smith wrote:
>>>>> document.addEventListener("click", documentClicked, false);
>>>>> 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.
>
> // Scope.
> (function(){
> APE.mixin( APE.dom,
> {
> method1 : method1,
> method2 : method2
> });
> function method1(){/*...*.}
> function method2(){/*...*.}
> })();
>
> 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.

To be fair, that is what a lint-like tool is supposed to flag:

,-<http://en.wikipedia.org/wiki/Lint_%28software%29>
|
| In computer programming, lint was the name originally given to a
| particular program that flagged some suspicious and non-portable
| constructs (likely to be bugs) in C language source code. The term is now
| applied generically to tools that flag suspicious usage in software
| written in any computer language. The term lint-like behavior is
| sometimes applied to the process of flagging suspicious language usage.
| lint-like tools generally perform static analysis of source code.
| [...]
| Suspicious usage includes: variables being used before being set,
| conditions that are constant, and calculations whose result is likely
| to be outside the range of values representable in the type used.

However, IMHO, such a tool, when written for analyzing ECMAScript
implementations, SHOULD be aware that variable instantiation comes before
execution, thus function declarations need to be considered to be variable
initializations even if they come last in an execution context. I do not
think that would contradict the purpose of static code analysis.

So, at most, there should be a warning here, and it should be possible to
disable that warning.

> The only trouble is when you have some expressions that need to be part
> of the export, and those expressions need variables defined. Then it
> gets a little messsy.
>
> // Scope.
> (function(){
>
> var x = 10,
> y = x + Math.random();
>
> APE.mixin( APE.dom,
> {
> method1 : method1,
> method2 : method2,
> y : y
> });
> function method1(){/*...*/}
> function method2(){/*...*/}
> })();

Why, you could use the more complex expression in the initializer:

// Scope.
(function(){
var x = 10;

APE.mixin( APE.dom,
{
method1 : method1,
method2 : method2,
y : x + Math.random()
});

function method1(){/*...*/}
function method2(){/*...*/}
})();

> To me that is uglier because the variable statement is up at the top. I
> prefer to see more like:-
>
> // Scope.
> (function(){
>
> APE.mixin( APE.dom,
> {
> method1 : method1,
> method2 : method2,
> y : getY()
> });
> function method1(){/*...*/}
> function method2(){/*...*/}
> function getY(){
> return 10 + Math.random();
> }
> })();

You can also lose two declarations and write

// Scope.
(function(){
APE.mixin( APE.dom,
{
method1 : method1,
method2 : method2,
y : (function(x) { return x + Math.random(); })(10)
});

function method1(){/*...*/}
function method2(){/*...*/}
})();

instead.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: DOM ready, window.onload, etc.
Next: Chrome, canvas, PNG, Save Image As