FLUID-4504 focus styling issue
michelled33 at gmail.com
Fri Oct 7 14:35:49 UTC 2011
I'm leaning towards argument 2 - we are very late in the dev cycle to change this decision.
Let's leave fl-focus as is and add documentation that tells implementors to use the fl-focus class along side the theme. Finally we can add fl-focus to the demos to fix the current blocker.
Senior Inclusive Developer
Inclusive Design Research Centre, OCAD University
On 2011-10-07, at 9:46 AM, Justin Obara wrote:
> Thanks for looking into this and sending this out. I think I'm leaning towards agreeing with you. I was talking to Michelle yesterday about how we don't have a clear definition of what our themes are expected to be doing and providing our users.
> I had tried to keep the information on FLUID-3880 up-to-date with our skype calls and etc., but on reading it back yesterday there did seem to be some missing details. Sorry about that. Also, I wasn't in on the original meetings with uPortal, but perhaps others who were there would have some notes they could share.
> At any rate, I think we have two arguments to weigh.
> 1) The fl-focus scoping is new to this release. If we are uncertain of it's effectiveness should we back it out of the themes for now, before we lock it into a release?
> 2) There seemed to be, albeit unclearly, a decision made months ago and we are beyond the point, in this release, to revert those decisions.
> I'm interested in what others view points on this are, or if there are additions and/or clarifications to the two arguments above.
> On 2011-10-07, at 2:03 AM, Antranig Basman wrote:
>> Hi folks - I was asked to looking into the FSS focus styling issue that exercised us in the channel yesterday, but the more I look into it, the less clear the reasons behind the issue seem.
>> As a revision, the day's logs are here:
>> Justin_o reopened FLUID-4504 yesterday in response to finding a focus failure in the UIO demo -
>> Unfortunately this seems like a straight reversal of the reasoning which led to FLUID-3880
>> The reasoning isn't recorded in great detail there, other than "uPortal's preference: let the browser handle focus styling." but we should try to uncover the reasons behind this earlier decision in more detail, contacting Gary for information if necessary. It seems that there is some vagueness about the purpose that our FSS themes actually meet - which may reflect a transition in the way we are thinking about them, but this point in the release cycle doesn't seem the right point to effect such a major change in policy as removing the focus scoping rule which we had previously committed to, apparently specifically in response to a request by one of our major users. My vote is for carrying on with our previous policy (this change really amounts to an "API change" and possibly something even deeper) and reassess the meaning and content of the FSS themes over the next release cycle.
>> For example -
>> i) it may be that uPortal is not interested in our specific delivered themes, but only in our reset file and general rules for making themes (true or false?)
>> ii) it may be that our themes are not intended for the purpose of visual styling in the sense of "aesthetic preferences" but actually for the purpose of reflecting more functional preferences by users affecting usability (true or false? or do we actually declare this question meaningless?)
>> iii) the crucial issues (to me) of a) who gets to write themes - b) what work is required in writing a theme, and c) who can the author of a theme tell about it, and how
>> fluid-work mailing list - fluid-work at fluidproject.org
>> To unsubscribe, change settings or access archives,
>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fluid-work