May 2003 Archives
15 entries
15 entries
After following, what we thought were, fresh moose tracks into the woods for a few hours with no luck, we finally met a moose on the side of the road. Several times. Turns out this moose stayed in pretty much the same spot on the side of the highway for the better part of a full day. In fact this same moose was still there at 9pm that same night, drinking water in the gutter and lifting its head as we drove by. I took some other pictures as well. Click the moose for a slideshow.
I can’t recommend the Moose Meadow Lodge enough — hiking trails, stocked pond, easy access to Stowe, Montpeiler, Burlington, Ben & Jerry’s factory, etc., great hosts and great food.
A couple more days off before going back to work. It’s going to be hard after an unwind like this…
li tag with span and be done with I suppose — for now.
li tag with CSS?
For instance, I’d like to bold the number, but not what’s in the li. Giving font-weight: bold to the ol doesn’t do it. And giving font-weight: bold to the li tag just bolds the whole thing. I realize I could add a span in there, but that seems uneccesary.
Seems like a completely logical thing to do — give the number special treatment like bold or a different color or font size.
I’m waiting for someone to make me feel stupid. And hoping…
While I didn’t set out to create it in an A List Apart style, it did turn out that way. Perhaps the stroked fonts…
Anyhow, I was inspired to contribute to the garden — it’s already a great resource to point people, and hopefully it continues to grow.
On a related note, there’s an interesting post regarding XBL and the Zen Garden over at Dave Hyatt’s blog. Dave even demonstrates in plain English a simple example using XBL and CSS. Looks interesting, although only supported by Mozilla. I’m still a fan of XSLT because it is more standardized — but realize its limitations.
Part of the comments to this post talk about the extra span tags throughout the Zen Garden’s XHTML. They are there so that the multitude of designers that work on it can have the utmost flexibility. Sure they’re not necessary — in fact I didn’t use many of them. But that’s not the point of the excercise.
It can be done, and now there is “tranquil” place to do so. I especially like that he’s named it a Zen garden — a calm place to soothe the naysayers. I’m hoping to add something eventually, that is if I can come up with a design that’s worthy of being alongside what is already there.
It was still nice to get out and see some music though.
Here there’ll be just quick hits to stuff that I’ve found noteworthy. I still need to fix up the archive page for this, but the separate RSS feed should be working fine.
It still uses SimplePost — I just duplicated the whole thing and told it to deal with a single file, rather than multiple months.
Less Code. It’s easy to understand that a CSS layout takes far fewer lines of code than a nested table one. CSS is read once and then cached (which can be annoying at times). Less code means, faster downloads and a smaller footprint. It saves money, people. Just ask ESPN.com, who recently went CSS on their homepage, saving a gazillion terrabytes or something in bandwidth (I’m too lazy to dig up the link where this is quoted), or what we’ve just done with Fast Company — where page load has proven to decrease dramatically.
Accessibility. It’s a fact that coding with structure in mind will make the content of pages more accessible. People can easily read in text and speech readers as well as all browsers. They might not get the design details — but they will be able to read the darn thing. And isn’t that what counts the most?
CSS isn’t all that hard. It’s true. Too many are giving up because CSS doesn’t solve all of their problems easily. All it takes is a little reading. Just like it did to learn HTML — and the payoff is much greater. A lot of the anti-CSS rants I’ve been reading sound like they come from someone that does not really want to give much effort into learning it. Sure there are browser quirks. But getting around those quirks isn’t impossible.
Tables are not evil. Yes, you read correctly. Tables are perfectly fine — it’s about separating presentational markup from structural markup. When you separate, you get all sorts of benefits. Use tables for what they were designed for. Heck use them to layout a basic framework, then use CSS to handle the rest. It doesn’t have to be one way or the other. In fact, use what’s best depending on the project. Just don’t bash a technology that can improve things for everyone.
</props>
target attribute is not allowed within hyperlinks in XHTML 1.0 Strict. There’s a workaround using DOM and JavaScript (via a post on What Do I Know).
It’s stuff like this (throwing out a perfectly fine attribute, that is both dead-simple and easy to implement) that keeps me away from Strict. Using target to open links in a new (or named) window is sometimes necessary — even if you don’t believe it should ever be done from a user’s perspective. Content management systems and other web-based tools often depend on this, and complicating an elementary task such as this one will just keep more developers from adopting the Strict document type. My two cents.
So. I’m proposing that someone starts marketing 14 oz. cans. It’s gotta be a can, and it’s gotta have that 2 more extra oz. It’ll be just enough to take that last sip after you’ve polished off that BLT.
A tiny web design studio founded by designer and author Dan Cederholm. We deliver hand-crafted pixels & text from Massachusetts, USA. Learn more