- From: Kynn Bartlett <kynn@reef.com>
- Date: Tue, 10 Apr 2001 10:42:00 -0700
- 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 -- Kynn Bartlett <kynn@reef.com> Technical Developer Liaison Reef North America Tel +1 949-567-7006 ________________________________________ ACCESSIBILITY IS DYNAMIC. TAKE CONTROL. ________________________________________ http://www.reef.com
Received on Tuesday, 10 April 2001 13:35:12 UTC