text:
Abstracting CSSJanuary 07, 2004
The further you abstract the structure of your markup, the weightier your CSS file becomes. It's inevitable, and by all indications, the way things are meant to go for two important reasons: it fulfills the complete separation of structure and presentation, and CSS is cachable — each new page load pulls new content alone, without pulling new presentation.
Structural purists would like you to write markup that looks like so:
Markup Listing 1
Of course, we all know that's simply an ideal. The reality these days is still something more along the lines of this:
Markup Listing 2

Why the disconnect? With gratuitous use of CSS2 and CSS3 selectors, we could very well achieve for Listing 1 the amount of control we'd expect to apply to the Listing 2 and its extra

s and
classes. Except that, thanks to a few stagnant and under-powered browsers, we can't today.
It's easy to just say that things will be perfect when the proper selectors are supported across the board, but those who dismiss the issue that easily haven't looked hard enough at the implications of the incredible CSS-fu necessary to make the first example work. How do we hook into the second

 of the

, for example, if more than one

 exists on the page? The corresponding CSS for Listing 2 is easy:
#nav .about {}
Or simply, if there prove to be no conflicts with other elements on the page,
.about {}
What about the code in Listing 1? Consider the following snippit:
h3 + ul > li + li {}
Technically this selects all instances where a second
li is immediately adjacent to the first, so it works for selecting the second one, but we'd have to go further and override the rest of the
li elements in that particular list. Of course if we were trying to target the 8th element in any given list, that trailing group of
li + li + li + ... selectors gets awful long. CSS3 minimizes this by introducing the
:nth-child pseudo-element:
h3 + ul li:nth-child(8) {}
Neither of the previous two work in all of today's browsers. But we're exploring the future here, so stay with me.
Let's say we've written our selector to target the above-mentioned second

 in the list in Listing 1,
.about. Now we want to add modest formatting to the link within, say a style each for the
:hover, and
:visited states. We'll forget
:active for now, but assign the same style to
:focus that
:hover will get:
h3 + ul > li + li a:link {}
h3 + ul > li + li a:hover,
h3 + ul > li + li a:focus {}
h3 + ul > li + li a:visited {}
For comparison, the equivalent code for Listing 2:
.about a:link {}
.about a:hover, .about a:focus {}
.about a:visited {}
Now, so far we've assumed that there will only be one instance of the mentioned
h3 + ul adjacency. What happens if our document is littered with this particular one-after-the-other combination? How would we target a single item and style the links we mentioned above? What if we're relying on a parent element (perhaps an
id assigned to the
 element) to specifically style the link on a per-page basis? Let's extend the above example to address these what-ifs:
#homePage h3:nth-child(3) + ul > li + li a:link {}
#homePage h3:nth-child(3) + ul > li + li a:hover,
#homePage h3:nth-child(3) + ul > li + li a:focus {}
#homePage h3:nth-child(3) + ul > li + li a:visited {}
Clearly there's a problem here. As the markup simplifies, the necessary selectors increase dramatically. The current state of affairs says that the CSS equivalent of an old-school table-based design reduces the code's byte-size by roughly 50%. That's not a hard number, but the case is strong that file size savings are to be had. If the markup simplifies further, will the CSS complexity (and size) increase proportionately, or exponentially?
I've explored just this in the past. I'd even revise my numbers upwards — I now foresee writing CSS files of 80k to 100k and beyond. While comparing this experience to old style sites that wasted all their bandwidth in the markup is a valid point, I can't help but wonder about the future once we've stopped doing that.
There's a digression here about authoring files of that size, especially when you need to edit but one single selector. I'll save it, since I'd imagine most who work with 15k CSS files can easily see the consequences of that much more bulk.
There's another digression here about the selection methods used above, and how they're ultra-reliant on linear ordering. This again will be saved, though it bears investigation some time down the line.
Most of this isn't a problem now. Odds are it won't be for many years. But this is the ideal that we're supposedly moving toward, and I'm not quite sure how ideal it is.
Reader Comments
"Next up: why client side xslt is bad."
-I am anxiously awaiting your post
In vague relation to this topic:
Honestly, I think the real thing that CSS support in the future will change is extraneous markup. Getting rid of IDs and classes isn't necessarily ideal, especially if these further identify the content (as opposed to having a "bold" class and a "leftBar" ID). The real deal in coming implementations of CSS will be content generation.
Currently my site's design employs several extra, non-semantic DIVs just to apply a custom border. CSS3's content generation module is awesome; I'll be able to put in the extra design-related elements in as I see fit, without touching the markup (plus, CSS3's border's module will eliminate this particular case of extra DIVs, but it was an easy example).
Don't get me wrong; complex selectors are quite useful, and will probably reduce the number of unnecessary IDs and classes, but I don't see a need to get rid of them all. The real awesomeness is in content generation.
" … there's gonna be alot of trouble finding the particular class when you need something changed."
I've started indenting elements in stylesheets to identify dependencies. It makes things a little easier to track. Or it would if things weren't broken across multiple stylesheets. Even so, it creates a clear indication of whether a style declaration exists on its own or if it needs to be placed inside another element before it applies. Anything to make the CSS scanable again. You can see the germ of the idea (it's about 6 months old) here: http://www.nh.gov/osp/SmartGrowth/includes/base.css
jgraham wrote"
"Having a class element is not a bad thing, because the �semantic poverty� of html is a design feature. Semantic poverty is good because it allows the html language itself to stay clean and *simple*, with most elements being general purpose and only a few elements with narrowly defined semantics. Class then allows the author to add structure* relevant to his or her particular topic.
*Structure. /Not/ semantics. Using classes does not add semantics unless you also provide a rigorous specifcation detailing the type of content in each class."
Which is why it really burns my toast when people use  to italicize some text, and *think* that by doing so they're being more "semantic."
Rather than using  or, if that's too much trouble, using the humble  element, they take one of the few elements of HTMLwhose semantics convey definite meaning (the text herein is *emphasized*) and spooge it.
I personally prefer markup example 2 simply because if I were to look at example 1, I would be hard pressed to tell what each part was. ID and Class are not a bad thing, and there is no reason to get rid of them, and indeed they are necessary. Sure, complete division of structure and presentation is a nice ideal, but it's just that, an ideal.
If my CSS files have to bloat from ~3k (with very minimal hacks, as I don't believe in CSS hacks unless I have to) to obscene filesizes just to create a more pure division, that's going too far. I definately embrace XHTML and CSS, but I prefer my data being able to tell me what a portion of content is, whether it be a masthead, menu, or whatever, rather than having to guess, and playing markup games to style my navigation list for example. (When can I have <nl>s?)
I really look forward to full-CSS3 availability times. Markup 1.01 would be my choice, with .01 being that I would add ids to particular headings and then gladly use that complicated syntax to define styles for elements going with that header.
I'm sick and tired of changing my HTML, just to be able to implement particular layout.
OKthen: "why client side XSLT is bad".
It's slow. To view a normal html document, you need to download and parse a single file. If the file links to any other files (in particular, those with rel="stylesheet" or rel="script"), those files need to be downloaded and parsed. In the XSLT case, it is necessary to:
Download the XML source.
Parse the source
Download the XSLT file
Parse the XSLT file
Run the XSLT file against the source
Parse the resulting document
Download any linked documents such as scripts or stylesheets.
Parsing XML is not known for speed, and this could certianly be a problem for low speed devices such as PDAs or phones.
It's inaccessible. This is the real killer. At present, only two browsers I know of support XSLT - IE and Mozilla. However, for XML+XSLT->HTML to be accessible, it must be perfectly supported by everyone. If a browser doesn't support CSS, it is still possible to use the document. If a browser doesn't support XSLT and the document uses some madeup markup language the user doesn't have a recourse. They will be presented at best with an XML tree (like viewing a raw RSS feed), at worst with a bunch of unformatted text, or a blank screen. Because web browsers are highly optimised for HTML viewing, even if the user goes to the trouble of reading this bundle of text, features such as links won't work*. The situation with oral browsers is even worse. To my mind, this alone is enough to file client side XSLT under "fundamentally broken", except perhaps in a controlled-browser environment.
It doesn't provide additional seperation of presentation from content, especially where there is scripting involved. Although you can generate different presentations of a document using XSLT, the DOM used by client side scripts is still that of the final document. So any client side scripting you want to use still has to know about the final structure of the document.
It provides no benefit to the user. If you feed a user a made up dialect of XML, it doesn't provide the user with any additional semantics they can use in a meaningful way, unless you yourself provide specalised tools. The simplest example of this is trying to obtain the source of the html document. View-source gives the original untransformed file in both existing implementations. This means that I can't look for (say) ids that I can use as fragment identifiers. Moreover, the user's tools have to work with the transformed document, since they are designed to process html- so these applications are not getting any additional information above and beyond what is provided by the html - a screenreader cannot work out that your <book> element represents the name of a book and should be read as such - it still has to rely on the transformed  and an appropriate stylesheet. This increases the complexity, whilst reducing the usability.
On the other hand, I think that /server side/ XSLT or indeed any kind of server side transformation which allows you to keep your documents in files which are easy to author** and use markup which matchs their logical structure is an /excellent/ idea. In fact, if you are planning on going XHTML (with proper mime types of course), having some sort of content management system that deals with XML properly is all but necessary***. However, I don't see any value in burdening the client with random XML, especially given the serious drawbacks that approach has.
* Xlink isn't a solution either, unless you expect every UA to support Xlink.
** This doesn't have to be XML, of course. Jacques uses something like LaTeX to write equations which are then converted to MathML because authoring in MathML is tedious at best.
*** Unfortunatley, this means that XHTML will never acheive its stated goals. People just aren't good at writing well formed markup, particually if the document itself isn't rigidly structured - as is the case with all HTML documents. Instead, we'll see XHTML 1.x documents that are just as malformed as HTML 4 documents, but with a different doctype.
I, for one, would rather edit a 100k CSS file than have to edit each and every page on an entire site. Surely this is the whole point? It might be easier to do with the likes of Dreamweaver but like many others here, I still use a text editor. What is needed is better structuring of the CSS in order to make it easier to find specific selectors etc. The only advice that I can find concerning the structure is about making sure you name things sensibly. This is obviously not enough. A logical pattern would make even a 100k file easy to change. I just wish I could figure one out!
This is a test, I have submitted several comments and they do not show up.
An exponential increase in CSS size will still decrease overall bandwidth usage because the ids and classes in the HTML would otherwise be downloaded anywhere from five to hundreds of times. If the concern is downloading the 100k in one shot, by the time CSS 3 is actually implemented on 85% of browsers you can also expect 85% of your visitors to have broadband internet access.
I think the problem with large CSS files is not so much the size (although maybe 100Kb is quite large, one can compress the file or split the CSS into several sheets representing useage patterns across the site, for example) but the complexity of editing such large files.
As always, the tools will save us all :)
At risk of being like mpt and linking all my own work, see http://zeus.jesus.cam.ac.uk/~jg307/index.xml#date2003050720 for some suggestions I made regarding Mozilla Composer (lately Nvu). In particular, when editing an html document, one should easilly be able to get a list of all selectors from any source that apply to the current element. Maybe Dreamweaver already allows this - I haven't used it for quite a while.
I agree with Jacques and Gerrit.
Counting down the s when you can simply identify the
right one with simple and bandwidth effective (compared to li+li+etc) id="foo" seems the right way to do. And less prone to errors too.
nth-child would reduce the usage of class attribute I guess, but that's a different story.
100k CSS files brings up another problem… sure, the overall bandwidth usage of a certain site may go down a lot, the initial (and all important) first page load (eg home.html) – the first impression a user gets – might mean a 10k html file PLUS 100k+ of linked CSS and JS files.
110K+ download for a first impression? That's pretty scary!
I think this is an excellent argument for splitting CSS up into smaller files, given the user the styles they *need* for a certain type of page, rather than the styles for an entire site.
To get back on topic, I don't believe that this is the intention of where CSS+XHTML is going at all – it's just an extension which will become useful, and perhaps reduce the number of divs required to achieve certain effects, NOT a replacement.
If divs, spans, classes and ids were on the way out, I think they'd be labelled as deprecated.
The good news is that until a div IS deprecated, we won't have to change our ways at all.
re: previous post about broadband
Perhaps in richer countries but in poorer countries, modem connections may be the only solution for a while.
Are we seperating content from presentation so our pages are available to a wider audience?
with bloated css files are we going against this?
"Are we seperating content from presentation so our pages are available to a wider audience? with bloated css files are we going against this?"
I suppose the argument could be made that dial-up users can always "turn CSS off" in their browsers to avoid downloading bloated css files in the same way that some dial-up users "turn images off" in their browsers.
I think this actually demonstrates one of the benefits of diverting page weight from your markup to your stylesheet: content (what's important) is still accessible to all.
To repeat a bit more bluntly what a few people have said : Whose-the-heck ideal is markup without classes or IDs? Using classes and IDs RATHER than proper elements is the semanticists'/structuralists' beef, not classes or IDs themselves. Indeed, the "ideal" selectors listed above are not just unsupported and convoluted, but just plain WRONG.
There're "semantics" to styles too. "I want to apply this style to the eighth item in this list" means something COMPLETELY DIFFERENT from "I want to apply this style to //this particular// item." These plain-English statements are how you decide what selectors to use; they're how you distinguish whether a class, or an ID, or a descendant selector, etc. etc., or a combination thereof are appropriate. And if you go by those statements, your use of superfluous classes and IDs is greatly reduced.
BUT, who's even to say that there's any such thing as a superfluous class or ID? Yeah, maybe bytewise you don't want to use them unnecessarily. But if you establish that one element belongs to a class, why shouldn't you put it on other elements that belong to it, even if you don't want to style them? Likewise, if you give an element an ID, why shouldn't you give its siblings IDs to match?
You can say that classes and IDs aren't just there to be hooks for style, but they ARE there to be hooks for things in general. Maybe someone somewhere someday will run your code through their own special parser or something; I don't know, I'm not totally up on the projected future coolness of XML, or what the semanticists say people should be able to do with others' code. But I do know that being stingy with classes and IDs cannot possibly help anyone, anywhere, in any way, except for shaving a few increasingly unimportant bytes off the file.
From someone who uses XML/XSLT daily I don't agree with the "no benefit to the user" comment. We have a pretty complex web app with dataviews, tabpanels, custom event binding and communication, validation, full CSS liquid layout, DHTML select boxes, error handling, help system, RPC, etc. This app is used 24/7/365 and our response time per page has to be on average 5 seconds. The majority of the time it's within 3 seconds (average, most pages are subsecond, a few go up to 30 seconds because of backend systems).
We use XSLT in both server side and client side parsing modes and can switch depending on the user/client.
The gain from client side use for certain clients is mostly from a caching point of view. If I have often used data or some of our more generic templates, they can be cached at the client and help reduce our bandwidth and off load some of our server CPU cycles. We haven't noticed any appreciable speed difference between the two methods of parsing.
I mean if we argue that parsing XML/XSLT is slow can't the same thing be said about parsing on the server as well. The difference there is really in the hardware chosen.
As to the accessibility issues, yes I'd agree - some user agents won't be able to do anything with the content. We are relatively lucky in that we know exactly who is using our app and what their systems are capable of. So for some unknown external user use I might agree that it's a bad fit client side, due to the lack of control.
"The further you abstract the structure of your markup, the weightier your CSS file becomes."
In fine art, to abstract something is to simplify it by breaking complex forms down to their more basic shapes. This also makes the piece more *ambiguous*. In fine art this is not necessarily a bad thing. But we're not talking about fine art. When sifting through hundreds or thousands of lines of code, ambigousness is never a good thing. Using a combination of CSS selectors and tag identifiers is probably a better way to design a document so that it makes sense when you are altering the code. Aristotle said that finding the path of balance is the most advantagious.
Forgive me, but I see very little sense in being a structure purist. Using tag identifiers such as id and class is an easy way to hook into our CSS files. The real problem is that HTML tags do very ambiguous jobs. DIV doesn't mean a thing to a web design initiate, much less what you do with one. Learning web design is becoming very difficult without programming experience. We shouldn't allow it to become even more difficult.
CSS needs to reach a point where it's a completed standard that is completely implemented. Additionally, XHTML must remain relatively easy to learn, and tags must become more representative of what they are meant to do. There are always better ways of doing things, but at some point a standard must mature and remain consistent, or it loses all of its authority.
Just to dip my feet in the somewhat digressive XSLT topic…
I wouldn't be so quick to label an unsupported technology as inaccessible. Here's an example to illustrate my point.
Let's say you have a browser that will absolutely choke and die if it sees any XHTML nonsense. It's stuck in the past and can only understand vanilla HTML. Would you label XHTML as inaccessible? Would you say that XHTML is simply not practical in any foresight, that all client-side implementations of XHTML should be abandoned?
I should hope not. After all, XHTML isn't what's inaccessible. It's obviously the user agent in question that's causing inaccessibility, and I think we need reminded of that now and then. If you change your code just to candor to an inaccessible browser, aren't you degrading the code (in essence creating *more* inaccessibility)?
Back to my example. Let's say that the browser in question is used by 90% of web surfers.
Given that, one can safely say that it's a bad design decision at that point in time to employ XHTML; however, you just can't say that XHTML is inaccessible.
Take that and apply it to client-side XSLT. It's not a great design decision to employ its use on a diverse, public system. However, it's no more inaccessible just because some user agents don't work with it. Again, the user agents are those responsible for accessibility problems.
To sum it up: XSLT isn't practical right now, but it's an accessible recommendation that has its place in the future.
Tony Cervo wrote:
"When you select "New CSS Style in DWMX2004, the last item on the dialog is "Define In:". Simply select which external style sheet to add it to, and it appends it to the end. I do it all the time�DWMX has *never* dropped a style in the head of my document, and won�t unless I tell it to by selecting �This document only� for the "Define In:" dropdown."
At a meeting of a local user group i am a member of, a Macromedia technician was showcasing some of the MX products (not sure if it was just MX, or MX2004). As he was showing off some of what dreamweaver was doing, he decided to edit the style of a certain piece of text. As he did, the new style (i think he changed a font from black to red) was dropped into the head of the document.
He said that you can define styles in a seperate file, but if you are in the HTML file, and want to change a style, it will not append the external sheet from within the HTML file, it will just add it to the head section. He said you just have to open the stylesheet seperately.
again, back to the topic at hand…
I'm inclined to agree that this isn't necessarily an ideal worth striving for. With the current model we have of XHTML and CSS, it is ludicrous to me to _completely_ separate style and content. As you pointed out, we are still dependent on a linear system of organization which, though frustrating at times (skip nav! don't skip nav!) works really pretty well.
My question is: what will the future bring with regard to XML and styles which purport to be able to allow more complete separation and more complete control? Are the examples you cited reasons that XHTML + CSS will simply become obsolete like table-based layouts?
If we are moving to a world of nth selectors and plus signs and <> up the wazoo, I might want to get off. CSS was supposed to simplify life. But maybe that's just if I have to hand-code all of it.
IF we want the complexity that 100K CSS files will bring us, I have a feeling that some management tools will step in to help us out. I mean, I remember my 300 baud modem and waiting a couple hours for an image download; size is relative… 100K sheets may not be that bad if we have better ways (software) to manage them and/or they write some things for us. Just think of writing pages of the complexity you are talking about without CSS…
I'm still old fashioned - I still code in notepad and write my own style sheets, but if the day comes when the demands placed on us as designers requires that we use some software, and it is developed well, I don't really think it's a problem.
Good article. One pedantic note:
"h3 + ul > li + li" will apply to all but the first element of said ; i think what you're looking for is "h3 + ul > li:first-child + li".
Obviously, as you mention, this gets to be quite a bore when you're trying to select any specifically ordered child. Furthermore, it's going to be more of a bore to wait for "all modern browsers" (of their day) to support CSS3 selectors properly.
This is supposed to be the ideal we're moving towards? Well, if it is, then I'd rather not move with you ;)
Honestly: While it is true that the second document structure contains theoretically unnecessary div's only needed for styling-hook purposes, I don't think there's a need to forget about classes and IDs.
I consider these as markup-enhancing elements not as mere style hooks. While I wouldn't call myself a "markup purist", even one of those guys will probably like better than one without ID.
IDs and Classes are an important part of HTML. They're not just there for Styling purposes (e.g. for DOM Scripting aswell). And they also enhance structure. And they will be there in the future. At least I think so.
I agree with Eric.
I too handcode all my stuff (Homesite for xhtml, TopStyle Lite for CSS) and when you start getting large style sheets going, it gets pretty hard to keep up with everything.
IF dreamweaver mx 2004 handled style editing better (writing to/appending and external file rather than dropping it in the head of the doc) it would come close to a good editor, as long as you stayed away from the WYSIWYG. I still don't trust those things.
On the last few sites I have designed, including the new version of http://www.jeremyflint.com, i started by writing strictly in markup, then wrote the styles for it. I found that i really only had to make a few changes to the markup to pull in a special style for certain h2 or h3 elements.
replace: "even one of those guys will probably like better than one without ID."
with: "even one of those guys [markup purists] will probably like
 better than one without ID."
in my previous posting.
Note to self: never forget to use the preview button again. It's useful.
While I certainly like the look of Markup Listing 1 better, I think I'll be sticking with the latter method for quite some time to come. It's taken long enough to get browser support up to a level where basic CSS works. Just imagine how long it will take to get CSS3 support across the board.
I'm wondering the same as Eric. What about XML? If we're talking "the future"… then why would I want to create markup that looks like when I could just do , and then use XSL to style it exactly? If we're talking about the future, then why are we working on CSS3 when we could work on XML/XSL support on the client side?
Are there any posts/discussions on this site about CSS vs XSL? I'm sure it's been discussed here somewhere….
Sometimes I wonder if we changed CSS3 (or CSS4 or whatever) to XCSS, if Microsoft and uh, whoever else sucks at standards, would be forced to implement it entirely for buzzword compliance. Wouldn't that be cool?!
Nice observation Dave. I noticed the same in a recent redesign that we did - while removing the effects of 'classitis' the stylesheet balooned (well actually it doubled).
What I find (and I'm sure we've all observed while we toil away) is that carfeul use of id's can mitigate things to some degree, though it wouldn't allow the level of specificity you outline with your list classes.
After reading though I do have a question (which betrays my shortsightedness!) - Why would we need to forgoe the use of classes for such specificity - other than 'because we can'?
Anyway, I've started experimenting with serving up gzipped content+css as a result of the ballooned stylesheet (it's only 17k, but hey, a zipped 17k text fileleads to some serious packet reduction).
Whoops! sorry:
why would I want to create markup that looks like  when I could just do <book>
Aside from the totally superfluous
 in the second markup, I see no reasonable sense in which it is "inferior" or "less semantic" than markup 1. Indeed, I would argue that the opposite is the case.
The fact that you need ridiculously complicated CSS2 selectors to style markup 1 (or only slightly less ridiculous CSS3 selectors) is symptomatic of its unsemantic, brittle nature.
Reorder the links in your navigation list (or add an new one) and — poof! — you break your hideously complicated CSS stylesheet.
By removing the
 and
 from markup 1, you've removed all traces of structural groupings and muddled the semantics of your document.
id's are potential link-targets, not just hooks for CSS styling. Again, by removing them, you've harmed the semantics, decreased the accessibility, etc, etc of your document.
The *only* good thing to be said about markup 1 over markup 2 is that it has fewer bytes. Turn on gzip compression and even that advantage goes away.
Nick, the reason we're not having css vs. xsl discussions is because they work hand-in-hand. XSL is a transformation language more than a style language. And it transforms XML into HTML. You're still left with the problem of how to style the HTML in this case. Then you're right back to the tables versus CSS argument again.
I think as a reult of these 100k files, theres gonna be alot of trouble finding the particular class when you need something changed. Even if you break your CSS into multiple files, only the original developer will be intimate with the code enough to find the proper class to change…
Good thing we're getting rid of CSS Hacks which would unnecessarily add to the CSS file size. ;)
I agree with the XML/XSL comments above though. It seems the way to go, but try cross-browser developing in it right now. Near, if not totally, impossible.
I always have thought that the web was for the masses. Once we get to the point where you have to have a degree in coding will the web become only for corporations and the elite. Using ID's and Classes make coding and layout easier. I work in the museum business archiving lot's o stuff. For this we have RAD, EAD, Dublin Core, MARC and so on. Once we start creating our own tags <book> instead of  we are going to begin to get a standard that if printed out would take numerous binders. While we may end up there, there is a point where you have to go 'enough' and deal with what you have.
Can you imaging the flame wars discussing the use of a <book> tag or similar? "Is this really a book, more like a collection, maybe it's a periodical" etc…. Classes work well - perhaps what is needed is a controlled Vocabulary so that when you do mark up a book you would use  replacing 'book' with whatever is needed.
Maybe we should just code all our sites in SGML and leave it at that - but do we really want to write our own DTD for each site, or page? BTW if you really want a brain hemorrhage try reading the SGML specs. I think that classes and ids are more than just a hook for styling they give meaning to an otherwise meaningless tag.
Remember why we're seperating content from style (well, one of the reasons, anyway) — for ease of updateability (made that word up on the spot :D). Overuse of the adjancecy selector tosses this out of the window. For example, we have this list:

Item One

Item Two

If we want to refer to only the second item, it seems quite obvious that we use ul li+li. But as the list gets longer and longer, it gets harder and harder to specify the right element (especially if you add an element high up in the list — whoops! twenty CSS declaration blocks need to be changed), and if we're dealing with, say, lists 20 items long, and with CSS files in excess of 20k, well, it's starting to look infeasible.
That's why :nth-child() needs to be supported. It's great.
jonner, alot of people think about XML/XSL that way, but what if instead of sending HTML to the browser we sent XML to the browser and instead of linking in a CSS we linked in an XSL (IE has been able to do this for years). XSL has MUCH more powerful selection capabilities than CSS… and it has it right now. the problem is that it isn't well supported on the client side. but we're talking about he future ;)
so you get better markup and better selection power.
Is there a compelling reason to not use the cascading part of cascading stylesheets to ease one's pain with larger files? They can be nested, in that regard, no? As long as we have identified elements that structure the document, one could have a stylesheet for positioning, and then a stylesheet for each unique div, all nested in a larger global stylesheet. Dynamic scripting could control which CSS files are popped inside the main one?
For me, the essential part of separating the style from the content isn't standards or current trends or cred – it's not having to touch the content itself repeatedly. I don't mind revising the templates and the CSS files, but to have to go in an work with existing markup drives me crazy. I'd gladly create complex CSS to save myself from the tedium of modifying the markup of already marked up content.
Jeremy F. wrote:
"IF dreamweaver mx 2004 handled style editing better (writing to/appending and external file rather than dropping it in the head of the doc) it would come close to a good editor…"
When you select "New CSS Style in DWMX2004, the last item on the dialog is "Define In:". Simply select which external style sheet to add it to, and it appends it to the end. I do it all the time…DWMX has *never* dropped a style in the head of my document, and won't unless I tell it to by selecting "This document only" for the "Define In:" dropdown.
Ok, back to the topic…
I want my XHTML2, complete with
 and <h> tags.
DIVs really don't have any meaning. They are just the generic block-level tag (like SPAN is for inline elements). Sections will allow us to make semantically correct chuncks with less markup (you can probably trash a few of your class names along the way with section tags).
Then again, many out there don't like XHTML2, but I digress.
I have to agree with Gerrit and Jacques here. I don't think anyone has tried to depreciate class or id yet.
In fact, the more id's you put in your documents the better, becase they allow people to link to specific parts of the document. Ideally, documents would have ids on every element that anyone might want to link to - which basically means every block level element in the document.
The side efffect of this is it makes it very easy to select individual elements in the document to apply style. This is orthogonal to the use of complex css selectors, which allow you to apply rules based on patterns of elements, so that the same style may appear throughout the document with only a single rule.
As people seem to be suggesting, the solution that seemed obvious to me was to mark up the first example with IDs, surely?
As with everything in life, moderation is best. I don't think going the nutso-selector route is a good idea. Sure mozilla-philes tout it as the only way to go (especially by ignoring the colgroup/col html tags).
I think it has it's place but as is the case with dynamic content you don't always know at what level that element might be.
For instance we have a "dataview" which is XML data transformed by XSLT into a tabular dataset with scripting providing client side sorting and row hit highlighting. Each column has to be sorted according to it's data type which also defines how it's styled. So in a header we might have a class called "standardDate". In IE we could set that class on the col and have it format the alignment of that particular column. In Mozilla we can't use col so we have to go the selector way tr > td + td + td + td. The problem with that is that no two dataviews throughout the app are the same. This means on one page it's tr > td + td + td + td and another it's tr > td + td.
We could have the XSL just output the CSS with the selector set properly but that's extra processing time. Likewise it's extra processing time to put the column class on every "x" cell for that column. Unfortunately placing the class in every cell is easier for the developer to read, easier for use with CSS, and better cross browser.
The point here being that I think id, class, and selector are all just tools and you'll find ways that they work, and areas where they don't work well enough. It's just a matter of striking a balance between keeping your content/style seperated and keeping things maintainable.
Curmudgeon alert. I think that if people thought CSS was headed any direction except this, they never really understood it. The point wasn't to simplify sites, it was to make markup meaningful. A 1000 page site with a 100k CSS file isn't a bad thing. Requiring intimate knowledge of CSS isn't a bad thing.
Although CSS selectors and styling the BODY element are great things. ID does add quite a lot of sementics to a document as said by Jacques and jgraham.
The only thing I'm not sure about is CLASS, I think that one is just lame and is currently only there for people who don't know how to use CSS or for the few times you need it, since IE doesn't supoprt anything better.
Anne wrote:
"The only thing I'm not sure about is CLASS, I think that one is just lame and is currently only there for people who don't know how to use CSS or for the few times you need it, since IE doesn't supoprt anything better."
OK, so let's see how we can improve markup 2. First of all, we should ditch the
, which serves no semantic purpose. The other two
s serve to group elements into semantically-meaningful units. So they stay.
All the id's stay. They are potential link-anchors, hooks for DOM scripting, and just plain *id*entify sections of your document.
What about the
s in the navigation list?
Sure you could replace those with cleverly-chosen child selectors. But that would be brittle: add an item to the list, or reorder the items and your stylesheet would break. An unordered list is supposed to be … unordered. CSS selectors which would break horribly if you reordered the list are just *wrong*.
I think the  versus <book> example discussed above is an example why – given the semantic poverty of XHTML – the use of class selectors are inevitable.
to be honest, i wouldn't say that grouping sections of a document via DIV or similar goes against a structuralist way of building pages…on the contrary. it does, imho, add quite a bit of structural information.
so…i don't think the future is quite that shade of black that you're painting it here…
Having a class element is not a bad thing, because the "semantic poverty" of html is a design feature. Semantic poverty is good because it allows the html language itself to stay clean and *simple*, with most elements being general purpose and only a few elements with narrowly defined semantics. Class then allows the author to add structure* relevant to his or her particular topic. From the point of view of CSS, class is invaluable when styling html because it is the /only/ way to write a single selector that applies to multiple elements in the document which cannot be distinguished by position in the document tree alone. Hence class is absolutely necessary if you want html to be both simple** and useful.
Incidentially, if you were wondering why "Only four properties apply to table columns", Hixie has all the gory detail: http://ln.hixie.ch/?start=1070385285&order=-1&count=5
Next up: why client side xslt is bad.
*Structure. /Not/ semantics. Using classes does not add semantics unless you also provide a rigorous specifcation detailing the type of content in each class.
**What, out of interest, could replace 'class', provide the same functionality, but be "more semantic". Regardless of the number of elements you define in the specifcation, it is impossible to cover every possibility, and you loose simplicity. Allowing authors to define arbitary elements is even worse, since there is no structure to the language. The /really/ geeky solution is to require authors to define elements where they would have used class, but place the elements in their own namespace. If that ever happens (it won't), I'm defining a namespace that provides a single attribute: class, which everyone will be encouraged to use.
As usual, Jacques hits the nail on the head in his earlier post. Removing all ID'd DIVs is not markup to aspire to–that's much like telling programmers "don't forget to remove all comments from your source code." Bleah. If nothing else, that would play hell on site maintenance. Balance the microseconds that thousands of readers will sacrifice against the hours you as a designer spend tracing through dependencies.
Class still has a use–the "posted by" lines in this blog (and mine, and others) are
 or something similar. Having that class attribute could make useful things happen other than just CSS styling. It could make even more useful things happen if everyone used the same markup.
The syntax of CSS, frankly, isn't set up for maximum ease of authorship or markup. CSS3 looks to be a bit of an improvement.
Stripping of id's and classes is for the johnnys that used visually names styles, like class="topleft", class="blue".
These add nothing to the semantic value of the markup, and are all about visual appearance. If you are descriptive with your id's and classes, they have a value in the markup, both now and in the future. The CSS3 selectors are icing on the cake, but you will have to be careful when specifying relativity or adjacency, as any changes to markup will fail the design more quickly than named selectors.
One thing that needs resolving is the use of additional elements to allow for proper box model positioning. Some of these have a semantic purpose in the markup, others do not. The top level 'container' in your example is redundant semantically, as 'body' should perform that function, but we know that we need it to reliably centre content on the page.
In the case where you have precise control over the users of your site, I agree the accessibility issue becomes less of a concern. Moreover, the disadvantages I listed were primarilly based on the idea of a document based site rather than a web app. If you're creating a web app and you can control what browser your users are using, you could conceivably replace the html with something that was designed specifically for providing application interfaces like Mozilla's XUL. Not only would that provide familiar widgets, but it would also allow you to cache the entire application locally and only load the data from the server.
The fundamental difference that I see between using XHTML and random XML + XSLT is that XHTML is broadly backwards compatible. Anyone using XHTML can still serve it as text/html to UAs which don't support XML and still expect the page to display and function. If there's one thing that HTML UAs are good at, it's dealing with malformed HTML.
If the world ever moves to XHTML 2, this syntax compatibility won't be avaliable, but I would still expect XHTML 2 sites to provide a HTML-compatible version of their page (e.g. using server side XSLT to convert from the stored XML format to either XHTML 2 or HTML and selecting the type to send based on the accept header of the browser). In fact, depending on how XHTML 2 turns out, it might not be necessary to do this, since the syntax may be close enough to HTML that browsers will display something reasonable. At the very least, it will still look like a document (a title at the top, followed by subheadings and body text).
For XML+XSLT, there are never two documents with the same syntax, so the poor HTML UA is left without a hope.
Little typo there Dave.
"No we want to add", "no" should be "now".
Using classes, you can apply the same styling to different things, over-ride part of the styling in specific instances through selectors and change document structure and retain style. Who in the history of the world, *ever*, has written a structurally perfect document first time round without thinking… "hmm - I could do with another set of links here." Answer: no-one. Hence, we use classes.
More importantly, you can find and change what you need to change in a matter of seconds instead of trying to replicate the document structure with the tab key, or carefully counting the tags to find the nth one.
So, the argument is a none-starter. It won't be taken up, because it can't be - in much the same way that XHTML 2.0, or XML / XSLT won't be taken up en-masse. It requires people to act in a coherent, structured and logical fashion at all times.
Semantic purity is for machines - not people.
And frankly, I couldn't give a tinker's cuss whether or not a UA can understand the structure of my document - all I want to know is that I can go in myself, find the menu and change the style without worrying about whether it is a child of x, adjacent to y or sibling of z. There's a whiff of techno-fascism about all arguments to the counter…
I have been considering this issue of having to overstyle stylesheets. I am currently testing shortcutting instances of selectors that tend to be repetitively used in CSS, like color, font-size, etc. You can check it out at http://www.jasonspage.net/test/catalog/ Although the site is extremely basic, to renders as intended in IE 6 and Opera 7. The shortcutted CSS is a little tricky to follow, but at this point, I have reduced the CSS from 92 to 30 lines of code by doing this. Maybe this is a viable way to cut down on redundant CSS markup and clean up style sheets?
The debate here seems to be a bit dubious. Do we really want to style list items separately? Make the ninth item a different colour? It sounds like a rare case.
As for removing class and id, well they do make a mess of your code. I hate image tags - you have to put so much in them (width, height, ALT etc) that a simple piece of HTML becomes awful to read. Add classes and other stuff and it gets worse.
I still code by hand though.
I would say the future lies in XML, that is converted on the server into whatever format is required. New formats can be added easily without touching the code. Hence you will never have to look at the output (except to test it). Headers and sections will be declared in single tags, like the first HTML example in this article. (Mind you, namespaces can add all kinds of junk to XML tags, ending in a soup that's as bad as old school HTML. Ever looked at the source of a Word file?)
jgraham, good post. my comments for those that care:
"It's slow". Your entire first paragraph about "it's slow" and then you go into all the details of what has to be downloaded/parsed/linked/parsed/etc/etc… but all of that has to be done with HTML as well! There's no quantitative proof that it takes less time to download/parse HTML, then download/parse CSS, then download/parse scripts. it's the same thing. Also, I am not aware of XML parsing "not being known for it's speed". The thing is, HTML *IS* XML… it's a predefined set of XML and parsing either takes the same amount of effort (of course, you could find a crappy XML parser that is the slowest thing on earth and then make that claim). The difference is only that the XML parser will expect a well-formed document, and the HTML parser will take anything. So I'd bet if we ripped open the code for the HTML parser, we'd find it was actually more complicated.
"It's inaccessible" - IE 5.x and Netscape 6.x (and so, of cousre, Mozilla) supports it… and that's over 95% of the market… and that's inaccessible? Your point about what a user sees if the browser doesn't support XSL vs CSS is well taken. But again, I thought this entire discussion was about THE FUTURE of styling…not the present.
Good point about the scripting issue… I hadn't thought about that. but then again, if you put your scripting in the stylesheet (since the script will be dependant on the type of "DOM" you're going to create…. HTML/WML/??), then it doesn't much matter.
"It provides no benefit to the user" - I'd argue that a user reading "semantic HTML" would be just as lost as reading XML. There are really only a few of us in the world that actually view the source of a document. I know, when you surround yourself with those people (us) it seems hard to imagine… but I'm sure well over 80% (maybe even 90%) have no idea about any of this crap. Yes, the user AGENT may not know what to do with it… but that's why you woudl send the style sheet for that type of user agent (the HTML stylesheet). Yeah, we could do it server-side with a agent check (as mentioned above)… but again, we're talking about the FUTURE of styling. A screen reader that expects HTML would request the HTML XSL and that would transform the XML into a format it wanted. If the reader was like an RSS reader, then it would be happy with just the XML.
In any case, there are no standards for either the source HTML or source XML. HTML has predefined tags that browsers know to look for, because browsers are all about reading… where XML is about storing data semantically. "Semantic HTML" is just an attempt to bring XML usefulness to a markup that is out of control. But I would say that having all of the data properly marked up in an XML document would make MORE sense than having a bunch of spans and divs…
everyone, please feel free to fire back at me. I've been looking for some enlightened people to discuss this very topic with :)
see, I *could* just make an XML document that reflects the same structure of a "semantic HTML" document… then have an XSL that styles it… EXACTLY like CSS would style the HTML.
OR, with XSL, I could make the XSL the actual HTML file, and then pull in the XML as datachunks and place them on the page. Now you're talking about full control of the page. no worries about "hey, I need an extra DIV here or an ID there". You use the XSL to build the HTML exactly as you want it to be… and use the XML to fill in the content. You're not limited to simply styling of CSS.
But in that case, you'd probably want to use all three technologies… :)
>[it's slow] … but all of that has to be done with HTML as well!
No. If you send HTML over the wire, then the UA just parses the HTML once (through the slow HTML parser or the faster XML parser if you get the right mime type). With XSLT + XML -> HTML you *still* have to parse the resulting HTML, just as if you'd sent it over the wire. But you *also* have to parse the XSLT and the XML. There might be situations where this isn't a problem - principally if each page is broadly similar so a) the XSLT can be cached and b) sending XML only is significantly smaller than sending all the html. Even then, this is only a benefit if the network connection is slow compared to the processor speed. This might be true for the web app case, but is unlikely to be true for a document based site.
> [it's inaccessible] … But again, I thought this entire discussion was about THE FUTURE of styling�not the present.
Yes, but the point is that using client side XSLT produces a *requirement* that all future browsers support XSLT, or miss out on the content delivered that way. It also *requires* everyone to upgrade to such a browser.
As for IE + Mozilla accounting for 95% of all browsers; that may be true, but accessibility isn't really about catering for 95% of people 95% of the time. I might use Mozilla 99% of the time and lynx the other 1%. But when I'm using lynx, it might be because X windows won't start and I'm trying to work out which line of the config file is wrong. In that case I *really* need sites to work in text only browsers which have no clue about style (or XSLT for that matter). So maintaining accessibility is important for everyone.
> If the reader was like an RSS reader, then it would be happy with just the XML.
Well assuming the XML was RSS. Which I think is my point; a user only has tools to deal with a limited number of document types. I see no benefit in sending the user a document type they don't understand and a script to convert it to a type that they do understand over just sending them a document type that they understand in the first place. Moreover I see several disadvantages, of which 'inability to view source' was just one example.
> �Semantic HTML� is just an attempt to bring XML usefulness to a markup that is out of control
No, semantic html is all about what the user is able to do with it. The advantage of having an  element over having everyone write a variation on  is that it allows consistent interpretation by user agents (e.g. visual user agents might render it red ot italic, oral user agents would apply a certain vocal style). This makes life easier both for users and for authors.
> But I would say that having all of the data properly marked up in an XML document would make MORE sense than having a bunch of spans and divs�
On the authoring side, sure. But markup only adds semantics insofar as it is possible to know what a piece of markup means. Semantics are only useful insofar as it is possible to use them for something. So, if you want to author in your own madeup namespace where all the tags correspond to the type of data in your documents, that's A Good Thing, because it adds value for you (you can use the semantics to enable different presentations of the document via XSL transforms, for example). For delivering the content, it adds no value, because the user has no way of knowing what your markup means. Even if you provide a rigorous specifaction of what the different elements mean, the user isn't likely to have any tools that will help them extract any of those semantics. If, on the other hand, you convert the document to a widely used delivery format such as HTML or RSS, then the user already has tools that understand those namespaces, and are able to make your markup meaningful /to the user/.
> You use the XSL to build the HTML exactly as you want it to be�
Which sounds cool, but it's nothing that can't be done just as inaccessibly using the DOM+javascript, or done server side at a higher cost of server hardware but with the massive benefit that all your users can actually get at the content.
Something I read on the lists of the W3C and I totally agree with: "XML has no semantics, HTML has". Maybe not those words, but it was something like it.
For the CLASS used in each LI, that should have been IDs, since there is only 1 link to 'home' etc.
About the SPAN with the CLASS 'book', using a custom element BOOK is indeed better and possible using namespaces etc.
>[it�s slow]
OK, I see what you're getting at. didn't catch that from the first post. but in reality, it will take all of a few milliseconds longer to parse two extra docs (XML and XSL) into an HTML doc on the client. the slowness will come from downloading the two (instead of one html). Then it will do all the same work that an HTML doc would do. good point though.
> [it�s inaccessible] [XSLT produces a *requirement* that all future browsers support XSLT, or miss out on the content delivered that way]
Isn't that just the same as requiring a browser to support xHTML2 and CSS3? If accessibility is a question of backwards compatibility, then yeah… XML/XSL will never work :)
The advantage of sending someone the XML along with a script to convert it to what they want (if they don't have their own) is that I can maintain my content in one core format: XML, and then I can give it to everyone. I dont' have to maintain my content in HTML and RSS and blah blah blah. Sure, if I have a database system that can generate the files based on templates… then the problem is somewhat solved. but if I could just keep all of my content stored in one format (either my favorite format, or a standard format for my industry), then I don't have to maintain duplicates… and that's better for everyone. Of course, I can just do the transformation on my side and send back the HTML… and then everyone is happy :) … just wondering about the future and how many "stylesheet" technologies the W3C has to develop.
> [Semantic HTML]
OK, makes sense. at some point someone will want to say "hey, all this XML is a mess… we need to come up with a standard for readable documents. let's make an XML markup that looks like this, and we'll call it HTML". and the cycle will continue. I know this probably seems obvious to everyone… but I like to break things down to the basics and think about them (even if they seem trivial, you never know what you might find)
thanks for your input, jgraham!
also, I'm just grasping this new meaning of "accessibility"… a restaurant may be "accessible" to 99% of it's patrons, but if it doesn't have a wheelchair ramp, then it's "accessibility" is very poor
Which is why it really burns my toast when people use to italicize some text, and *think* that by doing so they�re being more �semantic.�
Rather than using or, if that�s too much trouble, using the humble element, they take one of the few elements of HTML whose semantics convey definite meaning (the text herein is *emphasized*) and spooge it.
oh my &deity;
finally, somebody who understands – if you'll pardon the pun – the meaning of semantics
thanks, Jacques
anybody want to discuss the semantics of the humble SUP tag?
wrong thread, i guess
> Isn�t that just the same as requiring a browser to support xHTML2 and CSS3?
CSS3 shouldn't affect backwards comptability, because CSS only affects layout not content. XHTML 2 is more problematic (see my earlier comment), which I think explains much of the resistance to it.
> Of course, I can just do the transformation on my side and send back the HTML� and then everyone is happy :)
That's certianly what I would advocate.
> About the SPAN with the CLASS �book�, using a custom element BOOK is indeed better and possible using namespaces etc.
Why is that better?
> anybody want to discuss the semantics of the humble SUP tag
Like http://zeus.jesus.cam.ac.uk/~jg307/index.xml#date200305092030 ?
why the class in body?

I guess you can always change body using just  alone. Eventually for the different pages you can override it just by using specific one-page css.
Can anyone explain why upcoming versions of CSS aren't structured with XML? It just seems like such a logical application. Also, why are we dealing with plus signs and greater-than signs and whatnot in our selectors when something like XPath has been designed exactly for this purpose?
I think the first example isn't ideal at all and totally broken markup, the second example comes closer to how it should be.
Symantically the first example is totally meaningless, if I would like to parse that code I would end up with some meaningless headers and some paragraphs. Where is the content part ? Which part belongs to the navigation ?
It would be quite challenging in the first example to center the main content and put a border around it, simply because there is no main content, just some headers and paragraphs.
The
 parts have a right to be there, because it's the place where ideally would be something like <maincontent> <navigation> or
whatever.
Like Mr. Franceschina said, why use
 when you could write <book>. The div's are there because the markup of html is very limited.
I tried to play around with making my own dtd and using a stylesheet with it. I'm wondering if such a thing is valid. Just a custom DTD and using Css with it: http://www.rhalff.com/dtd/
> I tried to play around with making my own dtd and using a stylesheet with it. I�m wondering if such a thing is valid.
I'm not sure, but I think some of the following points may be valid:
1) On the client side, I'm not sure why you'd want to do this. I've said a lot about that already so I'll try to avoid that discussion here
2) Creating a custom DTD is a perfectly valid thing to do. Obviously. Sending a file using that doctype as text/html seems like a hack though. On the other hand, without employing the hack, you can't do much. In general, the amount of useful stuff you can do with a custom DTD in a browser is limited. You have to rely on existing html elements to do any of the interesting stuff (like linking, inline stylesheets and so on). You probably also want default styles for the various elements, so that you don't end up with 100Kb stylesheets(!).
3) Most web browsers (as far as I know, all web browsers, but I might be wrong) are non validating. That means that they don't have to load the DTD file and in particular don't have to resolve external entities. The fact that this works for entities defined in the html spec is because the browser carries around a hardcoded list of such entities. This is an example of browsers being well adapted to html, but poorly adapted to generic (SG / X)ML.
4) One reason your XML file doesn't display as expected is because you've commented out the stylesheet (XML parsers can ignore comments, the practice of hiding data in comments is specifically forbidden in the XHTML/HTML compatibility guidelines). The other reason is that you're relying on specific XHTML semantics in a text/xml document - in particular the use of


text:
Premiere Pro CS4 Classroom in a Book
I just got my copy of the Premiere Pro CS4 Classroom in a Book, and I'd recommend it to any Premiere Pro user. The CS4 release is so loaded with new features and improvements that this manual is a must have to get the benefit of the new workflow. For example, the New Features list is 3 pages long, with new features that touch on just about every aspect of the editorial process. And, it comes with a DVD-ROM (Windows AND Mac) with sample clips to test out. Whether you're just switching over to Premiere Pro, or have been using it since the first release, you'll see some benefit from this book.

subset: commoncrawl


text:
Michael Golrick, Director of the Southern Connecticut Library CouncilAre multitype consortia successful? Can they plan to be successful? Is consortial success a myth or a reality? Let me try to answer this by first talking about consortia in my life, briefly covering the history of Connecticut library cooperation and then looking at some of the successful library consortia in the country.
Personal History with ConsortiaConsortia have played a variety of roles in my life. I must have been all of twelve or thirteen when my local public library changed from the paper library card with a number (which you wrote on the book card) to the plastic Gaylord stamp card. Your name and address were embossed, and it was placed in a machine which imprinted your name/address onto tape which was peeled off the book card when you brought it back. It was a major step in patron confidentiality! When I received my new card they asked if I wanted it stamped. You know how kids are, and I of course said "Yes, what is it for." As best I remember the answer, it was all about reciprocal borrowing.
I did not pay much attention to the "stamp" until high school. Then the arrangements made by the Central Massachusetts Regional Library System became important. I often took the bus to downtown Worcester to use the much larger public library there. From the point of view of a member of the public, it was great! I could go and use the books, and check out whatever I wanted! This was well before the days of any kind of computer catalog. This was my first exposure to consortia.
I remember hearing in Library School about the Lincoln Trails Library System—and indeed the whole structure of the Illinois State Library's cooperatives. The sharing of reference resources and shipping of books was the major role. Back in the mid 1970s, Illinois was one of the nation's models with this service. [That is what they taught us at the University of Illinois Library School!]
In Arizona, there were county systems. But, there is still a great deal of territory to cover once you are outside Metro Phoenix and Tucson. The Tucson Public Library had funding from MURLS (Major Urban Resource Library Services—part of LSCA) which they used to run a second level reference service for libraries in the southern half of Arizona. This was a service where the local library would call with questions they could not answer. Dave Kendall ran the service out of a small windowless office tucked in a corner of the Main Library. He spent some time using the Main Library resources, but he also knew every small, special library in the area (in those days there were lots of mining companies, local bank headquarters, the local newspapers, etc.). He had the freedom to go to the University of Arizona Library (and all of its special collections). It was a different kind of service, but beloved and effective.
The Connecticut StoryWhen I came to Connecticut, I worked in a library which housed one of the library consortia. Actually, it was while I was there that it split into two! One focused on library automation. The other remained the "traditional" Cooperating Library Service Unit. How did they come to be?
For many years, the public and academic library directors in Fairfield County have met on a regular basis. They still do. They are vocal. They represent some of the best funded libraries in the nation. They are a force to be reckoned with in the Connecticut library community. In the late 1960s they created the Southwestern Connecticut Library System while corporate and other academic libraries created the Library Group of Southwestern Connecticut. Both had the same goals: a union catalog, interlibrary loan, and delivery. Much was done in a fairly unsophisticated way. One example was the "ring search." ILL requests were put on catalog cards which were looped together (on a ring). The driver/searcher went from library to library (in a ring) searching for the items on the ring. Crude, but it worked! A similar organization was born in the greater Hartford area.
In the early 1970s Connecticut librarians began planning for the future. A series of planning meetings took place and culminated in a multi-day planning retreat called Target 76. A number of current library services in the state are the result of this effort. They include Connecticard (ability to use you library card in any public library in the state), Connecticar (the delivery service which means that you can return a book to any library in the state—no matter its home), and the Cooperating Library Service Units or CLSUs. With the redirection of LSCA money towards library cooperative efforts, "the System" and "the Group" merged to form the Southwestern Connecticut Library Council (SWLC).
The CLSUs serve based on geography. They are creatures of the State Library with a separate line item in the budget. When the CLSUs were set up, they reported to a separate organization—the CLSU Review Board. Each office received a basic operating grant and any additional funding for additional programs was awarded on a competitive basis. When I say competitive, I mean it. I know from my years of service on the Southwestern Connecticut Library Council Board (including a year as President).
In the late 1980s a new state librarian arrived. He streamlined the State Library's advisory committees. Several Boards were eliminated (including the CLSU Review Board). In addition, hard times hit the state's economy. State agency budgets were level funded or even cut. As a result of the funding cuts the CLSUs had to work more efficiently which meant more cooperation and a reduction in the number of regions from 6 to 4. It was a very uncertain time—especially for CLSU staff. The old SWLC and Region One Cooperative merged into the Western Connecticut Library Council. Eastern Connecticut Library Association and the South Eastern Connecticut Library Association merged to form Eastern Connecticut Libraries.
For the last five years the CLSUs have worked much more closely together. The funding is now divided using a formula, with a lump sum for each office, distributions for managing services offered statewide to CLSU members, and the remainder divided with 50% of the balance based on the number of members, 25% based on relative wealth of the towns covered, 15% based on population, and 10% based on number of square miles. Because there are no more fights about money, we can spend our energies on cooperating.
The Value and Necessity of Member ParticipationI have been on both sides of the CLSU table—board and staff. I served six years on the SWLC (South Western Connecticut Library Council) Board including a term as President. I have now been five years at the Southern Connecticut Library Council. I can not state more strongly that every regional or cooperative effort, any consortia, is only as good as the efforts of the participants. I went to the dictionary to look up the etymology and meaning of the word consortium. It is Latin for fellowship. This has real implications when used in the business sense—or more properly, in the nonprofit world. We will be most successful when we work together as "fellow" colleagues. One of the very clear implications to me is that the effort needs to be put forth by ALL participants.
In talking about Connecticut's non-automation consortial history, I mentioned the role played by personal interactions. I solicited input about successful consortia on a national list. One of the Massachusetts automation consortium directors wrote back and said (in part) "Interpersonal networking was equally important. Though the libraries were close geographically, many of the librarians had never met each other, particularly at the staff levels, nor had they visited the other institutions." This visiting back and forth can be extremely valuable.
Success StoriesI started off by asking "Are multitype consortia successful? The answer to the question is clearly: "YES!" What are some of the success stories for consortia?
North Suburban Library System
The first multitype that came to mind is the employer of this year's ALA President, Sarah Long. Sarah is the Executive Director of the North Suburban Library System. At North Suburban, they were ahead of the Net craze. They began Internet access in libraries throughout the system area in 1993. Included with that they established NorthStarNet, a collection of home pages representing most of the communities in the area north of Chicago. [Note these are COMMUNITY pages, not just LIBRARY pages.] Their partnerships have included the Ravinia Music Festival, the Chicago Wolves' hockey team and the Chicago Tribune. One of the most interesting is the establishment of the North Suburban Library Foundation in 1995, an independent foundation that presents the Literary Circle, an annual author lecture series. Visit their web site for more information.
Chicago Library System
The Chicago Library System includes the Chicago Public Library among its members. Its web page was recently updated to comply with Americans with Disabilities Act requirements (something we all should do). They have also set up a library related "chat room." As systems go, they are relatively young. They are in the process of celebrating their tenth anniversary.
Other related systems:
Alliance Library System.
A page listing ALL of the Illinois Systems
Mideastern Ohio Regional Library Organization
The Mideastern Ohio Regional Library Organization (MOLO) set up a rather extensive technology training lab, which enhanced their extensive and well-utilized continuing education program.
A page listing ALL of the Ohio Regions
South Jersey Regional Library Cooperative
Karen Hyman, Executive Director of the South Jersey Regional Library Cooperative in New Jersey, reported that SJRLC's web page includes a Power Point presentation by the director on reference work in the digital age. Their budget and annual work plan is on the web page. Their annual budget is almost $1 million ($922,000) of which over 85% is from the state library.
Central Jersey Regional Library Cooperative
The Central Jersey Regional Library Cooperative has a very small staff (the term "lean and mean" comes to mind). They have training labs (can you tell that I am envious) and their web page has a list of local legislators with links for those who have email addresses! A great idea. . . I may have to steal that one! They also are working on ways to help libraries deal with helping patrons with technology. They have a section of their web page called Help for Patrons and a separate page with Help for Librarians.
A page listing ALL of the New Jersey Cooperatives
SEFLIN [South East Florida Library and Information Network]
The South East Florida Library and Information Network has a more traditional automation consortium aspect, but among other things, they also run a Free-net. Interestingly the bottom of each page has a "partner and supporter." Rather than business sponsors, they are the SEFLIN member libraries. (With full color logos!)
Tampa Bay Library Consortium
The Tampa Bay Library Consortium, directed by Diane Solomon, has a server is named "Snoopy." This means that in the full Internet address (email or web page) the word "snoopy" shows up. In addition to CE and a training lab, TBLC runs an automated system, ILL service and-most importantly-manages the statewide delivery/courier service. This service has successfully made the transition from fully grant funded to half grant and half library payments as of October 1 this year. Turnaround for sites with three and five day per week delivery is 48–72 hours from one end of the state to the other—Key West to Jacksonville or Pensacola are long distances. Solomon said, "We are looking forward to implementation of our Anywhere-Anytime Library for West Central Florida early in the new year [i.e. 2000]." In addition, there are a number of automation related services which they provide including inclusion of area library holdings in OCLC.
A page with a clickable map of ALL of the Florida Cooperatives
Southwest Area Multicounty Multitype Interlibrary Exchange (SAMMIE)
The seven multitype cooperative systems in Minnesota are a little different from most states as they operate in parallel with the twelve regional public library systems. Most have been in operation for 20 years this year, with the original pilot region operating for 25 years.
Western NY Library Resources Council (WNYLRC)
New York has nine multitype consortia. The Western NY Library Resources Council (WNYLRC) focuses on consortial pricing for online databases, training, library advocacy, regional automation, and resource sharing. One of the more interesting services they provide is their Hospital Library Services Program. This service has four staff, and (if I understand it correctly) provides "circuit hospital librarians" to some of the very small hospitals in the region.
Central New York Library Resources Council
The Central New York Library Resources Council has mounted some digitized collections of local history materials. This makes those materials available not only outside the library, but to the whole world!
South Central Regional Library Council
The South Central Regional Library Council (also in New York) recently received an IMLS National Leadership grant to collaborate with the other 3Rs in New York State to develop a prototype statewide virtual catalog. This will be based on existing regional efforts to develop virtual catalogs. Their LakeNet service provides Internet service for rural libraries, Web pages and other Web services for libraries that can't or don't want to do them themselves, including hosting discussion groups, etc. They have also established an innovative solution to distance learning for their large, rural region—two sets of eleven laptop computers that can be networked to each other and to the Internet through a hub and modem and one telephone line (each laptop thus has its own IP address). The network staff take these on the road and teach hands on classes; the training goes to the participants rather than the participants to the training.
A page with a clickable map of ALL of the New York Cooperatives
North Bay Cooperative Library System (California)
Enter "guest" as the patron ID
North Bay Cooperative Library System in California has a great success story to share. They have a fully automated patron initiated interlibrary loan system called SuperSearch. SuperSearch ties together the online catalogs of 16 out of 33 member libraries to create a virtual union catalog. The VUC is accessible from home, work, school, or library. Users with valid library cards can request items that are not owned by their local library and the item will be delivered to the branch of their choice. There is no cost to the patron for using this service because it is so time efficient for the libraries. It takes seven minutes for staff to process a SuperSearch ILL request as opposed to 25 minutes for an OCLC ILL request. In an email about the service , Director Annette Milliron wrote, "Of the seventeen 'unconnected' member libraries, three will be added to the virtual union catalog by the end of 1999. Two more libraries use SuperSearch as borrowing libraries only because the libraries are not automated and therefore cannot lend via the VUC. The remaining twelve members are either new members that haven't addressed the issue of joining a VUC yet or are members with political battles to conquer about lending." She continued, "We have statistical proof that no one has suffered resource rape during the three years we've been operating SuperSearch. We also have proof that patrons love the service. But some members still have to proceed slowly."
INCOLSA (Indiana Cooperative Library Services Authority)
My last example is from Indiana. There the former regional services united in 1995 as the Indiana Cooperative Library Services Authority (INCOLSA), a multitype network of 759 member libraries including college and university libraries, public libraries, as well as school districts and corporate libraries. Also housed at the INCOLSA building in Indianapolis is the Private Academic Library Network of Indiana (PALNI), a consortium of private academic libraries in the state. INCOLSA offers Wheels, a statewide delivery service which allows many more libraries to participate in ILL and allows costs of ILL to remain low, and INSPIRE (INdiana SPectrum of Information REsources), a suite of online databases offered to the entire state of Indiana from library, school, office, home, or anywhere with an Internet connection. INSPIRE Kids is the children's interface for INSPIRE geared to grades K-7. They also offer technology training, consortial purchasing, reference, and special programming. Working with the Indiana Library Federation, they produced a great set of PSA videos promoting this service and giving their legislature credit for the funding.
ConclusionI asked whether consortia are successful. My research shows that there are a large number of successful consortia. If a consortium is not on the list I made, it does not imply that it is not successful, only that I don't know about it.
Can consortia plan to be successful? I believe that to be successful consortia must plan. Success does not just happen. Each of the consortia above listens to its members. Each one plans what they do.
Is consortial success a myth or a reality? I believe that it can be the reality for any consortia which wants it. Consortia and their members control their own destiny. Each of the success stories above has one element in common: they identified a need and proceeded to meet it!


text:
"Sun Dried" Sweet Peppers
We are still seeing bell peppers in the markets, though the season is almost done. When they are young, bell peppers are green. Red bells are vine-ripened and, as a result, are particularly sweet.
I usually blister red peppers, peel them and put them up in a marinade (which can be water bath canned—the recipe is in Well-Preserved, but there is also a recipe available on the data base, Preserving Food Safely, which uses only USDA approved recipes). But recently I was shopping on Arthur Avenue in the Bronx and saw that Teitel Brothers at 2372 Arthur Avenue (http://www.teitelbros.com/) was selling sun-dried red peppers—right next to the bins of sun-dried tomatoes.
This is an incredible product: When you add the peppers to soups, stews and sauces they lend a lovely sweetness. They also make a fabulous pesto, which I've used on bruschetta, tossed with spaghetti and seared scallops, and served with grilled steak. You can also use these peppers in a Romesco sauce (but you'll want to add some heat). See my post from April 2010 for a Romesco sauce recipe.
Dried sweet peppers are actually pretty easy to do at home—they are put up the same way as sun dried tomatoes. You will have the best results with a food dryer.
"Sun-Dried" Sweet Red Peppers
Wash the peppers and cut them in half, and remove the seeds. If the peppers are very large, cut them in quarters lengthwise.
Place the peppers on trays in the food dryer. Set the temperature to 120 degrees and dry for 24 hours. The peppers should be leathery.
Place the dried peppers in a large jar and shake them up every day for about a week. This distributes the moisture—the 10 to 20% that remains–throughout the food.
Keep the peppers in jars in the pantry or in the fridge, or covered in olive oil in the fridge. Food stored at 52 degrees will last two to three times as long as dried foods stored at 70 degrees.
If you want to use your oven, the peppers can be laid directly on the oven racks, or a finer rack can be inserted. Most ovens don't go below 200 degrees, so set to 200, or whatever the lowest option is, and open the door. Or, if you have a warm feature, use that. Turn on the convection feature if you have one, to move around the air. You will need to use an oven thermometer to determine whether your oven is too hot. 140 degrees is your goal. (Note, its okay for the oven to run hotter than the dehydrator.) The peppers should take 12 to 18 hours to dry, but remember, oven drying is less dependable that using an electric dehydrator.
I recommend you put up dried foods in small packages or jars because if there is any spoilage then at least only a small percentage will spoil. In general, dried foods last about one year.
"Sun-Dried" Pepper Pesto
Makes 1 cup
1 cup packed "sun dried" peppers
2 small garlic cloves
2 tablespoons Italian parsley, coarsely chopped
¼ cup blanched and skinned almonds
About 4 tablespoons or more light olive oil (see Note)
Salt and freshly ground black pepper
Place all of the ingredients in the food processor and pulse to grind. You can make the pesto a bit grainy or process to a smooth puree. Taste to adjust seasoning, and have fun with the ingredients. If you want more garlic, add it. If you crave a little tartness, add a squeeze of lemon. You may need to add more olive oil, but if the pesto seems dry, I would recommend instead a bit of warm chicken stock or water.
Pack the pesto into a sterilized half pint jar (to sterilize, place the jar, lid and band in a pot of water and boil for 10 minutes at sea level, adding 1 minute for every 1000 feet altitude). Cover with a prophylactic of light olive oil and refrigerate. Holds for about a week.
Note: I don't prefer extra virgin olive oil in this pesto: it's too rich, but it is certainly okay to use if you like!
On another subject, I will be preparing a mushroom tasting at the American Museum of Natural History in New York City on November 9. The speaker is Gary Lincoff, an incredibly knowledgeable guy who is known as the "Woody Allen of Mycology." I am going to prepare marinated maitake with scallops, chicken canzanese with morels, and cheesecake bars with candy cap syrup. Here is the link: http://www.amnh.org/calendar/event/Wild-Mushroom-Harvest:-Foraging-Local-Woods-and-Markets/


text:
Floodwaters recede, struggles remain
Linda Schaumburg
With a Pine County flood recovery meeting set for 7 p.m. tonight at the Rutledge Community Center, several flood victims recently shared their recovery stories. Many of the victims are sitting in a holding pattern for relief or have given up hope it will really happen.
Rutledge residents Greg and Dee Koivisto are currently existing by renting east of Barnum. These are his words. They not only lost everything inside their home as it was swept away by the Kettle River, they lost the right to rebuild their home.
The Koivistos had flood insurance. Their land has now been changed by the Federal Emergency Management Agency (FEMA) from a floodplain to a floodway. This does not allow any permanent structures to be on their 9.9 acres. The insurance company could only give them half of their mortgage coverage as they could no longer rebuild on the original site. That settlement was sent directly to the bank mortgage.
They will also have to remove from the floodway what is left of the existing home structures. Funds are available through FEMA for that, but it is only a payment of 50 percent up front and the remaining 50 percent once they have proven through photos that all buildings have been removed.
As they continue to pay a mortgage on their unlivable home, they are hoping to qualify for a buyout. They must stay current on their mortgage as it is a requirement to be eligible for the majority of the funding available. The county has been very apologetic to Koivisto, when he met with them recently, about the length of time that has passed for the buyout.
One person Koivisto feels "really cares" is Denise Baran from the Pine County management team for flood victims. Koivisto stated, "She has continued to support victims and has fought hard to get things going faster for us."
Gertzens of Sturgeon Lake
Sturgeon Lake residents Jan and Denny Gertzen are also victims, albeit in a different way. They also had flood insurance but ran into many problems when the insurance adjuster did not follow through on their claim correctly. There were errors on dimensions of areas needing repair. As it was a flood claim, the insurance company had to bring in independent adjusters from out of the area trained for floods.
The Gertzens did not receive their first estimate until the end of August, even though the adjuster came within two weeks of the flood. Their insurance company has been very supportive through the long fight with the adjuster. They also felt they had a lot of support from Lonny Thomas from the Minnesota Department of Natural Resources (DNR) Regional Waters Division out of Brainerd.
A group of neighbors in the Cathedral Pines area of Sturgeon Lake had already started a communication hub via the Internet due to ongoing high water issues. When the flash flood happened in June 2012 this hub grew as the Gertzens, along with Ken Grey and others, were trying to pass along any information the city, county and state gave them. Communication to the flood victims about available programs was not always getting to them when needed. The first their area was notified they were in a flood plain was in April 2012, slightly before the flood.
Looting began two weeks after the flood. Many homes, including the Gertzens', were broken into. This added insult to injury, they said. After the flood, at least three of the homes have been abandoned in their area. The Pine County Sheriff's Office increased patrols by car and four-wheelers after the first looting occurred.
The Gertzens say the neighborhood has become a lot closer after the tragedy. They continue to support each other through the wait. In reference to the buyout, Jan Gertzen asks, "If they have the money to buy you out, causing the loss of taxes, by adding green land space only, why wouldn't they give you the same amount of money to fix your home?"
Jan says she feels fortunate they had insurance, and she has been focusing on helping the victims who are struggling around them.
Ockwigs of Sturgeon Lake
Bob and Dody Ockwig of Farm to Market Road in Sturgeon Lake are also recovering from last June's flood. They are located a half mile from the river and 2-3 miles from the Cathedral Pines area. They were surviving from paycheck to paycheck and feeling like they were doing all right until the nightmare of the flood occurred.
They have been trying to work with their mortgage company, a large corporate bank, since the flood. After qualifying for a loan through the Small Business Administration (SBA) they thought they could move on.
According to Dody Ockwig, their mortgage lender would not accept the payment from SBA because it was not 100 percent. The SBA could not release any funds without the cooperation of the mortgage lender. The mortgage lender sent them to two other departments in their system but nothing changed. For the Ockwigs there was no relief from the rising costs to survive and the continuing mortgage payment.
The Ockwigs lived with family the first month after the flood and then a cousin lent them a 30-foot camper trailer that was parked on their property so they could work on their home until September. They had to use an outhouse, shower elsewhere and survive without many of the conveniences that were now gone. They hauled ice to keep their food cold.
They also had looting problems to complicate trying to clean up their home. Theirs was among five other homes that suffered damage and looting in their neighborhood. They still felt very isolated from the follow-up of help. There was a constant stream of curious folk driving by and checking out damage shortly after the flood. That did not help.
The good things that happened were all the meals that were provided by the Salvation Army as people were struggling to start cleanup during the first two weeks. Sturgeon Lake city employee Scott Helfman was extremely helpful, always stopping in to check on the Ockwigs and helping out as much as possible from the beginning with all of the Sturgeon Lake flood victims.
Before they could begin cleanup, it took the Ockwigs two months of sump pumps, fans and dehumidifiers to dry out the basement as the water table receded slowly.
Dody Ockwig said they had to finally decide to funnel their money into a furnace, rewiring and putting the necessities back into the home to make it livable by winter. Bob said Veterans Affairs helped with their furnace. "We wouldn't be in here right now if it wasn't for them," Ockwig, a veteran, said, although they still feel like they are "basically camping out in their home."
They have been unable to pay their mortgage since September and after continuing to try to work with their mortgage lender to allow them to either catch up with a repayment plan or modify their loan, they were told "no." They are currently waiting in fear of the foreclosure notice to happen and will lose their home at that point because their mortgage lender will not accept payments once the foreclosure goes into effect, according to Dody.
She said it was a rough Christmas when your gifts to each other were things you lost. Ockwig gets to look out at a six-foot sinkhole in their yard where her flower garden had been, wondering where they can go when foreclosed on with their family animals in tow. Ockwig doesn't know if she will learn anything new that may help them at the flood recovery meeting on January 17. It just may be too late. Ockwig said, "Apologies of slow movement of help don't feed you."
These are just three stories from many of the Pine and Carlton County flood victims.


text:
Monday, April 19, 2010
Impressionist Bangles - Van Gogh2 comments Posted by Lia @ Bullfinch and Barbury at 9:45 AM
I'm very excited about these bangles! Vincent Van Gogh has long been one of my favourite painters and I think that his style translates well into enamel. The saturated tones of his work and the extraordinary use of contrasting color and shape draws an immediate response from the viewer. There is an emotional content in Van Gogh's work that resounds far beyond the subject matter. Who else could make a Cafe seem so charged with tension - or a night sky appear so hopeful and caressing and tranquil?
Van Gogh was actually considered a failure in his lifetime, and suffered from extreme anxiety and mental illness. He was very close with his brother, Theo, and though his letters, much insight into Vincent's life was preserved. Vincent once explained that painting eased his anxiety and relieved his depression - and from looking at his later paintings, it is clear that Vincent was optimistic and concentrating on a healthy outlook. Many of his paintings from this time incorporated swirls - like the clouds in Starry Night.
It was only after his death that Van Gogh's work became recognized as a foundation for modern art. His peers later described his work as "genius", and when you peruse the list of most expensive paintings ever sold, Van Gogh's "Portrait of Dr. Gachet" is in the top five.
The Starry Night bangles were made using watercolor enamels and crayon enamels. Both of these are applied like a person would use any other watercolor or pencil, but are fired into the surface just like a powdered enamel. The addition of rutilated quartz cabochons by stone cutter Greg Genovese, brings out the golden, glimmering effect of the 24 Karat gold foil stars.
The next set in the works is Monet's Waterlilies . . . Do you have a favourite Impressionist that you would like to see in bangle-form? Please leave a comment with your suggestions!
Labels: Bangle, Enamel, Gold, Impressionist, Set, Spring Fashion, Starry Night, Stars, Summer, Van Gogh, Vincent Van Gogh


text:
The Best Free Things to Do in Wanaka, New Zealand
Some of the best outdoor activities in Wanaka are completely free. Here are our favourite free Wanaka attractions.
It is easy to find plenty of free things to do in Wanaka. The town and surrounding area is an outdoor enthusiast's paradise, and some of the best Wanaka attractions are free.
Wanaka is a stunning resort town, popular in both winter and summer. It is located in district of Central Otago, which is one of the most beautiful regions of the South Island in New Zealand. Situated on the south end of Lake Wanaka close to the Crown and Southern Alps mountain ranges, Wanaka is blessed with some of the most exquisite landscapes and jaw dropping views you could find anywhere in the world. Here are some of the best Wanaka activities and attractions.
Go for a Hike
Wanaka is blessed with glorious weather in the summer time. It is hot, bright and dry during December to February, perfect for outdoor adventures. If you are looking for things to do in Wanaka in Summer then you will find no better place to go walking, tramping, strolling and hiking You can find something for every fitness level, whether it be a gentle stroll around the town itself to more challenging hikes and tramps into the mountains and around the lake. The rewards of the incredible views from the mountains and lake edge will leave you in awe of the natural beauty of this land.
Visit the Farmers Market
You could treat yourself to the tastes of this glorious regions when you visit the Wanaka Farmer's and Gardeners Market, located in Pembroke Park during the summer months. You can sample mountain-bred lamb, delicious fruits and vegetables, specialty goods and breads and a wide range of organic produce all grown and nurtured lovingly in the area. You will be delighted by the fresh, outstanding quality food and produce, which is sure to satisfy any craving.
Have a Picnic by the Lake
What could be nicer than a picnic by the lake? Sunbathing and swimming in the lake as the heat rises. Lake Wanaka is truly a picture-perfect setting for relaxing and playing al-fresco.
Experience the Local Arts
Besides skiing, there are so many awesome things to do in Wanaka in winter, and you don't need to spend a lot of money to enjoy what the region has to offer. If you want to take a break from outdoor adrenalin filled activities and venture inside, there are wonderful art galleries and museums to lose yourself in while keeping the crisp cold air at bay.
Visitors to Wanaka have the choice of contemporary art spaces such as Gallery Thirty Three in the township of Wanaka. If fine photography appeals a visit to The Picture Lounge will stun you as you view images of the local area brought to exquisite life.
Take a Scenic Winter Stroll
One of the most wonderful activities you can do while in Wanaka over the winter months is simply to take a walk by Lake Wanaka. The views of the pristine snow covered mountains framed with the clearest of blue skies will warm your soul and leave you pondering the majesty of our incredible planet and this very special piece of New Zealand.
If you have children then you can also take them to Snow Farm where they can go down slopes in tubes or try their hand at sledding for free.
Wanaka is a must see destination when travelling the South Island of New Zealand. To get to Wanaka, hire your Queenstown rental car from one of Omega's two local branches and follow Crown Range Road and Cardrona Valley Road for an hour.
Article by
Omega Rental Cars Queenstown
Omega has been trusted by customers from around the world for 20 years. Our all-inclusive rates and Up Front and Honest service mean we deliver on our promises - with no nasty surprises at the counter - and we always put your safety first.


text:
The official Club Eymetois de Cricket app
Stage Bretou Eymet Dordogne 24500 View with Google Maps
This website is part of the Pitchero Cricket network. Create your own free Cricket club website with Pitchero.
Digital advertising by Minute Media
© Pitch Hero Ltd 2008-2019
Pitch Hero Ltd Registered in ENGLAND | WF3 1DR | Company Number - 636 1033


text:
I have just purchased yet another set of Sterilite plastic drawers for yarn storage. This one has 2 large bins, one of which is now filled with various shades of fingering weight yarn (mostly KnitPicks Palette) that I've purchased specifically to do colorwork projects.
I have yet to complete a single colorwork project in my entire life.
There's just no logical explanation for this. I'm either incredibly optimistic (read: delusional) or just plain old insane.