Patrick H. Lauke wrote:

Geoff Deering wrote:

How do you know what device configuration is receiving your design? Because if you do not, and cannot be absolutely sure your design is not clashing with this principle, you cannot *ensure* you have succeeded.


But that is true of pretty much any element and situation where you're applying style. And that's why we have separation of content and presentation: if the presentation does present a problem to the user, the user agent should provide the user with a simple way of overriding, or completely ignoring, the styles suggested by the designer.


Firstly, this still does not address the initial problem.

Secondly, by this recommendation you are actually addressing the flip side of the problem I am trying to address.

The case you are addressing here is
1) A recommendation of how to deal with styles that may conflict with a form element that is in an activated state. 2) What I was addressing was dealing with styles that may conflict with a form element that is in a non activated state.

Either way, that these recommendation could be feasible in practice, is for the functions within the user agent being able to detect at least two conditions;

for your condition;
if(FormElementWebDesignerStyle != FormElementClientDefaultValue) & (FormElement == active) then do {apply correct display of state};

and for my condition;
if(FormElementWebDesignerStyle != FormElementClientDefaultValue) & (FormElement != active) then do {apply correct display of state};

I can't see how this type of functionality will ever be added to a user agent because it goes against the fundamental interface principles of OSs. The WAI/UAAG would come under scrutiny if they did this. And with all the bugs and unimplemented recommendations in user agent development, I can't see this ever seeing the light of day.

I'm really not up to date with CSS behaviour at all, but if someone can show me a real world example of this recommendation and how it could be applied, without programming the user agent functionality, and therefore changing the UAAG specs, I'd be happy to see it. You could probably do it with client side scripting, but then that breaks when it's turned off.


Unless you know for sure how users have configured their interface you are swimming in the sea of uncertainty. [...] If accuracy of communicating [...] is a primary principle to your design philosophy,

> you cannot be

sure you have not interfered with this process


With my intentional omissions (not trying to misquote you, just making it generic), I'd say this applies to any styling, not just the specific case of form elements.


If you are suggesting this is to be handled by the user agent, how are you going to implement it? I'd like to know your suggestions on this, and the functional logic.



I know many people feel that about the WAI GL, but I have never felt that. People complain about the WAI police and the lengthy drawn out debate that goes on there, but I mostly see a lot of people concerned *not* to write recommendations that restrict design.


Fair enough...I'm probably thinking of some of the more radical (and possibly most vocal and entrenched) elements here.


Yes, I know, but the way they are still worked with and appreciated for their input is inspiring. I used to play the devils advocate there because in the long run it helps to apply as much scrutiny and analysis as possible for the most clear and comprehensive outcome. It's incredibly hard work to develop accurate standards that are also free of unnecessary restrictions. It requires that type of process.

-----------
Geoff Deering
******************************************************
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************

Reply via email to