Re: [Plone-UI] Plone 5 Theme

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

for plone 5 i wouldn't change much how we're already doing addon development.
the only thing we gain by separation is that addon will that does frontend
changes will never break edit form (backend stuff). in terms of steps how to
include css/js into front-end:
 - register css/js with resourceregistries under "default" bundle (which is
   default anyway
 - them diazo theme will have to "pass" this styles to front end. like we do
   now.

there will a default js and css file (result of plonetheme.barceloneta effort)
that others could depend on (by depend on i mean that they can put their css/js
after barceloneta's). only difference is that we wont manage +40 css/js files
in resource registry, but outside - in mockup.

there is ofcourse an option of advance js/css customization for optimized
custom projects, but is not required for addons to follow same practise. its
required for plone core and only advice for addons.


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

same consern was raised by ramon during the sprint. i had no clear answer since
all options are still open and it mostly depends on whoever is going to take
time to do it. i think after plonetheme.barceloneta is done we'll have better
idea what we are capable as a community.

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

we follow this "recipe" already with most of the patterns we developed in
mockup. prefix is different but there is a prefix.

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

as an option to explore: in plone.app.toolbar we are already "forcing" to open
certain urls in overlay-iframe, (eg. when you visit http://portal/url/edit it
will open edit form in overlay). we could easily make this possible for other
forms. i know sometimes this is not what is desired.

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

+1 that is also the reason why we need to continue with work on
plonetheme.barceloneta and experiemnt all scenaries. there are many ways how we
can solve problems, i won't say one is better then other until i have a chance
to see it, but i think next month or two we should experiment with this.


--
Rok Garbas - http://www.garbas.si

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk