[Plone-UI] [Plone-developers] Plone 5 Theme

David Glick (Plone) david.glick at plone.org
Mon Nov 18 22:02:28 UTC 2013


On 11/18/13, 4:13 AM, Ramon Navarro Bosch wrote:
> Sorry for the cross-posting!
>
> I decided to write down my opinions after working at Arnhem sprint on 
> plone 5 theme, it's just a dump of what I have in mind :
>
> http://bloc.jardigrec.cat/2013/11/plone-5-theme-plonethemebarceloneta.html
>
> Go go go !
>
>
I think there's been a big thing missing from the discussion of 
plone.app.toolbar and isolating theme resources from Plone edit UI 
resources. That big thing is what it means for add-on authors: how can 
we make sure add-ons get a look and feel that fits with a site's custom 
theme?

Some add-ons only change things in the edit UI, and they'll be fine. But 
what about add-ons that provide their own portlets or viewlets, or a 
custom template that renders in the content area? These are common.

Currently in Plone there is a de facto "standard library" of markup 
available to add-on authors. You can get an idea of what's included in 
this if you look at /test_rendering on a Plone 3 or Plone 4 site. As an 
add-on developer, I don't have to spend time on CSS or work with a 
designer, because I know what markup to use for a portlet or an alert 
message or a form, and can expect that all Plone themes will provide 
styles for that markup. This idea of a markup library is similar to 
Twitter Bootstrap, only ours has evolved organically over time rather 
than being carefully designed.

We can decide to change this library of markup patterns for Plone 5 
(switch to Bootstrap, perhaps), if we want. But we can't stop having a 
library available altogether. The result would be that
1. Add-on authors have to spend time writing their own CSS
2. Different add-ons will not have a consistent look and feel
3. Themers will need to spend time overriding the styles for each 
addon's markup, rather than merely implementing styles for the standard 
markup

In other words, it would make things harder for both developers and for 
themers.

So are we stuck with the status quo where it's hard to write a Plone 
theme because you have to worry about styling standard Plone elements? 
Well, we can't avoid that entirely, but we can improve the situation:
1. We can namespace the default styles so that they only apply inside an 
element with class="plone". This way the themer can easily toggle them 
on/off, or limit their application to the content area.
2. Moving the toolbar to the top or side of the screen means the themer 
doesn't have to worry about fitting the edit bar into the design. Note 
that this is true whether the toolbar loads forms in overlays or not.

By the way, the "standard library" thing isn't just about look and feel. 
It's also about functionality. For example, as an add-on developer I can 
put a form in the content area and know that the user won't be able to 
easily navigate away after they start filling it out, or click the 
submit button more than once.

I guess what I am saying is that even if the toolbar is in its own 
iframe with its own resources, there should be some styles and js that 
add-on developers can assume will be present in the main frame. If we 
don't provide that I think we'll make Plone a much less fun system to 
write add-ons for. And I think we can do it without being too much of a 
nuisance for custom themers.

David


More information about the UI mailing list