jQuery Mobile Team Meeting – Mar 06 2014

  • Style option removal
    • Might increase CSS size, leading to longer startup time.
    • Certain widgets support certain options. If it's just classes, users might try to add any class to any widget.
    • Kangsik: There will be too many classes and too many ways of adding them - sometimes to data-wrapper-class, sometimes to class. It will be harder to use jQM.
      • keep non-bool style options like theme, icon, and iconpos; look into deprecating theme swatches for 1.6
  • Collapsible collapsed/collapsed-icon/expanded-icon
    • Might be doable entirely in css with, maybe, like .ui-icon-expanded-plus and .ui-icon-collapsed-plus, etc., but again, it would probably add a lot to the CSS, increasing startup time.
  • Shadow option
    • If we change the default to false, is there a way to provide a deprecation period?
    • We could add a shadow even if no class is specified, and then create a class ui-no-shadow to turn it off.
  • page vs. pagecontainer events demo
  • Changing file structure
  • testswarm
    • Need to find out where to start
      • Alex looking into
  • selectmenu
    • Native fall back is complicated. Needs different markup

jQuery UI Team Meeting – Mar 05 2014

jQuery Core Team Meeting – Mar 03 2014

Attending: DaveMethvin, rwaldron, m_gol, gibson042

link Wrap up on browser support in 1.12/2.2

  • Dave has draft blog post
  • Stop accepting new bug reports on these, close wontfix
  • Only fix severe regressions but leave patches in for 1.12 & 2.2
  • Sync with UI to remove IE 7 etc support there too
  • Still needs edits to clarify, want to prevent wails of protest
  • Changes won't come until 1.13, months away
  • We'll pull IE6/7, Safari 5.1, Opera 12.1x all at once in 1.13
  • per markelog, what about IE7 CV mode in IE8?

link $.fn.data API

  • Let's make a call on this, need to make 1.x and 2.x compat
  • What is the easiest & least disruptive behavior change?
  • I'm leaning towards 1.x behavior with minor changes
  • Conclusion: "Embrace HTML5" with one exception: Don't camelize objects that are extended into the data object
  • TODO: clean up docs for .data() to make things clearer

link Bower

link support.boxSizing - why is the test so complicated & requires a body?

  • check old Androids
  • ask mikesherov

link 1.11.1 and 2.1.1

  • Land fixes soon so we can move on to 1.12 and 2.2 in master
  • Can always branch later if we need 1.11.2 etc

link Current open tickets

jQuery UI Team Meeting – Feb 26 2014

jQuery Core Team Meeting – Feb 24 2014

Attending: DaveMethvin, m_gol, gibson042, markelog, rwaldron

(Chat was held on the Google Doc, IRC was flakey)

link Job for underachieving old browsers being put out to pasture

  • "Weekly Job" is the name

link $.fn.data API

  • Let's make a call on this
  • Do we want to make two new entry points for a “pure js” data object with no “black magic” and a “dataset” that only works on elements/with string values
  • “the new API is not going to fix any of this, since people will still want .data() to work they way they expect, and populate with JSON data to initialize, etc.” - Dave’s reasoning against
  • We need to bring 2.x into compat with 1.x behavior

link Bower

  • Did timmywil's latest updates take care of this?
  • Do we need to update older tagged versions?

link Wrap up on browser support in 1.12/2.2

  • Proposed: Keep IE6/7 in 1.12.x (last one), fork Sizzle to remove non-jQuery-2.x browser support
  • Announce the end of the line in a blog post
  • Do we really fail a lot of tests on Safari 5.1?
  • OUTCOME: Dave to write up a blog post
  • We'll pull IE6/7, Safari 5.1, Opera 12.1x all at once in 1.13

link Android 4.0 & $.trim

  • this was the only test failing consistently in Android 4.0
  • OUTCOME: Just use a regex

link $.xhr

  • Need to start work on this
  • 1.11.1 and 2.1.1

link Maintenance fixes?

  • Let's land these soon and use master for 2.2

jQuery Mobile Team Meeting – Feb 20 2014

jQuery UI Team Meeting – Feb 19 2014

Testing Team Meeting – Feb 13 2014

Location: jQuery Conference San Diego

Attending: James, Timo, Leo, Jörn

  • reporter interface that we can share with other testing tools
    • to make it easy to integrate into karma, browserstack-runner or grunt plugins
    • needs a data format ala JUnit XML (maybe ala tap?), that is flexible enough to support QUnit and others
    • reporters should be built on top of this format: console, html etc.
    • need to do research for this - how do other test frameworks and their integrators currently handle this? What are the differences?
  • assertions cleanup
    • what do we really need to keep?
    • make equal/notEqual() strict and drop strictEqual/notStrictEqual
    • deprecate/remove ok()
      • need to research how ok() is used, and document what to do instead
      • like ok(array.indexOf > -1) -> notEqual(array.indexOf, -1)
  • make it reasonable to compose assertions
    • at least expose the traversal of QUnit.equiv
    • maybe expose an API for custom assertions that fixes stack traces when delegating to other assertions?
    • or try to have the assertion wrapper/constructor keep track, so that it doesn't matter on what level you call assertions, it'll unwrap correctly
    • or try and see what happens if we simplify the stack trace handling - a few more lines might be worth removing the complexity
  • async tests!
    • references: mocha, nodeunit
    • force calling done like nodeunit? make that configurable?
    • grunt style async() method that returns a callback which you run when done?