W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2001

RE: !important

From: Kynn Bartlett <kynn@reef.com>
Date: Tue, 10 Apr 2001 10:42:00 -0700
Message-Id: <>
To: "Jon Hanna" <jon@spinsol.com>, <w3c-wai-ig@w3.org>
At 10:09 AM 4/10/2001, Jon Hanna wrote:
>I disagree - ish! [...]
>On the other hand it does have two advantages on server-side
>solutions. The first is that there is no need to indicate to the
>server in any way what the requirements for a given user are, this
>means less work for both the server in terms of processing per page
>and also for the user, once they have their css in place.

Two points to address here:

(1) Less work for the server

     Due to technological advances, this argument is rapidly losing
     weight.  The two primary changes are:  Servers are getting faster
     and faster, and thus the power necessary to make this kind of
     decision, when it would have been amazingly slow in 1995, is now
     relatively trivial; and, With increasing moves towards dynamic
     generation of the entire page these days, especially on larger
     sites, dynamically generating or selecting a stylesheet is as
     easy as anything else being dynamically created.

(2) Less work for the user

     Since a client-side CSS file will _never_ be a complete solution,
     the user may be needing to specify preferences and capabilities
     _anyway_ on a given site; in fact, you may have cases where a
     user will need to manage MULTIPLE client-side CSS files, a case
     which is not supported by any browsers that I know of currently.
     For example, "assign this stylesheet when I visit www.hwg.org
     and THIS stylesheet when I visit www.cnn.com."  When you reach
     that level of complexity -- and that WILL be necessary for a
     full(er) client-side CSS solution -- you have lost the benefit
     you described here!  You can do that kind of switching now, by
     the way, but it's all manual and is a pain in the ass.

The best answer to #2, of course, is Composite Capabilities/Preferences
Profiles (CC/PP), which would, in a CC/PP-aware browser, allow the
user to enter her preferences ONCE into the browser, and then browser
can both adjust itself and share the information with the CC/PP-aware
web sites it contacts.

CC/PP is still some ways off, though, as it's still under development
by a W3C working group.

>The other
>is that it could potentially deal with accessibility issues that
>haven't been considered when the server-side solution was dealt with,
>and perhaps to a finer degree of customisation.

Yes, but to be able to do that, you need a level of technological
sophistication on the end user side that is unreasonable to expect
from the average (disabled or otherwise) web user, who is -not- better
trained in web design than someone who developed the web site.

>I think it's reasonable to assume that user css will become easier to
>configure, since that is the trend with practically all technologies,
>and in the near future it will become a useful accessibility tool,
>and also a tool used by all of us to make our browsing experiences
>closer to our personal preferences.

I disagree with the assumption that it will somehow become easier to
code CSS.  CSS, by its nature, requires a degree of knowledge that is
relatively high; it requires you to understand HTML's structure as a
language, for example.

This is why I want to see browser programmer work over end user work,
so that "setting preferences" -- which is relatively speaking a lot
easier -- is how you create an invisible CSS document, or even better,
a CC/PP profile which can then be translated and/or transformed into
a CSS document if that makes sense.

CSS itself is a -very poor language- for the task of -communicating
user preferences-.  Trying to store those in CSS is like trying to
store graphical layout and presentation in HTML.  Sure, you can
cludge your way around it, and maybe there are work-arounds, but it
is the -wrong language- for user preferences.

CC/PP is -- or "will be" -- the right language for the task.


Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Reef North America
Tel +1 949-567-7006
Received on Tuesday, 10 April 2001 13:35:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:12 UTC