Ticket #9315 (closed PLIP: fixed)

Opened 5 years ago

Last modified 5 years ago

New theme for Plone 4

Reported by: limi Owned by: limi
Priority: n/a Milestone: 4.0
Component: Templates/CSS Version:
Keywords: Cc: plip-advisories@…, robzonenet, grahamperrin@…, denys.mishunov@…, emanlove

Description (last modified by limi) (diff)

Proposer: Alexander Limi
Seconder: Steve McMahon

Motivation

Plone's look is quite dated, and the CSS has grown organically over the years, and is quite messy, inefficient and large. Furthermore, there's a lot of things that we know better how to pull off with the CSS techniques of today, and we have an awesome new way to do layouts with the Deco grids.

It's also a great way to signal progress in the Plone world, since we've had the current look since Plone 1.0.

Proposal & Implementation

  • Create a theme based on the new plone.org typography
  • Keep the theme color-neutral (black, white, grays), so it meshes with any company logo and doesn't feel like it requires color adjustment for doing the 10-minute-show-it-to-the-boss exercise.
  • The theme will be tableless, based on the Deco grid approach which is currently in use on plone.org. It works perfectly in all browsers, including IE6.
  • The grid works in both fixed-width and flexible-width modes, we may optionally include a switch for this if we think it's a common operation.
  • No substantial markup changes are expected outside of the table removal, class and ID names will be kept.
  • The theme will not have the same look as plone.org for the navigation parts, portlets, etc — it will only share the basic typography.
  • The theme will probably be using less files than the current theme, since we went a bit overboard there. Probably the same as trunk, 2-3 files + the print/mobile/RTL/IEFixes CSS.
  • We will "future-proof" the theme as far as possible to make the transition to something like Deliverance/xdv easy in anticipation for Plone 5.
  • The theme will use some CSS3 features, but degrade gracefully (although not identically on browsers like IE6)
  • The theme will not use any DTML.
  • The theme will be a separate Python package, which is a dependency of Plone. This way, we can make releases independently of the CMFPlone package.

Deliverables

  • A new standard theme to replace the current one, living in a separate Python package.
  • Complete package includes RTL + Print CSS, and a simple @media-based mobile stylesheet for mobile devices that use WebKit (iPhone, Palm Pre, Android) and Opera (a large variety of handsets)
  • Documentation on how Deco grids work.
  • List of changed selectors or markup, if any — to make it easy for people to update their existing themes.

Risks

  • If people reuse parts of the default Plone theme in their own themes, this will obviously change those parts. Generally, existing themes should work unless they address things in a way that depends on tables — table.something, etc. — but that's an easy fix.
  • Some re-testing with IE6 will be required — not for the grid framework, but more for things like the peekaboo bug and other standard IE6 issues. The upside is that most of these bugs disappear with the new grid approach, but there's bound to be some.
  • Some themes that re-use parts of the Plone 1/2/3 CSS (without copying the code) will have their typography and whatever else changed. This is simple to fix by copying the relevant parts from an old CSS file, though.
  • RTL needs some testers, as it is hard to test as a non-native speaker. Most of the existing RTL style sheet applies, though — since we don't change the markup.
  • If people have sites deployed using only the standard theme, their site will look different when they upgrade. This could be mitigated by providing the old theme as an add-on that they can download if they really want to keep the old look. My instinct is that people won't care, but packaging up the old CSS in a dedicated product isn't too much work, so should probably be done.

FAQ

Why not refine and use NuPlone? While NuPlone is a beautiful design, it's not flexible enough to handle being the default theme. It's way too "opinionated" — which is a good thing when you want to make something that looks good, but things like not working with flexible-width layouts, automatic moving of portlets, and stronger visual identity — all conflict somewhat with the "generic" quality that a default theme needs to have. There are several great and neutral design elements from NuPlone that could potentially be carried over (portlet design comes to mind), but NuPlone as a whole is too specific in its goals. It's also a bit too smart for its own good — since it uses some very advanced tricks to get around Plone limitations, it's less "hackable", which is something that the default theme should definitely be.

Won't this take us back to square one, where "every Plone site looks like plone.org"? There's an explicit goal to make it not look like plone.org. It will reuse some of the time-consuming parts to get right (typography, etc), but it won't use the same style except for that.

Participants

  • Alexander Limi (theme implementation, typography, browser testing)
  • Iain Claridge (designer for the current plone.org theme, helping out on the remaining design elements like navigation)
  • I will need some help with the actual Python packaging bits, volunteers welcome. :)

Progress

Some of the work is already done (the hard parts ;):

  • Deco grid system is in production on plone.org, and I have used it extensively outside of Plone for a while. I have also let people that have never used CSS before use it, and it works really well for them — it fits their brain.
  • The typography of the design (which is arguably one of the major parts since we're keeping the theme very simple) has been in use on plone.org since the redesign.

Attachments

plone 4 theme.png Download (105.5 KB) - added by limi 5 years ago.
Screenshot of the theme (will change a bit, typography from the plone.org redesign, etc)
Picture 69.png Download (138.7 KB) - added by limi 5 years ago.
State of the theme on Aug 24th, 2009 (for those of you who are too lazy to install it ;)
32929852.png Download (214.3 KB) - added by esteele 5 years ago.
State of the theme, as of Oct 1, 2009

Change History

comment:1 Changed 5 years ago by limi

  • Owner set to limi

comment:2 Changed 5 years ago by limi

  • Description modified (diff)

comment:3 Changed 5 years ago by limi

  • Description modified (diff)

comment:4 Changed 5 years ago by limi

  • Description modified (diff)

comment:5 Changed 5 years ago by limi

  • Description modified (diff)

comment:6 Changed 5 years ago by limi

  • Description modified (diff)

comment:7 Changed 5 years ago by pupq

1) The ability to change colors quickly with base_properties is much appreciated by new integrators--they really, really like it. I understand that developers think it should go away, but, if we haven't invented an easier way to make quick, broad look-and-feel changes, why make "no templated CSS" a requirement of this?

2) In general, +1 to a fresh look! People do think it's dated. Just a general warning about tableless CSS: our integrators often have rather mediocre HTML skills. Let's just make it one of our goals that they should be able to write "mere mortal HTML/CSS" and have it work. The old tableless skin from years ago had all sorts of nasty surprises when non-expert designers started working with it.

If you can make something prettier that they can successfully change, given their skills, they'll love you for it.

comment:8 Changed 5 years ago by pupq

P.S. +1 to the "reasons why NuPlone didn't work". The standard look probably does need to be a "logo at the top left, search box on the right, 3 column look" -- it should be close to the "standard corporate kind of web site". After all, the point is this is to give them something close to what they've already been told they need to make.

comment:9 Changed 5 years ago by erikrose

  • Owner limi deleted

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:10 Changed 5 years ago by alecm

  • Owner set to limi

+1

Though I agree with Joel that we may need to continue to provide a fast and easy way to globally change colors, fonts, ... as we have with base_properties. It may be that if the css is well designed and reasonably compact, css-based customization is enough. I think an add-on with the Classic Plone theme is a necessity.

comment:11 Changed 5 years ago by smcmahon

  • Cc plip-advisories@… added

comment:12 follow-up: ↓ 13 Changed 5 years ago by MatthewWilkes

Please use base_properties for CSS, and make the old theme an add-on product.

With those caveats, FWT Vote: +1

comment:13 in reply to: ↑ 12 Changed 5 years ago by rossp

Replying to MatthewWilkes:

Please use base_properties for CSS, and make the old theme an add-on product.

With those caveats, FWT Vote: +1

FWT vote: +1. With the same caveats. Doing this would also resolve my concerns about #8805.

comment:14 Changed 5 years ago by davisagli

FWT vote: +1, same caveats.

It would be great if this could also result in a doc on "things to consider when writing CSS for a Plone theme".

comment:15 Changed 5 years ago by raphael

FWT vote: +1 provided the current skin/theme stays available and existing sites won't break. We have a framework that supports multiple skin selections for a reason ;-)

comment:16 Changed 5 years ago by calvinhp

FWT Vote: +1 as long as we keep the current theme as an alternate that is bundled with the release.

comment:17 Changed 5 years ago by wichert

Can't we let this mature outside of core first, and then include it when it is?

We already did this wrong with NuPlone, and I would rather not that we repeat that mistake.

comment:18 Changed 5 years ago by esteele

Approved by FWT vote.

comment:19 Changed 5 years ago by limi

  • Status changed from new to assigned

comment:20 Changed 5 years ago by esteele

So I'm going to risk Limi never telling me his plans again and bring up some points he made during a recent chat...

Basically there were several bits of his plans for the Plone-retheme that aren't included in the original proposal that, the more I consider them, I feel need to be further discussed with the wider group.

  1. Writing the new theme in HTML 5.
  2. Pull existing theme into a new package.
  3. Removal of base_properties.
  4. Inclusion of a "change logo" and "insert CSS" form.

I'm +.5 on the first two, mainly because I would like some discussion of what, if any, theme migration challenges might be introduced.

As far as 3 and 4... As much as I hate dtml-vars, I really like having the ability to make quick changes to site colors, font-sizes etc. I'm very much in favor of providing a simple theming story of some sort, but I want to make sure we do it correctly. While these two fields would cover some of the most common use cases, do they cover enough to warrant inclusion instead of just being a bit of duct tape? Can we update this to use a more modern approach, ie a utility/view that these stylesheets can pull variables out of or are we rejecting the use of variables in our CSS altogether?

In the interest of full disclosure, we've put some time here at WebLion into building up CSSManager to do that sort of simple theming thing, so I may have a bias. I'd be remiss in my duties as release manager though if I let this slide by without us getting it right.

comment:21 Changed 5 years ago by esteele

  • Cc robzonenet added

comment:22 follow-up: ↓ 23 Changed 5 years ago by MatthewWilkes

Eric: There are at least 3 FWT members who voted yes with the proviso that base_properties would still work. I will be -1 on any implementation that breaks this.

A change logo and add CSS form would need their own PLIP, imho, so would be -1 on inclusion. This isn't intended to start a debate, Alex should implement what he's suggested and we've said we want, not something else.

comment:23 in reply to: ↑ 22 Changed 5 years ago by jensens

Replying to MatthewWilkes:

Eric: There are at least 3 FWT members who voted yes with the proviso that base_properties would still work. I will be -1 on any implementation that breaks this.

ad base_properties: I wrote cornerstone.cssvar which provides browser-resources with variables in css. And using an new (to be done) utility providing the base_properties as variables for the css would solve a problem here. But cornerstone.cssvar is in an early state and needs more testing. It works in a pure Zope Toolkit application very fine, but Five makes live difficult.

reference:  http://pypi.python.org/pypi/cornerstone.cssvar/1.0

comment:24 Changed 5 years ago by grahamperrin

  • Cc grahamperrin@… added

Changed 5 years ago by limi

Screenshot of the theme (will change a bit, typography from the plone.org redesign, etc)

comment:25 Changed 5 years ago by limi

First cut of the theme is checked in (a bit late because of the Snow Leopard build issues).

comment:26 follow-up: ↓ 27 Changed 5 years ago by robgietema

Added review in [29333].

comment:27 in reply to: ↑ 26 ; follow-up: ↓ 28 Changed 5 years ago by limi

Replying to robgietema:

Added review in [29333].

Cool, thanks!

Most of the issues noted (apart from some of the failing tests?) seem to be unrelated to the theme as far as I can see.

Changed 5 years ago by limi

State of the theme on Aug 24th, 2009 (for those of you who are too lazy to install it ;)

comment:28 in reply to: ↑ 27 Changed 5 years ago by limi

Replying to limi:

Replying to robgietema:

Added review in [29333].

Cool, thanks!

Most of the issues noted (apart from some of the failing tests?) seem to be unrelated to the theme as far as I can see.

…and are also for PLIP 9311, not this one. So that would explain it. :D

comment:30 Changed 5 years ago by spliter

I am concerned about HTML5 in Plone's default theme. HTML5 even though it accepts almost everything we had in XHTML1 is not a simple change of doctype. HTML5 is about changing markup to make it readable and have much more sense. HTML5 itself is just a wonderful markup language. But when it comes to Plone I am not sure this is a good idea to make it default for such a generic product at the moment.

  1. HTML5 needs markup changes. Otherwise what's the point of using it? If Plone will be the same XHTML1 markup with just changed doctype it doesn't make sense to me. We should either do it proper HTML5 or leave it as XHTML (maybe make it Strict instead of Transitional though)
  1. As far as I can see there are some markup changes towards HTML5 in the current theme's implementation already. Those changes make all themes done for previous Plone versions broken even though still 10 minutes away from being fixed (but companies will need people who understand what to fix). Some changes:

<div id="portal-top"> becomes <header> <div id="portal-footer"> becomes <footer> <div class="visualPadding"> becomes <aside> Technically what we do is break compatibility with existing themes that might rely on mentioned IDs without actually gaining anything since we don't do full transition to HTML5. We can add those IDs and classes to new elements of course, but then we have no point of moving to HTML5 at all. And in addition these changes conflict with "No substantial markup changes are expected outside of the table removal, class and ID names will be kept." bullet point of the PLIP.

  1. HTML5 in current implementation doesn't give any benefits except declaring we are HTML5. It's a very-very basic transition from XHTML1 towards HTMl5 at the moment.
  1. Making proper HTML 5 theme is way more than just changing main_template.pt - we have portlets, viewlets, we have control panels we have a lot of different views that need to be transformed to be proper HTML5.

Instead of making the new Plone 4 theme with HTML5 I would propose to make a group of people who would start working on transforming all templates of Plone into HTML5 for Plone 5. And this should be done already now.

comment:31 Changed 5 years ago by spliter

  • Cc denys.mishunov@… added

comment:32 Changed 5 years ago by esteele

Your PLIP has been reviewed by the Framework team. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 23.

comment:33 Changed 5 years ago by limi

(In [29871]) Branching for Plone 4 theme changes. This refs #9315.

comment:34 Changed 5 years ago by limi

(In [29947]) Lots of fixes, re-architected the structure so nesting elements no longer influences font size, and removed a lot of unnecessary declarations in the process.

Fixed most of the the issues reported by Martin. Everything should look pretty decent now, with the exception of profile, dashboard and portlets management screens. Need to make sure they use more standard markup.

Added more comprehensive TODO.txt to make sure we don't forget to apply some fixes that should happen after the merge.

This refs #9315.

comment:35 Changed 5 years ago by limi

(In [29948]) Temporarily disabled mobile.css until we get the issues with ie8.js fixed, see  http://code.google.com/p/ie7-js/issues/detail?id=197 for more info.

This refs #9315

comment:36 Changed 5 years ago by limi

(In [29949]) Updating TODO, ready for merge.

This refs #9315.

comment:37 Changed 5 years ago by limi

Remaining items are here:

 http://dev.plone.org/plone/browser/plonetheme.sunburst/trunk/TODO.txt

Some made more sense to do after merge (e.g. jQuery Tools integration, viewlet cleanup), some are waiting on bug fixes upstream (ie8.js, ZPT DOCTYPE addition), and some are outside my scope (moving code out of main_template and into views).

Let me know if you have any questions.

comment:39 Changed 5 years ago by esteele

(In [30083]) Adding merge review (+1 recommendation) for 9315. Refs #9315.

Changed 5 years ago by esteele

State of the theme, as of Oct 1, 2009

comment:40 follow-up: ↓ 43 Changed 5 years ago by MatthewWilkes

This is missing the DTML variable support that I wanted. I know Alex has claimed that it's not useful, but it is best practice and it does break products like CSSManager. FWT vote: -1

comment:41 follow-up: ↓ 44 Changed 5 years ago by esteele

One bug I've found: the dashboard link no longer works, since that anchor now opens a menu instead.

comment:42 Changed 5 years ago by rossp

FWT vote: +1 for merging

comment:43 in reply to: ↑ 40 Changed 5 years ago by limi

Replying to MatthewWilkes:

This is missing the DTML variable support that I wanted.

To collect the feedback from FWT channel:

  • base_properties for three color values really doesn't make any sense
  • We want to avoid using variables in CSS, especially using DTML
  • We'll still ship with a deprecated base_properties to ensure products don't break, but it will be marked as non-functional as far as the theme goes
  • The plan is to work with Rob (of CSSManager) to add logo customization + header HTML + ploneCustom.css support in 4.1
  • base_properties has been marked as deprecated since 2.5 (AFAIK)

comment:44 in reply to: ↑ 41 Changed 5 years ago by limi

Replying to esteele:

One bug I've found: the dashboard link no longer works, since that anchor now opens a menu instead.

Yeah, it's one of the things I need some assistance with. There are a couple of items that should be in that menu that aren't currently. Thought it would be more appropriate to add those after a merge, though.

comment:45 Changed 5 years ago by limi

Oh, and people have started working on the RTL bits now, which makes me happy. :)

comment:46 Changed 5 years ago by emanlove

  • Cc emanlove added

comment:47 Changed 5 years ago by emanlove

I've taken an initial look at RTL and submitted a few fixes. Here is a summary fixes so far and some RTL issues still to be resolved.

  • [30271] Adds some logic to reposition columns under RTL
  • [30272] Reposition the searchbox to the left under RTL
  • [30273] Reposition the personal tools tab to the left under RTL
  • [30274] Moved the vertical separators on the global navigation bar to the left under RTL
  • [30275] Repositions the status messages to the right under RTL
  • [30276], [30277] Swapped the content action menus and the view tabs respectively under RTL

Issues still to be resolved

  • The far left hand drop-down action submenu appears of the left hand side of the screen.
  • When there is no left-hand (on the right side for RTL) portlet the bullet/numbers lists appear of screen to the right.
  • Content history box has some RTL issues.
  • other ???

If anyone else sees any RTL issues under the new theme feel free to contact me.

comment:48 Changed 5 years ago by esteele

This PLIP has been accepted for merging into Plone 4.0

The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose +1 Laurence Rowe +1 Matthew Wilkes -1 Ross Patterson +1

Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.

We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.

comment:49 Changed 5 years ago by esteele

(In [30313]) Merge in PLIP #9315. Refs #9315.

comment:50 Changed 5 years ago by esteele

(In [30316]) Removing dev branches. Consider #9315 merged. Refs #9315.

comment:51 Changed 5 years ago by esteele

(In [30328]) Default to plonetheme.sunburst. Refs #9315

comment:52 Changed 5 years ago by esteele

Please assist the doc team in creating/updating documentation relating to this PLIP. See #9622.

comment:53 Changed 5 years ago by esteele

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.