On Saturday, June 15, 2013 at 7:53 AM, Thijs Jonkman wrote: > I really like most of what I'm reading, but I've got a few remarks on "Plone > 5's UI gets an extensive overhaul". > . > * Fewer CSS files makes finding and overriding easier > > I don't see how this would work. Fewer CSS files just means you have to > override more in one go. Which in turn means that you have more custom code > that you have to upgrade with new plone versions. In this pull request > (https://github.com/plone/plonetheme.sunburst/pull/10) we've actually split > up public.css in sunburst for better overriding. Also, is finding really an > issue? It's easy with most editors to find across multiple files, and tools > like firebug, directly point you to the right file and line. If we didn't have so much !@#$ css I think the way people deal with theming would dramatically change. I personally never override, and instead just make stronger selectors in my own css. This is the right way™... but I know that the use case and skills make people do otherwise. Like you say below, switching to a more modern framework will help immensely. I feel like people are still clamoring for the old school base_properties and we can recreate that "feeling" with different tools. Additionally, a modern theme to begin with should reduce the number of customizations.
FYI, for Plone 5 you will not be required to switch to the new theme at all. This will be the OOB theme for new sites. > It should be easier to customize defaults. After a lot of talk on embracing > the future for plone javascript, we should do the same with css. Moving to > diazo and p.a.toolbar seperates the complete front-end, thus actually making > it very easy to do things the new way. We should move to using a framework > for the base of plone theming. We should start using a preprocessor (sass, > less,...) for css, using variables to give a flexible base to jumpstart the > theming process and keep your themes up to date. > > > I agree here 100%. We need some serious CSS vision and this is one place where we haven't had a lot of strong opinions step up (mine are mildly spicy). I'd love to see this thread turn into the type of discussion that occurred over javascript. If you (or anyone) thinks they have a grand vision for modernizing the Plone css framework, please raise your hand. Now is the time to plot, plan, argue, and agree! > * Deco.gs (http://Deco.gs) is replaced with a more commonly-used grid > system, responsive > > Is there a solid, grounded reason to leave deco.gs (http://deco.gs)? The last > few months I've been playing around with creating diazo css framework parent > themes*, which would make it easy to create child themes, using a lot of > predone rules to mold the content into what the css framework expects. This > has exposed me to a lot of grid systems and frankly I havent really seen > anything better than deco.gs (http://deco.gs). Most of them use row column > structures, like deco.gs (http://deco.gs), but none of them allow you to > shift around your content order as beautifully as deco.gs (http://deco.gs) > does. It is really easy to understand how deco works and it's actually really > easy to make it responsive. Just nullify the grid classes with a media query > and add a max width to the container (#visual-portal-wrapper). For me > currently the most sensible basis for a new plonetheme would be the PureCSS > framework with Deco.gs (http://Deco.gs). Officially: deco.gs has no maintenance outside of the plone community. The vision was never followed through and designers outside of plone don't use it. It's in our best long term interest to move to something thats maintained by a community smarter than we are. We need to think about people who hire external designers and what they work with. Personally: I haven't had the same experience. If I never see another negative margin again it will be too soon. I LOVE working with bootstrap and even 960. I'll trade the flexibility for something maintained and industry standard any day. > * https://github.com/TH-code/diazotheme.framework.plone, > https://github.com/TH-code/diazotheme.framework.bootstrap, > https://github.com/TH-code/diazotheme.framework.baseline, > https://github.com/TH-code/diazotheme.framework.amazium, > https://github.com/TH-code/diazotheme.framework.goldilocks, > https://github.com/TH-code/diazotheme.framework.kube, > https://github.com/TH-code/diazotheme.framework.purecss, > https://github.com/TH-code/diazotheme.bootswatch > > > It would be awesome if you updated these README's so that people knew what they did. I'm sure its great work so make sure to promote it well :) Liz > > > > On Fri, Jun 14, 2013 at 11:57 PM, Eric Steele <[email protected] > (mailto:[email protected])> wrote: > > So, as you've likely noticed, we spent a lot time of talking about Plone 5 > > during the recent Plone Symposium Midwest. I think we've reached the point > > where can really start prioritizing concepts for a major release. > > Obviously, any changes need to go through the Framework Team for final > > approval, but I've got a bully pulpit and I'm not afraid to use it. > > > > Here's how I'd like to see development focused over the near term: > > > > * Plone 5 ships with Dexterity as its default content type story. > > * Dexterity versions of plone.app.event and plone.app.collection > > * Better set of widgets (plone.app.widgets) > > * Products.Archetypes, Products.ATContentTypes, > > archetypes.schemaextender remain available as add-ons for older content > > * Full multilingual story available (plone.app.multilingual) > > > > * Plone 5's UI gets an extensive overhaul. > > * Diazo becomes the default theming story > > * Fewer CSS files makes finding and overriding easier > > * No more !important in its CSS > > * Editing interface is separated from content for easier styling > > (plone.app.toolbar) > > * Accessible: WCAG- and ATAG-compliant > > * Deco.gs (http://Deco.gs) is replaced with a more commonly-used grid > > system, responsive > > * New folder contents UI with filtering and batch operations > > * Improved, tested widgets > > * TinyMCE gets upgraded to version 4.0, with a simplified integration > > making it easier for us to stay up-to-date > > > > * Plone 5 ships with an empty portal_skins. > > * Exists for add-ons > > * Most content moved to browser views, z3c.form > > * Login rewritten to use views, events. Simple, but pluggable for more > > complex use cases > > * Pay attention to proper XSRF protection for our most common > > functionality > > > > * Plone 5 has amazing test coverage. > > * Migrating scripts from portal_skins to browser views allows more unit > > testing > > * New JavaScript practices mean more unit tests for our interactive > > stuff > > > > * Plone 5 is faster. > > * Chameleon reduces rendering times by 30% > > * Date formatting is handled on the client side > > > > * Plone 5 is easier to learn. > > * plone.api covers most common development tasks. > > * Plone 5 eats its own dog food and sets an example for: > > * Views > > * z3c.form > > * Dexterity > > * Diazo > > * JavaScript integration/development requires less knowledge of Plone > > * Theming requires less knowledge of Plone, less fighting with the > > default setup > > > > And most importantly... > > * Plone 5 is achievable within the next 12 months. > > > > There are, I'm sure, 30 other features that are in some stage of > > not-doneness, and while I'd like to see us do everything, we need to find > > some kind of scope. I think the above featureset gives us a nice range of > > features, a not-too-painful upgrade, and gives everyone plenty to do over > > the next year. > > > > We've already begun approaching Plone companies to get buy in to the > > effort, asking for time, money or organizational support. Six Feet Up has > > pledged 5 hours per week of their QA team's time to test our work. Netsight > > is organizing a sprint to rework the login. AMP is pledging 5 hours a week > > toward deprecating portal_skins. Wildcard is taking on the folder contents > > revamp. If your group has a particular need, now is the time to make it > > happen. > > > > In addition, we have plans to use the general community excitement that > > comes along with a major release to build some momentum in our non-code > > teams. If we can move this forward, I think Plone 5 will be a big step up > > for both Plone the software and Plone the community. > > > > Eric > > ------------------------------------------------------------------------------ > > This SF.net (http://SF.net) email is sponsored by Windows: > > > > Build for Windows Store. > > > > http://p.sf.net/sfu/windows-dev2dev > > _______________________________________________ > > Plone-developers mailing list > > [email protected] > > (mailto:[email protected]) > > https://lists.sourceforge.net/lists/listinfo/plone-developers > > > > ------------------------------------------------------------------------------ > This SF.net (http://SF.net) email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Plone-developers mailing list > [email protected] > (mailto:[email protected]) > https://lists.sourceforge.net/lists/listinfo/plone-developers > >
_______________________________________________ Framework-Team mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-framework-team
