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

Tue Nov 19 09:27:33 UTC 2013

On 19 Nov 2013, at 9:02 am, David Glick (Plone) <david.glick at plone.org> wrote:

> 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.

+1 it's something we haven't talked enough about. 
However I'm -1 that it's common.
These days a lot of the front end (FE) facing plugins can be replaced by custom diazo based solutions quickly since most plugins aren't generic enough to meet the needs of the theme. A good example is a carousel.

I had a look at plugins we often use that are FE general plugins that do require their own js and css.
- PloneFormGen
- PloneBoard
- Plomino
- collective.recaptcha
- oembed and video stuff

Thats pretty much it. Some of these use their own frameworks, for instance Plomino uses lots of JQuery UI so they don't rely on much from Plone 

In terms of Plone itself there is very little that needs styling or JS that is FE. Things like the contact form and public registrations we should try and remove I believe. These things we almost always replace by things like PFG as it gives more flexibility. We even do public user registration with PFG now via collective.pfg.signup. Commenting is perhaps another feature that requires special CSS. It's not something I've ever used but perhaps it needs to go out of the core too? Live search should be removed since it's a performance killer anyway and almost no public site would want to turn this on unless they can guarantee a very light load.
Once you take all of that out, I think you only very basic styles such as those that can be set in tinymce.
I think we should make this set of style as small as possible and should not assume that any of p.a.widgets is available on the FE.

> 
> 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

This side steps the issue that in reality themers spend that time overriding the styles assumed by a plugin, whether its provided by Plone or not. We don't live in a world where websites look like their CMS anymore. We need to encourage an eco system of plugins that make a minimum of style decisions, or make it really easy to diazo to make the markup work with our chosen style framework such as bootstrap. If we try to enforce a particular style framework on our themers we lose a lot of potential users of Plone because Plone is too opinionated. Plone should be the blanksheet that a designer can rely on to make any site they want. This makes Plone a truely useful CMS that will stand out of the pack.

> 
> 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.

There are existing frameworks outside of plone that provide functionality such as this. Chances are a themer knows and love this other framework already. They don't know the "plone" way of doing it. Chances are if they do buy into the plone way of enforcing a form a lot more comes with it. I say let them do it themselves. 

https://www.google.com/search?q=stop+navigation+away+from+form

> 
> 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.

-1
I think we should have discourage the use of plone.app.widgets in any FE plugins or themes. In fact I think we should reduce the amount of CSS and JS needed for any theme in Plone to zero JS and just the CSS in needed for the default styles editors can set in tinymce. Since the themer can also modify the tinymce styles then thats effectively zero CSS too. 

> 
> David
> _______________________________________________
> UI mailing list
> UI at lists.plone.org
> https://lists.plone.org/mailman/listinfo/plone-ui