Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Modify Element Tag Question

94 views
Skip to first unread message

Mel Smith

unread,
May 11, 2012, 3:42:09 PM5/11/12
to
Hi:

In my phone book (of 613 multi-line entries in a table), I am currently
'bolding' the names of the people, and leaving other fields 'unbolded'.

Now, when a user decides to change the sorting order to street address,
I wish to 'unbold' the names, and bold the street addresses.

So, is there a 'placeholder' HTML Element Tag that I can use for all
sortable fields (and later search for) so that the text is displayed
correctly but *unbolded*.

I did a short test, and determined that undefined element tags (e.g.
<nobold>Hi There</nobold>) are (apparently) ignored and the text is
displayed correctly. Does this happen (i.e., underfined element tags are
ignored) across all major browsers ??

Then, when the user changes the sort order, I can 'bold' what needs to
be bolded, and 'unbold' the other fields (in this phone book).

Thanks !

--
Mel Smith


Martin Honnen

unread,
May 12, 2012, 6:00:38 AM5/12/12
to
Mel Smith wrote:

> In my phone book (of 613 multi-line entries in a table), I am currently
> 'bolding' the names of the people, and leaving other fields 'unbolded'.
>
> Now, when a user decides to change the sorting order to street address,
> I wish to 'unbold' the names, and bold the street addresses.
>
> So, is there a 'placeholder' HTML Element Tag that I can use for all
> sortable fields (and later search for) so that the text is displayed
> correctly but *unbolded*.

Define a class with CSS e.g.
td.sorted { font-weight: bold; }
then make sure you manipulate the className for the cells you want to
change e.g.
function changeSortStyle(table, unsortedIndex, sortedIndex) {
for (var i = 0, l = table.rows.length; i < l; i++) {
table.rows[i].cells[unsortedIndex].className = '';
table.rows[i].cells[sortedIndex].className = 'sorted';
}
}



--

Martin Honnen --- MVP Data Platform Development
http://msmvps.com/blogs/martin_honnen/

Thomas 'PointedEars' Lahn

unread,
May 12, 2012, 9:02:40 AM5/12/12
to
However, it is a lot more efficient to give each column (or element, in
general) a class corresponding to its content in advance, and just change
the corresponding style rule.

Finding that rule only has to be done once and is most beautifully done in
conforming implementations of ECMAScript, 5.1 Edition (or emulations
thereof):

/* See also <http://PointedEars.de/scripts/dom/css.js> */

var findRules = (function () {
var _slice = Array.prototype.slice;
var a = [];
var _concat = Array.prototype.concat;

function toArray (obj)
{
return _slice.call(obj || a);
}

return function (selector, exactMatch) {
var prefix = "(^|\\s)";
if (exactMatch)
{
prefix = "^\\s*";
}

var rxSelector = new RegExp(
prefix + selector.replace(/[$.(){}\[\]^]/g, "\\$&") + "\\s*$");

var hits = toArray(document.styleSheets).map(
function (styleSheet) {
return toArray(styleSheet.cssRules || styleSheet.rules).filter(
function (rule) {
return rxSelector.test(rule.selectorText);
});
}).filter(function (hit) {
return hit.length > 0;
});

return _concat.apply([], hits);
};
}());

var rulesets = Object.create(null);

if (!rulesets["people"])
{
rulesets["people"] = findRules(".people", true);
}

var rules = rulesets["people"];
if (rules.length > 0)
{
rules[rules.length - 1].style.fontWeight = "normal";
}


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).

John G Harris

unread,
May 12, 2012, 11:15:01 AM5/12/12
to
On Sat, 12 May 2012 at 15:02:40, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:

<snip>
>Finding that rule only has to be done once and is most beautifully done in
>conforming implementations of ECMAScript, 5.1 Edition (or emulations
>thereof):
<snip>

Surely an emulation of a conforming implementation will itself be a
conforming implementation.

What subtle distinction were you trying to make?

John
--
John Harris

Mel Smith

unread,
May 12, 2012, 4:32:09 PM5/12/12
to
Martin, Thomas and John:

Thank you all for the tips/suggestions.

I'll study them thoroughly.

-Mel Smith


Dr J R Stockton

unread,
May 12, 2012, 2:29:59 PM5/12/12
to
In comp.lang.javascript message <a158cj...@mid.individual.net>, Fri,
11 May 2012 13:42:09, Mel Smith <med_cuto...@aol.com> posted:
Ersatz tags will annoy a validator. Why not use <SPAN> ? Or use a
class on the TD elements, and toggle it between one meaning bold and one
not meaning anything?

OTOH, would <COL> serve? For me, it does not alter the font; but the
tested (FF 12) following, which alters the background, may serve.
<table border=1>
<col><col style="background:cyan"><col>
<tr><td>1<td>2<td>3</tr>
<tr><td>4<td>5<td>6</tr>
<tr><td>7<td>8<td>9</tr>
</table>
To change columns, one needs only alter two entries in the DOM tree,
which should be possible.

You could class every element in the table with "X" + its row column
number, and alter the classes as needed.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and 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.

Mel Smith

unread,
May 12, 2012, 8:08:30 PM5/12/12
to
Dr John said:
>
> Ersatz tags will annoy a validator. Why not use <SPAN> ? Or use a
> class on the TD elements, and toggle it between one meaning bold and one
> not meaning anything?
>
> OTOH, would <COL> serve? For me, it does not alter the font; but the
> tested (FF 12) following, which alters the background, may serve.
> <table border=1>
> <col><col style="background:cyan"><col>
> <tr><td>1<td>2<td>3</tr>
> <tr><td>4<td>5<td>6</tr>
> <tr><td>7<td>8<td>9</tr>
> </table>
> To change columns, one needs only alter two entries in the DOM tree,
> which should be possible.
>
> You could class every element in the table with "X" + its row column
> number, and alter the classes as needed.
>


Dr John (and the others):

My phone book has two visible columns. Each column has 307 cells. Each
cell has 3 rows

Each of the rows contains 5 <td> elements for each of the visible
columns.

When the user 'clicks' a sorting button (for Name, for street address,
or for Lot No.), then the following javascript function is called:

It is this next function that I would like to add (bolding/unbolding)
code to

Denis McMahon is the original designer of this fone book. (and I made
several mods over the last year)

Thanks,

-Mel Smith

******************** one of the fone book table functions below

// build the table from the sorted data
function rebuildTable() {
var theTable, theCells, i, r, baseRow;
theTable = document.getElementById("theTable");
for (i = 0; i < allData.length; i = i + 2) {
baseRow = 2 + (4 * (i / 2)); // first 2 rows are header & spacer, then 4
rows for each 2 data records
// left side data is allData[i];
// right side data is allData[i+1];
for (r = 0; r < 3; r = r + 1) { // don't worry about spacer rows, just
do data rows 0, 1, 2
theCells = theTable.rows[baseRow + r].cells;
if (r === 0) {
theCells[0].innerHTML = allData[i].memName; // would like to test
'unbolding' here when address below is bolded
theCells[1].innerHTML = allData[i].editButt;
theCells[3].innerHTML = allData[i + 1].memName;
theCells[4].innerHTML = allData[i + 1].editButt;
} else if (r === 1) {
theCells[0].innerHTML = "<b>"+allData[i].localAddr+"</b>"; //
testing bolding here
theCells[1].innerHTML = allData[i].lotNum;
theCells[2].innerHTML = allData[i].localTel;
theCells[4].innerHTML = "<b>"+allData[i + 1].localAddr+"</b>";
theCells[5].innerHTML = allData[i + 1].lotNum;
theCells[6].innerHTML = allData[i + 1].localTel;
} else if (r === 2) {
theCells[0].innerHTML = allData[i].otherAddr;
theCells[1].innerHTML = allData[i].otherTel;
theCells[3].innerHTML = allData[i + 1].otherAddr;
theCells[4].innerHTML = allData[i + 1].otherTel;
}
}
}
}


Denis McMahon

unread,
May 12, 2012, 10:59:58 PM5/12/12
to
On Fri, 11 May 2012 13:42:09 -0600, Mel Smith wrote:

> In my phone book (of 613 multi-line entries in a table)

That sounds familiar ....

>, I am
> currently
> 'bolding' the names of the people, and leaving other fields 'unbolded'.

> Now, when a user decides to change the sorting order to street
> address,
> I wish to 'unbold' the names, and bold the street addresses.

Hmm

The way I think I would do it, assuming that each row has a series of td
elements ....

To the td elements that contain names, I would add 'class="name"', and to
the td elements that hold addresses, I would add 'class="addr"'

Then, as an appendage to the sort routines, call something like boldCells
as shown below with either "name" or "addr" (it can be expanded to other
fields if needed):

function boldCells( embolden ) {
var cells = document.getElementsByTagName( "td" );
var ix = cells.length;
var cell, class;
while ( ix-- ) {
cell = cells.item( ix );
class = cell.attributes.getNamedItem( "class" );
if ( class.indexOf( "name" ) != -1 ) {
if ( embolden == "name" )
cell.style.fontWeight = "bold";
else
cell.style.fontWeight = "normal";
}
else if ( class.indexOf( "addr" ) != -1 ) {
if ( embolden == "addr" )
cell.style.fontWeight = "bold";
else
cell.style.fontWeight = "normal";
}
}

Note - code is untested!

Basically, boldCells will look at all the td cells in the document for
any with one of the defined class attributes, and apply either bold or
normal font-weight to each of the matching cells depending on whether the
cell's actual class matches the one passed to the boldCells function.
Cells which don't match any of the defined cell classes won't be affected
at all, so if they are bold they will stay bold, and if they are not bold
they will remain not bold.

Rgds

Denis McMahon

Evertjan.

unread,
May 13, 2012, 4:11:58 AM5/13/12
to
Mel Smith wrote on 13 mei 2012 in comp.lang.javascript:

> My phone book has two visible columns. Each column has 307 cells. Each
> cell has 3 rows
>
> Each of the rows contains 5 <td> elements for each of the visible
> columns.


This is not a table in the html sense.
A html-table has the cell as the smallest element.
So you are probably using tables inside tables.

I would put all data in a database and build the differently sorted
phonebook from scratch after each sort-request.

=======

Serverside?

Preferably I would do this serverside, as serverside there are much more
elaborate options of database sorting, and either renew the html-page on
every sort-request, or get the content with an Ajax call.

=======

Clientside?

However you could do all this with clientside javascript using objects
and/or arrays as a database, and rebuilding the table-system with
javascript DOM-functions.
Even then index-arrays for the different sort-options could be prepared
serverside, if the phonebook is clientside-static.

=======

table1.style.display = 'none';
table2.style.display = 'block';

If you have only 2 sort-options you could build 2 table-systems of which
only one is displayed at a time, switchable with an onclick in the table
header. Diffferent bolding and colouring of columns is even simpler then.



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

Martin Honnen

unread,
May 13, 2012, 5:25:09 AM5/13/12
to
Dr J R Stockton wrote:

> OTOH, would<COL> serve? For me, it does not alter the font; but the
> tested (FF 12) following, which alters the background, may serve.
> <table border=1>
> <col><col style="background:cyan"><col>

The CSS properties to apply on 'col' elements are restricted to border,
background, width and visibility
(http://www.w3.org/TR/CSS21/tables.html#columns).

Thomas 'PointedEars' Lahn

unread,
May 13, 2012, 9:50:16 AM5/13/12
to
Denis McMahon wrote:

> On Fri, 11 May 2012 13:42:09 -0600, Mel Smith wrote:
>> In my phone book (of 613 multi-line entries in a table)
>>, I am
>> currently
>> 'bolding' the names of the people, and leaving other fields 'unbolded'.
>>
>> Now, when a user decides to change the sorting order to street
>> address,
>> I wish to 'unbold' the names, and bold the street addresses.
>
> Hmm

If only you would stop right there, posterity would be saved a lot of
precious bandwidth that they are going to need desperately.

> The way I think I would do it, assuming that each row has a series of td
> elements ....
>
> To the td elements that contain names, I would add 'class="name"', and to
> the td elements that hold addresses, I would add 'class="addr"'

So much, so good.

> Then, as an appendage to the sort routines, call something like boldCells
> as shown below with either "name" or "addr" (it can be expanded to other
> fields if needed):

How do you manage coming up so easily with the worst "solutions" possible?
Did V'Often Wrong'K teach you?

> function boldCells( embolden ) {
> var cells = document.getElementsByTagName( "td" );

That inefficient, error-prone method call is unnecessary. HTMLTableElement
objects have a `rows' property, and HTMLTableRowElement objects have a
`cells' property, that hold a reference to a NodeList of references to
HTMLTableRowElement objects and HTMLTableCellElement objects, respectively.

> var ix = cells.length;
> var cell, class;

`class' is a future reserved word; it cannot be the name of a variable as
that must be an *identifier* (see the ECMAScript Language Specification, 5.1
Edition, section 7.5.3, but also about any JS tutorial out there, for any
common meaning of "JS" being a programming language).

As result, this code does not compile, and does not run. For example, in
Chromium 18.x:

| > var class = 42;
| SyntaxError: Unexpected reserved word

> while ( ix-- ) {
> cell = cells.item( ix );

This rather expensive and potentially incompatible call of the `item' method
of the `cells' NodeList object is not necessary, you can simply write

cells[ix]

instead.

<http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>

> class = cell.attributes.getNamedItem( "class" );

OMG. As regulars will know, an HTMLElement object has a `className'
property. A simple

cell.className

does it all, and is a lot more compatible than your bloatcode (even the
equally bloated and equally wrong cell.getAttribute("class") is more
efficient than that).

<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>

> if ( class.indexOf( "name" ) != -1 ) {

This is insufficient to determine if the attribute value contains a certain
class name, because it will result in false positives if a class name is,
for example, "foonamebar". (Besides, the index of a substring can never be
negative, so you should lose the loose comparison and use `> -1' instead.)

We have already discussed here ad nauseam how to determine efficiently and
reliably if a CSS class name is in a `class' attribute value. For those who
have not been paying attention, or are new here, the consensus reached in
those discussions was:

if (/(^|\s)name(\s|$)/.test(cell.className))
{

}

[`\b' as delimiter does not suffice, because (CSS) class names may contain
non-ASCII characters, which are considered non-word characters. `\s' should
suffice but does not match HTML's white-space definition exactly in all
implementations; so a custom character class might be used instead.]

<http://www.w3.org/TR/1999/REC-html401-19991224/struct/
global.html#adef-class>

> if ( embolden == "name" )
> cell.style.fontWeight = "bold";
> else
> cell.style.fontWeight = "normal";
> }
> else if ( class.indexOf( "addr" ) != -1 ) {
> if ( embolden == "addr" )
> cell.style.fontWeight = "bold";
> else
> cell.style.fontWeight = "normal";
> }

Or you could simply switch the class name.

foo.className = "bold";

> }
>
> Note - code is untested!

… and written cluelessly, like everything else coming from you before.
Not just in this newsgroup.


PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>

Mel Smith

unread,
May 13, 2012, 10:56:49 AM5/13/12
to
Hi:

To add more fuel to the fire, here are two rows of fone book entries.

I have obscured information by changing some onfo, but this is out of
the current phone book.

(Anyway, will look more over the suggestions and flames above, and
decide what to do.)

Thanks to all !

-Mel Smith


******************************************************
<tr>
<td colspan="2"><b>Smith, Donny&amp; Chad</b></td>
<td align="right">&nbsp;<!-- EDIT 182 --></td>
<td class="spacer"></td>
<td colspan="2"><b>Smith, Melvin &amp; Harriett</b></td>
<td align="right">&nbsp;<!-- EDIT 318 --></td>
</tr>
<tr>
<td>7444 E. Baltic Cir.</td>
<td>Lot : 432</td>
<td align="right">485-699-4567</td>
<td class="spacer"></td>
<td>7214 E. Baywood Ave.</td>
<td>Lot : 310</td>
<td align="right">480-877-1404</td>
</tr>
<tr>
<td colspan="2">10904 Steamer Lane NW #2, Walker, MA 56564</td>
<td align="right">321-231-3665</td>
<td class="spacer"></td>
<td colspan="2">68 Alpine Blvd., St. Albert, MB., Canada T8N 2M7</td>
<td align="right">781-456-1234</td>
</tr>
<tr>
<td colspan="7" class="spacer"><hr /></td>
</tr>
<tr>
<td colspan="2"><b>Smith, Mickey &amp; Shanna Ann</b></td>
<td align="right">&nbsp;<!-- EDIT 534 --></td>
<td class="spacer"></td>
<td colspan="2"><b>Smith, Michael &amp; Sarah</b></td>
<td align="right">&nbsp;<!-- EDIT 101 --></td>
</tr>
<tr>
<td>7267 E. Azara Ave.</td>
<td>Lot : 572</td>
<td align="right">316-345-3456</td>
<td class="spacer"></td>
<td>345 S. 78th Way</td>
<td>Lot : 102</td>
<td align="right">485-276-3456</td>
</tr>
<tr>
<td colspan="2">Box 1321 Moose Ass, MB Canada T5J-4S1</td>
<td align="right">316-694-2714</td>
<td class="spacer"></td>
<td colspan="2">&nbsp;</td>
<td align="right">&nbsp;</td>
</tr>
<tr>
<td colspan="7" class="spacer"><hr /></td>
</tr>



Mel Smith

unread,
May 13, 2012, 11:00:01 AM5/13/12
to
Hi Denis:

Will look carefully at the suggestions above, and test the
implementation.

btw, your design has worked flawlessly over the past year, and the
residents of my Senior's Park, and the office lady really appreciate your
work.

Thanks you very much !

-Mel Smith


Mel Smith

unread,
May 14, 2012, 10:45:58 AM5/14/12
to
Hi All:

Using Denis McMahon's code (in an earlier post) and with some minor mods
suggested by Thomas Lahn following that post, I am able to bold/unbold the
sorting field in my fone book.

The time taken for the bold/unbold function to operate seems buried in
the approx 4 seconds to do the sorting operation on my Pentium 5 machine,
and so will be inconsequential to my user

Thanks for all the suggestions and help !

-Mel Smith



Dr J R Stockton

unread,
May 14, 2012, 3:01:47 PM5/14/12
to
In comp.lang.javascript message <1402505.A...@PointedEars.de>,
Sun, 13 May 2012 15:50:16, Thomas 'PointedEars' Lahn
<Point...@web.de> posted:

>… and written cluelessly, like everything else coming from you before.
>Not just in this newsgroup.

Cluelessness is remediable. Boorishness is not. Ave Angela!

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05.
Website <http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc. : <http://www.merlyn.demon.co.uk/programs/> - see in 00index.htm
Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.

Dr J R Stockton

unread,
May 14, 2012, 3:19:57 PM5/14/12
to
In comp.lang.javascript message <4faf7df5$0$6639$9b4e...@newsspool2.arc
or-online.net>, Sun, 13 May 2012 11:25:09, Martin Honnen
<maho...@yahoo.de> posted:

>Dr J R Stockton wrote:
>
>> OTOH, would<COL> serve? For me, it does not alter the font; but the
>> tested (FF 12) following, which alters the background, may serve.
>> <table border=1>
>> <col><col style="background:cyan"><col>
>
>The CSS properties to apply on 'col' elements are restricted to border,
>background, width and visibility (http://www.w3.org/TR/CSS21/tables.htm
>l#columns).


That explains why it does not work; but it seems a strange decision to
restrict the choices so. In particular, if the background colour is
changed, it ought to be possible to change the foreground (text) colour.

--

Scott Sauyet

unread,
May 14, 2012, 7:31:24 PM5/14/12
to
Mel Smith wrote:

>     Using Denis McMahon's code (in an earlier post) and with some minor mods
> suggested by Thomas Lahn following that post, I am able to bold/unbold the
> sorting field in my fone book.

Glad to hear it. Is your result publicly available?

>     The time taken for the bold/unbold function to operate seems buried in
> the approx 4 seconds to do the sorting operation on my Pentium 5 machine,
> and so will be inconsequential to my user

With 613 entries, it's very unlikely that an actual sort would take
very long at all. 4 seconds to sort and redisplay seems excessive. I
think that likely has to do with your repeated calls to change the
DOM:


| theCells[0].innerHTML = allData[i].memName;
| theCells[1].innerHTML = allData[i].editButt;
| theCells[3].innerHTML = allData[i + 1].memName;
| theCells[4].innerHTML = allData[i + 1].editButt;

-- from <a18cc2...@mid.individual.net>
also found at http://groups.google.com/group/comp.lang.javascript/msg/9023984143f368ed

If you were to find a way to group all your DOM-related changes, you
might not have that sort of slow speed.

-- Scott

Mel Smith

unread,
May 15, 2012, 11:03:06 AM5/15/12
to
Scott said:
> Using Denis McMahon's code (in an earlier post) and with some minor mods
> suggested by Thomas Lahn following that post, I am able to bold/unbold the
> sorting field in my fone book.

Glad to hear it. Is your result publicly available?

Scott:

I have sent to your email address (...@gmail.com) the latest fone book
page for your perusal.

You should be able to test it at your location.

Thanks for your interest.

--
Mel Smith


Dr J R Stockton

unread,
May 15, 2012, 3:04:21 PM5/15/12
to
In comp.lang.javascript message <a1ck5a...@mid.individual.net>, Mon,
14 May 2012 08:45:58, Mel Smith <med_cuto...@aol.com> posted:

> The time taken for the bold/unbold function to operate seems buried in
>the approx 4 seconds to do the sorting operation on my Pentium 5 machine,
>and so will be inconsequential to my user

Four seconds is quite a long time to sort 613 entries; in my P4/3G, FF12
JavaScript can generate and sort a million random numbers in about 3.5
seconds. And Batch sort seems to do 800 lines in a time verging on the
imperceptible.

You might like to consider whether you are using bubblesort, and if so
look for something quicker. Try duplicating your data to 1226 entries;
of the sort now takes sixteen seconds, it's unnecessarily slow.
Otherwise, are you repeatedly swapping relatively large items? If so,
you might do better by sorting an array of index to item, in which the
indexes only are swapped.

--
(c) John Stockton, nr London UK ?@merlyn.demon.co.uk IE8 FF8 Op11 Sf5 Cr15
news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
<http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Mel Smith

unread,
May 16, 2012, 12:19:14 AM5/16/12
to
Dr. J said
> Four seconds is quite a long time to sort 613 entries; in my P4/3G, FF12
> JavaScript can generate and sort a million random numbers in about 3.5
> seconds. And Batch sort seems to do 800 lines in a time verging on the
> imperceptible.
>
> You might like to consider whether you are using bubblesort, and if so
> look for something quicker. Try duplicating your data to 1226 entries;
> of the sort now takes sixteen seconds, it's unnecessarily slow.
> Otherwise, are you repeatedly swapping relatively large items? If so,
> you might do better by sorting an array of index to item, in which the
> indexes only are swapped.


Dr. J:

Scott Sauyet said this morning that running *my* page on *his* machine
took less than a second ????

I'll look into why *my* clicking on one of the Sort buttons took nearly
4 secs to complete the sort, and then bold the new sort key. Hmmmm ...

(btw, I use Win XP Pro (sp3), and Pentium 5 , 1.80 GHz with 1.99 GB of
RAM ).

-Mel Smith


Dr J R Stockton

unread,
May 17, 2012, 2:13:10 PM5/17/12
to
In comp.lang.javascript message <a1go68...@mid.individual.net>, Tue,
15 May 2012 22:19:14, Mel Smith <med_cuto...@aol.com> posted:

>
> Scott Sauyet said this morning that running *my* page on *his* machine
>took less than a second ????
>
> I'll look into why *my* clicking on one of the Sort buttons took nearly
>4 secs to complete the sort, and then bold the new sort key. Hmmmm ...

If you've not yet succeeded, post the sort algorithm, and the structure
of the elements which it sorts, and the comparison function.

But I don't recall what browsers you and Scott Sauyet are using. That
can make a very considerable difference.

--

Scott Sauyet

unread,
May 17, 2012, 9:48:05 PM5/17/12
to
Dr J R Stockton wrote:
> Mel Smith wrote:

>>    Scott Sauyet said this morning that running *my* page on *his* machine
>>took less than a second ????
>
>> I'll look into why *my* clicking on one of the Sort buttons took nearly
>> 4 secs to complete the sort, and then bold the new sort key. Hmmmm ...

AISB, the biggest issue is almost certainly the way the content is
loaded one bit a time back into the table.

I tested the page Mel emailed me on my WinXP machine (dual 2.5 GHz
processors, 3GB RAM) on recent versions of Chrome, Firefox, Safari,
and Opera, as well as IE8, IE6, and IE5.01. On IE6 and IE8, the sort/
rebuild process took about 1.5 seconds. On all the others, it was
well below half a second.

I didn't bother loading up my Linux partition; it's generally just a
little faster than the Windows one at tasks like this.

> If you've not yet succeeded, post the sort algorithm, and the structure
> of the elements which it sorts, and the comparison function.

The page Mel supplied included a fair bit of sensitive customer data,
which, I assume is why he hasn't posted simpler versions anywhere.
But there is nothing sensitive about the sorting routines, and they
are simple and appropriate:


function cmpNameAsc(x, y) {
if (x.mem === y.mem) return 0;
return (x.mem > y.mem) ? 1 : -1;
}

// ... elsewhere ...

allData.sort(cmpNameAsc);

The members of the array `allData` are fairly simple objects created
from a constructor function. Their fields are scraped at startup from
a fairly large table. But the actual sort is a standard array sort.
I've never looked, but I assume that the standard sort is either a
mergesort or a quicksort. In either case, the sort is almost
certainly not the culprit.

But after that sort, the table is updated by individually setting the
innerHTML on each cell. I'm guessing that most of the time Mel is
seeing is in that process.


> But I don't recall what browsers you and Scott Sauyet are using.  That
> can make a very considerable difference.

I can't imagine what's causing the difference unless it's simply the
raw power of the machines.

-- Scott

Mel Smith

unread,
May 18, 2012, 3:14:45 PM5/18/12
to
Scott said:

AISB, the biggest issue is almost certainly the way the content is
loaded one bit a time back into the table.

I tested the page Mel emailed me on my WinXP machine (dual 2.5 GHz
processors, 3GB RAM) on recent versions of Chrome, Firefox, Safari,
and Opera, as well as IE8, IE6, and IE5.01. On IE6 and IE8, the sort/
rebuild process took about 1.5 seconds. On all the others, it was
well below half a second.

I (Mel) tested on my IE7 browser, and *my error*: my time was approx
*2.5 seconds* (Not 4 secs) from: Clivking the 'Sort' Button thru the
following sequences:

a. Unbolding the 'previous' bolded fields
b. Sorting the data fields on the new sort key
c. Rebuilding the table
d. Bolding the new bold sort fields
e. Informing the user of the new Sort Field


I didn't bother loading up my Linux partition; it's generally just a
little faster than the Windows one at tasks like this.

> If you've not yet succeeded, post the sort algorithm, and the structure
> of the elements which it sorts, and the comparison function.

Dr J:
Yes, it works fine now !


The page Mel supplied included a fair bit of sensitive customer data,
which, I assume is why he hasn't posted simpler versions anywhere.
But there is nothing sensitive about the sorting routines, and they
are simple and appropriate:

Scott:
Yes, because I have personal info on 613 residences, I feel obliged to
restrict access to the internal data


function cmpNameAsc(x, y) {
if (x.mem === y.mem) return 0;
return (x.mem > y.mem) ? 1 : -1;
}

// ... elsewhere ...

allData.sort(cmpNameAsc);

The members of the array `allData` are fairly simple objects created
from a constructor function. Their fields are scraped at startup from
a fairly large table. But the actual sort is a standard array sort.
I've never looked, but I assume that the standard sort is either a
mergesort or a quicksort. In either case, the sort is almost
certainly not the culprit.

But after that sort, the table is updated by individually setting the
innerHTML on each cell. I'm guessing that most of the time Mel is
seeing is in that process.


> But I don't recall what browsers you and Scott Sauyet are using. That
> can make a very considerable difference.


I can't imagine what's causing the difference unless it's simply the
raw power of the machines.


Scott:

Did another test:
Chrome 19.0.1084.46 took less than a second !
FireFox 12.0 took approx 1.5 seconds.
IE7 took approx 2 seconds

Sorry to have led you astray.

--Mel



Dr J R Stockton

unread,
May 19, 2012, 3:47:12 PM5/19/12
to
In comp.lang.javascript message <60e864d1-ef34-4b1d-924e-5a8ec62c849a@3g
2000vbx.googlegroups.com>, Thu, 17 May 2012 18:48:05, Scott Sauyet
<scott....@gmail.com> posted:

>The page Mel supplied included a fair bit of sensitive customer data,
>which, I assume is why he hasn't posted simpler versions anywhere.
>But there is nothing sensitive about the sorting routines, and they
>are simple and appropriate:
>
> function cmpNameAsc(x, y) {
> if (x.mem === y.mem) return 0;
> return (x.mem > y.mem) ? 1 : -1;
> }

I think, supported by very brief testing, that it would be better to do
a > test and return +1, else do a < test and return -1; else return 0.
That is on the assumption that equality is rare.

The code shown will almost half of the time do one comparison, whereas
comparing first with 0 will almost always do two comparisons.

The difference made to the overall time will be small but possibly
measurable; and it may be browser-dependent.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike 6.05 WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

Evertjan.

unread,
May 20, 2012, 4:31:04 AM5/20/12
to
Dr J R Stockton wrote on 19 mei 2012 in comp.lang.javascript:

> In comp.lang.javascript message
> <60e864d1-ef34-4b1d-924e-5a8ec62c849a@3g 2000vbx.googlegroups.com>,
> Thu, 17 May 2012 18:48:05, Scott Sauyet <scott....@gmail.com>
> posted:
>
>>The page Mel supplied included a fair bit of sensitive customer data,
>>which, I assume is why he hasn't posted simpler versions anywhere.
>>But there is nothing sensitive about the sorting routines, and they
>>are simple and appropriate:
>>
>> function cmpNameAsc(x, y) {
>> if (x.mem === y.mem) return 0;
>> return (x.mem > y.mem) ? 1 : -1;
>> }

No reason for prohibiting typeconversion with ===,
or is this a speed issue?

if the === false and the == is true,
you would end up with returning -1,
not so useful.

> I think, supported by very brief testing, that it would be better to
> do
>a > test and return +1, else do a < test and return -1; else return 0.
> That is on the assumption that equality is rare.
>
> The code shown will almost half of the time do one comparison, whereas
> comparing first with 0 will almost always do two comparisons.
>
> The difference made to the overall time will be small but possibly
> measurable; and it may be browser-dependent.


function cmpNameAsc(x, y) {
return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
};

This way it looks nicer to me,
would it be even faster?

Mel Smith

unread,
May 20, 2012, 8:25:22 PM5/20/12
to
Evertjan said:

>
> function cmpNameAsc(x, y) {
> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
> };
>
> This way it looks nicer to me,
> would it be even faster?

I'll give it a try tomorrow.

Thank you.

-Mel Smith


Evertjan.

unread,
May 21, 2012, 12:06:30 PM5/21/12
to
Mel Smith wrote on 21 mei 2012 in comp.lang.javascript:

> Evertjan said:
>
>>
>> function cmpNameAsc(x, y) {
>> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
>> };
>>
>> This way it looks nicer to me,
>> would it be even faster?
>
> I'll give it a try tomorrow.

missed a "?", try:


return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;

Mel Smith

unread,
May 21, 2012, 3:24:14 PM5/21/12
to
Evertjan said:
>>> function cmpNameAsc(x, y) {
>>> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
>>> };
>>>
>>> This way it looks nicer to me,
>>> would it be even faster?
>>
>> I'll give it a try tomorrow.
>
> missed a "?", try:
>
>
> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;
>


Hi Evertjan:

Yes, I tried it last nite and it didn't work, so I didn't fiddle with
it. Will try it again later.

Thanks,

-Mel


Mel Smith

unread,
May 21, 2012, 3:34:27 PM5/21/12
to
Evertjan said:

>> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;
>>
>
>

Evertjan:

Using the corrected version above, it seems that the speed is about the
same -- maybe a tad slower ? (just an eyeball test though), and my *real*
user is active now in Arizona, so I'd better wait for the evening to try it
again.

Thanks,

-Mel Smith


Scott Sauyet

unread,
May 21, 2012, 4:09:39 PM5/21/12
to
Mel Smith wrote:
> Evertjan said:
>
>>> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) ? -1 : 0;
> Using the corrected version above, it seems that the speed is about the
> same -- maybe a tad slower ? (just an eyeball test though), and my *real*
> user is active now in Arizona, so I'd better wait for the evening to try it
> again.

That would be a micro-optimization. It might be worth doing. But
it's not likely to significantly change any of your speed.

I did a JSPerf test, and the results of three tests each on these four
browsers of sorting arrays of 1000 random numbers were (in operations
per second, so higher is better):

Android 2.3.4: equals first: 114, equals last: 121
Chrome 19.0: equals first: 2259, equals last: 2370
Firefox 10.0: equals first: 3191, equals last: 3410
IE 8.0: equals first: 131, equals last: 131

<http://jsperf.com/sort-test-order>

There's up to a 7% difference; it's probably a good idea in general to
choose the faster version. But it almost certainly won't be
noticeable for your case.

-- Scott

Dr J R Stockton

unread,
May 21, 2012, 3:33:11 PM5/21/12
to
In comp.lang.javascript message <XnsA0596AFC...@194.109.133.133>
, Sun, 20 May 2012 08:31:04, Evertjan. <exjxw.ha...@interxnl.net>
posted:

>Dr J R Stockton wrote on 19 mei 2012 in comp.lang.javascript:
>
>> In comp.lang.javascript message
>> <60e864d1-ef34-4b1d-924e-5a8ec62c849a@3g 2000vbx.googlegroups.com>,
>> Thu, 17 May 2012 18:48:05, Scott Sauyet <scott....@gmail.com>
>> posted:
>>
>>>The page Mel supplied included a fair bit of sensitive customer data,
>>>which, I assume is why he hasn't posted simpler versions anywhere.
>>>But there is nothing sensitive about the sorting routines, and they
>>>are simple and appropriate:
>>>
>>> function cmpNameAsc(x, y) {
>>> if (x.mem === y.mem) return 0;
>>> return (x.mem > y.mem) ? 1 : -1;
>>> }
>
>No reason for prohibiting typeconversion with ===,
>or is this a speed issue?
>
>if the === false and the == is true,
>you would end up with returning -1,
>not so useful.

In using a sort routine for a comparison function, it seems to me rather
probable that the two arguments will be of the same type. One could of
course construct an artificial counter-example.


>> I think, supported by very brief testing, that it would be better to
>> do
>>a > test and return +1, else do a < test and return -1; else return 0.
>> That is on the assumption that equality is rare.
>>
>> The code shown will almost half of the time do one comparison, whereas
>> comparing first with 0 will almost always do two comparisons.
>>
>> The difference made to the overall time will be small but possibly
>> measurable; and it may be browser-dependent.
>
>
>function cmpNameAsc(x, y) {
> return (x.mem > y.mem) ? 1 : (x.mem < y.mem) -1 : 0;
>};
>
>This way it looks nicer to me,
>would it be even faster?

No. At least, not in FF12, in a crude test. But the OP should try that
properly.

--
0 new messages