- From: David Bolter <david.bolter@utoronto.ca>
- Date: Wed, 25 Jun 2008 10:19:07 -0400
- To: Aaron M Leventhal <aleventh@us.ibm.com>
- CC: James Craig <jcraig@apple.com>, W3C WAI-XTECH <wai-xtech@w3.org>, wai-xtech-request@w3.org
Wishy-washy == badness. Maybe the goal to make ARIA simple enough should override the goal to provide this property vs state fidelity? I tend to agree with James on folding properties and states together, and I with Aaron on not specifying static-ness... but I'm not deep into this topic. cheers, David Aaron M Leventhal wrote: > > I'm not sure that helps. Al explained to me once that it's really just > to help give authors an idea of what the semantic is for. > > Not that I'm suggesting this, but Al's purpose for states vs. > properties would tend to lead to something like: > usuallyStatic > > Unfortunately that kind of wishy-washy stuff leaves me feeling > unsettled. Likewise, I wouldn't want to actually limit whether > something is dynamic or not. > > For example, at first glance multiline would seem to never change. > However, I have seen many chat or IM apps where the text line can be > changed to a multiline text area. > > - Aaron > > > > From: James Craig <jcraig@apple.com> > To: W3C WAI-XTECH <wai-xtech@w3.org> > Date: 06/25/2008 12:25 AM > Subject: Re: ISSUE: States should just be Properties with isDynamic=True > > > ------------------------------------------------------------------------ > > > > > 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 Wednesday, 25 June 2008 14:18:35 UTC