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

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?
>
>
>
>