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

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

Changing letters in boxes

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

Contents

  Changing letters in boxes fulio pen <fuliopen@yahoo.com> - 2011-10-30 05:26 -0700
    Re: Changing letters in boxes "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-10-30 15:08 +0200
      Re: Changing letters in boxes fulio pen <fuliopen@yahoo.com> - 2011-10-30 07:14 -0700
      Re: Changing letters in boxes fulio pen <fuliopen@yahoo.com> - 2011-10-30 10:22 -0700
        Re: Changing letters in boxes "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-10-30 20:14 +0200
          Re: Changing letters in boxes fulio pen <fuliopen@yahoo.com> - 2011-10-30 12:27 -0700
      Re: Changing letters in boxes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-30 18:58 +0100
        Re: Changing letters in boxes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-30 19:07 +0100
        Re: Changing letters in boxes Andrew Poulos <ap_prog@hotmail.com> - 2011-10-31 06:15 +1100
          Re: Changing letters in boxes Lasse Reichstein Nielsen <lrn.unread@gmail.com> - 2011-11-01 17:17 +0100
            Re: Changing letters in boxes Andrew Poulos <ap_prog@hotmail.com> - 2011-11-02 07:10 +1100
              Re: Changing letters in boxes Andreas Bergmaier <andber93@web.de> - 2011-11-01 23:37 +0100
                Re: Changing letters in boxes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-02 00:20 +0100
          Re: Changing letters in boxes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-01 18:01 +0100
        Re: Changing letters in boxes Matt McDonald <matt@fortybelow.ca> - 2011-10-30 17:42 -0600
          Re: Changing letters in boxes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-31 02:19 +0100
            Re: Changing letters in boxes Matt McDonald <matt@fortybelow.ca> - 2011-10-31 21:29 -0600
              Re: Changing letters in boxes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-11-01 11:52 +0100
        Re: Changing letters in boxes RobG <rgqld@iinet.net.au> - 2011-10-30 19:33 -0700
          Re: Changing letters in boxes "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2011-10-31 08:37 +0200
          Re: Changing letters in boxes Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-10-31 11:50 +0100
    Re: Changing letters in boxes faqir <faqir@faqir.com> - 2011-11-03 23:20 +0200

Page 1 of 2  [1] 2  Next page →

#7819 — Changing letters in boxes

Dear group members:

I wanted to accomplish something, and know javascript or jquery can do
the work, but my knowledge on both languages is too limited.  If
possible, please help. My idea is in the following web page.

http://www.pinyinology.com/js_learning/letters.html

Thanks for your help.

fulio pen

[toc] | [next] | [standalone]

#7820

30.10.2011 14:26, fulio pen wrote:

> I wanted to accomplish something, and know javascript or jquery can do
> the work, but my knowledge on both languages is too limited.

You don't need jQuery for a simple job like this. Using jQuery may 
simplify coding a lot, but here probably the only thing it would be 
useful for is simplifying the reference to a specific element. And 
jQuery isn't really a language (at least not in the same sense as 
JavaScript is a programming language) but a library that you may use in 
addition to JavaScript, to ease coding.

> My idea is in the following web page.
>
> http://www.pinyinology.com/js_learning/letters.html

Remove the jQuery-related script elements (the reference to the library 
doesn't work anyway) and add the following:

<script>
function letters(a,b,c) {
   document.getElementById('box').innerHTML =
     '<td>' + a + '</td><td>' + b + '</td><td>' + c +  '</td>' ;
  }
</script>

Change the <tr> tag for the table to <tr id=box>. (Here and before "box" 
is just an identifier; choose another one if you can find a more 
self-documenting name.)

Add onclick attributes to the <input> element to make them as follows:

box #1: <input type="text" value='x y z' size='10' 
onclick="letters('x','y','z')" /><br />
box #2: <input type="text" value='a b c' size='10' 
onclick="letters('a','b','c')" /><br />
box #3: <input type="text" size='10' onclick="letters('','','')" />

This way, the entire <tr> element is changed at the same time as 
requested (though in practice, just replacing the <td> contents in 
sequence would be just as good, unless there is a real risk of 
intervening interrupts).

Note that clicking on the last box makes the letters disappear entirely, 
i.e. the contents of each <td> element becomes empty, and this affects 
the layout - the cells shrink. (They are still 10px wide and high due to 
the padding you set.) If this is not desirable, there are varyings 
things you can do, depending on the exact desired appearance. For 
example, you could use '\xa0' (standing for no-break space) instead of 
'' to make the cells preserve height (though not width) when cleared.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

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

#7821

On Oct 30, 9:08 am, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> 30.10.2011 14:26, fulio pen wrote:
>
> > I wanted to accomplish something, and know javascript or jquery can do
> > the work, but my knowledge on both languages is too limited.
>
> You don't need jQuery for a simple job like this. Using jQuery may
> simplify coding a lot, but here probably the only thing it would be
> useful for is simplifying the reference to a specific element. And
> jQuery isn't really a language (at least not in the same sense as
> JavaScript is a programming language) but a library that you may use in
> addition to JavaScript, to ease coding.
>
> > My idea is in the following web page.
>
> >http://www.pinyinology.com/js_learning/letters.html
>
> Remove the jQuery-related script elements (the reference to the library
> doesn't work anyway) and add the following:
>
> <script>
> function letters(a,b,c) {
>    document.getElementById('box').innerHTML =
>      '<td>' + a + '</td><td>' + b + '</td><td>' + c +  '</td>' ;
>   }
> </script>
>
> Change the <tr> tag for the table to <tr id=box>. (Here and before "box"
> is just an identifier; choose another one if you can find a more
> self-documenting name.)
>
> Add onclick attributes to the <input> element to make them as follows:
>
> box #1: <input type="text" value='x y z' size='10'
> onclick="letters('x','y','z')" /><br />
> box #2: <input type="text" value='a b c' size='10'
> onclick="letters('a','b','c')" /><br />
> box #3: <input type="text" size='10' onclick="letters('','','')" />
>
> This way, the entire <tr> element is changed at the same time as
> requested (though in practice, just replacing the <td> contents in
> sequence would be just as good, unless there is a real risk of
> intervening interrupts).
>
> Note that clicking on the last box makes the letters disappear entirely,
> i.e. the contents of each <td> element becomes empty, and this affects
> the layout - the cells shrink. (They are still 10px wide and high due to
> the padding you set.) If this is not desirable, there are varyings
> things you can do, depending on the exact desired appearance. For
> example, you could use '\xa0' (standing for no-break space) instead of
> '' to make the cells preserve height (though not width) when cleared.
>
> --
> Yucca,http://www.cs.tut.fi/~jkorpela/

Thanks a lot. Will change accordingly immediately, and come back with
the changed page.

fulio pen

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

#7823

On Oct 30, 9:08 am, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> 30.10.2011 14:26, fulio pen wrote:
>
> > I wanted to accomplish something, and know javascript or jquery can do
> > the work, but my knowledge on both languages is too limited.
>
> You don't need jQuery for a simple job like this. Using jQuery may
> simplify coding a lot, but here probably the only thing it would be
> useful for is simplifying the reference to a specific element. And
> jQuery isn't really a language (at least not in the same sense as
> JavaScript is a programming language) but a library that you may use in
> addition to JavaScript, to ease coding.
>
> > My idea is in the following web page.
>
> >http://www.pinyinology.com/js_learning/letters.html
>
> Remove the jQuery-related script elements (the reference to the library
> doesn't work anyway) and add the following:
>
> <script>
> function letters(a,b,c) {
>    document.getElementById('box').innerHTML =
>      '<td>' + a + '</td><td>' + b + '</td><td>' + c +  '</td>' ;
>   }
> </script>
>
> Change the <tr> tag for the table to <tr id=box>. (Here and before "box"
> is just an identifier; choose another one if you can find a more
> self-documenting name.)
>
> Add onclick attributes to the <input> element to make them as follows:
>
> box #1: <input type="text" value='x y z' size='10'
> onclick="letters('x','y','z')" /><br />
> box #2: <input type="text" value='a b c' size='10'
> onclick="letters('a','b','c')" /><br />
> box #3: <input type="text" size='10' onclick="letters('','','')" />
>
> This way, the entire <tr> element is changed at the same time as
> requested (though in practice, just replacing the <td> contents in
> sequence would be just as good, unless there is a real risk of
> intervening interrupts).
>
> Note that clicking on the last box makes the letters disappear entirely,
> i.e. the contents of each <td> element becomes empty, and this affects
> the layout - the cells shrink. (They are still 10px wide and high due to
> the padding you set.) If this is not desirable, there are varyings
> things you can do, depending on the exact desired appearance. For
> example, you could use '\xa0' (standing for no-break space) instead of
> '' to make the cells preserve height (though not width) when cleared.
>
> --
> Yucca,http://www.cs.tut.fi/~jkorpela/

Hi, Yucca:

Thanks for your help. I changed the code by taking your advice. The
new page is as follows:

http://www.pinyinology.com/js_learning/letters.html

In above page, I like to change the cursor to default in the boxes.
Now it is a vertical bar called text. I tried to change it, but failed
all efforts.  I may have more questions, but have to modify the page
to present them. Thanks again.

fulio pen

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

#7826

30.10.2011 19:22, fulio pen wrote:

> http://www.pinyinology.com/js_learning/letters.html
>
> In above page, I like to change the cursor to default in the boxes.
> Now it is a vertical bar called text.

Setting the cursor is a CSS issue, not JavaScript (though you can set 
the element property corresponding to the CSS property via JavaScript, 
but there's no reason to do so if you want the setting to take effect 
independently of the state of the page).

So please check
http://www.w3.org/TR/CSS21/ui.html#propdef-cursor
Note that an <input type=text> element typically has cursor: text set in 
the browser stylesheet, so it won't inherit the property from its 
ancestor. To set the cursor on <input> elements, use e.g.
input { cursor: default; }
in your stylesheet.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

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

#7828

On Oct 30, 2:14 pm, "Jukka K. Korpela" <jkorp...@cs.tut.fi> wrote:
> 30.10.2011 19:22, fulio pen wrote:
>
> >http://www.pinyinology.com/js_learning/letters.html
>
> > In above page, I like to change the cursor to default in the boxes.
> > Now it is a vertical bar called text.
>
> Setting the cursor is a CSS issue, not JavaScript (though you can set
> the element property corresponding to the CSS property via JavaScript,
> but there's no reason to do so if you want the setting to take effect
> independently of the state of the page).
>
> So please checkhttp://www.w3.org/TR/CSS21/ui.html#propdef-cursor
> Note that an <input type=text> element typically has cursor: text set in
> the browser stylesheet, so it won't inherit the property from its
> ancestor. To set the cursor on <input> elements, use e.g.
> input { cursor: default; }
> in your stylesheet.
>
> --
> Yucca,http://www.cs.tut.fi/~jkorpela/

Hi, Jukka:

Thanks a lot.  The "input { cursor: default; }" has been inserted to
the style section. Now the cursor is the default arrow:

http://www.pinyinology.com/js_learning/letters.html

Other people have also helped me. I thank them all very much, and will
study their suggestions carefully to modify the code.

Thank you all for your help.

fulio pen

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

#7824

Jukka K. Korpela wrote:

> <script>
> function letters(a,b,c) {
>    document.getElementById('box').innerHTML =
>      '<td>' + a + '</td><td>' + b + '</td><td>' + c +  '</td>' ;
>   }
> </script>
> 
> Change the <tr> tag for the table to <tr id=box>. (Here and before "box"
> is just an identifier; choose another one if you can find a more
> self-documenting name.)

Unreliable.  Especially MSHTML (the layout engine that Internet Explorer 
uses) is prone to errors with `innerHTML' accesses in table structures.

A safer approach is to remove all cells of the row except one, then replace 
the content of the first cell and add more cells:

  var tr = document.getElementById("box");
  var firstChild = tr.firstChild;
  while (tr.lastChild != firstChild)
  {
    tr.removeNode(tr.lastChild);
  }

  tr.cells[0].innerHTML = a;

  var td1 = document.createElement("td");
  td1.innerHTML = b;

  /* or td1.cloneNode(false) */
  var td2 = document.createElement("td");
  td2.innerHTML = c;

  tr.appendChild(td1);
  tr.appendChild(td2);

(It suffices here to add text nodes to the cells, or replace their values if 
existing, instead of using the proprietary and error-prone `innerHTML' 
property.  This can be accomplished using the `textContent' property of DOM 
Level 3 Core or the document.createTextNode(…) and appendChild(…) methods of 
DOM Level 2+ Core.)

Another possibility is to rewrite the entire table with `innerHTML'.  
Quirksmode.org results have shown that this can be much more efficient than 
the standards-compliant DOM approach.  But probably not in this case.

> Add onclick attributes to the <input> element to make them as follows:
> 
> box #1: <input type="text" value='x y z' size='10'
> onclick="letters('x','y','z')" /><br />
> box #2: <input type="text" value='a b c' size='10'
> onclick="letters('a','b','c')" /><br />
> box #3: <input type="text" size='10' onclick="letters('','','')" />

Since the value of the control can be used to construct the argument list 
for the letters() method, and the `click' event bubbles universally, it 
might not be necessary that each `input' element has an `onclick' attribute 
specified.  For example:

  <script type="text/javascript">// <![CDATA[
    function clickHandler(e)
    {
      var t = e.target || e.srcElement;
      if (t)
      {
        if (t.nodeType == 3)
        {
          /* if a text node */
          t = t.parentNode;
        }

        if (t.tagName.toUpperCase() == "INPUT")
        {
          letters.apply(null, t.value.split(" "));
        }
      }
    }
  // ]]></script>

  <… onclick="if (typeof event != "undefined") clickHandler(event)" …>
    <input type="text" value='x y z' size='10' /><br />
    <input type="text" value='a b c' size='10' /><br />
    <input type="text" size='10' value='  ' />
  </…>

Usability, in particular keyboard navigation, might be better served by 
listening to the not universally bubbling `focus' event instead, though.  
For that matter, formatting should not be achieved using the `br' element, 
but a semantic element, for example `label' elements that are parent 
elements of their `input' elements.
 

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

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

#7825

Thomas 'PointedEars' Lahn wrote:

>   <… onclick="if (typeof event != "undefined") clickHandler(event)" …>

That has to be 

    <… onclick="if (typeof event != 'undefined') clickHandler(event)" …>

or

    <… onclick='if (typeof event != "undefined") clickHandler(event)' …>

>     <input type="text" value='x y z' size='10' /><br />
>     <input type="text" value='a b c' size='10' /><br />
>     <input type="text" size='10' value='  ' />
>   </…>
> 
> […]


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

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

#7827

On 31/10/2011 4:58 AM, Thomas 'PointedEars' Lahn wrote:

>    <script type="text/javascript">//<![CDATA[
>      function clickHandler(e)
>      {
>        var t = e.target || e.srcElement;
>        if (t)
>        {
>          if (t.nodeType == 3)
>          {
>            /* if a text node */
>            t = t.parentNode;
>          }
>
>          if (t.tagName.toUpperCase() == "INPUT")
>          {
>            letters.apply(null, t.value.split(" "));
>          }
>        }
>      }
>    // ]]></script>

Shouldn't the last line be on two lines, thus:
   // ]]>
   </script>
?

Andrew Poulos

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

#7901

Andrew Poulos <ap_prog@hotmail.com> writes:

> On 31/10/2011 4:58 AM, Thomas 'PointedEars' Lahn wrote:
>>    // ]]></script>
>
> Shouldn't the last line be on two lines, thus:
>    // ]]>
>    </script>
> ?

No. Why do you think it needs to be on two lines?
/L
-- 
Lasse Reichstein Holst Nielsen
 'Javascript frameworks is a disruptive technology'
  

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

#7912

On 2/11/2011 3:17 AM, Lasse Reichstein Nielsen wrote:
> Andrew Poulos<ap_prog@hotmail.com>  writes:
>
>> On 31/10/2011 4:58 AM, Thomas 'PointedEars' Lahn wrote:
>>>     // ]]></script>
>>
>> Shouldn't the last line be on two lines, thus:
>>     // ]]>
>>     </script>
>> ?
>
> No. Why do you think it needs to be on two lines?

Doesn't the leading "//" comment out the entire line?

Andrew Poulos

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

#7915

Andrew Poulos schrieb:
> Shouldn't [that] be on two lines, thus:
> // ]]>
> </script>
> ?
>
> Doesn't the leading "//" comment out the entire line?

Yes, but that doesn't matter the HTML Parser. The (X)HTML(soup)-Parser 
just looks for the end of the CDATA-section (if it knows about CDATA - 
else it looks for the end of the <script>-tag), and then might send its 
content to the script engine.

  Bergi

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

#7917

Andreas Bergmaier wrote:

> Andrew Poulos schrieb:
>> Shouldn't [that] be on two lines, thus:
>> // ]]>
>> </script>
>> ?
>>
>> Doesn't the leading "//" comment out the entire line?
> 
> Yes, but that doesn't matter the HTML Parser. The (X)HTML(soup)-Parser
> just looks for the end of the CDATA-section (if it knows about CDATA -
> else it looks for the end of the <script>-tag), and then might send its
> content to the script engine.

That CDATA declaration is for real X(HT)ML parsers only.  An HTML parser 
would ignore it since the content model of the HTML SCRIPT element is CDATA 
already (hence the single-line comments for the script engine); it would 
look for `</' instead (which is why you should escape ETAGO delimiters – </ 
– regardless in XHTML `script' elements).  A tagsoup parser would not care 
at all, it would probably look for `</script>' only (which is also why you 
get used to escaping unwanted ETAGOs there).
	

PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
 -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

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

#7902

Andrew Poulos wrote:

> Thomas 'PointedEars' Lahn wrote:
>>    <script type="text/javascript">//<![CDATA[
>> […]
>>    // ]]></script>
> 
> Shouldn't the last line be on two lines, thus:
>    // ]]>
>    </script>
> ?

Not necessarily.


PointedEars
-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

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

#7886

On 10/30/2011 11:58 AM, Thomas 'PointedEars' Lahn wrote:
> Unreliable.  Especially MSHTML (the layout engine that Internet Explorer
> uses) is prone to errors with `innerHTML' accesses in table structures.
>
> A safer approach is to remove all cells of the row except one, then replace
> the content of the first cell and add more cells...

Agreed. Given the Table API that the DOM provides, usage of innerHTML 
here is erroneous, especially in IE. There's also, of course, 
createElement + appendChild if desired.

I wrote an article earlier today on this topic, except utilizing the DOM 
Table API (insertCell + deleteCell):

http://www.fortybelow.ca/hosted/comp-lang-javascript/table-cell-replacement/

Comments are welcome.

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

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

#7889

Matt McDonald wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Unreliable.  Especially MSHTML (the layout engine that Internet Explorer
>> uses) is prone to errors with `innerHTML' accesses in table structures.
>>
>> A safer approach is to remove all cells of the row except one, then
>> replace the content of the first cell and add more cells...
> 
> Agreed. Given the Table API that the DOM provides, usage of innerHTML
> here is erroneous, especially in IE. There's also, of course,
> createElement + appendChild if desired.
> 
> I wrote an article earlier today on this topic, except utilizing the DOM
> Table API (insertCell + deleteCell):
> 
> http://www.fortybelow.ca/hosted/comp-lang-javascript/table-cell-
replacement/
> 
> Comments are welcome.

One problem which what you dubbed "DOM Table Cell API" (there really is no 
official name for that part of the W3C DOM Level 2 HTML Specification) is 
that the W3C DOM API Specification and the MSHTML DOM API definition 
disagree (again, cf. HTMLSelectElement::add() [1]) with regard to the 
meaning of the method's arguments and its return value:

Both support the value -1 to append a new cell; but while the standards-
compliant implementation requires the number of existing cells to be passed 
for an alternative of that (tr.cells.length), MSHTML is at least documented 
to require tr.cells.length - 1.  Also, while the standards-compliant 
implementation is supposed to throw DOMException INDEX_SIZE_ERR on error, 
MSHTML is at least documented to throw no exception at all then, but to 
return "null" instead (which, for the ECMAScript binding, is the `null' 
value of the JScript implementation of the Null type). [2]

The same problem exists with 
HTMLTableElement/HTMLTableSectionElement::insertRow(). [3]

Those differences suggest the possibility of other differences between 
standards-compliant and other implementations than the MSHTML DOM in this 
area.  Therefore, I have intentionally used DOM Level 2+ Core methods in my 
example – for which I am not aware of such quirks – and made no mention of 
that "DOM Table Cell API".


PointedEars
___________
[1] <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-14493106>
    <http://msdn.microsoft.com/en-us/library/ms535921(VS.85).aspx>
[2] <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-68927016>
    <http://msdn.microsoft.com/en-us/library/ms536455(VS.85).aspx>
[3] <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-93995626>
    <http://msdn.microsoft.com/en-us/library/ms536457(VS.85).aspx>
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

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

#7895

On 10/30/2011 7:19 PM, Thomas 'PointedEars' Lahn wrote:
> One problem which what you dubbed "DOM Table Cell API" (there really is no
> official name for that part of the W3C DOM Level 2 HTML Specification) is
> that the W3C DOM API Specification and the MSHTML DOM API definition
> disagree (again, cf. HTMLSelectElement::add() [1]) with regard to the
> meaning of the method's arguments and its return value:

Right. That was a silly typo ("Table Cell" over "Table"). I've amended 
the title along with any reference to any "API" short of the DOM itself.

> Both support the value -1 to append a new cell; but while the standards-
> compliant implementation requires the number of existing cells to be passed
> for an alternative of that (tr.cells.length), MSHTML is at least documented
> to require tr.cells.length - 1.  Also, while the standards-compliant
> implementation is supposed to throw DOMException INDEX_SIZE_ERR on error,
> MSHTML is at least documented to throw no exception at all then, but to
> return "null" instead (which, for the ECMAScript binding, is the `null'
> value of the JScript implementation of the Null type). [2]

Noted in both cases. Thanks.

> The same problem exists with
> HTMLTableElement/HTMLTableSectionElement::insertRow(). [3]
>
> Those differences suggest the possibility of other differences between
> standards-compliant and other implementations than the MSHTML DOM in this
> area.  Therefore, I have intentionally used DOM Level 2+ Core methods in my
> example – for which I am not aware of such quirks – and made no mention of
> that "DOM Table Cell API".

Ah, I see. Still, it's a powerful set of methods/properties that tend to 
get overlooked.

Regarding your double colon notation (::), am I to infer those 
properties/methods are static? I've been unable to locate anything 
utilizing that notation regarding the DOM beyond your posts.

Finally, I've spent most of today cleaning up the article and making it 
easier to parse through. I'd like to thank you for reviewing it and 
being very thorough (as always). Will you mind if I attribute you in the 
footnotes?

PS: Your suggestion previously to stick to table cell modification 
instead of a complete overhaul of the row led me to fix a reflow bug in 
IE:Mac. Thanks a bunch. :)

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

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

#7896

Matt McDonald wrote:

> On 10/30/2011 7:19 PM, Thomas 'PointedEars' Lahn wrote:
>> The same problem exists with
>> HTMLTableElement/HTMLTableSectionElement::insertRow(). [3]
>>
>> Those differences suggest the possibility of other differences between
>> standards-compliant and other implementations than the MSHTML DOM in this
>> area.  Therefore, I have intentionally used DOM Level 2+ Core methods in
>> my example – for which I am not aware of such quirks – and made no
>> mention of that "DOM Table Cell API".
> 
> Ah, I see. Still, it's a powerful set of methods/properties that tend to
> get overlooked.

ACK

> Regarding your double colon notation (::), am I to infer those
> properties/methods are static? I've been unable to locate anything
> utilizing that notation regarding the DOM beyond your posts.

ECMAScript Ed. 1 to 3, and 5 do not specify class-based inheritance and have 
no notion of static methods as they are defined in class-based OOP.  
Apparently we (the participants of this newsgroup that I am aware of) use 
the shortcut "static" (I try to use it in quotes in discussions, to be sure) 
to talk about a property that is a property of a constructor (like 
Object.defineProperty) or is otherwise not implicitly inherited by other 
objects (like Math.max).

`::' notation is my way of referring (unambiguously, or so it seemed) to the 
interface specification (formally given in OMG IDL) instead of some 
ECMAScript object or an object available through ECMAScript language binding 
(like Node.ELEMENT_NODE in some DOM implementations).  Keep in mind that the 
W3C DOM is a *language-independent* API, where language binding is specified 
for some programming languages, including ECMAScript implementations:

<http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html>
(You can find similar sections in the other module specifications.)

So when I wrote "HTMLSelectElement::add()", read it as if I had written "the 
add() method of objects implementing the HTMLSelectElement interface of W3C 
DOM Level 2 HTML".  (Easier, yes?)

> Finally, I've spent most of today cleaning up the article and making it
> easier to parse through. I'd like to thank you for reviewing it and
> being very thorough (as always). Will you mind if I attribute you in the
> footnotes?

I would not, but I have not reviewed it yet (except perhaps, by 
coincidence).  Perhaps later this week.  You better remind me.

> PS: Your suggestion previously to stick to table cell modification
> instead of a complete overhaul of the row led me to fix a reflow bug in
> IE:Mac. Thanks a bunch. :)

You are welcome. 


Regards,

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

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

#7890

On Oct 31, 3:58 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Jukka K. Korpela wrote:
> > <script>
> > function letters(a,b,c) {
> >    document.getElementById('box').innerHTML =
> >      '<td>' + a + '</td><td>' + b + '</td><td>' + c +  '</td>' ;
> >   }
> > </script>
>
> > Change the <tr> tag for the table to <tr id=box>. (Here and before "box"
> > is just an identifier; choose another one if you can find a more
> > self-documenting name.)
>
> Unreliable.  Especially MSHTML (the layout engine that Internet Explorer
> uses) is prone to errors with `innerHTML' accesses in table structures.

Yes. MS documentation explicitly says not to use innerHTML to modify
tables[1].

>
> A safer approach is to remove all cells of the row except one, then replace
> the content of the first cell and add more cells:
>
>   var tr = document.getElementById("box");
>   var firstChild = tr.firstChild;
>   while (tr.lastChild != firstChild)
>   {
>     tr.removeNode(tr.lastChild);
>   }
>
>   tr.cells[0].innerHTML = a;

You seem to be assuming here that the firstChild of the tr will be a
cell (TD or TH), when it may be a text node:

  <table>
    <tr onclick="alert(this.firstChild);">
      <td>foo
  </table>

The above shows "3" for the text node following the TR in Firefox,
Opera and Chrome, or "1" for the element node in IE 8 (which seems to
omit the text node).

To get the first cell, better to be explicit:

    var firstCell = tr.cells[0];

An alternative is getElementsByTagName('td')[0], but the cells can be
TH or TD, using the cells collection deals with both.

[...]
> When all you know is jQuery, every problem looks $olvable.

<grin> is that one of yours?

1. http://msdn.microsoft.com/en-us/library/ms533897%28v=VS.85%29.aspx


--
Rob

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

#7891

1.10.2011 4:33, RobG wrote:

 > MS documentation explicitly says not to use innerHTML to modify
 > tables[1].

Then I would recommend just putting id attributes on each <td> and 
changing the cell contents. Any practical risk of making the cell update 
operation divisible that way must be ignorable when compared with the 
risks caused by added complexity of code.

But if an indivisible operation is really needed, then the simplest 
approach that avoids the IE bug is probably something like this:

function addCell(row,data) {
   var cell = document.createElement('td');
   cell.innerHTML = data;
   row.appendChild(cell);
}
function letters(a,b,c) {
   var boxId = 'box';
   var box = document.getElementById(boxId);
   var newRow = document.createElement('tr');
   newRow.id = boxId;
   addCell(newRow,a);
   addCell(newRow,b);
   addCell(newRow,c);
   box.parentNode.replaceChild(newRow,box);
}

 > An alternative is getElementsByTagName('td')[0], but the cells can be
 > TH or TD, using the cells collection deals with both.

No, all the three cells are <td> elements. If the real intent is to 
create something easily modifiable and extensible, then you might worry 
about the optimal way of retrieving all cells, or all data cells, in a 
table row, and looping through them, but the problem posed was specific 
and simple.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web