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

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

Why newly inserted area is not editable?

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

Contents

  Why newly inserted area is not editable? justaguy <lichunshen84@gmail.com> - 2016-12-08 13:39 -0800
    Re: Why newly inserted area is not editable? JJ <jj4public@vfemail.net> - 2016-12-09 06:25 +0700
      Re: Why newly inserted area is not editable? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-12-09 00:53 +0100
        Re: Why newly inserted area is not editable? justaguy <lichunshen84@gmail.com> - 2016-12-08 17:29 -0800
      Re: Why newly inserted area is not editable? justaguy <lichunshen84@gmail.com> - 2016-12-08 17:29 -0800

#31786 — Why newly inserted area is not editable?

HTML:
<table id="TBL">
  <!-- ... dynamically inserted TR or TRs without respective ID or IDs -->
  <tr id="last10" style="display:none">
     <td></td>
  </tr>
</table>	

Javascript:
	if (document.getElementById('last10').previousSibling) {
		console.log("PreviousSibling EXIST==============");
		document.getElementById('last10').previousSibling.contentEditable = true;
	}

Intention:
To make the newly or dynamically inserted area editable. Ignore how they are inserted (it's working).

Outcomes:
Firefox version 50 with its console log indicated that the PreviousSibling exits, however, 
the new inserted area (TRs and their TDs) is not editable.

Question:
What's wrong?

Thanks.	

[toc] | [next] | [standalone]

#31787

On Thu, 8 Dec 2016 13:39:21 -0800 (PST), justaguy wrote:

> HTML:
> <table id="TBL">
>   <!-- ... dynamically inserted TR or TRs without respective ID or IDs -->
>   <tr id="last10" style="display:none">
>      <td></td>
>   </tr>
> </table>	
> 
> Javascript:
> 	if (document.getElementById('last10').previousSibling) {
> 		console.log("PreviousSibling EXIST==============");
> 		document.getElementById('last10').previousSibling.contentEditable = true;
> 	}
> 
> Intention:
> To make the newly or dynamically inserted area editable. Ignore how they are inserted (it's working).
> 
> Outcomes:
> Firefox version 50 with its console log indicated that the PreviousSibling exits, however, 
> the new inserted area (TRs and their TDs) is not editable.
> 
> Question:
> What's wrong?
> 
> Thanks.

previousSibling may not be an element node, depending on where you've
inserted the dynamically created TR element. You don't ignore that.

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

#31788

JJ wrote:

> previousSibling may not be an element node, depending on where you've
> inserted the dynamically created TR element. You don't ignore that.

The “previousElementSibling” property introduced with DOM4 can provide an 
easier workaround than an XPath expression (supported by an implementation 
of DOM Level 2 XPath) or sibling node iteration.  Likewise, before one 
writes an XPath expression, or attempts to iterate over child nodes, or 
resorts to a library, one should check if the “firstElementChild”, 
“lastElementChild”, or “children” properties are implemented that are 
specified there.

<https://www.w3.org/TR/dom/#nondocumenttypechildnode>
<https://www.w3.org/TR/dom/#parentnode>

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

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

#31789

On Thursday, December 8, 2016 at 6:53:37 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> JJ wrote:
> 
> > previousSibling may not be an element node, depending on where you've
> > inserted the dynamically created TR element. You don't ignore that.
> 
> The “previousElementSibling” property introduced with DOM4 can provide an 
> easier workaround than an XPath expression (supported by an implementation 
> of DOM Level 2 XPath) or sibling node iteration.  Likewise, before one 
> writes an XPath expression, or attempts to iterate over child nodes, or 
> resorts to a library, one should check if the “firstElementChild”, 
> “lastElementChild”, or “children” properties are implemented that are 
> specified there.
> 
> <https://www.w3.org/TR/dom/#nondocumenttypechildnode>
> <https://www.w3.org/TR/dom/#parentnode>
> 

Thanks but problem resolved with making a specific ID content editable.

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

#31790

On Thursday, December 8, 2016 at 6:25:55 PM UTC-5, JJ wrote:
> On Thu, 8 Dec 2016 13:39:21 -0800 (PST), justaguy wrote:
> 
> > HTML:
> > <table id="TBL">
> >   <!-- ... dynamically inserted TR or TRs without respective ID or IDs -->
> >   <tr id="last10" style="display:none">
> >      <td></td>
> >   </tr>
> > </table>	
> > 
> > Javascript:
> > 	if (document.getElementById('last10').previousSibling) {
> > 		console.log("PreviousSibling EXIST==============");
> > 		document.getElementById('last10').previousSibling.contentEditable = true;
> > 	}
> > 
> > Intention:
> > To make the newly or dynamically inserted area editable. Ignore how they are inserted (it's working).
> > 
> > Outcomes:
> > Firefox version 50 with its console log indicated that the PreviousSibling exits, however, 
> > the new inserted area (TRs and their TDs) is not editable.
> > 
> > Question:
> > What's wrong?
> > 
> > Thanks.
> 
> previousSibling may not be an element node, depending on where you've
> inserted the dynamically created TR element. You don't ignore that.

Thanks.

[toc] | [prev] | [standalone]

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

csiph-web