FAQ

  • Thread starter Dr J R Stockton
  • Start date
D

Dr J R Stockton

I see remarkably little use of structure-manipulating DOM methods in the
FAQ, even in Section "8 DOM and Forms". There is a firstChild, and I
did not see anything else.


8.1
When is the shorter var contrl = frm.elementname not OK, except
as in 8.2? Surely one should name all items to match /^\w+$/, where
possible, perhaps also allowing judicious $.

ISTM that the value of a form control is predominantly needed in
functions called by elements within the form; and in that case it can
appropriately be obtained by giving this.form as an argument - minimal
demo :

<script> function Fn(F) { alert(F.A.value) } </script>
<form><input name=A><input type=button onClick="Fn(this.form)"></form>


8.2
The word "illegal" should be used only in respect of breaches of the Law
(users can get perturbed by messages such as "illegal operation
invoked"). Consider

Form controls can be accessed with formref.elements["FormName"]. The
bracket characters, amongst others, are _not allowed_ in ID attributes
and javascript identifiers; avoid them, as browsers may handle them
incorrectly.

Much of Section 8 does not seem to fit the title "DOM and Forms" - and
from that title it is not clear whether the intent is "about DOM and
about Forms" or "About (DOM with Forms)".


Section 9.3 is too long. There should be no space in "et c" - should be
"etc."

Section 9.16 How do I open a new window with javascript?
Perhaps should be "Window or Tab".
Could add "How to replace the entire content of the present window?"
see my js-misc1.htm, Bar Codes, table, note for 'OK 2'.

There is no mention of "Tab" in the FAQ, in the sense of 'sub-window'
rather than 'to tab-stop', except for Fiddler.


Here's a DOM question that I currently want the answer to, that *might*
serve for a FAQ DOM example : After multiple appendChild, how do I
remove all of them?

There seems to be no removeChildren provided. One can presumably get
and remove firstChild or lastChild until there are none left; or
likewise make them grandchildren of one parent and later remove her.

---

If Bart cannot sequentially post ALL FAQ sections, then his regular
postings should stop. They distract our attention from the rest of the
FAQ.

And if the entire FAQ is not regularly posted to the group, in one to
many parts, then it cannot be considered a collective work.
 
D

David Mark

I see remarkably little use of structure-manipulating DOM methods in the
FAQ, even in Section "8 DOM and Forms".  There is a firstChild, and I
did not see anything else.

Yes, it is lacking in that regard.
8.1
When is the shorter     var contrl = frm.elementname    not OK,except
as in 8.2?  Surely one should name all items to match /^\w+$/, where
possible, perhaps also allowing judicious $.

When is it OK? Not recommended for cross-browser use at all.
ISTM that the value of a form control is predominantly needed in
functions called by elements within the form; and in that case it can
appropriately be obtained by giving  this.form  as an argument - minimal
demo :

  <script> function Fn(F) { alert(F.A.value) } </script>
  <form><input name=A><input type=button onClick="Fn(this.form)"></form>

8.2
The word "illegal" should be used only in respect of breaches of the Law
(users can get perturbed by messages such as "illegal operation
invoked").  Consider

  Form controls can be accessed with formref.elements["FormName"]. The
  bracket characters, amongst others, are _not allowed_ in ID attributes
  and javascript identifiers; avoid them, as browsers may handle them
  incorrectly.

Much of Section 8 does not seem to fit the title "DOM and Forms" - and
from that title it is not clear whether the intent is "about DOM and
about Forms" or "About (DOM with Forms)".

Agreed. It's a bit of a hodgepodge.
Section 9.3 is too long.  There should be no space in "et c" - should be
"etc."

Section 9.16 How do I open a new window with javascript?
Perhaps should be "Window or Tab".

Yes. Outdated.
Could add "How to replace the entire content of the present window?"
see my js-misc1.htm, Bar Codes, table, note for 'OK 2'.
Link?


There is no mention of "Tab" in the FAQ, in the sense of 'sub-window'
rather than 'to tab-stop', except for Fiddler.

Here's a DOM question that I currently want the answer to, that *might*
serve for a FAQ DOM example : After multiple appendChild, how do I
remove all of them?

There seems to be no removeChildren provided.  One can presumably get
and remove firstChild or lastChild until there are none left; or
likewise make them grandchildren of one parent and later remove her.

Either will suffice. Or if you are adventurous, set innerHTML to
'' (not recommended.)
---

If Bart cannot sequentially post ALL FAQ sections, then his regular
postings should stop.  They distract our attention from the rest of the
FAQ.

Yes, please make it stop. If I see one more posting about which books
are recommended...
And if the entire FAQ is not regularly posted to the group, in one to
many parts, then it cannot be considered a collective work.

It would still be a collective, but not of this group.
 
M

Martin Honnen

Dr said:
Here's a DOM question that I currently want the answer to, that *might*
serve for a FAQ DOM example : After multiple appendChild, how do I
remove all of them?

There seems to be no removeChildren provided. One can presumably get
and remove firstChild or lastChild until there are none left;

If you want a pure W3C DOM Level 1 solution then yes, do
while (element.hasChildNodes())
{
element.removeChild(element.lastChild);
}

On the other hand when scripting HTML elements in the browser doing
element.innerHTML = '';
should also be well supported.
 
J

Jorge

(...) make them grandchildren of one parent and later remove her. (...)
^^^^^
Wow, a sexed DOM, so in and trendy Mr.Dr. !

Use she.parentNode.removeChild(she); (it works just once), or
she.innerHTML= ""; (she is emptied but remains inserted) or
she.outerHTML= ""; (fluff, she completely dissipates, why not ? why
is .outerHTML not so popular ?)
 
D

Dr J R Stockton

In comp.lang.javascript message <f728cbbe-f297-4f25-b4b8-69514b3331b1@u1
0g2000vbd.googlegroups.com>, Wed, 3 Jun 2009 10:30:38, David Mark
Yes, it is lacking in that regard.


When is it OK? Not recommended for cross-browser use at all.

An asserted generalism without a specific example is not a satisfactory
answer. And for it to be not recommended _at all_ there must be no
common circumstance in which it is adequately reliable.



If you are not smart enough to easily find the page, I'm not interested
in having you read it.
 
D

Dr J R Stockton

In comp.lang.javascript message <[email protected]
cor-online.net>, Wed, 3 Jun 2009 19:31:16, Martin Honnen
If you want a pure W3C DOM Level 1 solution then yes, do
while (element.hasChildNodes())
{
element.removeChild(element.lastChild);
}

On the other hand when scripting HTML elements in the browser doing
element.innerHTML = '';
should also be well supported.

Thank you. You have the unusual (here) property of actually giving
useful answers.

Sub-topic change; <FAQENTRY>.
If posting in a language other than English, please name it in English.
 
B

Bart Van der Donck

Dr said:
If Bart cannot sequentially post ALL FAQ sections, then his regular
postings should stop.  They distract our attention from the rest of the
FAQ.

Thanks for bringing this up; I didn't notice it (yet). The posting
script was set up to start over after four chapters. I had set this
rule as a result of the following request:
http://groups.google.com/group/comp.lang.javascript/msg/174ac58cd91a5feb
At that time, the FAQ was 5 chapters long.

It appears that this rule was still in use, hence causing the script
to prematurely restart (after "How do I format a date with
javascript?"). When Garrett added more chapters, the script still used
the old rule. I must have missed the post of the FAQ update towards
more chapters - sorry.

I have altered the working of the script, so that it now posts again
all entries from start to finish; not using a fixed number of
chapters, but deriving the amount of chapters/entries dynamically from
the XML input at http://www.jibbering.com/faq/index.xml . The first
chapter remains excluded from the sendouts.
 
G

Garrett Smith

Bart said:
Dr J R Stockton wrote:
I have altered the working of the script, so that it now posts again
all entries from start to finish; not using a fixed number of
chapters, but deriving the amount of chapters/entries dynamically from
the XML input at http://www.jibbering.com/faq/index.xml . The first
chapter remains excluded from the sendouts.

Thanks, Bart.

If it makes it any easier, in the future, it would not be much trouble
for me to generate a text file for each daily post. For example:

mon.txt
tue.txt

or

sec1.txt
sec2.txt

Garrett
 
T

Thomas 'PointedEars' Lahn

Martin said:
If you want a pure W3C DOM Level 1 solution then yes, do
while (element.hasChildNodes())
{
element.removeChild(element.lastChild);
}

It appears to be more efficient and equally compatible to use

while (element.lastChild)
{
element.removeChild(element.lastChild);
}

instead. (I have proposed .firstChild earlier, but I can see that
..lastChild probably requires less work updating .childNodes.)

BTW, both solutions works in W3C DOM Level 2+ (which is supposedly more
widely implemented because W3C DOM Level 1 *HTML* was designated obsolete)
as well.


PointedEars
 
J

Jorge

(...)
It appears to be more efficient and equally compatible to use

  while (element.lastChild)
  {
    element.removeChild(element.lastChild);
  }

instead.  (I have proposed .firstChild earlier, but I can see that
.lastChild probably requires less work updating .childNodes.)

We've been over this already:

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/e1692dbf3d798466
http://homepage.mac.com/jorgechamorro/cljs/048/

..innerHTML is much faster.
 
T

Thomas 'PointedEars' Lahn

kangax said:
I thought about `lastChild` as well, but then realized that its boolean
type conversion might have unexpected results. DOM 2 specs say that
`lastChild` returns either Node or `null`. If null can be assumed to
correspond to ECMAScript's `null` value, than that will type convert to
false. But how can we be sure that Node instance will type-convert to
`true`?

(There must be a bug in the Matrix ...)

Because it is supposed to be an object reference.
hasChildNodes()'s result, on the other hand, is specified to be
`boolean`. It seems like there are more chances for DOM's `true` to map
to ECMAScript's `true`, than there is for DOM's Node to correspond to
ECMAScript's `true`.

Does this make sense or am I drawing wrong conclusions?

It doesn't make any sense to me. There is no reason to believe that an
implementation would error out on .lastChild but not on .hasChildNodes()
(in fact, the latter is probably even less compatible). And as the `if'
statement forces type conversion of its parameter¹, there is also no reason
to believe that a DOM object reference would suddenly type-convert to
boolean `false' while `null' would type-convert to boolean `true'. If that
were the case, we could simply dump a lot of code out there that accesses
the DOM, and most certainly all the libraries, both better ones and worse ones.

¹ for the lack of a better word
Is it something you would worry about?

Not here.
Or is it overly paranoid?

Yes. All quirks aside, DOMs are still APIs designed to be *used*.


PointedEars
 
T

Thomas 'PointedEars' Lahn

kangax said:
I understand that, but `document.all` is an object reference too, yet it
type converts to `false` in Gecko (when in quirks mode).

But it does that for very a good reason: it is no equivalent for the
document.all in MSHTML.
Host objects are free to do all they want, no matter how they are
represented in a certain ECMAScript implementation.

Yes, but seriously, if an object reference provided by the implementation of
a standardized API does not type-convert to `true' ... well, I don't care
about implementations *this* borken unless I have to. While, as you
probably know, I am a strong promoter of feature-testing, to care for every
possible quirk or bug would mean that no quirk will ever cease to exist and
no bug will ever get fixed, and we would be writing workarounds for borken
implementations forever. That is not the kind of world I want to live in.
Do you?


PointedEars
 
G

Garrett Smith

Dr said:
In comp.lang.javascript message <f728cbbe-f297-4f25-b4b8-69514b3331b1@u1
0g2000vbd.googlegroups.com>, Wed, 3 Jun 2009 10:30:38, David Mark
On Jun 3, 12:35 pm, Dr J R Stockton <[email protected]>
wrote: [...]
8.1
When is the shorter var contrl = frm.elementname not OK, except
as in 8.2? Surely one should name all items to match /^\w+$/, where
possible, perhaps also allowing judicious $.
When is it OK? Not recommended for cross-browser use at all.

An asserted generalism without a specific example is not a satisfactory
answer. And for it to be not recommended _at all_ there must be no
common circumstance in which it is adequately reliable.

There is an example in the "names" article, at jibbering.com/names/ .
Jibbering.com is down again.

Getting the control directly off the form is not standard. It also has
the side effect of leaving the property on the form in some browsers. If
the form control is removed, the form still has a property of
form.controlName with that form control as a property.

Garrett
 
B

Bart Van der Donck

Garrett said:
Thanks, Bart.

If it makes it any easier, in the future, it would not be much trouble
for me to generate a text file for each daily post. For example:

mon.txt
tue.txt

or

sec1.txt
sec2.txt

Thanks for the offer, but not really necessary, as the script now
already works with XML parsing. I think it's always a good idea to do
the preview-tests on how posts will look on Usenet (ref emails Oct08).
 
G

Garrett Smith

I do not know if hasChildNodes is less widely supported than lastChild,
but I know that if I am removing lastChild, I need to concern myself
with lastChild being not null, lastChild being null . Therefore:

while(el.lastChild !== null) {
el.removeChild(el.lastChild);
}
- would do it.

Why is |el.innerHTML = ""| slower in Firefox?
¹ for the lack of a better word


Not here.

IE and ToBoolean is something to be concerned and aware of when using
ToBoolean conversion. The consequences of the problem is a runtime error.
Yes. All quirks aside, DOMs are still APIs designed to be *used*.

I would not be surprised at all to see an error on a particular type of
node. Maybe an <object>. I don't know.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,969
Messages
2,570,161
Members
46,705
Latest member
Stefkari24

Latest Threads

Top