state management plug-in idea

[Eli Cochran]

Really good questions.

> So this would involve identifying HTML elements, and within that,
> attributes, that have correlates in the 3 contexts? Or just 2 of  
> them? Is
> the lookup attribute the HTML attribute? I imagine so.

I've been doing some research into how _state_ is represented in HTML,  
CSS, and ARIA--the break down of functionality, presentation, and  
accessibility -- although the mapping isn't 1 to 1. At the moment that  
research is represented by some disorganized lists here:
	http://wiki.fluidproject.org/display/fluid/Springboards#Springboards-elementsandstates

(The Fluid component section I'v just barely started to flesh out.)

The next step for me is to create a matrix to see where the overlap  
is. My first surprise is how few states there are and how little  
overlap.

But to get to your question, in terms of utility, if there are two  
contexts that need setting then to set those contexts via a plugin  
would be worth it. But for simplicity, once you are setting the state  
of some elements via the plugin would you want to be able to set all  
your state this way even if there were only one context?

It would be great to be able to key off the HTML element, but I  
suspect that HTML elements are too high level. Think of a link [a]  
which could be a link, a button, a tab, a whatever. Depending on the  
link's role, you might need to set the state differently. Again, still  
some thinking to do there.

We're not at code yet, but the data might look like:

{
   selector:  { state: ["html-attribute", "aria-state", "CSS-class"]},
   selector:  { state: ["disabled", "disabled", ".disabled"] }
}

Well that's rough. (I keep picking on disabled because it's so obvious.)

> I could help with this, if needed.

That would be great!

>
> Also - I ask out of sheer ignorance and in complete innocence - why  
> is IE 6
> a concern? I assume that since Eli brought it up it is a supported  
> browser,
> but just want to make sure. It looks like if Moodle or Sakai support  
> it then
> Fluid supports it. Does this mean that if they did  not Fluid would  
> be free
> from it?

I can't speak for the Fluid project, but if Fluid's clients stopped  
supporting IE6, I'd be lobbying for dropping support in a heart beat.

<sandbox>
This moment reminds me of the moment about 6 years back when the vast  
number of web sites decided to drop support for Netscape 4 and IE5,  
even when there were still a fair number of people using those  
browsers. We (developers, managers, marketeers, decision-makers)  
individually decided that dropping support was the best thing for the  
web ecosystem as a whole even if it alienated and annoyed a minority  
of browser users who hadn't or didn't want to upgrade. Dropping  
support meant that we could increase our productivity and deliver  
better designs and user experiences, while (not so subtly) encouraging  
the last stragglers to upgrade their browsers. The last time this  
happened it was controversial, and it took time. But ultimately it  
only took a few big players saying that they no longer supported those  
browsers for others to start piling on. And we're beginning to see a  
few of big players stop supporting IE6. The stakes are high, but the  
gain in productivity is huge. I think that the time has come.
</sandbox>

> So many questions!
>
>    -Gonzalo
>
> On 8/14/08 5:51 PM, "Colin Clark" <colin.clark at utoronto.ca> wrote:
>
>> This is where the real work would come in, but I think it could
>> probably be done fairly easily by someone who felt like developing an
>> intimate familiarity with the HTML spec. Certainly the jQuery plugin
>> part is trivial, it's just a matter of capturing all the rules for
>> specific elements.
>

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley