Re: [Plone-developers] Plone 5 Theme

On Mon, 2013-11-18 at 14:02 -0800, David Glick (Plone) 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.
> 
> 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

I agree, we have to ship with a "library" of styles for default Plone
elements.

IMO, the current plonetheme.sunburst styles are way to immersive.
Diazo's vision can't be met easily - having a designer delivering a
"dummy" HTML/CSS theme and using this right away without any. The
changes I introduced with plonetheme.sunburst help a bit but it could be
better, like having better namespaces.

Is there any document, which describes, what the building blocks of a
Plone theme are? Or is plonetheme.sunburst our only organically evolved
documentation? Then, I guess, we'd have to reverse engineer this to find
out what styles we need to provide for addons.

Maybe we should start all over and really use Twitter bootstrap as a
foundation for our themes? There is a risk, that all websites will look
the same. But in it's essence, Twitter Bootstrap just gives us a better
default set of the browser's "Basic Page Style". And on top of that, any
design can be build.


> 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
> 
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers