Re: [Plone-UI] Plone 5 Theme

Quoting Ryan Foster (2013-11-20 08:08:12)
> On Nov 19, 2013, at 6:46 PM, Dylan Jay <[email protected]> wrote:
>
> >
> > On 20 Nov 2013, at 4:26 am, David Glick (Plone) <[email protected]>
> > wrote:
> >
> >> On 11/19/13, 1:27 AM, Dylan Jay wrote:
> >>> On 19 Nov 2013, at 9:02 am, David Glick (Plone) <[email protected]>
> >>> 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.
>
> FWIW, I think flexibility can be a dangerous road when it comes to theming
> and can lead to issues with CSS and markup integrity. In general, if addons
> don’t have guidelines for markup and CSS they will make their own choices,
> which then makes them harder to support and theme.  A framework, in this case
> Bootstrap, might actually make theming Plone simpler and more approachable to
> new themers.
>
> I truly don’t think it would be easier to theme Plone if it were less styled
> and addons provided less in terms of markup and styles.
>
> I also don’t prefer it when addons decide to use their own opinionated
> frameworks that differ from plone core. In some cases it is justified but in
> others it is just an opinion that gets in the way of my integrating the addon
> into my theme.
>
> If we provide logical defaults and guidelines for addons that are popular,
> well tested, neutral but attractive, and easy to customize with little
> effort, I believe we make things much easier for most themers.  A framework
> does that.  Bootstrap is the logical choice because it has the most backing
> and popular support.
>
> Nothing about using Bootstrap as a starting point leads me to think that
> every site has to look the same.  If anything I think it will open the door
> for many more themes.  It does however, make it more difficult to use
> a different framework. Personally, I am fine with that trade off considering
> the simplicity that consistency and logical defaults might provide. My worst
> case scenario is that Plone makes no assertions about markup and styling and
> addons and themes diverge further than they already have.
>
>
> >
> >>
> >>> 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.
>
> Then themes will need to be upgraded, however, the guidelines for how to do
> so might be clear and consistent across the board.
>
> >
> >> 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.
>
> Again, I think not using a framework encourages addons to include more CSS
> which is then harder to work with.  Of course, it could still be optional.
> But what about the markup?  Do we make the markup optional?  How would that
> work?  Well, the theme could include diazo rules to deal with the markup for
> the addon, but that is more work for the themer.  In most cases, logical
> defaults are good, especially when they are consistent and modern.  The
> problem with plone now is that it is neither consistent nor modern nor in
> some cases logical.
>

i think we are forgetting what we are already doing.

default plone theme provides easier way to theme plone and allows addons to
know (almost) what kind of html/css to expect. in plone 4 we call it sunburst
in plone 5 we'll call it barceloneta. in the same manner addons in future could
expect barceloneta based theme. in case of high customization you will have to
manually fix things anyway.

barceloneta (as far as i know, ramon please correct me if i'm wrong) will be
based on bootstrap 3.if somebody prefers other framework please go ahead and
create your own theme in a similar fasion that braceloneta is doing it. so
there is no lockin.  i'm not huge fan of bootstap, but i recognize most of
designers/developers are familiar with it and should provide low entry barrier
and sane default.

also important to mention is that there is "minimal" theme which barceloneta is
based uppon -> no css only clean html which you can style from scratch.

i dont see much problem with addons space in future. they will continue to be
written in similar manner. what we will add is new area where addons can hook
into - let call it "backend" for now. that dom space has more predictable
css/html then frontend theme which changes from one to another project and can
more reliably hook into it.

so in short: we're *adding* possibility to addons to hook into backend. how
they hooked into frontend stays the same as in plone 4.


--
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
_______________________________________________
Plone-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-developers