- From: James Craig <jcraig@apple.com>
- Date: Tue, 24 Jun 2008 15:24:52 -0700
- To: W3C WAI-XTECH <wai-xtech@w3.org>
What if we specify the characteristic/value in a way that looks less like a variable? "Property implied as State: Yes" instead of "isDynamic: True" On Jun 24, 2008, at 2:30 PM, Aaron M Leventhal wrote: > 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? > > > >
Received on Tuesday, 24 June 2008 22:25:36 UTC