Re: ISSUE: States should just be Properties with isDynamic=True

I would have liked isDynamic better than state vs. property, but my 
concern is that this makes it seem like if isDynamic="false" then the 
state can't change dynamically.  Any ARIA property can change dynamically. 
Right now I believe the spec says somewhere that it's just a hint.

It would be bad if we accidentally limited authors from dynamically 
changing semantics that are useful to change.

- Aaron



From:
James Craig <jcraig@apple.com>
To:
W3C WAI-XTECH <wai-xtech@w3.org>
Date:
06/24/2008 11:24 PM
Subject:
ISSUE: States should just be Properties with isDynamic=True




ISSUE: States should just be Properties with isDynamic=True

I'm concerned that the current ARIA distinction between States and 
Properties is primarily due to an AT implementor perspective on 
managed states. I understand the benefit to implementors, but I think 
this "subtle  difference" is not well defined, and I think it will 
lead to confusion among web application authors. Considering that 
number of authors reading ARIA specs will likely be much higher the 
number of AT implementors in existence, I'd lean towards skewing the 
readability in favor of the authors' perspective.

Current definitions of Properties versus States.

> Property: Attributes that are essential to the nature of a given 
> object. As such, they are less likely to change than states; a 
> change of a property may significantly impact the meaning or 
> presentation of an object. Properties mainly provide limitations on 
> objects from the most general case implied by roles without 
> properties applied.
>
> State: A state is a dynamic property expressing characteristics of 
> an object that may change in response to user action or automated 
> processes. States do not affect the essential nature of the object, 
> but represent data associated with the object or user interaction 
> possibilities.

Current web authors are very familiar with "properties as attributes" 
in HTML. I believe it hurts the readability of the document to 
separate dynamic properties (states) from standard properties. 
Likewise, splitting them into separate lists decreases the readability/ 
understandability of the document.

I propose we reconcile the list of states and properties into one 
master properties list. In the "Definitions for Properties" section, 
the properties-previously-known-as-states could be marked as 
isDynamic=True. isDynamic would then be defined as:

isDynamic: Dynamic properties are not essential to the nature of a 
given object. As such, they are more likely to change than non-dynamic 
properties; a change of a non-dynamic property may significantly 
impact the meaning or presentation of an object.

Comments?