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 Tuesday, 24 June 2008 22:25:36 UTC