Walking into the office today, I had an idea. It's not well thought
out but I want to toss it out for consideration.
There are a number of ways that "state" is managed for both
functionality, accessibility and presentation in DOM/HTML/CSS/ARIA.
For the most part these ways are not very consistent, coordinated or
interoperable. Some of the problems are just the same old browser
foo: browsers not being up-to-date, not supporting the latest and
greatest, or supporting things in inconsistent ways. And some of the
problems are that the different areas (functionality, presentation,
and accessibility) have different needs.
Let's take something basic like the concept of "disabled".
HTML Attributes
Many elements, specifically form elements support a "disabled"
attribute: <input type="text" disabled="disabled" value="some value" />
And, pretty consistently, the browsers support the "functionality" of
the disabled attribute. If a form element is set to disabled you will
no longer be able to interact with the element.
Styling and CSS
Some browsers (I'm not looking up which ones at the moment), do some
automatic styling of elements that have the disabled attribute. But it
is inconsistent from browser to browser (just as the default styling
for form elements is different from browser to browser).
And all the browsers except IE6 allow you to apply your own styles to
elements using the CSS attribute syntax: input[disabled="disabled"] {}.
But IE6 is lacking, and so to do styling on a disabled element we also
need to assign a CSS class to the element:
<input type="text" disabled="disabled" value="some value"
class="disabled" />
and build up a corresponding style
input[disabled="disabled"], input.disabled {}
ARIA
Additionally you want to add an ARIA state to the element to fully
support screen readers.
<input type="text" disabled="disabled" value="some value"
class="disabled" aria-disabled="true" />
In an ideal world, all browsers, all css, all functionality, all
accessibility would key off of one attribute that could be set in one
place. But we don't have that. (although if IE6 fell off the map, we'd
be 98% of the way there.)
So we're stuck with setting three things if we want to programatically
make something disabled: html attribute, css class, and ARIA
attribute. And this is just for disabled for one kind of element, some
elements would have different and, more or less, complex rules.
What if we had a state plugin (jQuery of course) that allowed us to
say $(elm).state('disabled'); that would set all three for us in one
shot?
Obviously this would have to be driven by some large data object that
contained information about which elements get which attributes, and
which matching class, and allow for custom states and classes, and
some logic for when states are applied, removed, changed, etc.
Does this make sense? I'm sure that I'm missing a bunch of things here.
Thanks for your consideration,
Eli
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
user interaction developer
ETS, UC Berkeley
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
