Since positioned Widgets are designed to be absolutely positioned, we've found that it's rarely the case that they need to remain at their document position so positioning them to 0,0 useful default to stop them from introducing whitespace at the end of a document when hidden. Please post the use case for which you feel you need the static position to be the default, and we look at building in the option to default to either.

In my case I'm using Widget to make what is essentially a rollout menu or window. It sits in it's normal position in the page flow until the user mouse-overs it and then "rolls out" to reveal its contents. I effectively want to set XY location relatively rather than absolutely since the module must start at its natural page flow location.

The WidgetPosition class lacks an API to place a widget either at it's normal location in the page flow or at a relative location. While absolute positioning may be the common case, the uncommon case is effectively impossible or very hackey.

I agree. I think the "position:relative" case is a valid one for supporting "DOM Position" default values. Will look into it for the 3.1 release.

Plugins now destroyed correctly, when host is destroyed. Fixes #2528388
View Commit:

Hmmm, commit c21506621a7c7e4905a72024e4a7f35f1a17b264 doesn't seem to have anything to do with this bug; are you sure you have the right one?

Incorrect bug # in commit message

Plugins now destroyed correctly, when host is destroyed. Fixes #2528388
View Commit:

Try that again - the commit email seems to have been resent. closing out the bug ... again.

Would the following work for your use case:

In Widget-Position's ATTRS configuration...

        xy : {

            valueFn: function() {

                var pos = [0,0],

                     posNode = this._posNode;

                if (posNode.inDoc() && posNode.getStyle("position") === "relative") {

                    pos = posNode.getXY();

                }

                return pos;

            },

            validator: function(val) {

                return this._validateXY(val);

            }

        }

Was hoping to avoid another "flag" which a developer would need to switch to change between [0,0] and current document position, as the default value.

Alternatively, was thinking of just exposing the valueFn on the prototype and letting customizations over-ride it if required.

Let me know.

Thanks,
Satyen

It seems like that would work, but why not just:

valueFn: function() {

    return this._posNode.getXY();

},

If the user of the Widget wants it outside of page flow, they can always set 'position: absolute' and then it will default to the origin of it's positioned ancestor, which should be intuitive in all but the most corner of cases. The user of Widget will be positioning the element with CSS to the preferred initial location anyways if they are following the principle of progressive enhancement.

The use case for 0,0 is the one I mention in my original comment above. When working with absolutely positioned Widgets, they virtually never need to be in their default DOM position (they normally get aligned to other elements, or the viewport), and are non-absolute in their non-progressively enhanced state. Leaving them in their default DOM position has the potential to introduce whitespace and scrollbars when appended to document.body (another common use case).

Sure, though if the widget is inserted into document.body with "position: absolute", it will snap to the origin of the page, it's only when the node lives somewhere else in the dom that it would possibly cause layout problems. But then, if you're just going to position it absolutely, what's the point of stuffing it deep within the HTML structure?

Not a big deal either way for me, just food for thought in hopes of keeping the code simple.

inserting into document.body is not likely to introduce whitespace, but appending will (it won't default to the page origin). It's also likely that when progressively enhancing, the markup could be deep within the HTML (e.g. a form, which when enhanced is a popup dialog)

Overall, point being, when positioning absolutely 0,0 seems like the most reasonable default value (as opposed to DOM position) and when positioning relatively, DOM position seems like the best default value - hence the code snippet for default value.

Widget-Position will default to current DOM XY for relative bounding boxes. Fixes #2528388. Also setup Widget contentBox to default to srcNode it provided
View Commit: