You're not crazy, you're just ahead of your time. CSS3 has introduced the box-sizing property to address this issue. This property allows you to specify whether the width property includes the border and padding or not. (essentially reverting to quirks mode for one element). This property is getting back ported to css2 using vendor prefixes (-webkit, -moz, -ms) as it is being implemented, so we might have decent access to this property in modern browsers in the next 6mo or a year.
http://www.quirksmode.org/css/box.html I would hope that once this property achieves decent saturation, that blueprint will adopt it to make styling columns simpler. Until that time, I highly recommend that you use nested elements. I would also point out that for your needs, the OOCSS grid might be better choice. http://wiki.github.com/stubbornella/oocss Chris On Fri, Aug 14, 2009 at 12: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 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
