Custom Query (18300 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (37 - 39 of 18300)

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Ticket Resolution Summary Owner Reporter
#4920 fixed _Container.addChild() tests for _started attribute Robert Coup
Description

dijit._Container.addChild() tests for the _started attribute on the parent widget to decide whether to call a child widgets startup() method.

16 widgets implement _Container but only 8 use _started (rough grep count).

This will only be noticeable if people are messing with containers dynamically. eg. adding a menu item programmatically after the menu is created.

Widgets that implement _Container but don't use _started:

  • dijit.form.Button
  • dijit.form.HorizontalSlider?
  • dijit._TreeNode
  • dijit.Menu
  • dijit.Toolbar

(from a quick grep, may not include everything)

#4921 wontfix Textarea: Be able to specify a minimum height Robert Coup
Description

While dijit.form.Textarea autosizes, it'd be nice to specify a minimum height for the editable area, and have it resize from that.

You can achieve this in the meantime via css:

#my_textarea IFRAME, #my_textarea DIV {
  min-height: 200px;
}
.dj_ie6 #my_textarea DIV {
  height: 200px;
}
#4979 invalid Textarea: Refactor to use <textarea> node rather than content-editable <div> Robert Coup
Description

(Filed on behalf of Alex)

Currently Textarea claims it's just a textarea that supports resizing with content.

Except that:

  • It uses an IFRAME or ContentEditable? DIV depending on browser.
  • That means lots of accessibility/event/focus-handling code wrt the rest of the page.
  • Nearly every method is a big if-else block on whether its using an IFRAME or a DIV.
  • The DIV/IFRAME is written as an inline conditional TemplateString? with inline javascript via <script> tags.
  • It processes some HTML tags via ~15 uncommented regexes, to replace <br/>, <p>, <div>, &gt;, etc.

Fundamentally, wouldn't it just be easier to be a TEXTAREA that sizes?

phiggins(?) pointed out there is a problem in FF detecting the size of content in a textarea (to shrink height, growing is ok), but surely there's a simpler workaround than going to these lengths? (helpfully solving #4929 & #4137).

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Note: See TracQuery for help on using queries.