[ANN] Updated Javascript Best Practices document

[Matt Kruse]

Uhm... (second one already ;-) These are two completely different
situations here:

Re-read the post:

I'm trying to write my page so that there is a div with a message like
this that is set to visible by default in the stylesheet, but hidden early
on in the app's initialisation process. This way, if any of the tests fail
(or the browser doesn't have JS at all), then the user will see this
message.

The alert should be hidden if any tests fail or if the browser doesn't have
js at all.
A <noscript> block will handle the second case, but not the first.
Very simple to understand.

 

[Randy Webb]

VK said the following on 6/2/2006 1:58 PM:

Uhm... Any particular reason to not use <noscript> instead?

Because it is unsuited to the task. And pretty much useless on the Web
anyway.

 

[VK]

Re-read the post:

The alert should be hidden if any tests fail or if the browser doesn't have
js at all.
A <noscript> block will handle the second case, but not the first.
Very simple to understand.

Very simple to understand the used technics. More difficult to
understand its application to the practical programming and - attention
- to the "best practice".

If script is disabled and any scriptable fall-backs are useless, it
could be a message like
<noscript>
<p style="border:meduim solid red">Scripting is not possible. Some data
or features on this page may be not available or not not rendered
properly. Text-only digest can be viewed <a href="foo">here</a>.</p>
</noscript>

If script is enabled, then your job is not to show some signs to your
visitor: you job is to prevent UA of showing such signs as error
messages, exclamations in status bar etc. Proper feature detection and
fall back is not an advertisement campain so any banners on the page
are out of place.

As I already said, these are two absolutely different situations one
should never mix together.

Also I'm really curious what text message could equally cover the
situation both with script disabled and document.getElementById not
supported ??
I may think only of something the most generic and rather useless like
"Attention! Something is not kosher with this page!".

 

[Randy Webb]

VK said the following on 6/2/2006 4:27 PM:

Very simple to understand the used technics. More difficult to
understand its application to the practical programming and - attention
- to the "best practice".

Only to you VK, only to you.

If script is disabled and any scriptable fall-backs are useless, it
could be a message like
<noscript>
<p style="border:meduim solid red">Scripting is not possible. Some data
or features on this page may be not available or not not rendered
properly. Text-only digest can be viewed <a href="foo">here</a>.</p>
</noscript>

Have you not been reading, paying attention, and thinking about the many
many conversations/threads in c.l.j with regards to the <noscript> element?

<div id="plainMessage">
Scripting is not possible. Some data or features on this page may be not
available or not not rendered properly.
</div>

window.onload= replaceMessage;

function replaceMessage(){
document.getElementById('plainMessage').innerHTML = '';
}

That is it at it's simplest. You make your pages 100% working and then
you complement them with scripting. Then, if script is disabled or there
is an error in your script, or the UA doesn't support what you are
trying to do, then the user gets a generic message.

If script is enabled, then your job is not to show some signs to your
visitor: you job is to prevent UA of showing such signs as error
messages, exclamations in status bar etc. Proper feature detection and
fall back is not an advertisement campain so any banners on the page
are out of place.

Who said anything about error messages or advertisement campaigns? Is
that another figment of your imagination?

As I already said, these are two absolutely different situations one
should never mix together.

I doubt I am the first to say this to you, and I don't doubt I won't be
the last. But, that statement above is pure 100% unadulterated garbage.

Also I'm really curious what text message could equally cover the
situation both with script disabled and document.getElementById not
supported ??

You gave it yourself and then want a generic message? Do you not even
read/comprehend what you write yourself?

<quote>
Scripting is not possible. Some data or features on this page may be not
available or not not rendered properly.
</quote>

Note: The link is useless and unneeded if the page degrades properly.

But, it doesn't even have to be that if your page works 100% properly
without script. Then, without script guess what? The user still has a
use-able page. With script, they get an enhanced page. And guess what

I may think only of something the most generic and rather useless like
"Attention! Something is not kosher with this page!".

Explaining common sense to you gets old after about 13 seconds.

 

[Randy Webb]

Andy Baxter said the following on 6/2/2006 5:01 PM:

VK said:


What's wrong with "This page has been tested in the following browsers
..... , but does not appear to work properly in the one you are using. If
you wish to see this page properly, please upgrade to one of them."

That doesn't quite cover the script disabled scenario. Telling a user of
an updated browser - with scripting disabled - to upgrade to a newer
version of the browser they are using isn't conveying a good image of
intelligence

The point is you are giving people the information that:
- The page has detected that there is a problem (which is better than them
just going to the page and thinking 'why isn't this working?')

To an extent.

- It will work in the browsers listed, which they may be able to do
something about.

Or choose not to

In the case of the page I'm working on at the moment, it simply won't work
without javascript, because html/css isn't capable of doing what I want,
so I want there to be some kind of notification to users to let them know
why they're getting a page that does nothing of interest.

See my other reply for that one.

You put a scripting required message on the page, then you feature
detect and if the browser is capable, you remove that message with
scripting. It covers both the scripting disabled and the script not
being able to do what you want to do all in one action.

 

[Randy Webb]

Tony said the following on 6/2/2006 5:58 PM:

Just curious - how many people are there likely to be out there using IE
4.0?

I know of at least 2 that use IE4.0 on a daily basis. One of them posts
to this group regularly.

But a better question would be why not have a script that gracefully
fails if it only takes one line of code to make it fail gracefully?

 

[VK]

What's wrong with "This page has been tested in the following browsers
.... , but does not appear to work properly in the one you are using. If
you wish to see this page properly, please upgrade to one of them."

Because this message doesn't cover say Firefox 1.5.0.4 (the latest one)
if someone disabled JavaScript out of curiosity. It also doesn't cover
IE 6.0 with security settings twisted by a wannabe admin. These are
definitely browsers you tested on, and there is nowhere to upgrade. So
such message is both useless and misleading.

Please get me right: I'm /not/ one of these bored mind thinking that i)
the working range of the solution has to cover all existing browsers
back to 1998 and further, ii) be ready for a blind and deaf user using
a tong manipulator for navigation, iii) respond for each Lynx esthete
with ads-free text-only content plus images converted into ASCII
graphics, iv) nor many crazy things like that.

The fingers are yours and you are free to show them at any moment then
you feel like (unless explicitly prohibited by law).

Still some basic street politesse requires at least to inform your
visitor of the reason (s)he sees a finger instead of the content. And
the reason has to be spelled correctly.

In this aspect I don't see a way to combine both "no script" and "no
vital feature" situations. There must be two fall-back ways completing
each other.

Note 1: Users with scripting disabled (if they really exist) will not
get any extra care out of me besides the <noscript>'ed "See you later,
alligator". But at least this I will give them.

Note 2: There is some bitter taste left from <noscript> from the Web's
childhood, and it seems inherited by some developers from the new wave:
as they "know" that "there is something about <noscript>", but they
have no idea what exactly.
The draw back was caused by placing <noscript> block right after the
<body> tag: the most obvious place for an attention grabber in case if.
As search engines were in their childhood too, they took sample text
for the index entry from the first paragraph on the page, disregarding
on whether it's <noscript> or <body> block on frameset page. As the
result many pages on say AltaVista were "indexed" like:
Page Title
http://...
Sorry, your browser doesn't support JavaScript...
or
Page Title
http://...
Sorry, your browser doesn't support frames...
(I have to explain that in 1996-99 a failure to index properly on say
AltaVista was a big deal).
I strongly believe that modern search engines including Google are much
smarter on that. Still rather than check the smartness of different
search engines I would suggest to place <noscript> block (if used) not
right after the body, but after the first paragraph on your page. One
can always adjust the position by using styles (though it is maybe
better do not bother with it for KISS considerations).


What's wrong with:

<html>
<head>
<title>Demo</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<style type="text/css">
body {
color: #000000;
background-color: #FFFFFF;
}
noscript p {
font-size: 100%;
font-weight: bold;
background-color: #FFFF33;
text-align: center;
width: 75%;
margin: 1em 1em;
padding: 1em 1em;
border: medium solid red;
}
</style>
<script type="text/Jscript">
//alert('That IE... Some extras just being done for it.');
</script>
<script type="text/javascript">
function init() {
if ('undefined' == typeof document.ImportantBogusOne) {
// we are still trying to use an equivalent but
if ('undefined' == typeof document.ImportantBogusTwo) {
// then the patient is hopeless
alert('Your browser is hopeless! Nothing I can do.');
}
}
}
//window.onload = init;
</script>
</head>

<body>
<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit,
sed do eiusmod tempor incididunt ut labore et dolore magna
aliqua.</p>

<!-- A bit out of the beginning if some search engine
happens to be so stupid: to grab this text: -->
<noscript>
<p>You have disabled scripting for this site.<br>
Some or all features on this page may be not available.
Some data may be missing or not shown properly.</p>
</noscript>

<p>Ut enim ad minim veniam, quis nostrud exercitation ullamco
laboris nisi ut aliquip ex ea commodo consequat.</p>

</body>
</html>

 

[Dr John Stockton]

JRS: In article <[email protected]
online.co.uk>, dated Fri, 2 Jun 2006 18:49:27 remote, seen in
Andy Baxter <[email protected]
online.co.uk> posted :

It could be useful if you had a message come up saying something like:

"Your browser is not able to view this web page properly. It has been
tested on the following browsers: IE 5.5+, Firefox 1.0+ .... If possible,
please upgrade to a newer browser."

I'm trying to write my page so that there is a div with a message like
this that is set to visible by default in the stylesheet, but hidden early
on in the app's initialisation process. This way, if any of the tests fail
(or the browser doesn't have JS at all), then the user will see this
message. In the case where they do have a suitable browser, it should then
be hidden so they don't see it.

That could be rather annoying. Consider :-

A page is written in a manner that happens to be compatible with, say,
Browser X, but not with some other browsers. A person using Browser X
finds the page, and stores the URL somehow (perhaps in an E-mail; or, as
some may remember, it can be done by using "pencil" and "paper"). This
URL is, a little later, given to a different browser ... and fails to
work adequately.

That's most annoying, especially if the aim *could* have been achieved
at the time using X, but X is now some distance away.

That happened to me on Thursday. The site appearance differed
considerably on the two browsers, which would not have mattered except
that one piece of information seen in the Library browser could not be
found later on.


Therefore ISTM that, if it is considered worthwhile to detect and code
and display a warning on a non-capable browser, the author should
consider showing in addition a brief footnote visible at least in
Browser X in small print along the lines of "This page/site uses
capabilities provided by Browser X but not by all other browsers.".

 

[Randy Webb]

VK said the following on 6/3/2006 4:55 AM:

Because this message doesn't cover say Firefox 1.5.0.4 (the latest one)
if someone disabled JavaScript out of curiosity. It also doesn't cover
IE 6.0 with security settings twisted by a wannabe admin. These are
definitely browsers you tested on, and there is nowhere to upgrade. So
such message is both useless and misleading.

The message is incorrect but the approach is correct.

Please get me right: I'm /not/ one of these bored mind thinking that i)
the working range of the solution has to cover all existing browsers
back to 1998 and further, ii) be ready for a blind and deaf user using
a tong manipulator for navigation, iii) respond for each Lynx esthete
with ads-free text-only content plus images converted into ASCII
graphics, iv) nor many crazy things like that.

Nobody, not even you, is sure of "what mind" you are.

The fingers are yours and you are free to show them at any moment then
you feel like (unless explicitly prohibited by law).

You really are a work of art, you know that?

Still some basic street politesse requires at least to inform your
visitor of the reason (s)he sees a finger instead of the content. And
the reason has to be spelled correctly.

That is simple enough. All you have to do is read my other replies in
this thread. It is a quite simple way to do it.

In this aspect I don't see a way to combine both "no script" and "no
vital feature" situations. There must be two fall-back ways completing
each other.

No, there doesn't. Do you not bother to read and comprehend what you read?

Note 1: Users with scripting disabled (if they really exist) will not
get any extra care out of me besides the <noscript>'ed "See you later,
alligator". But at least this I will give them.

That's your problem, don't propagate it to others.

Note 2: There is some bitter taste left from <noscript> from the Web's
childhood, and it seems inherited by some developers from the new wave:
as they "know" that "there is something about <noscript>", but they
have no idea what exactly.

No, VK, it is not "no idea what", it is the plain comprehension that
there is a better all around alternative and it doesn't involve the
noscript element.

The draw back was caused by placing <noscript> block right after the
<body> tag: the most obvious place for an attention grabber in case if.

You are a lost cause.

As search engines were in their childhood too, they took sample text
for the index entry from the first paragraph on the page, disregarding
on whether it's <noscript> or <body> block on frameset page. As the
result many pages on say AltaVista were "indexed" like:
Page Title
http://...
Sorry, your browser doesn't support JavaScript...
or
Page Title
http://...
Sorry, your browser doesn't support frames...
(I have to explain that in 1996-99 a failure to index properly on say
AltaVista was a big deal).

Please, don't try to explain what you don't understand and you obviously

I strongly believe that modern search engines including Google are much
smarter on that. Still rather than check the smartness of different
search engines I would suggest to place <noscript> block (if used) not
right after the body, but after the first paragraph on your page.

A better alternative is to not use the <noscript> element in the first
place.

One can always adjust the position by using styles (though it is maybe
better do not bother with it for KISS considerations).

And if the browser doesn't support styles?

What's wrong with:

Which of the 100 or so problems with it do you want me to start with?

<noscript>
<p>You have disabled scripting for this site.<br>
Some or all features on this page may be not available.
Some data may be missing or not shown properly.</p>
</noscript>

Your noscript message is insanely inadequate. It doesn't cover the UA's
that don't support scripting at all. And before you whine about outdated
browsers I have a brand new browser that doesn't support scripting in
any form at all. It's in my cellphone. So, please don't tell me I have
disabled something that doesn't exist.

Read my other replies, search the archives, and please try to comprehend
what is said about the noscript element and the better alternatives to it.

 

[petermichaux]

http://www.javascripttoolbox.com/bestpractices/new.php

I would love to get feedback from the experienced developers here.

ok, maybe you don't care what I think but I'm getting better

3. Use Square Bracket Notation

"To be cautious, it's not a bad practice to use square bracket notation
all the time."

I only use square bracket notation when I have the property name
generated at run time. This gives me a visual clue that something out
of the ordinary is going on.

In the hard code case I would write

object.property

instead of

object["property"]

and save square bracket notation for use with a sString

object.[sProperty]

How do you justify using object["property"] as a best practice?

12. Avoid prototype.js

"Prototype is a javascript framework" + "with it's own mailing list" +
"that is used in a variety of projects such as Ruby on Rails..."

That way we could point to your page when people want support. Maybe
add that avoid Scriptaculous (with it's own mailing list) because it
depends on prototype.js

http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

- Peter

 

[Randy Webb]

(e-mail address removed) said the following on 6/4/2006 8:07 PM:

http://www.javascripttoolbox.com/bestpractices/new.php

I would love to get feedback from the experienced developers here.

ok, maybe you don't care what I think but I'm getting better

3. Use Square Bracket Notation

"To be cautious, it's not a bad practice to use square bracket notation
all the time."

I only use square bracket notation when I have the property name
generated at run time. This gives me a visual clue that something out
of the ordinary is going on.

In the hard code case I would write

object.property

instead of

object["property"]

and save square bracket notation for use with a sString

object.[sProperty]

How do you justify using object["property"] as a best practice?

Because square bracket notation works even when dot notation won't.
Especially when PHP is used on the server and people use PHP habits and
name form elements as array objects:

<input name="myInput[]">

When submitted, any form control with myInput[] as the name gets put
into an array.

Now, try to access it with dot notation:

document.myForm.myInput[].value;

Doesn't work, whereas square brackets do:

document.myForm.elements['myInput[]'].value;

"Prototype is a javascript framework" + "with it's own mailing list" +
"that is used in a variety of projects such as Ruby on Rails..."

It's junk, no matter how you describe it.

 

[petermichaux]

Because square bracket notation works even when dot notation won't.
Especially when PHP is used on the server and people use PHP habits and
name form elements as array objects:

<input name="myInput[]">

When submitted, any form control with myInput[] as the name gets put
into an array.

Now, try to access it with dot notation:

document.myForm.myInput[].value;

Doesn't work, whereas square brackets do:

document.myForm.elements['myInput[]'].value;

If bracket notation is a best practice wouldn't you have just written
the following?

document['myForm']['elements']['myInput[]']['value'];

I know this is a fine point to argue about but I think best practices
should be best in all cases where they apply. The above is slower to
type. It is more difficult to maintain with matching quotes and
brackets. It is difficult to look at. Looks like life with hashes
instead of objects. It doesn't show that something special is happening
in the second to last position.

Peter

 

[Lasse Reichstein Nielsen]

How do you justify using object["property"] as a best practice?

My personal justification is that it points out when something is
not a standard DOM property, i.e., when the name of the property
depends on something dynamic, including the document it is being used
with.

That's why I write:

document.forms['formId'].elements['controlName'].value

Here "forms", "elements" and "value" are standard DOM names, whereas
"formId" and "controlName" are non-standard values that comes from
the HTML.

/L

 

[Richard Cornford]

"To be cautious, it's not a bad practice to use square
bracket notation all the time."

I only use square bracket notation when I have the property
name generated at run time. This gives me a visual clue that
something out of the ordinary is going on.

How do you justify using object["property"] as a best practice?

If the document does not provide a convincing justification for
something being a best practice then there is a good chance that it is
not one.

Bracket notation is an under-appreciated aspect of javascript,
particularly among novices and partly because there are javascript books
that do not even mention it. That is best addressed by improving the
understanding of bracket notation, its uses and role in the language.
Suggesting that it could always be used, to the exclusion of dot
notation, seems a knee-jerk reaction that is going too far.

"Prototype is a javascript framework" + "with it's own mailing
list" + "that is used in a variety of projects such as Ruby
on Rails..."

That way we could point to your page when people want support.
Maybe add that avoid Scriptaculous (with it's own mailing list)
because it depends on prototype.js

http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

The rational of directing people with javascript problems to places
where they should have no expectation of finding any javascript
expertise is extremely questionable. If the initial premise is that
prototype.js is significantly flawed in its design and implementation
then sending them to somewhere where those flaws are not even perceived
is not going to be doing them any favours in the long run.

In practice questions involving prototype.js could, and would, be
answered here in exchange for exactly the same effort on the part of the
OPs as is needed to get any other question well answered. I.E. They must
show the complete code they are using (rather than assuming that some
unseen code will be known and understood) in isolation (without any
superfluous code) and preferably in the form of a test-case that
demonstrates the issue.

In the long run people who need to work with javascript must benefit
most from acquiring a better understanding of javascript, and that
better understanding will inevitably involve an appreciation of what is
wrong with the whole notion of off-the-shelf javascript libraries, and
particularly the monolithic and framework-style libraries.

Richard.

 

[Randy Webb]

Richard Cornford said the following on 6/5/2006 3:22 AM:

"To be cautious, it's not a bad practice to use square
bracket notation all the time."

I only use square bracket notation when I have the property
name generated at run time. This gives me a visual clue that
something out of the ordinary is going on.

How do you justify using object["property"] as a best practice?

If the document does not provide a convincing justification for
something being a best practice then there is a good chance that it is
not one.

But in this case it *is* a Best Practice.

Bracket notation is an under-appreciated aspect of javascript,
particularly among novices and partly because there are javascript books
that do not even mention it. That is best addressed by improving the
understanding of bracket notation, its uses and role in the language.
Suggesting that it could always be used, to the exclusion of dot
notation, seems a knee-jerk reaction that is going too far.

You have to stop and think about the potential/intended audience for
that document, and even this groups FAQ, when you decide what should be
recommended and what shouldn't. And to give a short blanket answer to
the question:

Q:Should I use bracket notation or dot notation

The best general answer would have to be:

A: Bracket Notation.

Your dislike of Matt not withstanding.

But, can you give an example of where dot notation works but bracket
notation doesn't work?

We both know of instances where Dot won't work but Bracket does.

 

[Randy Webb]

(e-mail address removed) said the following on 6/4/2006 10:55 PM:

Because square bracket notation works even when dot notation won't.
Especially when PHP is used on the server and people use PHP habits and
name form elements as array objects:

<input name="myInput[]">

When submitted, any form control with myInput[] as the name gets put
into an array.

Now, try to access it with dot notation:

document.myForm.myInput[].value;

Doesn't work, whereas square brackets do:

document.myForm.elements['myInput[]'].value;

If bracket notation is a best practice wouldn't you have just written
the following?

document['myForm']['elements']['myInput[]']['value'];

If I wanted to be pedantic about it, sure. But what's the point? There
are times when Dot Notation simply will not work and Bracket Notation
does. Do I write code as above? No. Why? It's perverse (even my example
is perverse to me).

I use both. Anybody that scripts uses both. They both have advantages
and disadvantages and which you use is two-fold. Preference and the
intended code. But for a novice - which that document is intended for -
the best general advice is to use Bracket Notation.

I know this is a fine point to argue about but I think best practices
should be best in all cases where they apply.

Then you can't give a Best Practice General answer to the question.

When you want the value of an object that has certain characters in it,
you have to use bracket notation.

But, there are some situations where Bracket Notation simply won't work
and you have to use Dot Notation.

My first example shows where Dot Notation simply won't work. Want one
where Bracket Notation won't work? Alert the innerHTML for a div tag
without using Dot Notation (that is one of many answers to my question
to Richard).

So, which is a best *general* answer to the question?

The above is slower to type.

Another fine point to argue but either is just as easy to type once you
get used to it.

It is more difficult to maintain with matching quotes and brackets.

Huh? You lost me there. If a person can't make quotes and brackets match
then they sure won't ever understand the different places where to use
Dot Notation versus Bracket Notation

It is difficult to look at. Looks like life with hashes instead of objects.

JS doesn't have Hashes so I don't follow you there. And we are speaking
strictly of JS here, not other languages and any implications of other
languages.

It doesn't show that something special is happening in the second
to last position.

Neither does document.forms.myForm.elements.elementName.value

 

[Richard Cornford]

Randy Webb wrote:

You have to stop and think about the potential/intended
audience for that document, and even this groups FAQ, when
you decide what should be recommended and what shouldn't.
And to give a short blanket answer to the question:

Q:Should I use bracket notation or dot notation

The best general answer would have to be:

A: Bracket Notation.

But the best answer would point out the worthlessness of the question.
This is not a "should I use this or that" question. There are good
practical reasons for using bracket notation; when the property name
cannot be expressed as an Identifier, or when it must be evaluated at
run time. Apart from that there is not much to choose between them
(except that bracket notation can be expected to be fractionally slower
to resolve).

Your dislike of Matt not withstanding.

Matt already knows that I don't think that using bracket notation fits
with the concept of a best practice. He may elect to disregard my
opinion, but apparently he has not suitably justified his position to
convince others.

But, can you give an example of where dot notation works
but bracket notation doesn't work?

If I could the ECMAScript implementation would be broken as a result.

We both know of instances where Dot won't work but
Bracket does.

So we know that there are reasons for using bracket notation.
Understanding when and why the decision should (even must) come down on
the side of bracket notation is part of understanding javascript. It is
not a 'best practice' to be layered on top.

Richard.

 

[Matt Kruse]

How do you justify using object["property"] as a best practice?

My personal justification is that it points out when something is
not a standard DOM property, i.e., when the name of the property
depends on something dynamic, including the document it is being used
with.
That's why I write:
document.forms['formId'].elements['controlName'].value

I think that is good reasoning, and a good basis for the best practice
recommendation. Although, it does border on a style/convention more than a
best practice. But it does match up with how I think of it also, I just
hadn't defined it in so many words

 

[Matt Kruse]

Matt already knows that I don't think that using bracket notation fits
with the concept of a best practice. He may elect to disregard my
opinion, but apparently he has not suitably justified his position to
convince others.

My recommendation is not to blindly use square bracket notation everywhere.
The actual text is:

"When accessing object properties that are determined at run-time or which
contain characters not compatible with dot notation, use square bracket
notation. To be cautious, it's not a bad practice to use square bracket
notation all the time."

So, "it's not a bad practice" is not really a general recommendation, but a
note to say that if you want to be cautious, there's nothing wrong with
always using square bracket notation. For many, it may end up making their
life easier.

I will do some re-wording of this section before publishing the new doc,
though, so it is clear that square bracket notation is not the recommended
practice for all people in all situations, but instead recommended in
certain cases and when a developer thinks it will help them avoid problems.

 

[petermichaux]

Matt Kruse wrote:

"When accessing object properties that are determined at run-time or which
contain characters not compatible with dot notation, use square bracket
notation. To be cautious, it's not a bad practice to use square bracket
notation all the time."

So, "it's not a bad practice" is not really a general recommendation, but a
note to say that if you want to be cautious, there's nothing wrong with
always using square bracket notation. For many, it may end up making their
life easier.

I will do some re-wording of this section before publishing the new doc,
though, so it is clear that square bracket notation is not the recommended
practice for all people in all situations, but instead recommended in
certain cases and when a developer thinks it will help them avoid problems.

I would think the best practice would be "only use bracket notation
when dot notation will not work."

Peter