0

I have a very strange positioning issue at the moment. After 4 hours, I give up. I have a simple tabbed app, with simple normal layout:

http://mercmobily-bookingdojo.nodejitsu.com/pages/login (test/test) Once it's answered, I will make sure the snapshot will stay online.

There is the "top widget" that includes the Adding field at the top, and the dgrid underneath it. There is another widget, the "narrow widget", which should fall right underneath the dgrid. Instead, it overlaps it.

Position is either relative or static for all the widgets. However, the height of the top widget seems to "fall short" -- and therefore the narrow widget is placed over the dgrid.

I checked and checked and checked... any hints?

Merc.

Merc
  • 16,277
  • 18
  • 79
  • 122
  • The really strange thing is that the "top widget" seems to get its own height wrong. I don't understand why! – Merc Mar 28 '13 at 09:55

2 Answers2

1

Your #dgrid_1 has a height: 100%, but it's not the only content. There is also the 2 input fields.

Linus Caldwell
  • 10,908
  • 12
  • 46
  • 58
  • I tried to change that, so that there is enough space for the others, but still nothing... what do I need to change, in the CSS, to make it actually work? I must have tweaked every single node with Chrome! – Merc Mar 28 '13 at 09:53
1

In addition to Linus answer, to fix it you could apply absolute positioning to the edit-widget, which would extract it from the flow, obtaining the desired result:

.editing-widget {
    left: 0;
    position: absolute;
    top: 0;
    z-index: 1;
}

You also need to add position: relative to #dijit__WidgetBase_0 to align it correctly.

This will make the editing widget overlap the text contained in #dgrid_1: you can fix by adding a padding-top to its parent (#dijit__WidgetBase_0), e.g. padding-top: 36px will make the trick.

If you prefer to keep the editing widget in the flow, there's a simple css3 declaration that could help you:

#dgrid_1{
    height: calc(100% - 30px);
}

It's worth it to note that not all browsers currently support the standard CSS3 calc() function, so implementing the browser specific versions of the function may be required like the following:

/* Firefox */
height: -moz-calc(100% - 30px);
/* WebKit */
height: -webkit-calc(100% - 30px);
/* Opera */
height: -o-calc(100% - 30px);
/* Standard */
height: calc(100% - 30px);

(source: CSS: Setting width/height as Percentage minus pixels)

Community
  • 1
  • 1
Lorenzo Marcon
  • 8,029
  • 5
  • 38
  • 63
  • Thanks Lorenzo! I really want to keep the form in the document flow, because it's generated programmatically and I don't actually know beforehand the size of the adding widget (which in this case is a simple textbox,but it could well be a complex widget). My question is: what do I need to tweak to make it "work"? I tried with the height of #grid_1 but it didn't work! – Merc Mar 28 '13 at 09:55
  • Bit... I won't know how high the widget will be. This will tie me to 30px. Plus... why is this _really_ happening? Why does dijit__WidgetBase_0 have the wrong height, really? – Merc Mar 28 '13 at 10:26
  • It doesn't have the wrong height: it's set to 30%, relative to its parent. It also have two children: .editing-widget and #dgrid_1. If you set height 100% to #dgrid_1, there will be no more room for the editing widget. That's why the height of the parent is forced to be "itself" + the height of editing widget. If you remove the editing widget, everything is correct. If you want to perform more complicated alignements after the DOM is rendered, you need to add some javascript calculations (e.g.: height = 100% - ). I thought that editing widget would have had a fixed height – Lorenzo Marcon Mar 28 '13 at 10:39