#8566 closed enhancement (fixed)
enable dijit._Widget to handle style property declared as a string or as an object
Reported by: | ben hockey | Owned by: | bill |
---|---|---|---|
Priority: | high | Milestone: | 1.3 |
Component: | Dijit | Version: | 1.2.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
currently, the style property of a dijit._Widget is a string. when programmatically declaring a widget, it seems like it would be more "natural" to declare style as an object. in order to not break backwards compatibility style would still need to be able to be a string as well.
Change History (4)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Milestone: | tbd → 1.3 |
---|---|
Owner: | set to bill |
Status: | new → assigned |
comment:3 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [16577]) Allow widget style to be specified as name/value hash, or (as before) as cssText string. There's still an outstanding issue that setting the style doesn't erase any previous style settings, since those settings may have been part of the widget template rather than set via the style attribute.
Fixes #8566 !strict.
comment:4 Changed 13 years ago by
(In [16627]) Don't use 'style' as an attribute name to InlineEditor? since that implies (as per _Widget) that all those properties should be applied to the editor, which is not the case.
Probably involves removing "style" from attributeMap and instead creating custom setter/getter.
Setter might be something like:
Unclear whether attr('style') (to query the style of a widget) should return a string or an object. I guess for maximum back-compat it should return a string but probably returning an object is more useful. I doubt anyone is calling attr('style') anyway.
Also, Widget.domNode may have style attributes (like display: none, etc) that weren't specified as part of the widget parameters but that the widget handled internally. I suppose those should be omitted from any attr('style') return value.