I've been playing around with theming on the new Liferay 6.0, from what I've noticed (theming side)- not much has changed, we're still using most of the same effective processes that we've had since 5.2.3. So, while I'm at it, I wanted to share with you, how I build themes on Liferay 6.0.
I usually start with something simple. I take into account, not knowing what everyone needs, but what everyone is accustomed to. So let's say for example, not all users have the same logo size, so I don't build anything too restrictive to that. I want to make sure I design something that's easy to understand and has a familiar layout.
The goal is to reach as wide an audience as possible. The users I'm intending to target need to be able to understand the information that's on the portal. I like to think of this as straightforward design.
So this first blog post, in this series of blogposts, in this post I'll be focusing on design and some strategies I use.
This is the first iteration of a theme I'll call "Slate."
I designed this really simple theme in Photoshop. It's just really simple; I haven't hashed out all the pages that a theme like this could have... but for now I'd just like to keep this simple.
It all starts out with creating the theme in my Plugins SDK environment. This way, I'll be able to make sure my theme has all that it needs in order to display all the new Liferay and Alloy UI components it needs.
The theme I've created looks pretty bare for now, it's an un-styled version of classic. It only inherits things necessary to properly display portlets and other functioning items such as the new Dockbar. Theming in Liferay 6.0 gives me much more control over the whole theme. Even the CSS normalizer is so unintrusive, it enables me to design with more prescision and less dependencies on Liferay's CSS.
I usually start out by blocking out all the elements:
You're probably wondering, what did I do the past 14 minutes? I was looking through the design and structure of the theme, what html elements came after another, then just went on and styled each that I discerned was necessary. I kept all the styling really simple. The goal was to create a simple visual representation of what I want to accomplish. I like to think of this as a preliminary sketch an artist draws. It's like a soft brush stroke or a light pencil mark. Hmm, I guess I'll call this stage of theming for me a: "CSS Sketch"
While dealing with the CSS for this, I like to think of better ways to both consolidate code and make the CSS easier to read. For example:
#navigation {
background: #333;
height: 32px;
padding: 0 10px;
}
#navigation ul,
#navigation ul li,
.site-breadcrumbs .breadcrumbs,
.site-breadcrumbs .breadcrumbs li {
list-style-type: none;
margin: 0;
padding: 0;
}
#navigation ul li,
.site-breadcrumbs .breadcrumbs li {
display: inline-block;
float: left;
}
#navigation ul li a {
color: #FFF;
display: inline-block;
height: 32px;
line-height: 32px;
padding: 0 10px;
text-decoration: none;
}
I hope you notice from this example that "#navigation" comes before "#navigation ul," and "#navigation ul" comes before "#navigation ul li." I style from the topmost element then later target the more specific children elements if needed. This way, I code less and do more.
#navigation ul,
#navigation ul li,
.site-breadcrumbs .breadcrumbs,
.site-breadcrumbs .breadcrumbs li {
list-style-type: none;
margin: 0;
padding: 0;
}The reason why I've consolidated so many selectors within the second set of properties is because these are really generic properties and values that I can re-use over and over again.
The last part is alphabetized properties and consistent code formatting. I always try my best to alphabetize my properties, it's easier to read, sort-through and deal with. The way the code is formatted is first, the selector then single tabbed line-breaks and a space after, then properties. I try to make it as consistent as possible because I never know when I'm going to need to do a regex to find and replace multiple properties.
I was able to block out everything I saw fit with 87 lines of code, I kept it simple enough and tested it in IE6-8, Firefox 3.6 and Chrome 5.0+, and it works just great. All this was achieved while keeping it within "custom.css"
Well, that's it for now in this series. In the next blog-post, I'll be writing about CSS sprites and graphic strategies I use when rationalizing sprites.
