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

David Glick (Plone) david.glick at plone.org
Tue Nov 19 17:26:25 UTC 2013


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.

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

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



More information about the UI mailing list