What's your favorite CSS framework. Two contenders:

   - Blueprint CSS: http://code.google.com/p/blueprintcss/
   - YUI CSS foundation: (Reset, Fonts, Grid) video here
   http://video.yahoo.com/watch/1373808

I've played w/ YUI CSS foundation and found it solid and useful. Blueprint
looks perhaps a little lighter weight (e.g. nice results here
http://alestic.com/).

I've used YUI for a couple of projects, and it works really well.  However,
it's a bit of a pain to specify a grid layout other than the built-in ones.
E.g., if you want to use a left column width that's not standard, you have
to do some trial and error to figure out what percentage width you need to
set it to, like 18.345%.

I've just started using blueprint, and it seems to be more flexible in terms
of the number of columns, etc. It's cool that it divides the page up into a
bunch of (I believe 30px) columns, so you have a lot of options.  It also
uses the idea of a "baseline" line height of 18px, which apparently helps
make the page look nicer and flow better with images (as long as the image
heights are a multiple of 18px).

On Thu, Jun 12, 2008 at 12:32 PM, Bill Burcham <bill.burc...@gmail.com>
wrote:

I haven't used YUI so I can't compare the two, but I've put together a
number of sites in Blueprint CSS.  I really enjoy Blueprint, and it's
become my go-to grid framework.

I used it to build daneomatic.com and brainsideout.com, but by far the
most complicated project I undertook was implementing Blueprint on
bigwinds.com.  Everything on that site locks to the grid.  I've been
using the out-of-the-box grid setup (30px columns with 10px gutters),
however, so I don't have any experience with the ruby scripts for
generating your own custom grid structure.

Thanks for weighing in all. So this brings me to a philosophical question on
this fine Friday. How does one resolve the Absolute Good of semantic
HTML<http://en.wikipedia.org/wiki/HTML#Semantic_HTML>against the need
for a CSS layout framework? As they say:

Boy that's an understatement. I mean I've read it all and done a bit too.
But I swear, when I read
Transcending<http://www.amazon.com/Transcending-CSS-Design-Voices-Matter/dp/032141...>I'm
still struck by the fact that for each example of hand-crafted,
special-case, semantic HTML there are about a zillion counterexamples in the
real world. Source order dependencies, browser portability, crazy CSS
specification and limited time all conspire to produce a situation where
semantic HTML is the exception not the rule.

The level of knowledge and practice required to achieve the most basic
results (and achieve them across all our browsers reliably, without an army
of testers) just seems crazy. Compare doing layout in semantic HTML and CSS
to doing layout in Adobe InDesign for instance. I assert that the
requirements addressed by the two approaches are roughly equivalent and yet
you hardly have to be a high priest to do layouts in InDesign. You just lay
things out. Sheesh.

OK I'm not pickin' on anybody but take a look at corkd.com for example (by
Dan Cerdeholm himself). First off that has gotta be in the 99.99 percentile
of sites on the web in terms of semantic HTML-ness. But what's that - an
<hr>. What's semantic about that? (horizontal rule) What are those id's
"wrap", "sidebar" (oh it's on the side is it — and that's not
presentational). And as far as I can tell that site has about 2000 lines of
custom CSS code written by The Master. When he goes to write the next site
does he rewrite all that? Where are the reusable bits?

Now take a look at a YUI Grid site or a Blueprint CSS site like alestic.com.
Suddenly we've got presentational container divs and classes all over the
place w/ presentational names like "prepend-1", "span-12" and "pull-5" and
"push-4". So now our HTML is all about presentation.

So are those the choices. Either be Dan/Andy and rock the semantic house or
use a CSS layout framework and fail? Is that a false choice?

(Apologies for the length and the pedantics.)

On Jun 14, 2008, at 3:02 AM, Bill Burcham wrote:

But I must ask:  Semantic to whom?  The framework?  The browser?  The  
web developer?  The user?  The user who peers into the HTML page to  
see how well/poorly it's constructed?

Semantic HTML has always seemed like a misguided idea.  I have no  
problem with the idea of expressing content semantically, but I'm not  
sure HTML is the right place to take the fullest advantage of semantic  
markup.  It's language is too limited, too concrete, and was designed  
with the analog of printed, mostly textual publications.

And CSS doesn't help: its generally a one-to-one styling mechanism.  
It can bridge generic presentation with specific presentation ("make  
this header Helvetica"), but it can't provide more abstract functions:  
eg, creating a navigation system.  This abstraction, I think, is  
what's missing in the HTML/CSS universe.

At HTML's inception, there were two worlds: one of pixel-level object  
interaction (CD-ROM/multimedia) and one of hypertext (SGML/running  
text).  Tim Berners-Lee chose the latter.  Interestingly, early HTML  
was *all* semantic: you marked up headings, paragraphs, citations,  
lists, etc.  Here is the original "spec" for HTML:

        http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tag...

Most of those elements still function in modern HTML.  And in fact  
this is the only way I've been able to keep myself sane and still do  
web development: use old-style HTML elements (h[1-6], p, em, ul/li, dd/
dl/dt) for marking up the text structure, use logical elements (div,  
span) for defining areas that need special treatment, and very  
occasionally change the style of elements directly (eg, <p  
class="foo">).  I will even check sites using the lynx/links text-mode  
browsers just to make sure I haven't made a mess of it all.

The most pure method seemed to be pushing XML down to the browser, and  
using something like XSLT to convert truly semantic markup into  
presentation markup.  I think it was an idea ahead of its time,  
though; we were still knee-deep in the browser wars, decent web  
frameworks were rare, and most users/developers were still getting  
their heads around CSS.  I suppose nowadays the answer is  
XMLHttpRequest, JSON responses, and buckets of DOM-modifying  
Javascript code.

Of course, technology has moved on and we've solved this in a few ways:

        - Domain/content-type/browser detection: Instead of trying to make  
one perfect HTML/CSS page that properly renders on all browsers, give  
it up and create pages that are *more* specific for the user's  
purpose.  Just go full throttle and be unsemantic and concrete.

        - High-level widgets: Express the content semantically on the back-
end, and implement either server-side widgets that build HTML that is  
then sent down the pipe, or client-side Javascript widgets that are  
rendered by the browser.

        - Hold your nose and use a framework: I know this has been my  
attitude in my recent usage of YUI.  Yeah, it looks sucky and is  
unintuitive, but it works and I know I will never again vent my  
frustration for "hacks modes."  Of course, I still need a site-
specific CSS file, but I find that its content is far simpler and less  
browser-dependent.

But this is apples and oranges: you're comparing semantic HTML/CSS  
with (presumably) non-semantic page layout.

Doing semantic layout in InDesign is actually a total pain.  I do a  
lot of InDesign layouts (these days, probably more than websites), and  
am often irritated that I have to use "hacks" to, for example, get the  
first paragraph in a chapter flush left but remaining paragraphs  
indented.  There's no apparent way to do it other than a special  
substyle of a the paragraph with no indenting, and manually setting  
the first paragraph to that substyle.  Worse, there's *no* way to have  
the chapter title appear a few picas down on a page without either  
moving the text box handles, or adding a dummy pre-title line that has  
the appropriate amount of leading.

InDesign layout seems easier because the end result is just ink on  
paper; its semantic meaning is implicit in the relationships of the  
page elements.  Your choice of paper size, spacing, line measures,  
type size, font, etc., all create a meaning (if the design is  
successful) that the reader understands.  The effect is the same  
regardless of whether you (the designer) create the elements by  
directly specifying text blocks, fonts, etc., or whether you use  
InDesign's XML markup, stylesheets, anchors, etc.

And this gets back to my original point: who is the semantics intended  
for?  All that really matters, in the end, is that the user/reader  
sees the printed/web page and understands its meaning.

--John

On Jun 13, 2008, at 5:02 PM, Bill Burcham wrote:

Removing every trace of presentation isn't necessarily the goal of  
semantic markup. The ID of 'sidebar' serves a purpose to express  
something about the type of content that it contains. It's a common  
enough term in publishing (again with the cramped language that John  
mentioned) to refer to incidental material on a page that is not part  
of the page's primary content. Sidebar doesn't say, this is on the  
left, two columns wide, and has special header formatting, it simply  
denotes a section of content as belonging to a sidebar.

Overall, I agree that trying to make every class and ID relevant to  
only the content is a pipe dream due to limitations of the CSS layout  
module that require extra markup. However, this doesn't mean that it's  
time to throw things like column widths and placement into the markup,  
at least not exclusively. These grid libraries are great for  
prototyping and, really can produce some good results with very little  
effort. When I end up using them, I tend to combine the framework  
class names with my own, more semantic, class names (i.e. class="post-
body span-12"). With multiple classes on your elements, or with  
framework classes and semantic IDs, it's possible to use a framework  
and still get the benefits of writing all of your custom CSS code  
against a semantic document.

Another thing that's worth noting is that most of these frameworks  
offer a great deal of benefit even if you don't use their grid layout  
functionality. Even with just the default text styles you usually get  
baseline alignment, sane paragraphs, and an improvement in form  
usability and layout. Blueprint (and some others) are modular enough  
that you can only load the portions that you're actually using and  
build the rest yourself.