When switching between different vertical tabs, the margin between the upper end of the content area and the actual content is different depending on whether there is an input element with or without a label inside. This looks and feels odd and buggy.
Screenshot and patch that fixes this attached.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | vertical-tabs-align-3.patch | 567 bytes | reglogge |
| #6 | seven-vertical-tabs-922836.patch | 580 bytes | Jeff Burnz |
| #6 | seven-vertical-tabs-padding.png | 113.74 KB | Jeff Burnz |
| #3 | vertical-tabs-align-2.patch | 568 bytes | reglogge |
| #1 | vertical-tabs-alignment.patch | 559 bytes | reglogge |
Comments
Comment #1
reglogge commentedThis is probably more general and also limits the padding: 0 to only the first div within the pane in case some contrib module adds more divs to a pane.
Comment #2
Jeff Burnz commentedThis looks great, :first-child is fine by me, leaves a small visual inconsistency in IE6 which is no big deal.
I'm thinking it looks better with some padding top - to give a bit of breathing room between the top border and first form item - maybe 10 or 15 pixels? We have a big gutter to the left so I think it looks a little cramped with no top padding.
Comment #3
reglogge commentedHere's the patch again with 10px padding-top. I had to add a more specific declaration of first-child, since otherwise the radios in the comment settings (which are in their own div) would have inherited the padding and started jumping again.
On my IE6 I still see some jumping, and a very big margin on top of the fieldset "Revision information" on node/add - but this is not introduced by this patch. I won't file any IE6 issues though, as long as the functionality is preserved, I don't care about how it looks there.
Comment #4
bleen commentedwhy not
?
Comment #5
reglogge commented@bleen: I don't understand your question. Do you mean to suggest that
padding-top: 0would be better than 10px?Comment #6
Jeff Burnz commentedWhat if we zero out the padding and add 5px top padding to the fieldset?
@bleen - we need a bit of room at the top otherwise the first form item runs to close to the top border.
Comment #7
bleen commentedsorry .... I meant
padding-top: 10px;instead ofpadding: 10px 0 0;Comment #8
Jeff Burnz commentedHang on, no let NOT do what I proposed in #6, pretty sure that will create a regression for IE7 and create weird mysterious padding/margin when the last tab is selected...
Go back to #3, can we change the padding-top to 5px, account for bleens comment in #7 and we're done.
Comment #9
reglogge commentedRe 8: Done and done. This patch is based on #3 with the padding-top set to 5px
Comment #10
Jeff Burnz commentedRTBC, this is ready - been looking at this all the way through and for sure this brings a nice consistency.
Comment #11
bleen commentedRTBC++
Comment #12
sunYou realize that this does not work for IE6?
Note that I'm the last one who wants to support IE6, but the community thinks differently.
Powered by Dreditor.
Comment #13
bleen commentedthe IE6 issue was discussed in #2 & #3 and it was deemed acceptable that there will be a slight visual inconsistency on the dying (for the love of everything holy, die all ready) browser
Comment #14
Jeff Burnz commentedWe've taken the approach to not break things for IE6, but small visual inconsistencies like this are OK. This would also be the most minor thing to quibble over regarding support for IE in Bartik - for one it lacks rounded corners, transparencies, gradients etc - all the nice design attributes that make "the design"... something I am not exactly thrilled about to be frank.
Comment #15
sunAlthough badly needed, this is D8 material according to the rules (I had to learn today).
Comment #16
Jeff Burnz commentedD7 please, even if we don't get this in for RC or even release it could go in a point release.
Comment #17
dries commentedCommitted to CVS HEAD. Thanks.