[Home]Dan Donaldson

HomePage | RecentChanges | Preferences | Newbie Help

Dan Donaldson is contributor to comp.infosystems.www.authoring.stylesheets

Notes on the use of CSS

Part One

No replies to my earlier post but further investigation reveals that on IE5.2 on Mac OS X, use of position:fixed breaks forms on IE5. What about other browsers?

Without a solution to this sort of problem I encountered, my clients will say that CSS is definitely a not ready for prime time technology. Not because it fails on this or that test, but because as a standards-based system without an effective method of enforcing compliance, it leaves them far too exposed to future unknowns - other things that it ought to do, but never seems to quite do.

Especially ironic is that I can easily achieve the goal I have using frames of all god-forsaken solutions. If it isn't obvious that a lame approach like frames is the most obvious place to demonstrate the advantages of CSS - by supplying compatible browsers that actually achieve the goal of eliminating the unwieldy two-documents-just-to-have-fixed-navigation syndrome, but in the meantime, finessing typographic control of font weights, well... Come on.

Brings to mind the old motto: "in theory, theory and practice are the same. In practice, they are different".

My client would save a great deal of money and time if they could use this technology - and, they would spend a good deal of money and time to get to the point where they can use it - enterprise-wide browser upgrades, retraining etc.. But try telling them that a simple thing, and one of the real (theoretical) bonuses of the use of CSS - the ability to build highly productive interfaces on pages by fixing the location of form elements that the user will interact with - is going to require a kludge, a fix, and a lot of crossing of fingers, and what do you think they will say? And this is in a situation where the project is essentially an intranet deployment, and so browser control can be to some extent achieved. For public sites, the idea that 'only' twenty percent of the viewing public is going to be shut out is anathema.

I know, I know - why should we live with antiquated technology that was done badly to start with. Well, not many people have sold their cars and bought Segway's yet, either. And no city planners are de-allocating budgets for road and traffic light maintenance, just because a technology exists and has been demonstrated to work that might - one day - replace the car. 'But how do they expect the car ever to be replaced if they (urban planners and managers) don't take the first step?' comes the reply. This simply ignores two basic rules of economics: a.) people use what they have, and b.) change represents cost.

The optimistic webstandards.org redirect, recently mentioned on this list (http://www.webstandards.org/upgrade/) suggests that since all these smashing browsers are free, there could be no problem to simply upgrade. But change is a cost, and to not take this into account is na´ve. When the change suggested doesn't come close to guaranteeing that a given implementation of CSS will - or even might - work, the cost benefit is indeterminate, and most responsible managers would assume a negative, since the cost is known and the benefit is not. The reality is that compliance is a huge issue, and CSS has not yet matured - as far as I can see from the consultant's chair - to the point where I can recommend it.

Personally, and from a business point of view, the expenditure of money and time - will there be less of either or both - is the only real selling point for most of my clients. Technology per se is never a selling point - you will never see an ad saying 'Come to XYZ.com - now with CSS2!' - especially using web technology, because it's so hard to maintain a technological edge. Everyone uses the same technology. So the underling technology rarely carries weight. The way technology is used to support an approach to branding or to ease of use does carry weight, since these are the things that people actually sell. This is not, apparently universally understood in the web design community. What you will see is 'Come to XYZ.com - now even easier to use!', but again, not 'Come to XYZ.com - now even easier to use except for 20 percent of you all, where it will be harder or impossible!'. Clients hate for people to have surprises.

Brings to mind Holiday Inn's motto: "No Surprises". You may hate it, but it works.

I hope this won't spark a flame war here, but as someone whose obligation it is to assess this technology (css) and others for clients, I am quite surprised at the disregard that this sort of problem gets in the css community. I'm not referring to the lack of replies, but to the dismissive air that objections are sometimes dealt with. I wonder if, sitting in a board room with decision makers who are trying to figure out how to commit an X-million dollar web budget, the attitude would be quite so cavalier. This is not to ignore those posters who take the broader view. But those whose restrictive, almost puritanical zeal for separation of content and structure should know that this is not an argument that easily survives in the decision making context. Board members are rarely theoretical, and shareholders never are.

Clients are sophisticated enough to understand that saving time and money can also take the form of an improved user experience (less marketing and support), and will grasp the argument that building a site where the holy grail of separation of structure from content is worthwhile - although from their point of view, CSS does not offer this at all. They argue - correctly - that the only real divisions that exist are the division of roles among employees. And if, to make documents useable, authors have to learn lots of new skills - XML/XHTML/CSS etc to facilitate the 'separation' of content and structure - well, they'll say that the supposed benefits of separating content and structure disappear if they don't allow specialization and role definition. If authors need to know a form of markup, this will incorporate large costs in retraining and rediting archived material. In other words, if an author's job has to become the markup editor's job, to them, it's no different from any other place where I or anyone else suggests that authors become their own editors. Yet, to re-edit a document, the author has to either take on the marked-up document in raw form, or work in a WYSIWYG environment - which is (to a degree understandably) sniffed at by many in this group. I understand exactly what is wrong with Dreamweaver et al from a data separation point of view, but from a business case point of view, it allowed many companies to deal inexpensively with the problem of documents that needed to be re-edited. CSS as it is currently conceived doesn't do that - does it?

Brings to mind the old motto: "The editor who authors his own work has a fool for a writer." This motto has the commutative property.

OK. Would love to get your perspective on this. And if there's a solution to my problem, that's good too. No flames, I hope. I mean this constructively, and I hope you'll reply in kind. -- Dan Donaldson

Part Two

Here is an interesting example of the problem I was pointing out.

Authors are not the people on whom you would rely to markup their own work. It violates the validation of peer review, and it imposes an unreasonable burden on the author. The idea that someone has to know a technology like CSS/HTML/XHTML to express what they know about, say, stock options or cardiac care or garden care is not a good one.

I will argue that while, in some sense, CSS,XML and their ilk can achieve separation of content and structure, they can only do so by imposing a division between expression and knowledge. In other words, someone with knowledge cannot express themselves in this medium without either becoming expert in an abstruse technology (CSS), or with the aid of someone who is knowledgeable in this technology.

This puts a priority and a value not on the best knowledge, but the best combination of knowledge and this technology. I can safely assume that neither my stock broker nor my cardiologist are moonlighting as markup wizards. In fact, I expect them to be devoting their time to further mastery of their expertise, not some subset of web technology.

So for them to express what they know in this medium, they have to submit their knowledge to a process that imposes a second level of meaning upon it. A markup editor will have to make decisions as to what the meanings of various elements in the text they have been provided are. Whether they can be effective in communicating what they have done to the original author is not something contained within the CSS specification, so far as I know.

You can argue that the classic paper-based publication process also imposes a need for editorial and layout editors to process manuscript text. But the role of an editor in this case is to a.) facilitate peer validation of the text by other experts (not usually the editor), and b.) impose order - primarily visual order. With metadata markup, a very dangerous thing happens - the editorial process imposes not just order, but meaning on a text, and the generation of that meaning is the responsibility of people without expertise in the field the text addresses.

Tim Berners-Lee was very clear that his objective was to produce a markup language that would not impose unreasonable cost of learning and mastery on users. <H></H> tags both carried visual and informational order: they suggested a hierarchy of importance and allowed a practical subdivision of knowledge, which is not the same thing as the imposition of meaning. Any researcher could grasp this concept and apply it in twenty minutes. At the same time, it was well within the powers of the commercial and open source communities of developers to create compliant devices - browsers - to express the information contained in this markup.

My orginal argument/observation was really, 'that's nice, but it doesn't work, and the people I talk to don't care about it if you can't show it to them working.' In this sense, CSS is the last great holdout of the Internet Bubble Mentality: absolute vapourware with the assumption that investors are not going to ask too many questions, and certainly not expect to see a working example, never mind a positive cost-benefit before ponying up the dough.

But at a more theoretical level, here's what I think the problem is:

Implied in the idea of metadata is that a.) before researchers can have access to information a increased amount of time will pass than would have happened with appearance-based markup, which in turn is a greater gap than plain-text (ie purely authorial) documents; b.) the process that they will be subjected to will be inherently unreliable, introducing a second level of error as inexpert markup editors impose meaning on expert texts; c.) an individual author can only deal with this problem partially, and that by learning an abstruse, changing technology, thus diverting them from their primary expertise; d.) in any case, this technology has no compliant device (ie browsers) to use the information; e.) neither is there any immediate prospect of a compliant device appearing, as the body charged with developing standards has no power to enforce compliance, and does not offer certification that would aid its adoption in the marketplace.


This, realistically, is why CSS strikes me as a not-ready-for-primetime technology, and a boondoggle. -- Dan Donaldson

HomePage | RecentChanges | Preferences | Newbie Help
This page is read-only | View other revisions
Last edited December 19, 2001 4:39 pm (diff)

This FAQ is happily hosted by Betadome Digital Media