Opened 7 years ago

Closed 7 years ago

#11133 closed defect (fixed)

[regression] TextBox: user CSS migration issues

Reported by: glueball Owned by: doughays
Priority: high Milestone: 1.5
Component: Documentation Version: 1.5.0b2
Keywords: TextBox css Cc: bvds@…, mike@…, neonstalwart
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 glueball 7 years ago.
Test case showing error
11133.html (1.2 KB) - added by bill 7 years ago.
working absolute positioning

Download all attachments as: .zip

Change History (17)

Changed 7 years ago by glueball

Test case showing error

comment:1 Changed 7 years ago by bill

  • Description modified (diff)
  • Milestone changed from tbd to 1.5
  • Owner set to doughays
  • Summary changed from form TextBox with absolute positioning broken to [regression] TextBox: absolute positioning broken

comment:2 Changed 7 years ago by doughays

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 7 years ago by glueball

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 follow-up: Changed 7 years ago by bill

  • Summary changed from [regression] TextBox: absolute positioning broken to [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 7 years ago by glueball

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 7 years ago by glueball

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 follow-up: Changed 7 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 7 years ago by bill

working absolute positioning

comment:8 in reply to: ↑ 7 ; follow-up: Changed 7 years ago by glueball

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 7 years ago by glueball

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 7 years ago by neonstalwart

  • Cc neonstalwart added

comment:11 Changed 7 years ago by doughays

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 7 years ago by neonstalwart

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 7 years ago by doughays

  • Component changed from Dijit to Documentation

comment:14 Changed 7 years ago by doughays

  • Priority changed from normal to high
  • severity changed from normal to major

comment:15 Changed 7 years ago by bill

  • Resolution set to fixed
  • Status changed from new to closed

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.