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

[Dylan Jay]

On 20 Nov 2013, at 4:26 am, David Glick (Plone) <david.glick at plone.org> wrote:

> On 11/19/13, 1:27 AM, Dylan Jay wrote:
>> 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
> 
> Wow, I guess we totally disagree.
> 
> Here are some other examples:
> - collective.cover
> - Solgema.fullcalendar
> - collective.plonetruegallery
> - eea.facetednavigation
> - cioppino.twothumbs
> 
> If addons no longer have a common library of markup they can expect to work and a consistent way to inject their own Javascript and CSS, I think we basically destroy the Plone add-on ecosystem. And I think that ecosystem is a huge part of Plone's continued success. Without it we only have an archaic web framework with a better-than-average editing UI.

I'm not saying we remove the consistent way to inject CSS and JS. I'm saying we reduce as much as possible the opinion plone is putting on themes about what CSS and JS they have to implement to make a site work.
It isn't destroying the eco-system, it will make it stronger by making plugin developers develop plugins which are designed to be themed as opposed to be ones that can only be used on sites that look like Plone sites.
Most of the above plugins install their own JS which may or may not be compatible with your theme. For example collective.cover uses deco.js. Facetednav uses it's own JS. The themer will have to go through a process of testing these themes to make sure they work with their theme regardless of if they are made to be compatible with the default plone theme or not. Your suggestion doesn't prevent this unless we install every framework known. There really isn't this "common" library of JS and CSS that works with all themes. By enforcing such a set of CSS and JS you are instantly dating and straightjacketing Plone to only be used by themers that know how to work with Plones version of jquery, plones version or Jquery UI, plones version of overlays etc. We keeping the club of people that can use Plone to just us experienced Plone developers and missing the opportunity to make Plone a system that is inviting for anyone to create a site or intranet.
I see no problem with plugins being opinionated and installing their own CSS and JS but obviously they have to do this at the risk of making it less likely to be used by others since it will require more integration work. Make all Plone sites look the same doesn't solve that problem.
For example Plone's current use of jquery means that it's impossible to use custom JS in your theme that requires a later version of jquery. 
A Plone default theme should be an "example" theme, not the basis for which all themes in Plone should be built. I think it would be great to ship with multiple example themes, perhaps based on different frameworks. If a plugin requires the use of bootstrap or the CSS that comes with a certain theme then they should make that an explicit dependency of their plugin. If we can automate that, even better.

> 
>> 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.
> 
> I still think using a framework makes it easier for the themer.

Yes but which framework? If plone relies of bootstrap 3 then we lock out anyone that doesn't want to use bootstrap 3. What happens if a theme is built on bootstrap 3 and plone 5 moves to bootstrap4?
Simpler more independent plugins that are designed to not intefer with each other and have simple html that is easy to theme. I think this is the way to go.

> They can style the conventional markup, instead of figuring out what different markup each addon uses. It also provides greater flexibility. A site can be left without a custom theme, if it's look isn't important. Or the style framework can be replaced with custom CSS. Or a published theme addon can be used, since the markup is standard. If we don't try to define common markup, the *only* option is writing a custom theme. Yes, that happens for most sites by the time the site launches, but flexibility in when it happens is good.

I think there could be ways of handling this. For example a plugin could come with same css which you insert into your theme. This is as opposed to a plugin that fails to work at all if it doesn't include exactly the CSS that came with it and therefore you have to fight against the plugin CSS to be able to use the plugin with your custom theme.

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