Hi everyone, I'll try to summarize the issues we've been pondering both in the IRC channel and here on list, just so we're all on the same page.
The original issue that Gary Thompson and the uPortal community reported about the FSS is pretty straightforward: we were placing a very thick black border on all focused elements by default. This was specified at the very lowest level of FSS, the reset file. As a result, users of the FSS were constantly required to override the focus indicator style, ensuring that it was more appropriate for the look and feel of their site. Gary sensibly recommended that we not style :focus by default at such a low level. Our reset files are intended to be neutral-- they establish a common baseline from which a cross-browser look and feel can be defined. Heavy-handed focus styling doesn't belong here, so we made the right decision to remove it early in the Infusion 1.4 release cycle. The next question is, should we be styling :focus by default at a higher level in our theme files? At the moment, we do ship default focus styles in each theme, but they are scoped to the .fl-focus class. As a result, if users want to use our standard theme-specific focus styles, they simply need to place this class name on the appropriate parent element. In practice, this will typically be the body. Without the inclusion of .fl-focus, the browser's default styling will prevail. This is an opt-in system. There's a distinct disadvantage to an opt-in system: users need to know about it, and there is the risk that they never bother to do so if needed. This leaves it up to the user agent to style the focus indicator appropriately. Firefox is particularly subtle with this; one hopes that this may improve in the future. Explore an opt-out solution, we're not fully clear what impact placing a default :focus style in our themes will have on users who are using a theme as a baseline for styling their own look and feel. My gut feeling is that we probably should indeed style :focus by default, since themes are typically the place where colour and appearance issues are defined. But I'd like us to contemplate the issue and do some real-world tests before we go ahead with it. The risk of switching to an opt-out system for Infusion 1.4 is that if we get it wrong, we will potentially inconvenience users in a future release, since they'll have to opt-in to get previously default behaviour. Looking at it holistically, James has also suggested that we may want to revisit the nature of our themes for Infusion 1.5 anyway, so that seems like a good time to make the fix. So, in short, we'll ship Infusion 1.4 with an opt-in approach to focus styling in the themes. Authors simply need to place the .fl-focus class name on the body of their document, and they'll get our awesome default styling for free. If they want the browser's default styling, or want to take care of styling it themselves, they can omit .fl-focus and do whatever works best for their users. We'll revisit this decision for Infusion 1.5. Seem reasonable? Colin 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. > > Thanks > Justin > > 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: >> >> http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2011-10-06 >> >> Justin_o reopened FLUID-4504 yesterday in response to finding a focus >> failure in the UIO demo - >> >> http://issues.fluidproject.org/browse/FLUID-4504 >> >> Unfortunately this seems like a straight reversal of the reasoning which led >> to FLUID-3880 >> >> http://issues.fluidproject.org/browse/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 - [email protected] >> To unsubscribe, change settings or access archives, >> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
