Skip to content
This repository was archived by the owner on Oct 8, 2021. It is now read-only.

1.5 Style options removal

Jump to bottom
Jasper de Groot edited this page Feb 28, 2014 · 26 revisions

Notes about the changes we are going to make for 1.5 to remove style options from widgets

General

  • Open a ticket for each widget (milestone 1.5)
  • Separate branches for each widgets
  • Squash all commits in the branch before merging in master - the one commit that will be merged should close the ticket

Q - Hyunsook: How do you handle the default value of the style options? For example, on Button widget.

  • Current : The default value of the drop shadow option is true. So Button widget applies the drop shadow style even though user doesn't set option's value.
  • After (removing the style options) : But, let’s suppose we replaced the shadow option with a data-wrapper-class option. At that point, if user doesn't set a option's value, the button widget should be applied the shadow style? Or not?

A - Jasper: This is part of backcompat. I think we have to change the defaults to false because we can't detect if the user is using the new way and didn’t add a style class on purpose, or is using the old way and expected the style being adding by default.

Note: Mixing of deprecated style options and the new way (adding classes in markup) in 1.5 won't be supported

Q - Hyunsook. How can user get/set the removed or replaced style options at runtime? Current : The widgets support to get or set each option via setOptions. After : Should jQM support that user handle the removed/replaced style options via setter/gertter for data-wapper-class? Or just, can we guide that user should handle the options via jQuery.css()?

A - Jasper: Users should (un)set styles by adding/removing the applicable classes. Before a widget is initialized you can add classes in your markup or (if the classes need to be added to a generated wrapper) by setting wrapperClass option. After initialization you can use addClass/removeClass. I consider using .css() to set styles bad practise.

Button (use wrapperClass option)

  • Corners
  • Icon
  • IconPos
  • IconShadow
  • inline
  • mini
  • shadow
  • theme

Checkboxradio (use wrapperClass option)

  • mini
  • theme
  • iconpos

Collapsible

  • collapsed icon
  • corners
  • expanded icon
  • iconpos
  • inset
  • mini
  • theme

Collapsible Set

  • collapsed icon
  • corners
  • expanded icon
  • iconpos
  • inset
  • mini
  • theme

Controlgroup

  • corners
  • mini
  • shadow
  • type - not so easy because you also have to call refresh

Fixedtoolbar

none

Listview

  • count theme (deprecated)
  • divider theme
  • header theme
  • icon
  • inset
  • spliticon
  • split theme
  • theme

Loader

  • theme - not easily set should stay?

Navbar

  • iconpos - need to loop over the buttons?

Page

  • theme

Panel

  • theme

Popup

  • corners
  • theme
  • overlay theme - should stay?
  • shadow

Rangeslider

  • mini
  • theme
  • tracktheme

Selectmenu

  • corners
  • icon
  • iconpos
  • iconshadow
  • mini
  • inline
  • overlaytheme
  • shadow
  • theme

Slider

  • mini
  • theme
  • tracktheme

Table

  • column toggle - not easily set should stay?
  • column button theme
  • column popup theme

Textinput (use wrapperClass)

  • mini
  • theme

Toolbar

  • theme
Clone this wiki locally