Opened 9 years ago

Last modified 2 years ago

#11145 assigned defect

TextArea: placeHolder parameter does not work for dijit.form.SimpleTextarea widgets

Reported by: Jean-Rubin Leonard Owned by: bill
Priority: high Milestone: 2.0
Component: Dijit - Form Version: 1.5.0b2
Keywords: dijit.form.SimpleTextarea dijit.form.textbox HTML5 placeHolder Cc: Kitson Kelly
Blocked By: Blocking:

Description (last modified by bill)

Hi, in the release notes it says that the placeholder HTML5 parameter has been implemented for all textbox widgets. dijit.form.SimpleTextarea is a textbox widgets but the placeholder parameter doesn't seem to be working for it. See attached test file. This ticket should be assigned to LiuCougar.

Attachments (2)

placeholder.html (1.1 KB) - added by Jean-Rubin Leonard 9 years ago.
almostTextArea.patch (11.3 KB) - added by bill 9 years ago.
patch that works except for width: x% or height: y%

Download all attachments as: .zip

Change History (16)

Changed 9 years ago by Jean-Rubin Leonard

Attachment: placeholder.html added

comment:1 Changed 9 years ago by bill

Milestone: tbd2.0
Summary: placeHolder parameter does not work for dijit.form.SimpleTextarea widgetsTextArea: placeHolder parameter does not work for dijit.form.SimpleTextarea widgets

Cougar and I looked at this. It would require changing the template to add a <div> around the <textarea>, like TextBox now has (as of 1.5). The problem is that TextArea's cols=50 parameter wouldn't work anymore. I'm marking this for 2.0, maybe we'll desupport that cols parameter then, since I doubt anyone is using it, but shouldn't remove it for 1.0.

comment:2 Changed 9 years ago by bill

Milestone: 2.01.5
Owner: set to bill
Status: newassigned

I've figured out a way to get this to work, and I think I can put it in 1.5.

There are a number of approaches to solving this, each with advantages/disadvantages:

1) TextArea works like TextBox (border, padding, and size setting on wrapper node, except when rows/cols specified):


  • consistency of size w/textbox widgets.


  • scrollbar (on <textarea> node) is inset from the border
  • inconsistent size compared to plain <div>'s (padding-box size not content-box size)
  • code complicated because it needs to support two "paths": when rows/cols is specified on the <textarea> then the wrapper <div> needs to size itself to match the <textarea>, rather than vice versa
  • height problem on IE... height: 100% doesn't make <textarea> height match height of wrapper <div>. I don't know how to solve this problem, which makes this approach apparently impossible.

2) Invisible wrapper <div> around <textarea> (border, padding, and size setting on <textarea> node):


  • TextArea continues to have content box sizing, like other elements (but unlike all the other *TextBox based widgets)


  • must set define specific CSS for position of placeHolder text. Ex: if TextArea border=10px and padding=10px then placeHolder offset = 20px

3) Border on wrapper <div>, padding on <textarea>, size specified on <textarea>:


  • no scrollbar inset problem (except on FF, which has that behavior even on native <textarea>'s)
  • placeHolder positions correctly without custom CSS
  • TextArea continues to have content box sizing, like other elements (but unlike all the other *TextBox based widgets)

I'm looking at doing (3).

Changed 9 years ago by bill

Attachment: almostTextArea.patch added

patch that works except for width: x% or height: y%

comment:3 Changed 9 years ago by bill

Description: modified (diff)
Milestone: 1.52.0

I got some code that was almost working as per (3) above, where the <textarea> was wrapped by an inline-block <div>, and the size and padding was on the <textarea> node, but the border was on the <div>. However, it fails for a CSS width setting in percentage, like in test_TextArea.html with the width: 33% test case. height: x% is also broken, but apparently that has never worked on IE due to a browser bug.

The width: x% problem is difficult to solve. I tried setting width: 33% on the wrapper <div> and width: 100% on the <textarea>:

<div style="position: relative; width: 33%; border: 5px solid blue;">
	<textarea style="width: 100%; padding: 20px; height: 300px; overflow: auto;">
               textarea w/wrapper div at 33% width, textarea at 100%

But, since that adjusts the <textarea>'s content-box size rather than border-box size, the <textarea> overflows the <div>, except in IE quirks mode. Modern browser will allow setting border-box sizing on the <textarea>, solving that problem, but not IE6/IE7. display: block also doesn't work.

An alternate approach is to change placeHolder to write text directly into the <input>/<textarea>. That was actually the original design (see original patch in #3286), but we didn't check it in because when a form is submitted (via old style HTML form submit, rather than XHR), the hint text written in the <input>/<textarea> gets submitted as though the user had typed it in. This can be overcome by changing all the widgets with placeHolder text to extend MappedTextBox... or alternately in 2.0 just desupport direct form submission, assuming that everyone does it via XHR.

So, I'm retreating on this feature for now.

comment:4 Changed 9 years ago by bill

(In [22261]) Test cleanup from work on promptMessage, refs #11145.

comment:5 Changed 8 years ago by bill

Component: DijitDijit - Form

comment:6 Changed 6 years ago by Kitson Kelly

Cc: Kitson Kelly added

comment:7 Changed 4 years ago by chmielot


I'm using Dojo 1.8 and ran into the same issue. I'm wondering: why does Dojo remove my custom placeholder attribute at all? The browser would handle the placeholder element and all would be fine, I don't need any special dojo treatment to show the placeholder.

<textarea name="description" id="description_41" placeholder="My Placeholder" rows="4" cols="80" data-dojo-type="dijit/form/SimpleTextarea"></textarea>

comment:8 Changed 4 years ago by bill

why does Dojo remove my custom placeholder attribute at all?

@chmielot - it's because older browsers don't support the placeholder attribute, and it's for being able to style the placeholder; even on modern browsers it's difficult to change the font etc. used for the placeholder (changing color is easier).

comment:9 Changed 4 years ago by bill

#18269 is a duplicate of this ticket.

comment:10 Changed 4 years ago by dwolverton

I'm using Dojo 1.10.3. I'm seeing that placeholder specification is strangely finicky. It is different from TextBox?, and the test for it is broken: Finicky JSFiddle: Broken Test:

Note also how the behavior ends up being different between browsers. Particularly in IE (I tested in IE10) the behavior can be quite bad where the placeholder actually becomes the textarea value. In Chrome, it either works as a placeholder or doesn't show up at all.

comment:11 Changed 3 years ago by dylan

Milestone: 2.01.12

Bill, any interest in revisiting this now that we don't need to support older versions of IE (it seems your original patch was struggling with IE6/7)?

comment:12 Changed 3 years ago by bill

Sorry, I don't have time to work on this anymore. I also don't think it's wise to introduce such a major change (i.e. to change Textarea's template) at this stage in dojo's 1 life. That's why the milestone should be 2.

comment:13 Changed 3 years ago by dylan

Milestone: 1.122.0

I would say unless there's an active plan to fix it for 2.0 and/or delite/deliterful, we should just close it out. We're at a point where we need to close any tickets that we're not realistically going to work on, as a high volume of ignored tickets is not manageable.

comment:14 Changed 2 years ago by thierry.chaudy

Why not simply set a default value and remove it on focus (and re set it on blur when empty) ?

So something like that:

                var simpleTextarea = new SimpleTextarea({ 
                    value: this.resources.INSERT_YOUR_MESSAGE_HERE, 
                    onFocus: lang.hitch(this, function() { 
                        //on focus, remove the watermark 
                        if (simpleTextarea .get("value") == this.resources.INSERT_YOUR_MESSAGE_HERE) { 
                            simpleTextarea .set("value", ""); 
                    onBlur: lang.hitch(this, function() { 
                        // on blur, if empty, re set the watermark 
                        if (simpleTextarea .get("value") == "") { 
                            simpleTextarea .set("value", this.resources.INSERT_YOUR_MESSAGE_HERE); 
                }, simpleTextarea Container);

It's simple and can be a work around...

Last edited 2 years ago by thierry.chaudy (previous) (diff)
Note: See TracTickets for help on using tickets.