To follow up, from the HIG itself: A Word on Blueprint CSS
The Habari administration interface makes use of a CSS framework called Blueprint CSS to encourage a more coherent and homogeneous look and feel. You can read more about Blueprint CSS and its many virtues elsewhere. Suffice it to say, that it is good practice to stay as much as possible within the confines of its column system whenever possible. If you do need to lay out differently from what Blueprint CSS allows, consider if there exists a precedent for what you're trying to achieve, and consider adapting or reusing that solution instead, if possible. So why are we deviating from this specific point? Are arbitrary decisions on other elements within that "document" being deviated from? ~miklb On Aug 31, 10:43 am, Michael Bishop <[EMAIL PROTECTED]> wrote: > Can you explain to me why this wasn't done originally, and why my many > requests for making a decision on whether to use it and include it > before monolith was introduced to trunk went unanswered? > > ~miklb > > I'm on an island currently with little or no internet, so I haven't > been able to see this discussion finally take traction, and won't be > able to elaborate on my thoughts, but seeing this finally get some > interest is a good/bad thing, and I hope to see more when I'm back on > the mainland tomorrow evening/Tuesday morning (or sooner, depending on > how much side effect I see from Gustav) > > On Aug 29, 7:47 am, "Michael Heilemann" <[EMAIL PROTECTED]> wrote: > > > Alright, so I was asked to talk about why I don't think Blueprint CSS should > > be a part of the admin. > > It's quite simple really; it doesn't do anything we need. The admin is > > relatively small and very specialized. Most of our styling needs are very > > specific, and require specific solutions, and of those things, what we can > > grab from BP is really only the baselining (or 'reset') stuff, which is a > > very small part of it, and not really a BP exclusive. > > > But what we're getting, is not only an entire pixel-based column system, > > that doesn't allow for percentage-based columns (which is what we use) and a > > bunch of styling classes like .success, .error, .quiet, .first and so on, > > which not only do not add anything we need, but have actually managed to > > confuse me on more than one occasion by applying styling to things I hadn't > > expected. > > > Now, the reason we use percentages, in case anyone is wondering, is because > > there is no reason not to. And it allows us to switch resolution by changing > > numbers in a single place (the #page declaration in admin.css as it were) > > without having to recalculate a column-based pixel matrix. And if that > > forces us a little more leg-work in dealing with paddings and margins, then > > that's a burden I think we should take upon ourselves. > > > Now, this goes only for screen.css, and not print.css, though I suppose you > > could argue that there is little sense in printing anything from the admin > > anyway, except perhaps the log. But then we'd probably be better off > > creating a text-based export function for that anyway. > > > I've checked in a new admin.css just now, which includes the reset stuff > > from BP, and thus negates any need for BP in the admin, just to show how > > little we use. > > > -- > > Michael Heilemannhttp://binarybonsai.com --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
