Opened 9 years ago

Closed 9 years ago

#11133 closed defect (fixed)

[regression] TextBox: user CSS migration issues

Reported by: Brett van de Sande Owned by: Douglas Hays
Priority: high Milestone: 1.5
Component: Documentation Version: 1.5.0b2
Keywords: TextBox css Cc: bvds@…, mike@…, ben hockey
Blocked By: Blocking:

Description (last modified by bill)

This was broken by [22060]

	<style type="text/css" >
                #helpInput{
		        position:absolute;
                    	left:5px;
                 	bottom:5px;
			right:50px;
		}
	</style>

...

	<div dojoType="dijit.form.TextBox" id="helpInput"></div>

Causes a horizontal line to appear on the screen

Attachments (2)

textBox.html (1.3 KB) - added by Brett van de Sande 9 years ago.
Test case showing error
11133.html (1.2 KB) - added by bill 9 years ago.
working absolute positioning

Download all attachments as: .zip

Change History (17)

Changed 9 years ago by Brett van de Sande

Attachment: textBox.html added

Test case showing error

comment:1 Changed 9 years ago by bill

Description: modified (diff)
Milestone: tbd1.5
Owner: set to Douglas Hays
Summary: form TextBox with absolute positioning broken[regression] TextBox: absolute positioning broken

comment:2 Changed 9 years ago by Douglas Hays

This may be an unavoidable migration problem with 1.5. The TextBox? widget was enhanced to provide the same size and styling characteristics as TextBox? subclasses so that everything looks well-defined when used together. The ID attribute of the INPUT node is "helpInput" but the ID attribute of the positioning DIV is "widget_helpInput".
1 of 3 things needs to happen to make this work:
1) change helpInput to widget_helpInput in the STYLE section
2) add templateString="input" to your markup DIV (post-beta 2 [22145])
3) we roll back the multi-node template change and make TextBox?'s size differently than subclasses.

Any opinions Bill?

comment:3 Changed 9 years ago by Brett van de Sande

Thanks, I went with suggestion 2. But all three suggestions seem to be work-arounds, rather than fixes. What are the prospects for fixing the problem?

comment:4 Changed 9 years ago by bill

Summary: [regression] TextBox: absolute positioning broken[regression] TextBox: user CSS migration issues

Option (1) isn't a workaround, it's just a migration step from 1.4 to 1.5. Note that's how styling for other input widgets (ValidationTextBox, ComboBox, etc.) has worked since the old days.

I'll think about it some more but I think that the good of the TextBox template change outweighs the bad. Consistent sizing of TextBox, ComboBox etc. across all the browsers is a big step forward. Plus, although there is a CSS migration headache for existing users, styling for new apps is simpler since all the input widgets are consistent.

See #11138 also.

comment:5 in reply to:  4 Changed 9 years ago by Brett van de Sande

Replying to bill:

Option (1) isn't a workaround, it's just a migration step from 1.4 to 1.5. Note that's how styling for other input widgets (ValidationTextBox, ComboBox, etc.) has worked since the old days.

Thanks. So it sounds like suggestion 1 is the preferred fix? Is there somewhere in the documentation that tells me I should apply css styles to widget_divId rather than divId itself?

comment:6 Changed 9 years ago by Brett van de Sande

After some more testing ... Suggestion 1 causes the text box to appear, but the values for the positioning are ignored: the box placed in the upper left corner of the bounding container.

Suggestion 2 causes the text box to be correctly placed.

comment:7 Changed 9 years ago by bill

OK, you also need to add width: auto on the widget_helpInput... otherwise the left/right rules are fighting w/the width setting and the width setting wins. I'll attach a working version.

Changed 9 years ago by bill

Attachment: 11133.html added

working absolute positioning

comment:8 in reply to:  7 ; Changed 9 years ago by Brett van de Sande

Replying to bill:

OK, you also need to add width: auto on the widget_helpInput... otherwise the left/right rules are fighting w/the width setting and the width setting wins. I'll attach a working version.

I verified that this works for Firefox and Safari on OS X. It also works on IE 8. However, it doesn't work for IE 7 (more precisely, IE8 in IE7 emulation mode). We need IE 7 due to a VML bug in IE 8

comment:9 in reply to:  8 Changed 9 years ago by Brett van de Sande

Replying to glueball:

I verified that this works for Firefox and Safari on OS X. It also works on IE 8. However, it doesn't work for IE 7 (more precisely, IE8 in IE7 emulation mode). We need IE 7 due to a VML bug in IE 8

Oops, sorry about that. It also works fine in IE 7 emulation mode in IE 8.

comment:10 Changed 9 years ago by ben hockey

Cc: ben hockey added

comment:11 Changed 9 years ago by Douglas Hays

The height:100% suggestion from #11138 does not work in quirks mode and causes the TextBox? widgets to be 100% of the browser client height if the domNode's height is not explicitly set at widget creation time. Any other suggestions?

comment:12 Changed 9 years ago by ben hockey

i'm ok if you don't take any of the suggestions from #11138 - they were only tested on firefox. in my case, i have the rare opportunity of only needing to deal with firefox and/or maybe webkit so i can add those rules in for myself.

comment:13 Changed 9 years ago by Douglas Hays

Component: DijitDocumentation

comment:14 Changed 9 years ago by Douglas Hays

Priority: normalhigh
severity: normalmajor

comment:15 Changed 9 years ago by bill

Resolution: fixed
Status: newclosed

OK, I documented the template change in http://docs.dojocampus.org/releasenotes/1.5, so closing this ticket.

Note: See TracTickets for help on using tickets.