Hi,
I have a problem with the Window widget: The widget creates a <div> and moves content of the specified element that I want to appear inside the window. Finally it all gets appended just before the closing tag of <body>.
This makes it difficult to work with e.g. KnockoutJS if a scope for the bindings is specified (the optional second parameter for ko.applyBindings()). So, for example in my application there are many scopes for different parts of the page, and the Window's <div> gets basically outside of the scope it's supposed to be in, so Knockout can't update the window's content dynamically because it doesn't know that it wants to be updated (since it's outside of the scope that Knockout looks inside).
I think it would be much better to append the new <div> just after the element that initiated kendoWindow. This would certainly eliminate this problem.
Is there any specific reason why you append the new <div> to the end of <body>?
/Jacob
I have a problem with the Window widget: The widget creates a <div> and moves content of the specified element that I want to appear inside the window. Finally it all gets appended just before the closing tag of <body>.
This makes it difficult to work with e.g. KnockoutJS if a scope for the bindings is specified (the optional second parameter for ko.applyBindings()). So, for example in my application there are many scopes for different parts of the page, and the Window's <div> gets basically outside of the scope it's supposed to be in, so Knockout can't update the window's content dynamically because it doesn't know that it wants to be updated (since it's outside of the scope that Knockout looks inside).
I think it would be much better to append the new <div> just after the element that initiated kendoWindow. This would certainly eliminate this problem.
Is there any specific reason why you append the new <div> to the end of <body>?
/Jacob
5 Answers, 1 is accepted
0
Hi Jacob,
Yes, the Window resides in the <body> on purpose and this is the way it should be. This is the only way to ensure that the widget will be outside any stacking contexts and scrollable containers, which will prevent the user from dragging or seeing the Window properly on the page.
All the best,
Dimo
the Telerik team
Yes, the Window resides in the <body> on purpose and this is the way it should be. This is the only way to ensure that the widget will be outside any stacking contexts and scrollable containers, which will prevent the user from dragging or seeing the Window properly on the page.
All the best,
Dimo
the Telerik team
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
0
Jacob
Top achievements
Rank 1
Rank 1
answered on 14 Nov 2011, 10:36 AM
OK, I understand why you choose it by default, but perhaps it should be optional whether to append after the initial element or at the end of <body>?
The way it is now makes it impossible to mix the Window widget and Knockout-bound views in large applications with many scopes.
The way it is now makes it impossible to mix the Window widget and Knockout-bound views in large applications with many scopes.
0
Hi Jacob,
Nowadays web layouts tend to be quite complex. The cases in which the Window will work while not in the <body> are rare, that's why it is worthless to invest efforts and support two different behaviors.
One more reason for detaching and moving the Window in the DOM, which I forgot to mention, is the modality.
If using Window (popup) in your scenario is cumbersome, you can try a collapsible container instead, e.g. the PanelBar.
Greetings,
Dimo
the Telerik team
Nowadays web layouts tend to be quite complex. The cases in which the Window will work while not in the <body> are rare, that's why it is worthless to invest efforts and support two different behaviors.
One more reason for detaching and moving the Window in the DOM, which I forgot to mention, is the modality.
If using Window (popup) in your scenario is cumbersome, you can try a collapsible container instead, e.g. the PanelBar.
Greetings,
Dimo
the Telerik team
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
0
Jacob
Top achievements
Rank 1
Rank 1
answered on 14 Nov 2011, 11:27 AM
Dimo,
Thanks for the answer!
I'll take a look at the PanelBar, though it's probably not what I'm looking for. I need something that doesn't break my layout, appears on an event (e.g. mouseover or click), disappears on another event (e.g. click outside) and holds rich content (i.e. the notifications list). I'd probably be better of with some kind of tooltip. Is there any tooltip widget in plans for Kendo?
Thanks for the answer!
I'll take a look at the PanelBar, though it's probably not what I'm looking for. I need something that doesn't break my layout, appears on an event (e.g. mouseover or click), disappears on another event (e.g. click outside) and holds rich content (i.e. the notifications list). I'd probably be better of with some kind of tooltip. Is there any tooltip widget in plans for Kendo?
0
Hi Jacob,
We do not have a ToolTip planned for near future, however, note that it will also be rendered in the <body>.
Regards,
Dimo
the Telerik team
We do not have a ToolTip planned for near future, however, note that it will also be rendered in the <body>.
Regards,
Dimo
the Telerik team
Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!