Fave CSS

[Bill Burcham]

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/).

[Bryan]

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).

[Dane]

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.

[Bill Burcham]

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 against the need for a CSS layout framework? As they say:

Some aspects of authoring documents make separating semantics from style (in other words, meaning from presentation) difficult.

Boy that's an understatement. I mean I've read it all and done a bit too. But I swear, when I read Transcending 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?

[John Labovitz]

(Apologies for the length and the pedantics.)

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

> 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?

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/Tags.html

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.

> 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.

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

[Reid Beels]

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

> 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?

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.

> 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?

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.