Sorry - I didn't notice the original requirement of not nesting DIV's - I just saw it as the 'easiest' way without having to create an additional set of CSS rules.
On Mon, Aug 17, 2009 at 12:45 PM, Jon Trelfa <[email protected]> wrote: > > On Fri, Aug 14, 2009 at 3:29 PM, da <[email protected]> wrote: > >> >> I'm new to Blueprint. We're using for a prototype to see if it's a >> framework that would make sense for our application templates. >> >> So far, I like how it makes dealing with rows and columns (and, as >> such, floats and clears) a no-brainer. >> >> The thing I don't like is that it's very rigid (which is partly it's >> benefit, of course). >> >> A better way to put it: out of the box, Blueprint seems like the ideal >> framework for designing a site that will mimic traditional text-heavy >> layouts such as newspapers and magazines. It's perfect for columns of >> text separated by gutters and margins. >> >> But for UI design of web applications, where it's common to visually >> block off areas with borders and background colors and padding, it >> needs some help. >> >> To explain what I'm after, I'm designing a UI that will have boxed >> areas. Let's say the left column will have a border, padding, then >> text. The right column will also have a border, padding and text. >> There will be a margin between the two columns. (for those who suffer >> through Sharepoint, think of that 'dashboard UI' model it >> uses...albeit prettier) >> >> Adding additional padding and borders to the default Blueprint DIVs >> increases the overall width, which breaks the rigid px-based grid in >> Blueprint. >> >> The current standard answer to the issue appears to be 'nest >> additoinal divs and apply borders and padding to the nested divs'. >> That's not awful, but not ideal, either...especially if I want to add >> padding to a wrapper of more Blueprint gridded divs within it. In >> addition, since we're handing off the markup to developers, I'd like >> to keep the HTML sparse as possible and avoid nesting too much. >> >> So what I've done is dynamically create a set of additional class >> names that can be used in addition to the standard span-x ones. An >> example: >> >> .span-1 {width: 30px;} /* default */ >> .span-1-boxed {width: 28px; border: 1px solid #f7eeda;} /* adds a >> border and adjusts width to accommodate */ >> .span-1-padded {width: 14px; padding: 8px;} /* adds padding and >> adjusts width to accommodate */ >> .span-1-boxed-padded {width: 12px; border: 1px solid #f7eeda; padding: >> 8px;} /* adds padding and border and adjusts width to accommodate */ >> etc for the 2-24 additional classes... >> >> I'd like to get people's opinion on this. Is this a sane solution? >> Overkill? Am I missing a blatantly obvious simple solution? Am I >> breaking Blueprint doctrine? >> >> -DA >> > > > Personally, I think it's an in-sane solution - too much extra work. Seems > like a lot of work to extend the framework like that when you probably only > have a few areas needing borders. Here's what I have done when I've needed > something similar. > > <div class="column span-4"> > <div id="left_nav"> > <!-- content here --> > </div> > </div> > <div class="column span-20 last"> > <div id="main_content"> > <!-- main content here --> > </div> > </div> > > CSS: > div#left_nav { border:1px solid #7eeda; padding:8px; margin:0; } > div#main_content { border:1px solid #aaa; padding:8px; margin:0; } > > Adding the extra DIV within the blueprint framework layout DIV is the only > extra step - two extra lines of code rather than a new, huge CSS file > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Blueprint CSS" group. 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/blueprintcss?hl=en -~----------~----~----~----~------~----~------~--~---
