Prev: FAQ Topic - How do I trim whitespace? (2010-04-07)
Next: Problems with dynamic link creation
From: Richard Cornford on 12 Apr 2010 07:38
On Apr 12, 8:10 am, Garrett Smith wrote:
> Garrett Smith wrote:
>> Richard Cornford wrote:
>>> On Apr 9, 5:38 am, Garrett Smith wrote:
>>> <snip>
>>>>>http://jibbering.com/faq/notes/square-brackets/

<URL: http://jibbering.com/faq/faq_notes/square_brackets.html >

> [...]
>
> Regarding changing the FAQ note to use a DOM-compliant example (as
> expressed below "proposed change"),

Which are incomplete as they do not include the then necessary changes
to the examples of equivalent bracket nation property accessors.

> how strongly do you feel about
> keeping this.

I have no idea why you are wasting anyone's time (including your own)
on this pointless and trivial quibble. I will never approve such a
worthless change.

> Does else have an opinion on the proposed change?
<snip>

Richard.
From: Asen Bozhilov on 12 Apr 2010 11:33
Richard Cornford wrote:

> <URL:http://jibbering.com/faq/faq_notes/square_brackets.html>

Are you planning to update/rewrite with other name that article? Will
be good if you explain the `PropertyName` in object literals. For
example:

var obj = {if : true};

By ECMA-262-3 that should be SyntaxError, because property name is
bound by rules for Identifier. Identifier rules do not allow to be
used Identifier with same sequence of symbols as ReservedWord.

And the follow code is syntactical correct:

var obj = {'if' : true};

Because object literals allow to be used string literals as property
name.

Regards.


From: Garrett Smith on 12 Apr 2010 15:26
Richard Cornford wrote:
> On Apr 12, 8:10 am, Garrett Smith wrote:
>> Garrett Smith wrote:
>>> Richard Cornford wrote:
>>>> On Apr 9, 5:38 am, Garrett Smith wrote:
>>>> <snip>
>>>>>> http://jibbering.com/faq/notes/square-brackets/
>
> <URL: http://jibbering.com/faq/faq_notes/square_brackets.html >
>
>> [...]
>>
>> Regarding changing the FAQ note to use a DOM-compliant example (as
>> expressed below "proposed change"),
>
> Which are incomplete as they do not include the then necessary changes
> to the examples of equivalent bracket nation property accessors.
>
>> how strongly do you feel about
>> keeping this.
>
> I have no idea why you are wasting anyone's time (including your own)
> on this pointless and trivial quibble. I will never approve such a
> worthless change.
>

I do not approve of nonstandard examples in the FAQ. Particularly when
they are presented as solutions to problems and especially when the
consequences to using the nonstandard approach are not explained.

It is harmful advice.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 12 Apr 2010 15:42
Richard Cornford wrote:
> On Apr 9, 7:00 pm, Garrett Smith wrote:
>> Richard Cornford wrote:
>>> On Apr 9, 5:38 am, Garrett Smith wrote:
>>> <snip>
>>>>> http://jibbering.com/faq/notes/square-brackets/
>> [...]
>>
>>>> That is nonstandard
>>> Except in the sense that it has never been possible to show an
>>> HTML DOM environment where they don't work. But being standard
>>> or not is not relevant to which (recognizable) forms of bracket
>>> notation accessors would be equivalent (to showing the
>>> relationship between the strings in the brackets and the
>>> Identifiers following the dots).
>> It is not part of any official standard.
>
> Neither is having a - document - property of the global object that
> refers to an object implementing the Document interface. How much FAQ
> code is going to be rendered non-function when you get around to
> removing all instances of that?
>

We are not doing that.

> <snip>
>> I got that understanding the concept is the point of the article
>> and the example. My gripe is that the example uses nonstandard
>> approach.
>
> It doesn't 'use' anything, it just shows a dot-notation property
> accessor that is likely to be easily understood by people reading the
> article, especially in relation to the bracket notation alternative
> formulations.
>
>> That approach has a nasty side effect and can be avoided by
>> simply using the standard approach.
>
> The best you could say is that it _can_ have nasty side effects (How
> often do people actually change the name or ID of a form control?),
> but since actually using that formulation is not encouraged by the
> article (and is effectively discouraged) that is not relevant.
>

Changing the name or id of the form control is only one cause of the
problem.

The problem with leaked control occurs when the node is removed, as
discussed I don't know many times, and mentioned in the named form
controls article.

| The consequence of using the shortcut `myForm.controlName` is a leaked
| form control.
|
| If the element named `controlName` gets a new name or id, or is
| removed from the document, `myForm.controlName` still points to that
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| element.
|
| http://jibbering.com/faq/names/form_dom_removal.html

The link to the example provided shows how accessing a control as a
named property directly off the form results in a leaked control.

A beginner should not be shown examples of nonstandard DOM, even if the
DOM is not the point of the article.

It is too much to expect the beginner to read that article, plus the
additional article "Referencing Forms and Form Controls".

The amount of typing required to use the standard approach is not much more.

>> The standard approach can be used as example without any harmful
>> consequence.
>
> The example (which was original chosen, over possible alternatives
> (including all 'standard formulations), for its combination of
> relative complexity and recognisably for the expected audience) is
> fine as it is.
>

It has the consequence of showing a beginner a nonstandard approach, and
for what reason? Because it is simpler? Less typing?

How about using those reasons for writing code?

>>>> and can result in a leaked form control. HTML 5
>>>> terms this as some sort of feature.
>>>> How about:
>>>> |var stringOfValue = document.forms.formName.elements.inpName.value;
>>> The next line of text reads; "This dot notation has three dots, so
>>> there are three points at which the square bracket notation could
>>> be used in place of the dot notation (these are all equivalent)".
>>> You want to have five dots, and so must add the additional
>>> equivalents to the following text, making it considerably more
>>> complex without adding anything to the explanation that is being
>>> provided (indeed, probably making it less clear).
>> The example could be made to fit that text.
> <snip>
>
> Or it could be left alone.
>

Yes, but providing a nonstandard example that has inconsistent negative
side effects and not explaining those consequences is potentially harmful.

>>>> Although standard form control access is not the point of the
>>>> article,
>>> And examples of actual form access (rather than examples only of
>>> dot/bracket-notation property accessors) use the standard form
>>> access methods.
>>>> the examples should not propose the reader to use non-standard
>>>> access.
>>> It doesn't. Indeed pointing out that the simple 'shortcut' form
>>> exists and then not using it in the form access examples could
>>> be seen as discouraging its use (as the observant reader may
>>> recognize that not using the 'shortcut' accessors to work with
>>> forms would have been a deliberate decision).
>> That assumes that the reader reads both articles.
>
> Which "both articles"?

You mentioned the other "perfectly good article," as you put it, so I
assumed you meant the article on form control access. That makes two
articles:

1) square brackets
2) form access

[...]

>>>> Considering this is linked from an entry on how to access a
>>>> named form control, it has the effect of advocating
>>>> non-standard code.
>>> There is a perfectly good article in the notes talking about
>>> form access that states the relative status of the types of
>>> form access methods.
>> http://jibbering.com/faq/notes/form-access/
> That is linked from #formControlAccess entry.
>
> No:-
>
> <URL: http://jibbering.com/faq/faq_notes/form_access.html >
>

Try ctrl + f5 on the FAQ. You should see the updated link URL.
http://jibbering.com/faq/#formControlAccess

> The FAQ question on strangely named controls links to the last section
> of the bracket-nation property accessor article (which is long after
> the example you have decided to quibble about), so there is no reason
> to expect people interested in learning how to access form controls to
> be reading that article at all. They should be being directed to the
> form access article.
>

So you think the entry should link to /notes/form-access/ and not
notes/square-brakets/ ?

That sounds fine.

[...]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 12 Apr 2010 15:47
Asen Bozhilov wrote:
> Richard Cornford wrote:
>
>> <URL:http://jibbering.com/faq/faq_notes/square_brackets.html>
>
> Are you planning to update/rewrite with other name that article?

I don't exactly get your meaning. I'm not rewriting articles, but I am
editing them, including:
* Use HTML Strict
* Link all articles under /faq/notes/
* Navigation
* Edits for broken links, spelling, etc.

I will probably update the meta tags. I thought to put at the top of the
documents under faq_notes that a more recent of the document occurs at
/faq/notes/[article_path]

Will
> be good if you explain the `PropertyName` in object literals. For
> example:
>
> var obj = {if : true};
>
> By ECMA-262-3 that should be SyntaxError, because property name is
> bound by rules for Identifier. Identifier rules do not allow to be
> used Identifier with same sequence of symbols as ReservedWord.
>
> And the follow code is syntactical correct:
>
> var obj = {'if' : true};
>
> Because object literals allow to be used string literals as property
> name.
>

That's useful, but not really directly related to "Square Bracket
Notation". It seems out of place for that article.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: FAQ Topic - How do I trim whitespace? (2010-04-07)
Next: Problems with dynamic link creation