BorderLayout html table lose padding - Ext JS
Hi Jack,
I noticed in a recent build you did (this is still the case in alpha 2) that a regular HTML table inside a nestedBorderLayout ignores any padding settings. This is very odd behavior and I don't know exactly what is causing it. It looks like one of your styles may be overridding any css classes and even inline styles on the table. It causes the table to render with zero margin and zero padding, not really ideal in every situation.
Is this intenational?
Alan
#
2
02-24-2007, 10:11 PM
OK, here is the CSS that is getting inherited:
Is it really necessary to be zerioing the margin and padding on all these tags? It forces me to explicitly style any of the tags that I will be using including commonly padded tags such as
.
Thanks.
#
3
02-24-2007, 11:52 PM
This defaulting of styles was inherited from the original YUI reset.css. It is useful in that it effectively normalizes the starting styles across browsers, as certain size and padding properties begin differently in different browsers. The best approach to ensure consistency is to start from scratch and explicitly build up the styles that you need.
If you really want to globally override any of these settings (like 'p' for instance), just add the same style declarations to your own file (included after ext-all.css) and set them to whatever you wish.
__________________
Brian Moeskau
FAQ/Tutorials/User Extensions/Enhanced Forum Search
#
4
02-25-2007, 01:30 AM
Yes that makes sense. But is it possible that the js is applying these global styles instead the document reading them in onload? The reason I ask is because these styles seem to be overriding even my inline styles which should have the highest precedence. And my thought is that my inline styles are getting applied onload and then the js is overridding the styles when it builds the BorderLayout. If this is true then it will only be possible for me to set the styles via js after the BorderLayout is complete which is not very intuitive.
#
5
02-25-2007, 01:55 AM
I assume by your code block that you are inspecting your source in Firebug's Style pane right? The fact that it lists those styles specifically as being defined in ext-all.css tells you that that's where those definitions are coming from. If they were getting overridden by js/inline styles, the ext-all.cs styles would be crossed out and there would be a separate section above them showing the inline styles (with no filename associated to them). Firebug lists the styles top-down in order of precendence from most specific to least specific, which should help you debug these kinds of style inheritance issues.
If you are re-defining those styles after ext-all.cs and they are not applying correctly, then you probably have some issue going on in your css I would guess. Either they aren't getting pulled into your doc correctly or in the correct order, or maybe the css itself is not valid. It's hard to tell what the reason might be...
__________________
Brian Moeskau
FAQ/Tutorials/User Extensions/Enhanced Forum Search
#
6
02-26-2007, 10:08 PM
Awesome, thanks for your help, it is much appreciated.
I noticed in a recent build you did (this is still the case in alpha 2) that a regular HTML table inside a nestedBorderLayout ignores any padding settings. This is very odd behavior and I don't know exactly what is causing it. It looks like one of your styles may be overridding any css classes and even inline styles on the table. It causes the table to render with zero margin and zero padding, not really ideal in every situation.
Is this intenational?
Alan
#
2
02-24-2007, 10:11 PM
OK, here is the CSS that is getting inherited:
ext-all.css (line 9)
html, body, div, dl, dt, dd, ul, ol, li, h1, h2, h3, h4, h5, h6, pre, form, fieldset, input, p, blockquote, th, td {
margin:0pt;
padding:0pt;
}Is it really necessary to be zerioing the margin and padding on all these tags? It forces me to explicitly style any of the tags that I will be using including commonly padded tags such as
.
Thanks.
#
3
02-24-2007, 11:52 PM
This defaulting of styles was inherited from the original YUI reset.css. It is useful in that it effectively normalizes the starting styles across browsers, as certain size and padding properties begin differently in different browsers. The best approach to ensure consistency is to start from scratch and explicitly build up the styles that you need.
If you really want to globally override any of these settings (like 'p' for instance), just add the same style declarations to your own file (included after ext-all.css) and set them to whatever you wish.
__________________
Brian Moeskau
FAQ/Tutorials/User Extensions/Enhanced Forum Search
#
4
02-25-2007, 01:30 AM
Yes that makes sense. But is it possible that the js is applying these global styles instead the document reading them in onload? The reason I ask is because these styles seem to be overriding even my inline styles which should have the highest precedence. And my thought is that my inline styles are getting applied onload and then the js is overridding the styles when it builds the BorderLayout. If this is true then it will only be possible for me to set the styles via js after the BorderLayout is complete which is not very intuitive.
#
5
02-25-2007, 01:55 AM
I assume by your code block that you are inspecting your source in Firebug's Style pane right? The fact that it lists those styles specifically as being defined in ext-all.css tells you that that's where those definitions are coming from. If they were getting overridden by js/inline styles, the ext-all.cs styles would be crossed out and there would be a separate section above them showing the inline styles (with no filename associated to them). Firebug lists the styles top-down in order of precendence from most specific to least specific, which should help you debug these kinds of style inheritance issues.
If you are re-defining those styles after ext-all.cs and they are not applying correctly, then you probably have some issue going on in your css I would guess. Either they aren't getting pulled into your doc correctly or in the correct order, or maybe the css itself is not valid. It's hard to tell what the reason might be...
__________________
Brian Moeskau
FAQ/Tutorials/User Extensions/Enhanced Forum Search
#
6
02-26-2007, 10:08 PM
Awesome, thanks for your help, it is much appreciated.