Drupal 6.14
Created a page with a 3-col 25-50-25 layout
Created a mini panel with a 1 col layout
Located mini panel in center column of page (content of page)
When I display the page example.com/pagename the mini panel only occupies the left half of the column.
It can be corrected for by using the following sort of CSS
#mini-panel-minip_003_000 .panel-col{
width: 100%;
}
Where minip_003_000 is the id assigned to the mini panel and the .panel-col div is the next div directly under div where id="minip_003_000"
This behavior is rather odd. I suspect it may be a bug.
It is somewhat inconvenient to have to list all the full width divs that go into the center column and set their width explicitly. So I sort of doubt that that is the intention.
Please advise.
Thanks for reading.
Comments
Comment #1
merlinofchaos commentedSo the question is: Why isn't that div full width? Divs default to 100% width, which means something must be overriding that div to not be full width. It is possible that cascading is at fault, having one panel inside another can sometimes pick up the outer panel's CSS on the inner panel accidentally. If that's the case it is actually easy enough to correct with one line to override the cascade. Knowing for sure would probably require examining the page with firebug and seeing what markup is applying.
Comment #2
ss_drupal commentedYup.
... Sound of slapping head ...
The 3 column layout asserts a class definition of:
And as it happens (Doh!) the mini-panels all have a sort of inner wrapper div defined as:
<div class="panel-panel panel-col">The code for the mini panel gets emitted as follows
That last div for the mini panel content is the one that gets the user specified class or id -- not the ones that contain it.
The only way to avoid having to list all the mini-panels that one wants blown out to 100% width within that 50% column, in a css statement like:
... would be if one had the ability to attach a class at the level of the layout, level 2 in the list above.
So it would work something like
Where userDefined is asserted in the workflow at the point of chosing the layout. Then it could be defined once and then forgotten about except to apply that class to the necessary mini panels as they are defined.
But I guess this is slowly devolving into a feature request.
At all events, thanks.
BTW, I'm expecting that my next site will be an all Panels site. So, double thanks.
=============
Actually (I just thought...) another way to avoid such inadvertent effects would be to emit slightly different class names for the parts of the mini panels, which one knows will be placed within pages and which therefore will be vulnerable to undesired cascade effects such as the one I just bumped into.
So, for example, that layout level div might be defined as:
<div class="minipanel-minipanel minipanel-col">rather than:
<div class="panel-panel panel-col">Athough I still like the idea of adding a user defined class at that level anyway. So it would then be:
<div class="minipanel-minipanel minipanel-col userDefined">This would allow a lot of fine grained control.
Anyway, thanks again.
Comment #3
merlinofchaos commentedThe classes for the columns are currently supplied entirely by the layout, and they don't actually ahve any knowledge of what kind of container they live in. Check out any of the tpl.php files in the plugins/layouts directory, you'll see.