Going on a Safari....
justin.obara at utoronto.ca
Fri Jan 9 15:39:26 UTC 2009
In general I would agree that the font size would out weigh the merits
of the native appearance of the button. However, I have a question.
I'm assuming that this solution would only solve the problem for the
button in the component, and that the other buttons the integrator
puts on the page would still suffer from this issue.
In that case, would it be confusing to the integrator why it works in
some places and not in others? If this is a problem with the browser,
it may be a good idea to document the issue.
In general, it may be helpful to have a section on the wiki or build
site that demonstrates all of the 3rd party issues that we have
encountered and are reliant on someone else to fix. (i.e. browser
specific issues that don't have a work around) This would also provide
us with a point of reference to determine if new browser versions
solve these issues.
On 9-Jan-09, at 9:41 AM, Anastasia Cheetham wrote:
> On 8-Jan-09, at 4:35 PM, Jacob Farber wrote:
>> Do you think it's acceptable to squash the native appearance of a
>> form control in order to force it to accomodate other settings? Is
>> it more user-friendly for the font size to render properly or for
>> the form control to look like a native control?
> Hm... This is an interesting question.
> First, I think a screen shot or two might help convey just what the
> button looks like when you do and don't do your proposed solution.
> My reaction is: I would think it would be better to sacrifice the
> native appearance in favor of a 'properly functioning' button.
> Anastasia Cheetham a.cheetham at utoronto.ca
> Software Designer, Fluid Project http://fluidproject.org
> Adaptive Technology Resource Centre / University of Toronto
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work
More information about the fluid-work