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

Ramon Navarro Bosch ramon.nb at gmail.com
Tue Nov 19 21:13:47 UTC 2013


+100

That’s the reason I think that developing the plone 5 theme must be done plain with all the css, defining a clear skinning structure so it’s easier to overwrite or extend using add ons.

I think that we should deliver the less files ( as are on mockup ) so with a good documentation everybody can extend them and see how easy is going to be able to change the look and feel (less variables can be the new base_properties for easy skinning)

with a basic plone.less and toolbar.less we can split the edit UI and the frontend interface so it’s easy to extend and create my own look and feel.

About js, with the basic set in barceloneta theme for frontend we can cover some basic js (tinymce/dropdowns/doble-click…) 

Ramon


El 18 Nov 2013, a les 23:02, David Glick (Plone) <david.glick at plone.org> va escriure:

> 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