| Most obvious thing to discuss: __Liquid (sometimes referenced as Fluid) vs. Rigid design. __Some real-life instalation might refuse to accomodate for 800:600 screen resolutions, but a CMS theme definetely SHOULD.
|
| Any liquid "portal" (3-col) layout looks quite unaestetical to me when viewed in 800:600. It's way too crowded, the columns are usually fixed width, so the main area becomes so tiny...
|
| Any fixed layout will require horisontal scroll in small screens and will leave space on big screens.
|
| -The best solution I see is semi-liquid design that behaves like the Jello Piefecta. Fixed width left column and content area fill in all 800*screen, with a small line of right column visible, reminding to the surfer that he can horisontally scroll to see the auxilary info at right column. On 1024*screen all the columns are visible and fill all the width. On >1024*screen the content area stretches.
|
| +The best solution I see is semi-liquid design that behaves like the Jello Piefecta. Fixed width left column and content area fill in all 800*screen, with a small line of right column visible, reminding to the surfer that he can horisontally scroll to see the auxilary info at right column. On 1024*screen all the columns are visible and fill all the width. On >1024*screen the content area stretches. The header goes above left column and content area, but not above right column, like it's done in "mambo" theme here. |
| As the IE6 doesn't support min-width, it will require some cunning to achieve such effect (unless we use tables and graphuc spacers ;) )
|
| For the sake of 2 and 1 column layouts we should consider enforcing max-width too, as we don't need unreadably long strings.
|
|
|
| Another thing to discuss: __same-height columns__. Many portal-like CMSes have it as granted because of their table-based layout. But they don't necessary LOOK like that. Many real-life designs don't have any distinguishing design pattern for columns, only for modules, so the columns look as they end where the last module end. But the ''possibility'' for adding a distinguishing design for a column is of course neccessary to have for a CMS. Or am I getting too deep into details?
|
| Anyway, for a div-based layout it's necessary to provide some way to enforce the general height for all 3 columns as we need to know where to place a footer. Which is generally ends up with the necessity to add-up wrappers [http://css-discuss.incutio.com/?page=AnyColumnLongest|avaliable solutions listed]. It's only OK to me if that wrapping element is <html> or <body>, as we are in quest of reducing non-smantic markup here. Which leads us to a necessity to use positioning for header and footer.
|
|
|
| -Next item:__ position of the main menu__ in the sourcecode. If we want to get really "semantic" in our layout, we might put the main menu underneath the content area. After all, if someone loads the page, he's there not for the menu to jump to another page, but for the content. Currently we have half-soultion: hidden "skip navigation" link. Which might be good enough.
|
| +Next item:__ position of the main menu__ in the sourcecode. If we want to get really "semantic" in our layout, we might put the main menu underneath the content area. After all, if someone loads the page, he's there not for the menu to jump to another page, but for the content. Currently we have half-soultion: hidden "skip navigation" link. Which might be good enough. Because of the bug in IE6, which renders floats and formelements ABOVE dropdowns of the menu, it requires being positioned to fix this anyway. So we can actually place it anywhere in the code and then absolute position it. |
|
|
| __main menu length__. I like the idea of having "all included" menu with sub-levels. But it's hardly "designable" the way it is. There're so many items, that only very small font-size can be used. Current Jill design of menu brakes in 800*screens (right end interferes with name/logout float and some items might create second line, that merge with the bg image) For users with many permissions (like admins) it will breack even at 1024*screens. Making the font and padding betwin items smaller will render it unreadable. Possible solutions I see:
|
| *having icons only for top level items, with text names shown on hover: will be really nice looking but not if the browser switched off image loading (I often do this myself) and not really speed optimised
|
| *deliberately create a design in a 2-lines pattern (will require some creative thinking to look nice, but can become a distictive feature, making people recognise BW)
|
| -As for the suckerfish pattern, used now to style the top menu, I have agreed with xing to try and implement in HEAD another model, which I call tablemenu ([http://css-play.com|see for details]) Apart from crazy idea to nest conditionally commented tables inside <a> tag, it's the only one that works fine in IE6 without javascript at guard.
|
| + |
| +!basic html code |
| +So how much divs do we really need if we go as "minimal" as it gets? |
| +{code} |
| +<html> |
| +<body> |
| +<div id="header"></div> |
| +<div id="content"></div> |
| + ...<div class="leftmodule"></div><div class="leftmodule"></div>... |
| + ...<div class="rightmodule"></div><div class="rightmodule"></div>... |
| +<div id="menu"></div> |
| +<div id="footer"></div> |
| +</body> |
| +</html> |
| +{/code} |
| +As you can see, no containers for columns. It's too much trouble to make them equal height, so why bother. It will require some smarty or php tweaking to add new class to the module depending to what column is it assigned to, though. Some designer, willing to implement special styling for a column, can add as many wrappers as he wishes. |
| +Putting menu outside the header is not ''necessary'', but I find it fitting nicely the total concept. |
| +I placed html and body tags to remember them as possible containers for styles. |
| +Done with html, we are ready to CSS... |
| + |
|
|
| Coming more soon... |