FAQ
Dr J R Stockton
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.
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
David Mark
wrote:
> 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.
Martin Honnen
> 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.
--
Martin Honnen
http://msmvps.com/blogs/martin_honnen/
Jorge
> On Jun 3, 12:35 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk
> > 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...
... ?
--
Jorge.
Jorge
wrote:
>
> (...) 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 ?)
--
Jorge.
Bart Van der Donck
> 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.
--
Bart
Dr J R Stockton
cor-online.net>, Wed, 3 Jun 2009 19:31:16, Martin Honnen
<maho...@yahoo.de> posted:
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.
--
(c) John Stockton, nr London UK. ??@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
Dates - miscdate.htm Year 2000 - date2000.htm Critical Dates - critdate.htm
Euro computing - european.htm UK Y2k mini-FAQ: y2k_mfaq.txt Don't Mail News
Dr J R Stockton
0g2000vbd.googlegroups.com>, Wed, 3 Jun 2009 10:30:38, David Mark
<dmark....@gmail.com> posted:
>On Jun 3, 12:35�pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>wrote:
>> 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.
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.
>> 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?
If you are not smart enough to easily find the page, I'm not interested
in having you read it.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Garrett Smith
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
--
The official comp.lang.javascript FAQ:
http://jibbering.com/faq/
Thomas 'PointedEars' Lahn
> Dr J R Stockton wrote:
>> 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);
> }
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
kangax
> Martin Honnen wrote:
>> Dr J R Stockton wrote:
>>> 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);
>> }
>
> It appears to be more efficient and equally compatible to use
>
> while (element.lastChild)
> {
> element.removeChild(element.lastChild);
> }
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`?
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? Is it something
you would worry about? Or is it overly paranoid?
[...]
--
kangax
Jorge
wrote:
> (...)
> 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.
--
Jorge.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Martin Honnen wrote:
>>> Dr J R Stockton wrote:
>>>> 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);
>>> }
>> It appears to be more efficient and equally compatible to use
>>
>> while (element.lastChild)
>> {
>> element.removeChild(element.lastChild);
>> }
>
> 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
kangax
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> It appears to be more efficient and equally compatible to use
>>>
>>> while (element.lastChild)
>>> {
>>> element.removeChild(element.lastChild);
>>> }
>> 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.
I understand that, but `document.all` is an object reference too, yet it
type converts to `false` in Gecko (when in quirks mode). Host objects
are free to do all they want, no matter how they are represented in a
certain ECMAScript implementation.
>
>> 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
Well, I wasn't talking about `null`. Only that host object (which node
is) could convert to `false` (see `document.all` example above), while
result of hasChildNodes(), which - as per specs - is a boolean value,
has more chances of being converted "properly".
Ugh. I guess it is overly paranoid after all :/
[...]
>
>> Is it something you would worry about?
>
> Not here.
Ok.
>
>> Or is it overly paranoid?
>
> Yes. All quirks aside, DOMs are still APIs designed to be *used*.
Indeed.
--
kangax
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> It appears to be more efficient and equally compatible to use
>>>>
>>>> while (element.lastChild)
>>>> {
>>>> element.removeChild(element.lastChild);
>>>> }
>>> 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.
>
> 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
Garrett Smith
> 0g2000vbd.googlegroups.com>, Wed, 3 Jun 2009 10:30:38, David Mark
> <dmark....@gmail.com> posted:
>> On Jun 3, 12:35 pm, Dr J R Stockton <reply0...@merlyn.demon.co.uk>
>> 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.
Bart Van der Donck
> Bart Van der Donck 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 athttp://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
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).
--
Bart
Jorge
>
> (...) I think it's always a good idea to do
> the preview-tests on how posts will look on Usenet (...).
They'll look quite similar to mine... :-)
--
Jorge.
Garrett Smith
> kangax wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Martin Honnen wrote:
>>>> Dr J R Stockton wrote:
>>>>> 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);
>>>> }
>>> It appears to be more efficient and equally compatible to use
>>>
>>> while (element.lastChild)
>>> {
>>> element.removeChild(element.lastChild);
>>> }
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
>
>> Is it something you would worry about?
>
> 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.
>> Or is it overly paranoid?
>
> 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.