Stacks: Block styles are not visible on blocks of stacks in the dashboard
Permalink
I'm wondering why styles of block classes, defined in page_theme.php (ThemeBlockClasses) and applied to blocks in stacks, are not visible, while (most) styles are instantly visible when applied to blocks in an area of a page?
For instance, if i have a stack containing an image block with a block class applied, setting width: 30%; float: left;, followed by a wysiwyg text block, the image will always be visible as full width in the stack.
It would be nice, if block styles applied to blocks in stacks would be visible in stacks the same way they would be visible on blocks on a page in edit mode.
In that context, another question arises: while stacks can have styles when used on a page, why is there no option to add a class to a stack in the dashboard?
Since blocks inside stacks can have styles, it would be useful to be able to preview stacks in order to see how they will actually look on a page.
Why do stacks, when being clicked on the stacks list, always have to directly open up in edit mode, instead of behaving just like a page, not opening up in edit mode by default, but just showing all blocks with all styles applied, exactly how they will look on a page? The edit mode could be enabled for stacks only after clicking an edit button, just as it works for pages.
Is this an unrealistic suggestion?
For instance, if i have a stack containing an image block with a block class applied, setting width: 30%; float: left;, followed by a wysiwyg text block, the image will always be visible as full width in the stack.
It would be nice, if block styles applied to blocks in stacks would be visible in stacks the same way they would be visible on blocks on a page in edit mode.
In that context, another question arises: while stacks can have styles when used on a page, why is there no option to add a class to a stack in the dashboard?
Since blocks inside stacks can have styles, it would be useful to be able to preview stacks in order to see how they will actually look on a page.
Why do stacks, when being clicked on the stacks list, always have to directly open up in edit mode, instead of behaving just like a page, not opening up in edit mode by default, but just showing all blocks with all styles applied, exactly how they will look on a page? The edit mode could be enabled for stacks only after clicking an edit button, just as it works for pages.
Is this an unrealistic suggestion?
Concerning the possibility to preview a stack as if it were on a page, the problem is the system doesn't know how you'd be using it.
Would you insert it in an area that also has some styling applied? A layout maybe? All it could show you is a default situation: in an area with no styling and no layout and that may or may not be what you want.
So instead, you are asked to build your stack, add what you want to it, add your class names, then add it to a page exactly as you want it and start tweaking from there.
It's just difficult for C5 to make certain assumptions so it just leaves it to you.
Would you insert it in an area that also has some styling applied? A layout maybe? All it could show you is a default situation: in an area with no styling and no layout and that may or may not be what you want.
So instead, you are asked to build your stack, add what you want to it, add your class names, then add it to a page exactly as you want it and start tweaking from there.
It's just difficult for C5 to make certain assumptions so it just leaves it to you.
Well, i understand, so that would mean, currently, block classes are better to be used for blocks on pages, while for stacks custom template styles would be the better choice. But it's not that block classes are not getting applied, they just don't show up in the stack. I see no reason why it should not be possible to make a stack in the dashboard show up styles from a theme that is in use?
Why not showing up the effect of styles of block classes, if stacks allow for their blocks to be styled by them - which of course is based on theme styles, when block styles are defined inside the theme via page_theme.php. This looks like some inconsistency to me.
And why not showing the default situation, as set in a stack, if that's exactly what i want? Why is it possible to apply a class to a block inside a stack, while at the same time it's effect is hidden, so i have to insert the stack into a neutral area of a page first, just in order to be able to check the result of my edits?
Why not showing up the effect of styles of block classes, if stacks allow for their blocks to be styled by them - which of course is based on theme styles, when block styles are defined inside the theme via page_theme.php. This looks like some inconsistency to me.
And why not showing the default situation, as set in a stack, if that's exactly what i want? Why is it possible to apply a class to a block inside a stack, while at the same time it's effect is hidden, so i have to insert the stack into a neutral area of a page first, just in order to be able to check the result of my edits?
Sorry for the long delay between answers.
You know that Concrete5 front-end pages all are within a wrapper with the class name ccm-page. Without it things won't work so well.
Anybody who designs a theme should also make sure that their styles are namespaced with that class name.
The goal is to avoid the theme styles spilling over core stuff and breaking Concrete5 interface. All it takes is a position: relative instead of absolute to wreak havoc.
When you are in the dashboard, the class cc-page is not used for core stuff so the stacks page doesn't have it. As a result having your theme's styles loaded there would have no effect and you would still not achieve the desired result.
On the other hand allowing themes styling to be loaded in the dashboard would mean taking the risk that badly design themes break stuff.
Now that is not to say I don't see your point, I do and I have faced the same issues myself.
Personally, I think the only solution that would make sense would be some kind of preview loaded in an iframe so it would be separated from the dashboard. The same they use when viewing page versions.
You know that Concrete5 front-end pages all are within a wrapper with the class name ccm-page. Without it things won't work so well.
Anybody who designs a theme should also make sure that their styles are namespaced with that class name.
The goal is to avoid the theme styles spilling over core stuff and breaking Concrete5 interface. All it takes is a position: relative instead of absolute to wreak havoc.
When you are in the dashboard, the class cc-page is not used for core stuff so the stacks page doesn't have it. As a result having your theme's styles loaded there would have no effect and you would still not achieve the desired result.
On the other hand allowing themes styling to be loaded in the dashboard would mean taking the risk that badly design themes break stuff.
Now that is not to say I don't see your point, I do and I have faced the same issues myself.
Personally, I think the only solution that would make sense would be some kind of preview loaded in an iframe so it would be separated from the dashboard. The same they use when viewing page versions.
Thank you for that information, i agree, it's actually a preview functionality that i'm missing ("apply" was a misleading wording from my side).
Unfortunately, not even styles set within a custom template do show up when editing stacks in the dashboard, at least i haven't managed to make them show up yet.
While i understand the technical reasons behind, i have difficulty to accept that as a principal. Since content can be created in the dashboard inside stacks, it seems not logical to me, from the editor's point of view, that we cannot see the (styled) result of our edits. This is actually old school backend editing again, and the contrary of what concrete5 is primarily standing for.
I'm finding stacks not only great for displaying content on multiple pages and areas, but also as a very handy wrapper for blocks, regardless if a stack is used only once or many times. Stacks have greatly developed, and folders make it possible to organize them well, so we could make extensive use of stacks - if they only would behave more than a page, with an edit mode, a preview mode and a saved mode, rather than in the "raw" way as they currently do.
Unfortunately, not even styles set within a custom template do show up when editing stacks in the dashboard, at least i haven't managed to make them show up yet.
While i understand the technical reasons behind, i have difficulty to accept that as a principal. Since content can be created in the dashboard inside stacks, it seems not logical to me, from the editor's point of view, that we cannot see the (styled) result of our edits. This is actually old school backend editing again, and the contrary of what concrete5 is primarily standing for.
I'm finding stacks not only great for displaying content on multiple pages and areas, but also as a very handy wrapper for blocks, regardless if a stack is used only once or many times. Stacks have greatly developed, and folders make it possible to organize them well, so we could make extensive use of stacks - if they only would behave more than a page, with an edit mode, a preview mode and a saved mode, rather than in the "raw" way as they currently do.
Maybe you could post an issue in Concrete5's Github repository? When things are really a problem or get enough traction from other community members, they fix them. And if the core team doesn't maybe somebody else will.
If the block styling is in a block template's CSS file then it should definitely apply.
If on the other hand, the styling is in your theme's CSS then it won't apply because theme's styling is not applied in the dashboard.