Re: [Plone-developers] Plone 5 Theme

using twitter bootstrap is a fine idea IMO. We need to base it off of some
css framework and bootstrap is the most popular...


On Mon, Nov 18, 2013 at 7:36 PM, Johannes Raggam <[email protected]> wrote:

> 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
>
>
> _______________________________________________
> UI mailing list
> [email protected]
> https://lists.plone.org/mailman/listinfo/plone-ui
>



-- 
Nathan Van Gheem
Solutions Architect
Wildcard Corp

_______________________________________________
UI mailing list
[email protected]
https://lists.plone.org/mailman/listinfo/plone-ui