state management plug-in idea

[Jacob Farber]

Maybe I'm misunderstanding the Template Renderer, but should all this 
logic be handled by the templating system?

Eli Cochran wrote:
> 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
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20080815/bc494911/attachment.html>