0 Replies Latest reply on Jun 1, 2012 2:22 PM by Dillik

    Theme CSS: fields' "focus" and "pressed" state formatting sometimes disregarded

    Dillik

      Summary

      Theme CSS: fields' "focus" and "pressed" state formatting sometimes disregarded

      Product

      FileMaker Pro

      Version

      FMP 12.0v1

      Operating system version

      OS X 10.7.4 (also 10.6.8)

      Description of the issue

      (Note: Very few users will likely find this bug report relevant to their activities.  Sorry.)

      This bug pertains to how FMP12 processes the CSS in a theme's definition.  FMI can say developers shouldn't be designing custom themes, but I think FMI's developers should still know of this issue in preparation for the day when custom themes are encouraged or when subsequent official themes are developed.

      In a theme's CSS, properties can be specified for fields' hover, focus, and pressed states (these settings are accessible via the inspector as well).  FMP12 understands CSS specifying these states for all field types OR by specific field types.  For example, "field:hover .self" defines hover properties for all field types, while "container:hover .self" defines hover properties for container fields only.

      The problem comes if a field is given a non-default property which overrides the theme's "normal" setting for the field (for instance, let's say the theme specifies that all fields are yellow in their normal state, but a layout designer wants one field to be a non-default orange).  If the states have been specified for all fields at once (example: "field:hover .self") AND a field's normal state is non-default, this new normal state overrides the theme's specifications not just for the normal state, but also when a field is pressed or hovered+focused.  See example below.

      Steps to reproduce the problem

      I made a bare-bones test theme just with the following CSS:

      field .text { height: 100% } /* so the text will show up in the field */
      field .self { background-color: #ffff00 } /* fields normally yellow */
      field:hover .self { background-color: #00ff00 } /* green on hover */
      field:focus .self { background-color: #00ffff } /* cyan on keyboard focus */
      field:pressed .self { background-color: #0000ff } /* blue on click */

      As seen above, all fields (regardless of type) should be yellow in their normal state, green when the mouse hovers over them, cyan when the field has keyboard focus, and blue when clicked with the mouse.  These properties work fine in practice, so long as a field isn't given non-default normal-state properties in layout mode.  If it is, things go awry.

      In a layout that uses the above theme CSS, set a field to be orange in its normal state and then try interacting with it in browse mode.  The field will still turn green when hovered over and cyan when focused, but it turns orange (not cyan) when it's both hovered over and focused simultaneously.  Clicking also doesn't turn it blue as it should.  Both of these behaviors use their expected formatting if the field uses theme-default properties only (the normal state shouldn't ever override click-state formatting or hover+focus-state formatting).  It's the non-default normal-state formatting that screws things up here.

      So how do the 40 official themes avoid this issue?  Well, curiously, if the "focus" and "pressed" formatting is defined for one field type at a time, everything works as it should.  For example, adding this redundant code to the above CSS fixes it:

      edit_box:focus .self { background-color: #00ffff }
      edit_box:pressed .self { background-color: #0000ff }
      text_area:focus .self { background-color: #00ffff }
      text_area:pressed .self { background-color: #0000ff }
      drop_down:focus .self { background-color: #00ffff }
      drop_down:pressed .self { background-color: #0000ff }
      calendar:focus .self { background-color: #00ffff }
      calendar:pressed .self { background-color: #0000ff }
      pop_up:focus .self { background-color: #00ffff }
      pop_up:pressed .self { background-color: #0000ff }
      container:focus .self { background-color: #00ffff }
      container:pressed .self { background-color: #0000ff }
      checkbox_set:focus .self { background-color: #00ffff }
      checkbox_set:pressed .self { background-color: #0000ff }
      radio_set:focus .self { background-color: #00ffff }
      radio_set:pressed .self { background-color: #0000ff }

      So it would seem FMP12's programming for applying formatting is partially incomplete when it comes to specifying properties for all fields at the "field .self" level.  If there are any support admins working the board who wish to verify the behavior without having to produce and implement a custom theme file, let me know where I can send a two-layout test database with and without the redundant "fix" code (the layouts will remember what the theme's CSS code was the last time I applied it to each, so you shouldn't need the theme's CSS file itself).