On 16/06/13 03:31, Elizabeth Leddy wrote:
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.
hey all, uploaded this cause it seems relevant -
https://github.com/collective/plonetheme.diazoboilerplate41
I am coding it with the goal to have a diazo theme I can hand to a CSS
designer with the most common diazo rules implemented and to have a
mockup which forces the CSS coder to cover all the Plone cases I need
them to cover.
So it has three aspects:
- The boilerplate theme itself doesn't have content in it to theme, but
the idea is that the theme when used in plone should produce HTML which
can then be re-used as the mockup file. So the mockup should be able to
do a round trip through plone and be used as a mockup again. (The only
catch is that you need to remove the absolute part of resource URLs)
- The theme has an edited version of public.css (hence this theme is
fixed to Plone 4.1). The edited version of public.css wrappes plone
styles in a 'plonestyle' class. Allowing the diazo to style plone
specific widgets.
- Lastly, the mockup is annotated with HTML comments giving an
indication of what the diazo will do - this allows some editing of the
mockup html without worrying which edits will conflict with diazo
operations.
Hopefully, I can use it as a base to form themes which will act as a
kind of "Plone Theme Contract" with my HTML/CSS coder.
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
