Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #28261 > unrolled thread

Best way to show create different elements dynamically

Back to article view | Back to comp.lang.javascript

Contents

  Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 01:02 +0100
    Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 01:06 +0100
      Re: Best way to show create different elements dynamically Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-05 09:27 +0200
        Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 10:04 +0100
      Re: Best way to show create different elements dynamically danca <cyberdanny@tiscalinet.it> - 2015-07-05 10:10 +0200
        Re: Best way to show create different elements dynamically Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-05 10:22 +0200
          Re: Best way to show create different elements dynamically danca <cyberdanny@tiscalinet.it> - 2015-07-05 11:43 +0200
            Re: Best way to show create different elements dynamically Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-05 13:16 +0200
              Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 12:48 +0100
              Re: Best way to show create different elements dynamically danca <cyberdanny@tiscalinet.it> - 2015-07-05 14:47 +0200
                Re: Best way to show create different elements dynamically Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-05 16:03 +0200
                  Re: Best way to show create different elements dynamically danca <cyberdanny@tiscalinet.it> - 2015-07-05 19:53 +0200
                    Re: Best way to show create different elements dynamically Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-06 01:46 +0200
                      Re: Best way to show create different elements dynamically "danca (Daniele Campagna)" <cyberdanny@tiscalinet.it> - 2015-07-06 07:29 +0200
          Re: Best way to show create different elements dynamically Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2015-07-05 13:17 +0200
      Re: Best way to show create different elements dynamically "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-07-05 10:38 +0200
        Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 10:01 +0100
        Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 10:11 +0100
          Re: Best way to show create different elements dynamically Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-05 11:17 +0200
          Re: Best way to show create different elements dynamically "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-07-05 11:26 +0200
            Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 10:30 +0100
            Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 10:33 +0100
              Re: Best way to show create different elements dynamically "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-07-05 12:29 +0200
                Re: Best way to show create different elements dynamically danca <cyberdanny@tiscalinet.it> - 2015-07-05 12:38 +0200
                  Re: Best way to show create different elements dynamically "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-07-05 17:33 +0200
                    Re: Best way to show create different elements dynamically danca <cyberdanny@tiscalinet.it> - 2015-07-05 18:55 +0200
                      Re: Best way to show create different elements dynamically "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-07-05 19:44 +0200
                        Re: Best way to show create different elements dynamically danca <cyberdanny@tiscalinet.it> - 2015-07-05 20:42 +0200
                          Re: Best way to show create different elements dynamically "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-07-05 21:01 +0200
                Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 13:00 +0100
                  Re: Best way to show create different elements dynamically Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-05 16:13 +0200
                    Re: Best way to show create different elements dynamically Tim Streater <timstreater@greenbee.net> - 2015-07-05 15:23 +0100
                      Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 15:57 +0100
    Re: Best way to show create different elements dynamically JiiPee <no@notvalid.com> - 2015-07-05 10:03 +0100

Page 1 of 2  [1] 2  Next page →

#28261 — Best way to show create different elements dynamically

I use javascript to first create <p>-text lines inside a div (using 
innerHTML). Then after that text I would like to show a table (<table>). 
What is the best way to do this? Should I somehow put a element (like a 
div) at the last text place and then check its position and move the 
table to that position? Or possible adding just table to that innerHTML 
like I did with the text? I know there are several ways to do this, but 
how people normally do this? thank you

[toc] | [next] | [standalone]

#28262

Does not need to be an example but just a hint or direction would be 
enough ... I can search after that.

On 05/07/2015 01:02, JiiPee wrote:
> I use javascript to first create <p>-text lines inside a div (using 
> innerHTML). Then after that text I would like to show a table 
> (<table>). What is the best way to do this? Should I somehow put a 
> element (like a div) at the last text place and then check its 
> position and move the table to that position? Or possible adding just 
> table to that innerHTML like I did with the text? I know there are 
> several ways to do this, but how people normally do this? thank you

[toc] | [prev] | [next] | [standalone]

#28263

JiiPee wrote:

| Reply-To: no@notvalid.com
| From: JiiPee <no@notvalid.com>

> Does not need to be an example but just a hint or direction would be
> enough ... I can search after that.
> 
> [top post]

Your postings are inappropriate; read the FAQ.

@all: Caution.  The Web site on the domain used for the pseudo-address 
randomly redirects to other Web sites, including SMS/e-mail scam. 

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28270

On 05/07/2015 08:27, Thomas 'PointedEars' Lahn wrote:
> JiiPee wrote:
>
> | Reply-To: no@notvalid.com
> | From: JiiPee <no@notvalid.com>
>
>> Does not need to be an example but just a hint or direction would be
>> enough ... I can search after that.
>>
>> [top post]
> Your postings are inappropriate; read the FAQ.
>
> @all: Caution.  The Web site on the domain used for the pseudo-address
> randomly redirects to other Web sites, including SMS/e-mail scam.
>

ye I know, but it was only a small section I top posted, so is it so bad? :)

[toc] | [prev] | [next] | [standalone]

#28264

Il 07/05/2015 02:06 AM, JiiPee ha scritto:

>> I use javascript to first create <p>-text lines inside a div (using
>> innerHTML). Then after that text I would like to show a table
>> (<table>). What is the best way to do this? Should I somehow put a
>> element (like a div) at the last text place and then check its
>> position and move the table to that position? Or possible adding just
>> table to that innerHTML like I did with the text? I know there are
>> several ways to do this, but how people normally do this? thank you
>

I think you should investigate document.createElement() and 
document.appendChild() to manipulate the DOM instead of using innerHTML.
Example: (create a div, then set some properties)

var aDiv=document.createElement('div')
aDiv.style.position="fixed"
aDiv.style.width="100%"

You can nest other elements into the element created (but still not 
visible nor present in your document):

var info=document.createElement("span")
info.className="infobar"
info.id="info"
var lbl=document.createElement("label")
lbl.className="bar"
lbl.id="title"

info.appendChild(lbl)
aDiv.appendChild(info)

And now append the div to the document:

document.body.appendChild(aDiv)

Look also to firstChild(), replaceChild(), removeChild ecc.

Dan

[toc] | [prev] | [next] | [standalone]

#28265

danca wrote:

> Il 07/05/2015 02:06 AM, JiiPee ha scritto:
>>> I use javascript to first create <p>-text lines inside a div (using
>>> innerHTML). Then after that text I would like to show a table
>>> (<table>). What is the best way to do this? […]
> 
> I think you should investigate document.createElement() and
> document.appendChild() to manipulate the DOM instead of using innerHTML.

I think you should do some tests before giving advice. Including benchmarks.

> Example: (create a div, then set some properties)
> 
> var aDiv=document.createElement('div')
> aDiv.style.position="fixed"

It is customary and recommended to use whitespace to separate tokens.
It is recommended to use a consistent quoting style.
It is customary and recommended to end simple statements with a semicolon.

  var aDiv = document.createElement("div");
  aDiv.style.position = "fixed";

> You can nest other elements into the element created (but still not 
> visible nor present in your document):
> 
> info.appendChild(lbl)
> aDiv.appendChild(info)
> 
> And now append the div to the document:
> 
> document.body.appendChild(aDiv)

Good advice at last.  The reason for this order is that it prevents 
reflow/repaint in case of a race condition.  But it is still not more 
compatible or efficient with *tables*:

<http://www.quirksmode.org/dom/innerhtml.html>

> […]
> Look also to firstChild(), replaceChild(), removeChild ecc.

There is no “firstChild” method, and no “removeChild” *non-callable* 
property.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28276

Il 07/05/2015 10:22 AM, Thomas 'PointedEars' Lahn ha scritto:
> danca wrote:
>
>> Il 07/05/2015 02:06 AM, JiiPee ha scritto:
>>>> I use javascript to first create <p>-text lines inside a div (using
>>>> innerHTML). Then after that text I would like to show a table
>>>> (<table>). What is the best way to do this? […]
>>
>> I think you should investigate document.createElement() and
>> document.appendChild() to manipulate the DOM instead of using innerHTML.
>
> I think you should do some tests before giving advice. Including benchmarks.

I don't get the "benchmarks" part. Can you elaborate? [edit: ok, I have 
read the document you refers later in the message]

>
>> Example: (create a div, then set some properties)
>>
>> var aDiv=document.createElement('div')
>> aDiv.style.position="fixed"
>
> It is customary and recommended to use whitespace to separate tokens.
> It is recommended to use a consistent quoting style.

And I don't get this, too. I'm using Thunderbird on Linux and the 
quoting is automatic and seems to me just the same it was under 
Windows... Can you be more specific?

>> You can nest other elements into the element created (but still not
>> visible nor present in your document):
>>
>> info.appendChild(lbl)
>> aDiv.appendChild(info)
>>
>> And now append the div to the document:
>>
>> document.body.appendChild(aDiv)
>
> Good advice at last.  The reason for this order is that it prevents
> reflow/repaint in case of a race condition.  But it is still not more
> compatible or efficient with *tables*:
>
> <http://www.quirksmode.org/dom/innerhtml.html>

Interesting. Anyway, I was not concerned by any means about performance. 
And that page should be updated, it is really old stuff.
BTW isn't innerHTML generally discouraged?

>
>> […]
>> Look also to firstChild(), replaceChild(), removeChild ecc.
>
> There is no “firstChild” method, and no “removeChild” *non-callable*
> property.
>

Uh, right. Typos.

Dan

[toc] | [prev] | [next] | [standalone]

#28280

danca wrote:

> Il 07/05/2015 10:22 AM, Thomas 'PointedEars' Lahn ha scritto:
>> danca wrote:
>>> Example: (create a div, then set some properties)
>>>
>>> var aDiv=document.createElement('div')
>>> aDiv.style.position="fixed"
>>
>> It is customary and recommended to use whitespace to separate tokens.
>> It is recommended to use a consistent quoting style.
> 
> And I don't get this, too. I'm using Thunderbird on Linux and the
> quoting is automatic and seems to me just the same it was under
> Windows... Can you be more specific?

I mean your *code* style.  The first statement should be self-explanatory 
onec you read my correction.

As for the second one: You are using <'> as string delimiter in one line and 
<"> in the next one.  That is inconsistent and should not happen.  One 
reason is that it makes code harder to maintain as it requires regular 
expressions for search and/or replace.

I recommend to use <"> for delimiting string literals always unless there 
are valid reasons not to.  The reason for that is that the double-quote 
character is better visible with several fonts that the straight apostrophe.  
One valid reason for an exception is that the string value contains one or 
more <">; in that case using <'> as delimiter avoids the need for escaping 
the <">.  One example for that is generating HTML with document.write() 
(which is blocking, avoid this if possible) or “innerHTML”: I prefer the 
resulting markup with <"> as attribute delimiters, not least because I find 
straight apostrophes in attribute values more common than straight double-
quote characters (although you need to guard against that in any case, and 
the typographically correct characters would not be the straight ones).

Also, you should always guard against the possibility that the element 
object could not be created:

  var aDiv = document.createElement("div");
  if (aDiv)
  {
    aDiv.style.position = "fixed";
  }

>>> You can nest other elements into the element created (but still not
>>> visible nor present in your document):
>>>
>>> info.appendChild(lbl)
>>> aDiv.appendChild(info)
>>>
>>> And now append the div to the document:
>>>
>>> document.body.appendChild(aDiv)
>>
>> Good advice at last.  The reason for this order is that it prevents
>> reflow/repaint in case of a race condition.  But it is still not more
>> compatible or efficient with *tables*:
>>
>> <http://www.quirksmode.org/dom/innerhtml.html>
> 
> Interesting. Anyway, I was not concerned by any means about performance.
> And that page should be updated, it is really old stuff.

There is a pseudo-link attached to each benchmark which you can run.  I have 
run the tests 5 times each in Chromium “43.0.2357.130 Built on Debian 
stretch/sid, running on Debian stretch/sid (64-bit)”.  The “innerHTML” 
approach to building tables is still the fastest one there.

What surprises me is that the “innerHTML” approach that uses appending 
string concatenation –

	var string = '<table><tbody>';
	for (var i=0;i<50;i++)
	{
		string += '<tr>';
		for (var j=0;j<50;j++)
		{
			string += '<td>*</td>';
		}
		string += '</tr>';
	}
	string += '</tbody></table>';
	document.getElementById('writeroot').innerHTML = string;

– is indeed faster than the one that uses Array.prototype.push() –

	var string = new Array();
	string.push('<table><tbody>');
	for (var i=0;i<50;i++)
	{
		string.push('<tr>');
		for (var j=0;j<50;j++)
		{
			string.push('<td>*</td>');
		}
		string.push('</tr>');
	}
	string.push('</tbody></table>');
	var writestring = string.join('');
	document.getElementById('writeroot').innerHTML = writestring;

–, even though the latter method is a built-in, in that browser version.
Perhaps this has to do with the shortness of the strings as I remember 
having read of a benchmark that showed that appending string concatenation 
gets less efficient the longer the strings are, while the reverse is true 
for Array.prototype.push().

(Blame PPK for the tabs.)

> BTW isn't innerHTML generally discouraged?

*Apparently* not.
 
Please get a *real* name.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28281

On 05/07/2015 12:16, Thomas 'PointedEars' Lahn wrote:
> danca wrote:
>
>> t page should be updated, it is really old stuff.
> There is a pseudo-link attached to each benchmark which you can run.  I have
> run the tests 5 times each in Chromium “43.0.2357.130 Built on Debian
> stretch/sid, running on Debian stretch/sid (64-bit)”.  The “innerHTML”
> approach to building tables is still the fastest one there.
>
> What surprises me is that the “innerHTML” approach that uses appending
> string concatenation –
>
> 	var string = '<table><tbody>';
> 	for (var i=0;i<50;i++)
> 	{
> 		string += '<tr>';
> 		for (var j=0;j<50;j++)
> 		{
> 			string += '<td>*</td>';
> 		}
> 		string += '</tr>';
> 	}
> 	string += '</tbody></table>';
> 	document.getElementById('writeroot').innerHTML = string;


oh, thats the code I can use I think, so its ready there. Thanks :). I 
guess could google that as well

[toc] | [prev] | [next] | [standalone]

#28283

Il 07/05/2015 01:16 PM, Thomas 'PointedEars' Lahn ha scritto:
> danca wrote:

>>> It is recommended to use a consistent quoting style.
>>
>> And I don't get this, too. I'm using Thunderbird on Linux and the
>> quoting is automatic and seems to me just the same it was under
>> Windows... Can you be more specific?
>
> I mean your *code* style.  The first statement should be self-explanatory
> onec you read my correction.
>
> As for the second one: You are using <'> as string delimiter in one line and
> <"> in the next one.  That is inconsistent and should not happen.  One
> reason is that it makes code harder to maintain as it requires regular
> expressions for search and/or replace.
>
> I recommend to use <"> for delimiting string literals always unless there
> are valid reasons not to.  The reason for that is that the double-quote
> character is better visible with several fonts that the straight apostrophe.
> One valid reason for an exception is that the string value contains one or
> more <">; in that case using <'> as delimiter avoids the need for escaping
> the <">.  One example for that is generating HTML with document.write()
> (which is blocking, avoid this if possible) or “innerHTML”: I prefer the
> resulting markup with <"> as attribute delimiters, not least because I find
> straight apostrophes in attribute values more common than straight double-
> quote characters (although you need to guard against that in any case, and
> the typographically correct characters would not be the straight ones).

:-) what a misunderstanding. Ok, you are right. I have the habit to be a 
bit [ :-) ] sloppy about that. [offtopic&irrelevant] The main reason is 
the need to press 2 keys (on my keyboard) to obtain " and only one for 
'. So it seems it depends by my mood/hurry/sloppiness.

>
> Also, you should always guard against the possibility that the element
> object could not be created:
>
>    var aDiv = document.createElement("div");
>    if (aDiv)
>    {
>      aDiv.style.position = "fixed";
>    }
>

Just a curiosity: this has to do with feature testing or with the 
possibilty that the element can not be created for some other reasons?
In other words... are you aware of conditions that can reasonably cause 
createElement() to fail [if implemented]?

>>> <http://www.quirksmode.org/dom/innerhtml.html>
>>
>> Interesting. Anyway, I was not concerned by any means about performance.
>> And that page should be updated, it is really old stuff.
>
> There is a pseudo-link attached to each benchmark which you can run.  I have
> run the tests 5 times each in Chromium “43.0.2357.130 Built on Debian
> stretch/sid, running on Debian stretch/sid (64-bit)”.  The “innerHTML”
> approach to building tables is still the fastest one there.

Tried on Firefox 29 on Kernel 2.6.37.6 (Slackware 13.37/64) - best 
result on last option, concatenate array. And 180 msec vs 100 msec is 
the overall difference between fastest vs. slowest method.

>
> What surprises me is that the “innerHTML” approach that uses appending
> string concatenation –
>
> 	var string = '<table><tbody>';
> 	for (var i=0;i<50;i++)
> 	{
> 		string += '<tr>';
> 		for (var j=0;j<50;j++)
> 		{
> 			string += '<td>*</td>';
> 		}
> 		string += '</tr>';
> 	}
> 	string += '</tbody></table>';
> 	document.getElementById('writeroot').innerHTML = string;
>
> – is indeed faster than the one that uses Array.prototype.push() –
>
> 	var string = new Array();
> 	string.push('<table><tbody>');
> 	for (var i=0;i<50;i++)
> 	{
> 		string.push('<tr>');
> 		for (var j=0;j<50;j++)
> 		{
> 			string.push('<td>*</td>');
> 		}
> 		string.push('</tr>');
> 	}
> 	string.push('</tbody></table>');
> 	var writestring = string.join('');
> 	document.getElementById('writeroot').innerHTML = writestring;
>
> –, even though the latter method is a built-in, in that browser version.
> Perhaps this has to do with the shortness of the strings as I remember
> having read of a benchmark that showed that appending string concatenation
> gets less efficient the longer the strings are, while the reverse is true
> for Array.prototype.push().
>
> (Blame PPK for the tabs.)

[Reads OK in my newsreader] Indeed this can raise more than a eyebrow. 
This has probably to do with *how* the built-ins are... built in.
But if I can make a guess, this could be understandable. In a browser 
implementation at c-level we can imagine that the routines used to keep 
in sync the textual content of a document with its DOM counterpart are 
the ancient and more "core-level" ones (optimized and quite 
"straightforward") while the object management needs some more software 
levels. Just guessing.

>
>> BTW isn't innerHTML generally discouraged?
>
> *Apparently* not.
>
> Please get a *real* name.
>
For a human, ynnadrebyc can be understood as a childish way to protect 
my mail account from the spam, for a bot it can be puzzling [I hope].
[One sidenote: why the hell you insist on real names? Are you immune by 
spam?]

And thanks for your time.
Dan

[toc] | [prev] | [next] | [standalone]

#28285

danca wrote:

> Il 07/05/2015 01:16 PM, Thomas 'PointedEars' Lahn ha scritto:
>> Also, you should always guard against the possibility that the element
>> object could not be created:
>>
>>    var aDiv = document.createElement("div");
>>    if (aDiv)
>>    {
>>      aDiv.style.position = "fixed";
>>    }
>>
> 
> Just a curiosity: this has to do with feature testing or with the
> possibilty that the element can not be created for some other reasons?

Were it for feature-testing, you would also test the 
document.createElement() method before you call it, not only its return 
value.

> In other words... are you aware of conditions that can reasonably cause
> createElement() to fail [if implemented]?

Good question.  Yes, this is a factory method; instantiation of an object 
can fail for various reasons.

However, it should be noted that none of W3C DOM Core Level 1, W3C DOM Level 
2 Core, W3C DOM Level 3 Core, W3C HTML5, and WHATWG HTML fully specifies 
what should happen in this case.  HTML5/WHATWG HTML only implicitly 
specifies that an interface for an unknown element type should be used if 
the element type name is unsupported, which is precisely what happens in 
HTML5 browsers [they use HTMLUnknownElement].

In particular, it is _not_ specified, contrary to what I previously thought, 
that the document.createElement() method could return a “null” value if it 
does not throw an exception.  And it is specified that it only shall throw 
exceptions if the specified element type name contains an “invalid” or 
“illegal character”:

<http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html#i-Document>
<http://www.w3.org/TR/DOM-Level-2-Core/core.html#i-Document>
<http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-2141741547>
<http://www.w3.org/TR/2015/WD-dom-20150618/#dom-document-createelement>
<http://www.w3.org/TR/html5/dom.html#htmlunknownelement>
<https://html.spec.whatwg.org/multipage/dom.html#htmlunknownelement>

But it stands to reason that, without exceptions, the return value for 
failure would be a value that the ToBoolean() algorithm that is used by the 
“if“ statement converts to the “false” value (which I prefer to call “a 
false-value” for short).  So I think this test is still justified.
 
>>>> <http://www.quirksmode.org/dom/innerhtml.html>
>>>
>>> Interesting. Anyway, I was not concerned by any means about performance.
>>> And that page should be updated, it is really old stuff.
>>
>> There is a pseudo-link attached to each benchmark which you can run.  I
>> have run the tests 5 times each in Chromium “43.0.2357.130 Built on
>> Debian stretch/sid, running on Debian stretch/sid (64-bit)”.  The 
>> “innerHTML” approach to building tables is still the fastest one there.
> 
> Tried on Firefox 29 on Kernel 2.6.37.6 (Slackware 13.37/64) - best

You should say _Linux_ 2.6.37.6.  There are many kernels.

> result on last option, concatenate array.

Interesting.  I can confirm your observations in Iceweasel 38.0.1 on Debian 
GNU/Linux stretch/sid with Linux 3.16.0-4-amd64 (stock kernel).  However, it 
appears that *there* the runtime efficiencies of the two “innerHTML” 
approaches are so close that sometimes one is the faster one, then the 
other.

Have you also tested each approach 5 times in random order?

> And 180 msec vs 100 msec is the overall difference between fastest vs. 
> slowest method.

Even a difference of 80 milliseconds becomes significant if the algorithm 
taking 80 milliseconds longer than another one is repeated.

>> Please get a *real* name.
>
> For a human, ynnadrebyc can be understood as a childish way to protect
> my mail account from the spam, for a bot it can be puzzling [I hope].

Your hope is unfounded.

> [One sidenote: why the hell you insist on real names? Are you immune by
> spam?]

Posting using a pseudonym does not affect the amount of spam one is getting.
How did you get that idea?  Spam is sent to mailboxes referenced by *e-mail 
addresses*; not to specific people.  To use an analogy: if you remove your 
name from your real-life mailbox, or put a false name on it, that does not 
change the location of your home.

There is no good reason to believe that posting with a real name increases 
the amount of spam one is getting.  It does increase, however, the amount of 
people who can take you seriously.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28293

Il 07/05/2015 04:03 PM, Thomas 'PointedEars' Lahn ha scritto:

>> In other words... are you aware of conditions that can reasonably cause
>> createElement() to fail [if implemented]?
>
> Good question.  Yes, this is a factory method; instantiation of an object
> can fail for various reasons.
>
> However, it should be noted that none of W3C DOM Core Level 1, W3C DOM Level
> 2 Core, W3C DOM Level 3 Core, W3C HTML5, and WHATWG HTML fully specifies
> what should happen in this case.  HTML5/WHATWG HTML only implicitly
> specifies that an interface for an unknown element type should be used if
> the element type name is unsupported, which is precisely what happens in
> HTML5 browsers [they use HTMLUnknownElement].

Which various reasons??? You are scaring me a bit.
I have some script around relying heavily on createElement, and I'm not 
sure to have implemented a "graceful downgrade" or whatever. 
"document.createElement must work or you can trash your browser" - that 
is the actual state of things [in my scripts].

>>
>> Tried on Firefox 29 on Kernel 2.6.37.6 (Slackware 13.37/64) - best
>
> You should say _Linux_ 2.6.37.6.  There are many kernels.

Oh yes, I played wit DOS, DRDOS, AmigaOs, TOS, Real/32, AROS, Syllable, 
OS/2, Novell 3.12 & 5, and Android and MacOs, and... But the word 
"*Slackware*" clarifies every doubt one can have. It means only one 
thing: LINUX. :-) [Debian, Suse, RedHat too, with the only possible 
exception of the song "Panama Red" from Seldom Scenes, and a sloppy 
neuron fuzzy on RedHat).

>
> Have you also tested each approach 5 times in random order?

No, I'll try, and I have a Kernel 3.something (Ubuntu 12.04) on a test 
machine to tinker with before to put in producton Slackware 14.1 64-bits 
(also a 3.x kernel).
[I'm testing mainly SAMBA with old ISAM databases-a mess]

>
>> And 180 msec vs 100 msec is the overall difference between fastest vs.
>> slowest method.
>
> Even a difference of 80 milliseconds becomes significant if the algorithm
> taking 80 milliseconds longer than another one is repeated.
>

Agreed. You are talking to a man that saves every bit and every cycle 
where/if possible. I started with a 1-Kb "computer", Sinclair ZX-81.
You never really escape from your imprinting :-)

>> [One sidenote: why the hell you insist on real names? Are you immune by
>> spam?]
>
> Posting using a pseudonym does not affect the amount of spam one is getting.
> How did you get that idea?  Spam is sent to mailboxes referenced by *e-mail
> addresses*; not to specific people.  To use an analogy: if you remove your
> name from your real-life mailbox, or put a false name on it, that does not
> change the location of your home.
>

[OT - but not so much] ?! I think I could easily write a bot that reads 
addresses from the newsgroups, less easily to write one that elaborates 
the fake addresses (apart the "at" trick). Please [if you have time] 
elaborate.

[Edit] A doubt: are you referring to "DanCa" or to the fake mail 
address? What's wrong with nicknames? Sorry if it's a silly question but 
I have no problem at all to put my name, surname, face and Fiscal Code 
Number, if needed. From the Eighties anyway I use nicknames and it has 
always been just "normal" to do it this way.

> There is no good reason to believe that posting with a real name increases
> the amount of spam one is getting.  It does increase, however, the amount of
> people who can take you seriously.
>
:-) YOU are taking me seriously, anyway [this time] [it seems]. This 
contradicts your last sentence! [joking]

Dan

[toc] | [prev] | [next] | [standalone]

#28300

danca wrote:

> Il 07/05/2015 04:03 PM, Thomas 'PointedEars' Lahn ha scritto:
>>> In other words... are you aware of conditions that can reasonably cause
>>> createElement() to fail [if implemented]?
>>
>> Good question.  Yes, this is a factory method; instantiation of an object
>> can fail for various reasons.
>>
>> However, it should be noted that none of W3C DOM Core Level 1, W3C DOM
>> Level 2 Core, W3C DOM Level 3 Core, W3C HTML5, and WHATWG HTML fully
>> specifies what should happen in this case.  HTML5/WHATWG HTML only 
>> implicitly specifies that an interface for an unknown element type should 
>> be used if the element type name is unsupported, which is precisely what 
>> happens in HTML5 browsers [they use HTMLUnknownElement].
> 
> Which various reasons??? You are scaring me a bit.

(Cast out fear.)  For a start, the instantiation of an object requires the 
allocation of free memory to store that object’s data.  Free memory is 
limited in a computer system.

> I have some script around relying heavily on createElement, and I'm not
> sure to have implemented a "graceful downgrade" or whatever.
> "document.createElement must work or you can trash your browser" - that
> is the actual state of things [in my scripts].

I think you know what to do now.

>>> Tried on Firefox 29 on Kernel 2.6.37.6 (Slackware 13.37/64) - best
>> You should say _Linux_ 2.6.37.6.  There are many kernels.
> 
> Oh yes, I played wit DOS, DRDOS, AmigaOs, TOS, Real/32, AROS, Syllable,
> OS/2, Novell 3.12 & 5, and Android and MacOs, and... But the word
> "*Slackware*" clarifies every doubt one can have. It means only one
> thing: LINUX. :-)

“Linux” is _not_ an acronym.

> [Debian, Suse, RedHat too, with the only possible
> exception of the song "Panama Red" from Seldom Scenes, and a sloppy
> neuron fuzzy on RedHat).

While it may be possible that you cannot run Slackware on anything but 
Linux, you (still) can run at least Debian, Gentoo and Arch on GNU Hurd 
(that is not a recommendation).

>>> [One sidenote: why the hell you insist on real names? Are you immune by
>>> spam?]
>>
>> Posting using a pseudonym does not affect the amount of spam one is
>> getting.  How did you get that idea?  Spam is sent to mailboxes 
>> referenced by *e-mail addresses*; not to specific people.  To use an 
>> analogy: if you remove your name from your real-life mailbox, or put a 
>> false name on it, that does not change the location of your home.
> 
> [OT - but not so much] ?! I think I could easily write a bot that reads
> addresses from the newsgroups, less easily to write one that elaborates
> the fake addresses (apart the "at" trick). Please [if you have time]
> elaborate.

E-mail addresses have nothing to do with names.  That they had is a common 
misconception.  Spamming is successfully done because it is computationally 
and financially inexpensive for the spammer; a profit is to be made from it.  
If a spammer would consider all possibilities of mappings of names to e-mail 
addresses, spamming would not be so inexpensive for them, and it might not 
even be profitable, anymore.
 
> [Edit] A doubt: are you referring to "DanCa"

I have been and I am referring to the part of the “From” header field value 
of your posting that is not the address part.

> or to the fake mail address?

If you are actually using a “fake mail address”, which would actually mean 
that you are *lying* to me (and everyone else) about your e-mail address as 
well (“a mailbox receives mail”, RFC 5322), then consider that string being 
added to my killfile.  I consider address munging blatantly anti-social 
behavior.  It most certainly also violates the Acceptable Use Policy of your 
service provider(s).

<http://www.interhack.net/pubs/munging-harmful/>

> What's wrong with nicknames?

Nothing if you also provide your real name, as do I.

>> There is no good reason to believe that posting with a real name
>> increases the amount of spam one is getting.  It does increase, however,
>> the amount of people who can take you seriously.
>
> :-) YOU are taking me seriously, anyway [this time] [it seems]. […]

That may not continue.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28301

Il 07/06/2015 01:46 AM, Thomas 'PointedEars' Lahn ha scritto:

>>
>> :-) YOU are taking me seriously, anyway [this time] [it seems]. […]
>
> That may not continue.
>
Of course.
Thanks.

-- 
"People should pay taxes with a smile"
I tried, but they want money.

[toc] | [prev] | [next] | [standalone]

#28279

On 2015-07-05 10:22, Thomas 'PointedEars' Lahn wrote:
> danca wrote:
[...]

>> var aDiv=document.createElement('div')
>> aDiv.style.position="fixed"
>
> It is customary and recommended to use whitespace to separate tokens.
> It is recommended to use a consistent quoting style.
> It is customary and recommended to end simple statements with a semicolon.
[...]

Just small note: in order to make a code style consistent any of these 
JSLint / JSHint / ESLint tools can be used to validate the code style. 
Especially using grunt tasks.

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#28266

JiiPee <no@notvalid.com> wrote on 05 Jul 2015 in comp.lang.javascript:
> On 05/07/2015 01:02, JiiPee wrote:
>> I use javascript to first create <p>-text lines inside a div (using 
>> innerHTML). Then after that text I would like to show a table 
>> (<table>). What is the best way to do this? 

"best way" Qs are a bit silly.

>> Should I somehow put a 
>> element (like a div) at the last text place and then check its 
>> position and move the table to that position?

No need for that.

>> Or possible adding just 
>> table to that innerHTML like I did with the text? I know there are 
>> several ways to do this, but how people normally do this? thank you

[please do not toppost]

> Does not need to be an example but just a hint or direction would be 
> enough ... I can search after that.
 
While myDiv.appendChild() is "the" preferred way,

a simple and dirty:

myDiv.innerHTML += "<table>...</table>"

will often do a reasonable job.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#28268

On 05/07/2015 09:38, Evertjan. wrote:
>> w people normally do this? thank you
> [please do not toppost]

ok, but that was only a small portion i posted over, so its not so bad 
(everybody knows what happened there)?? :)

>> Does not need to be an example but just a hint or direction would be
>> enough ... I can search after that.
>   
> While myDiv.appendChild() is "the" preferred way,
>
> a simple and dirty:
>
> myDiv.innerHTML += "<table>...</table>"

ok, but if the table has a lot of stuff is this a lot of work? The other 
poster said not to use innerHTML. I dont know, thats why asked :).

>
> will often do a reasonable job.

ye I know that would do the job but just is there easier way?


>
>

[toc] | [prev] | [next] | [standalone]

#28271

On 05/07/2015 09:38, Evertjan. wrote:
> JiiPee <no@notvalid.com> wrote on 05 Jul 2015 in comp.lang.javascript:
>   
> While myDiv.appendChild() is "the" preferred way,
>
> a simple and dirty:
>
> myDiv.innerHTML += "<table>...</table>"
>
> will often do a reasonable job.

Yes its a bit more simple (although takes a bit efford to add all <tr>, 
<td> and <class> and other things)...I have not done so much js yet, so 
as a programmer this might do the job this time as I would like to it 
quickly (and maybe study the better was next time). Just wanted a 
confirmation what way people normally use.

>
>

[toc] | [prev] | [next] | [standalone]

#28272

JiiPee wrote:

> […] Just wanted a confirmation what way people normally use.

A million flies can’t be wrong?

Get a name and an e-mail address.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#28273

JiiPee <no@notvalid.com> wrote on 05 Jul 2015 in comp.lang.javascript:

> Just wanted a 
> confirmation what way people normally use.

Why?
Do you perhaps want to be considered "normal" yourself?

Btw, "confirmation" usually ["normally"?] is used,
when you provide the proposed way.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web