Right now, all CSS is lumped under a "Skin". But choosing things like whether you put the sidebar on the left or the right should probably not be conflated with the kind of choices typically determined by Bootstrap themes (colors, font, spacing, etc)
1. rename *layout to *webpage
Going to go with *webpage for now just as a working name.
2. add more *webpage options, like "two column", "three column", etc.
3. update *style rule editor interface
You should no longer choose just a Skin. You will choose a Theme (most of what is in the current skin) and a Layout (separate CSS that governs sidebars, headers, footers, etc)
....or something like that?
Good to have some sense of organization with styles. Even more would be better. Style use patterns that could lead to a more user-friendly semantic way of editing layouts, themes and styles would be great.
Have you looked at the bootswatch skins? There are a lot of good patterns for theme-building there.
This particular idea is not about editing CSS; it's mostly about making things approachable for those who don't want to go there. If we want to make CSS editing better, that strikes me as more about edit help text and inline commenting than about rule organization.
I guess I'm a little confused. This ticket is about organizing CSS, and isn't the point of separating these things so editing makes more sense?
If you mean the part of my comment about 'semantic' editing, then I think I agree. Just like an advanced link editor and WQL generator are for people who don't want to go there. The raw styles are actually very unfriendly for developers much less wagneers.
I figured there was (themable stuff) in what we have recently added, but the point is we need to expose that structure in an accessible way. Have some example themes that can be customized further by the community. We'll want an interface where they can pick from independent menus of themes and layouts, right?
I guess it depends on what you mean by "editing layouts, themes, and styles". If you mean editing CSS, that's not really what this ticket is about. If you mean choosing them (without necessarily even knowing what CSS is), then that's exactly what this is about.
The connection is when trying to wagneer a new theme. In principle, you clone the cards that are themes and customize the clones, then make the clones part of new style cards. Then add the new components to the choices. Maybe you are also saying that you can do a lot of this with bootswatch and very little cloning?
On another level, this is about not having such a hard line between the simple choosing mode, and wanting to tweak some style element. Without any guidance and organization, we are really telling them "don't do that if you want support". We don't need anything close to discoverability, but with nothing to go on, it's hard to justify or maintain even small tweaks.
And, it isn't directly on-topic, more stuff to think about as we get towards 2.0. What's the minimum we can do to address these issues?
>On another level, this is about not having such a hard line between the simple choosing mode, and wanting to tweak some style element.
Well no, that's not what this ticket is about. It's about making it easy for people who just want to choose. That's the common case: choose only, no tweaking. I talk to a LOT of people who just want that. I wouldn't want any of the editing/tweaking stuff to get in the way of folks who just want to choose.
I definitely do think it's valuable to support a smooth entry for those who do want to tweak / create / extend (that's just not what this proposal is about). In general, I don't see much value in "cloning", by which I assume you mean something like copy and paste; I would want to be able to reuse existing stuff wherever possible. If you study how we've implemented the bootswatch, you'll see we've done a lot to make things reusable; we just haven't done much to make any of this discoverable. All good fodder for a separate Idea
--Ethan McCutchen.....2015-05-30 23:38:12 +0000
We agree. This ticket is more specific, but it does blend into the other issues at some point.
I think the connection is the process of organizing all of this better so the transition from simple stuff (just choosing) and basic customizations not so stark. I didn't mean to digress here, just to point out that this organizing is welcome for other reasons too.
I also need to figure out what you've already addressed with components that aren't so discoverable yet.
+discussed in support tickets+relevant user stories