Re: [Plone-developers] Plone 5 Theme

What I do not like the Plone when creating a theme,
use "*!important*" for almost all attributes of the css selectors ..
Maybe being a child in Plone, I'm working in the wrong way

In other CMS's, my favorite themes are those that CSS
only reset.css normalize.css or (my favorite)...

I think this would be a legal way for the initial themes Plone

Att.


2013/11/21 André Nogueira <andre-grcfPhwenrP3rCIxTHco+PB2xoqF/[email protected]>

> I know a lot of people that just use Plone as a framework.
> Just edit one custom CSS file and transform the Frontend. No python
> and no PHP too :) And no XML :)
> This is the easyer and most important way to use Plone now
>
> To me, the basic steps for a new themer (for regular users not
> advanced users) is:
> 1. Clone the default DIazo theme
> 2. Try to find and change the logo
> 3. Try to make some CSS chances
>
> Newcommer and basic users will never create a Diazo theme from the
> scracth. I dont see this action as a trivial action. Can be trivial
> just for advanced front end developers
>
> To me, trown all the Front end responsability to custom diazo themes
> could kill one of the Plone most important feature: Accessibility. We
> really need a strong starting point for new themes and for small
> customizations.
>
> To me, the only option to make plone more popular with the public you
> are aiming, is to reach this 5 points:
>
> 1. One click install in production (something like Ploud or ready to
> use droplet in digital ocean or similar players)
> 2. A great number of high quality themes.
> 3. Very easy way to customize this themes (change logo and base
> colors). A editor based in LESS/SASS will be amazing.
> 4. Very easy way to install addons
> 5. very easy way to updat Plone and addons
>
> Only after that, Plone can become popular.
>
> Andre Nogueira
> andre-grcfPhwenrP3rCIxTHco+PB2xoqF/[email protected]
> Simples Consultoria
> www.simplesconsultoria.com.br
> Tel. (11) 3898-2121
>
>
> On Thu, Nov 21, 2013 at 6:40 AM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
> > Hi,
> >
> > I'd be interested to know of those in this discussion how many do custom
> themes on a regular basis? ie take html/css or a PSD from a designer and
> construct a theme.
> > I suspect we're coming at this issue from a variety of different
> experiences and perhaps there are a lot of people on the plone developers
> list who consider themselves more of a python programmer than a FE
> developer.
> > I'm not saying that plone shouldn't be useful out of the box but I am
> saying it's a huge barrier to it's adoption by other that it is so hard to
> customise. Diazo is a massive improvement in this respect and I can only
> think that you must be doing very different work from us if you don't see
> that.
> > As an example, this week we're tutoring a fedral government department
> on how to create their own intranet. They've already installed, configured
> it, installed the plugins they want, setup the IA, dummy content etc. They
> have got a html/css design mockup in php from a web agency based on their
> ideas (we had no input). Now we'll do a day workshop with them using diazo,
> the theme editor and within the week they will have a working intranet. No
> python written, no php written. However the biggest hurdle will be
> integrating the editing UI, something that will be fixed with toolbar. The
> next biggest hurdle is to make sure all the bits of Plone UI and the right
> versions of jquery etc still work with the theme, or someone has to rewrite
> them.
> >
> > Also trying to attract Python developers to Plone IMO is a waste of
> time. I understand the attraction. We love python, and we love other stuff
> python people do. However 99% of python programmers don't need or like a
> CMS. A CMS solves problems they don't have. Most python programmers are
> happy with static html generation like pelican. I think it's our pride that
> makes us want to be recognised within the Plone community for doing
> something worthy. I certainly feel that sometimes.
> > The solution however is to grow Plone itself into something widely used
> and admired. Not by pythonistas but by people who want to build websites
> quickly and that look awesome and have huge power underneath. At least then
> not only will we still have jobs working with software we love, by
> pythonistas would at least have to admit we created something popular even
> if it's not something they can use.
> > We won't create this popularity by trying to compete with flask or
> django or by make an out a kind of app container hybrid framework thing. If
> you want to build forms and apps etc that need complex FE widgets etc then
> you probably shouldn't be using a CMS IMO (Except if you want to do it TTW
> in which Plone/Plomino is great).
> > To do this we need to attract the very people that aren't here.
> Intergrators/themers. They don't care about Plone widgets and frameworks.
> They just want software that tick all the boxes for their clients/editors,
> and doesn't get in the way of implementing their design.
> >
> > Dylan Jay
> >
> > ---
> > www.pretagov.com - Secure SaaS for Government hosted locally.
> > P: +61-2-9955-2830  +44-87-0392-7071 | linkedin.com/in/djay75
> >
> >
> >
> > On 20 Nov 2013, at 11:51 pm, Alex Clark <[email protected]> wrote:
> >
> >> On 11/20/13, 5:25 AM, Rok Garbas wrote:
> >>> Quoting Ryan Foster (2013-11-20 08:08:12)
> >>>> On Nov 19, 2013, at 6:46 PM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
> >>>>
> >>>>>
> >>>>> On 20 Nov 2013, at 4:26 am, David Glick (Plone) <
> david.glick-z4DKO/[email protected]>
> >>>>> wrote:
> >>>>>
> >>>>>> On 11/19/13, 1:27 AM, Dylan Jay wrote:
> >>>>>>> On 19 Nov 2013, at 9:02 am, David Glick (Plone) <
> david.glick-z4DKO/[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.
> >>
> >>
> >> Wow, I'm only loosely following this thread and I had to jump back in to
> >> Thunderbird to see the full discussion (I've been following things via
> >> Feedly/RSS for months.) :-) Anyway, first allow me to say this: I am
> >> very excited to see the discussion "heat up" over all things Plone 5 &
> >> in particular theming.
> >>
> >> Obviously, we have a variety of different use cases "battling it out".
> >> This is our chance to define what we want Plone 5 to be and it's
> >> important we get it right NOW, because we're going to be living with
> >> Plone 5 LATER (for the next few years at least). Now, let me take a step
> >> back from the immediate theming discussion and reiterate what I want
> >> Plone 5 to be, FWIW:
> >>
> >> - Lightweight, fast & modern, in the Python sense. This means: fewer
> >> Python packages and as much deprecation of old technologies as humanly
> >> possible. Ripping stuff out and turning stuff off MUST be the priority,
> >> and easily represents the most challenging work. `pip install Plone` is
> >> still my benchmark for this. Not because I love pip, but because it's
> >> now part of the Python core and we need to start paying more attention
> >> to it IF we want the Python community's attention[1]. I've begun some
> >> work on something called Plock to bridge the gap: `pip install plock`
> >> until `pip install Plone` actually works[2].
> >>
> >> - Lightweight, fast & modern, in the Web sense. This means: using web
> >> technologies that web developers actually understand, are already
> >> familiar with, and can begin using quickly in the Plone context. I don't
> >> care about what framework we use (e.g. Bootstrap 3) as much as I INSIST
> >> the choice be lightweight, fast & modern in the Web sense. If that means
> >> we pick Bootstrap 3 now and a new framework for Plone 6, so be it.
> >> That's a lot of work, but at least it is' *definable* work. My eyes
> >> glaze over and roll back in my head whenever the discussion turns to
> >> "how do we bring the right HTML/CSS/JavaScript in from Plone to our
> theme".
> >>
> >> Much like with Buildout, I worry our choice to rely so heavily on Diazo
> >> may have been a mistake. Instead, I think we should focus on discussing
> >> why we needed Diazo in the first place. What is Plone? Is it a system
> >> that enables inline editing of websites for every-theme-on-earth? Are we
> >> still aiming to perform every management task TTP (through-the-Plone)?
> >> If so, do we absolutely positively need Diazo to do this? If the answer
> >> is "yes", then I don't fully understand why. If the answer is "no", then
> >> I'm no better off, because I don't know how to implement the above
> >> feature set without Diazo (i.e. I need to strictly control Plone's UI
> >> and let folks 'tie in' via Diazo). Obviously mapping content to a theme
> >> is attractive, which is why we all went for it in the first place. But
> >> if you look at any other modern system that allows customization (e.g.
> >> GMail) they make it easy for you to customize AND strictly limit what
> >> you can customize. I worry that by relying on an increasingly more
> >> complex Diazo rule set we are complicating the stack and still not
> >> achieving the goal of everything TTP.
> >>
> >> Lastly, I think we should make these decisions first then decide how to
> >> approach them in the current ecosystem. If we are confident about the
> >> direction, then we should have no issue documenting our progress and
> >> leading the users and integrators by example.
> >>
> >>
> >> Alex
> >>
> >>
> >> [1] This is just one case of many: "making Plone appealing to Python
> >> programmers." Arguably not even the most important, but one that I
> >> happen to care about.
> >>
> >> [2] https://github.com/aclark4life/plock
> >>
> >> [3] Both great tools, but overkill in a lot of cases where folks just
> >> want to "do Python & Web".
> >>
> >>
> >>
> >>>
> >>>
> >>> --
> >>> 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
> >>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >>> https://lists.sourceforge.net/lists/listinfo/plone-developers
> >>>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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
>
>
> ------------------------------------------------------------------------------
> 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
>



-- 
Felipe Duardo

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