f



Changing table cell between plain text and INPUT TYPE=TEXT control

I'd like to setup a table cell such that the contents displays as plain 
text until the mouse hovers over the cell, and then it changes to an 
INPUT TYPE=TEXT control, so I can edit the content.

I can probably just about manage the JavaScript and CSS necessary to 
achieve this, but before I start, is there any overarching reason why 
this wouldn't work? I anticipate placing the plain text and the input 
area in separate DIVs, and making the appear alternately, depending on 
where the mouse pointer is.

The page is for my own use, and perhaps one or two colleagues, so we 
don't have to be squeamish about whether or not this is a good idea in 
general.

I don't plan on making the cell an input area all the time, as updates 
will be very rare, and the text input field would spoil the appearance.

The text will all fit on one line, so I don't have to worry too much 
about the cell changing "shape", or even size (much).

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
0
Swifty
1/6/2009 10:17:44 AM
comp.lang.javascript 38370 articles. 2 followers. javascript4 (1315) is leader. Post Follow

8 Replies
920 Views

Similar Articles

[PageSpeed] 14

On Jan 6, 5:17 am, Swifty <steve.j.sw...@gmail.com> wrote:
> I'd like to setup a table cell such that the contents displays as plain
> text until the mouse hovers over the cell, and then it changes to an
> INPUT TYPE=TEXT control, so I can edit the content.
>
> I can probably just about manage the JavaScript and CSS necessary to
> achieve this, but before I start, is there any overarching reason why
> this wouldn't work? I anticipate placing the plain text and the input
> area in separate DIVs, and making the appear alternately, depending on
> where the mouse pointer is.
>
> The page is for my own use, and perhaps one or two colleagues, so we
> don't have to be squeamish about whether or not this is a good idea in
> general.
>
> I don't plan on making the cell an input area all the time, as updates
> will be very rare, and the text input field would spoil the appearance.
>
> The text will all fit on one line, so I don't have to worry too much
> about the cell changing "shape", or even size (much).
>
> --
> Steve Swifthttp://www.swiftys.org.uk/swifty.htmlhttp://www.ringers.org.uk

Actually with proper CSS they wouldn't spoil the "look" at all. You
can remove or change the borders and make them look just like text,
except when you click on them you can change them.

Wouldn't that be alot simpler than the alternative?
0
Tom
1/6/2009 3:30:08 PM
On Jan 6, 3:30 pm, Tom Cole wrote:
> On Jan 6, 5:17 am, Swifty wrote:
>
>> I'd like to setup a table cell such that the contents displays
>> as plain text until the mouse hovers over the cell, and then
>> it changes to an INPUT TYPE=TEXT control, so I can edit the
>> content.
<snip>
>> The text will all fit on one line, so I don't have to worry
>> too much about the cell changing "shape", or even size (much).
<snip>
> Actually with proper CSS they wouldn't spoil the "look" at all.
> You can remove or change the borders and make them look just
> like text, except when you click on them you can change them.
>
> Wouldn't that be alot simpler than the alternative?

Table cells tend to self-adjust their size to accommodate whatever
they contain, but INPUT elements do not. It would be tricky to arrange
for the INPUT element's widths to match their initial contexts (even
if the server generated em-based width styles based on the contents
length).
0
Henry
1/6/2009 4:25:58 PM
Henry wrote:
> Table cells tend to self-adjust their size to accommodate whatever
> they contain, but INPUT elements do not. It would be tricky to arrange
> for the INPUT element's widths to match their initial contexts (even
> if the server generated em-based width styles based on the contents
> length).

I've had no problems with:

<INPUT TYPE=TEXT STYLE="width:100%" ...> inside tables which themselves 
have WIDTH=100%

Everything scales/expands quite nicely.

See http://www.swiftys.org.uk/decisions but please don't look too 
closely at the HTML; it's liable to make most people who read this 
newsgroup a little queasy; I code for affect, not to win style prizes.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
0
Swifty
1/6/2009 5:13:35 PM
On Jan 6, 5:13 pm, Swifty wrote:
> Henry wrote:
>> Table cells tend to self-adjust their size to accommodate
>> whatever they contain, but INPUT elements do not. It would
>> be tricky to arrange for the INPUT element's widths to match
>> their initial contexts (even if the server generated em-based
>> width styles based on the contents length).
>
> I've had no problems with:
>
> <INPUT TYPE=TEXT STYLE="width:100%" ...> inside tables which
> themselves have WIDTH=100%
>
> Everything scales/expands quite nicely.

If you are happy with the amount of text displayed/avalable being
determined by the width of the containing window and the longest non-
width:100% contents of a table column then do that.

> Seehttp://www.swiftys.org.uk/decisionsbut please don't look
> too closely at the HTML; it's liable to make most people
> who read this newsgroup a little queasy; I code for affect,
> not to win style prizes.

It sounds like you are thinking that the recommendations to use (at
minimum structurally) valid HTML mark-up might be just the rambling of
overly pedantic zealots. In the context of DOM scripting they are
nothing of the sort. For (structurally) valid mark-up there is a
direct and *predictable* mark-up to DOM structure translation. With
non-valid mark-up the resulting DOM structure is a product of the non-
standardised application of error correction. So the same non-valid
mark-up can be expected to result in differing DOM structures when
processed by the error correction mechanisms of different web
browsers, and some non-valid mark-up has been shown to result very
divergent DOM structures in different browsers. With a particular
demonstrated cause of (quite extreme) DOM structure variation being
the result of placing FORM elements in non-valid locations,
particularly within TABLE elements and their descendants. And that
particular form of non-valid mark-up is one of the things clearly
demonstrated on that page of yours.

The point being that if you are going to interact with a DOM (which is
pretty much guaranteed if you intend non-trivial browser scripting)
then divergent DOM structures are going to be making that job (much)
harder than it needs to be. Using (structurally) valid mark-up just
avoids a whole category of (obviously avoidable) scripting issues, and
so represents a sensible 'best practice' for javascript authors to be
recommending.

("Structurally" valid mark-up is being stressed above because there is
no evidence of non-valid attributes having any impact on DOM
structure, and so their possible use has little relevance for browser
scripting (so long as there is no intention to script interactions
with those attributes). However, short of learning the rules relating
to structure in HTML mark-up and so knowing the structural validity of
the documents you write, one way to verify structural validity is to
test for full validity with a validator, at which point getting a lot
of non-valid attribute related error messages from the validator is
likely to get in the way of seeing if structural validity has been
achieved.)
0
Henry
1/6/2009 5:57:39 PM
Le 1/6/09 5:25 PM, Henry a �crit :
> 
> Table cells tend to self-adjust their size to accommodate whatever
> they contain, but INPUT elements do not. It would be tricky to arrange
> for the INPUT element's widths to match their initial contexts (even
> if the server generated em-based width styles based on the contents
> length).


span, p, div and contenteditable="true" and without width style

<td>
   <div contentEditable="true">
      User can write here what he wants
   </div>
</td>

Ff.3, IE.6, Safari.3, iCab.4, Opera.9.1

-- 
sm
0
SAM
1/6/2009 9:33:37 PM
SAM wrote:
> span, p, div and contenteditable="true" and without width style
> 
> <td>
>   <div contentEditable="true">
>      User can write here what he wants
>   </div>
> </td>
> 
> Ff.3, IE.6, Safari.3, iCab.4, Opera.9.1

Visually, that is absolutely perfect. However, I don't see how I can get 
the updated information back into the database on the server which 
generated the page, without some sort of JavaScript xmlhttp request 
(which I've not yet mastered).

However, this is my fault. I should be careful what I ask for - someone 
might give me exactly what I asked for. :-)

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
0
Swifty
1/7/2009 4:38:32 AM
Le 1/7/09 5:38 AM, Swifty a �crit :
> SAM wrote:
>> span, p, div and contenteditable="true" and without width style
(...)
> Visually, that is absolutely perfect. However, I don't see how I can get 
> the updated information back into the database on the server which 
> generated the page, without some sort of JavaScript xmlhttp request 
> (which I've not yet mastered).

To try changing the form's action with a file server-side
(and suppressing the onsubmit)

<html>
<form action="javascript:alert('I simulate the sent:\n'+sent)"
       onsubmit="sent=this.d_1.value+'\n'+this.d_2.value">
<table border=1>
   <tbody>
   <tr><th>item 1</th>
     <td>
       <p contenteditable="true"
          onkeyup="document.forms[0].d_1.value=this.innerHTML">
          data 1
       </p>
       <input name="d_1" type="hidden">
     </td>
   <tr><th>item 2</th>
     <td>
       <p contenteditable="true"
          onkeyup="document.forms[0].d_2.value=this.innerHTML">
          data 2
       </p>
       <input name="d_2" type="hidden">
     </td>
     </tbody>
   </table>
   <p><input type="submit">
</form>
</html>


-- 
sm
0
SAM
1/8/2009 2:07:24 AM
SAM wrote:
>> Visually, that is absolutely perfect. However, I don't see how I can 
>> get the updated information back into the database on the server which 
>> generated the page, without some sort of JavaScript xmlhttp request 
>> (which I've not yet mastered).
> 
> To try changing the form's action with a file server-side
> (and suppressing the onsubmit)
> 
> <html>
> <form action="javascript:alert('I simulate the sent:\n'+sent)"
>       onsubmit="sent=this.d_1.value+'\n'+this.d_2.value">
> <table border=1>
>   <tbody>
>   <tr><th>item 1</th>
>     <td>
>       <p contenteditable="true"
>          onkeyup="document.forms[0].d_1.value=this.innerHTML">
>          data 1
>       </p>
>       <input name="d_1" type="hidden">
>     </td>

Thanks for that. It's more or less what I guessed I'd have to do, but it 
would have taken me an age to figure out how *actually* to do it.

-- 
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
0
Swifty
1/8/2009 5:33:57 PM
Reply: