- Working through plans to remove duplication between jQuery UI build system and download builder.
- Working on Pointer Events special event implementation.
- Determining what testing framework to use.
- Working on theming documentation.
- Documented CSS Framework.
- Documented icons.
- Documented
.ui-front
. - Working on individual widgets.
Author Archives: builder
jQuery Core Team Meeting – May 27 2013
Attending: m_gol, jaubourg, dmethvin, gnarf, orkel
Official Agenda:
link jQuery 1.10.1/2.0.2
- .finish() on multiple elements
- Incremental animations
- Tickets still needing attention
- http://bugs.jquery.com/ticket/13938 okel has pr for sizzle
- Ship date?
- Thursday/Friday?
- Animation bugs likely to generate a lot of dups
link jQuery 2.1/1.11 changes
- Discuss at in-person Portland meeting?
link Open tickets triage
Ecma/TC39 Meeting – May 23 2013
link May 23 Meeting Notes
(by Erik Arvidsson)
John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH) (calling in), Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark Miller (MM), Tom Van Cutsem (TVC), Istvan Sebestyen (IS)
link Promises vs Monads
MM: ...Continuing from yesterday
AR: https://github.com/slightlyoff/Futures/blob/master/Promise.idl
STH: Don't like resolve but not willing to die on this hill.
AR: DOM has a bunch of ad hoc APIs to do promise like things.
YK: Mozilla is also actively working on APIs using promises.
AR: A lot of methods today return void so we can change these to return a promise. This is forward compatible.
AR: then does recursive unwrapping...
link ES6, ES7, ES8... Mark's Strawman Roadmap
LH: The important part is not the features but the process.
AWB: Can things be decoupled?
LH: These kind of structural questions are the important part
MM: Suggests "concurrency" to be the main theme.
AWB: Thought about the event loop. All we need is a processing queue... put things in the front and the back.
DH: Only need to add to the back.
AWB: OK.
STH: The callback is called at some later point.
AR: Don't think we need to specify the order.
STH: If we are going to specify promises etc we need to be able to specify things in detail. We can be loose in ES6 and then come back in ES7 and provide a more tight spec.
DH: We could specify the pending events as a set or something. Not sure if there is a consensus that we want a fast small ES7. Not opposed to a modularized approach.
AR: Are there any browsers that are not shipping stable ES6 features today.
YK: Yes. V8.
AWB: Where we have problem today is that there is a lot of interdependency.
MM: These ("concurrency") are coupled together to the event loop
AWB: We can do it as a separate non 262 spec
DH: Opposed to a separate spec. Introduces versioning confusion.
AWB: Roll up
DH: Think of all the extra overhead.
STH: Big difference with 402 since it was run by different people.
LH: Lack of confidence in new features has been an issue for implementers. Good exceptions were Object.observe
and Proxies
where the wiki contained a mostly complete spec.
AWB: We need to have wiki proposals be deltas to the spec.
TVC: We could have "stable" wiki pages. These would have complete spec deltas.
DH: Very concerned about over modularizing.
AWB: We need to find a way to work faster and be less monolithic.
DH: Agree. ES6 process has blocked implementation work.
LH: We are not committed to our designs.
STH: We are not resolving issues until we start to spec. We are not getting feedback until engines starts to implement.
EA: The problem is that we didn't start to spec things until very late. We had agreements on features long before there was any spec drafts for them.
YK: More from our champions before we get to concensus.
ARB: Lots of the proposals were very vague.
AWB: The more complete spec you bring to tc39 the better chance you have to reach consensus.
ARB: Lack of early spec leads to lack of early implementations...
AWB: ...which leads to lack of feedback.
LH: Not more work, just doing the work earlier before things pile up too much.
DH: Need to look at the dependency graph. Hold of the work of later feature.
ARB: We need to higher bar before we accept proposals.
MM: What we agreed to 2 years ago was that the features are the one we want to spend work on speccing.
LH: Less features to bite of.
DH: A lot of us have a hard time not getting too engage in too many features.
YK: if we focused more effort on managing the overall complexity instead of getting stuck on a lot of technical discussions (and nit picking).
DH: Object.observe
and Proxy
moved fast but are fairly isolated features
TVC: Didn't involve syntax.
AWB: With ES6 we had a long backlog.
DH: A language will have smaller and smaller complexity budgets as it grows.
AR: ES future needs events
DH: Since this is Mark's wishlist people will throw in their pet features.
MM: This is the direction I am going to work.
LH: There is a page on the wiki outlining the goals.
LH: Looking for 2 things: Something that would allow earlier implementations. Have not brought proposals (over the last 2 years) because we have been blocked by ES6.
LH: When is the appropriate time to bring new proposals to TC39?
AWB: We are free to do what we want. We can issue 6.1, 6.2 etc or technical reports which would serve as a recommendation.
DH: We cannot exclusively work on ES6.
YK: Time at f2f is the most important. Champions can go off and do what they want.
DH: Suggests adding non ES6 items to the agenda. We will prioritize the non ES6 stuff we can get to given our limited time.
YK: We should reinstate the rule that agenda items needs links to wiki pages.
YK: Spec language is good but examples at the top are a must.
ARB: Add step after proposal. For example "stable" or "spec" which a proposal gets promoted to once there is a spec draft, good enough to start implementing.
DH: Strawman: Anything goes.
YK: Proposals used to mean approved.
DH: 3 sections: strawman, proposal, spec/candidate. Keep strawman. Work on improving as a proposal, and when mature enough promoted to next level.
jQuery Mobile Team Meeting – May 23 2013
- Attending: Todd Parker, John Bender, Jasper de Groot, Anne-Gaelle Colom, Gabriel Schulhof, Alex Schmitz
link Todd
- No meeting last week
- Team is focused on 1.4 work
- New icon set is coming along nicely
- Spoke to Dragan who may be able to help us with docs and FAQs, he’s been doing great work on Stack Overflow support
link John Bender
- content widget
- changePage is now an alias for element.content( “change” )
- tests continue
- further thinking here: https://github.com/jquery/jquery-mobile/issues/5427#issuecomment-18353408
- Talked with the intel folks
link Jasper de Groot
- Almost finished with “next”, just few more small things to look into examples of new markup: http://view.jquerymobile.com/next/demos/test/theming/
- One issue: inheritance of popup theme or collapsible content theme
- Going to update unit tests, demo center, API docs, 1.4 changelog wiki one widget at the time
- Also want to create test pages (kitchen sink)
link Anne-Gaelle Colom
- Api docs:
- Icons page: http://api.jquerymobile.com/icons/
- Minor fixes (typos/rearrangements/added links)
- updated logo for Codiqa on resources page
link Gabriel Schulhof
- Starting work on widget cleanup with Alex
link Alexander Schmitz
- Fixed ability to view directories on jquerymobile.com
- gnarf added me to infrastructure so any needs we have there i can help with now
- merged toolbar widget into master
- page.sections is gone
- toolbars now work outside pages
- true persistent toolbars
- listviews now work outside pages
- First pass at panels outside pages.
- in branch ext-panels
- so far everything seems to be working just need some css tweaks
- looked into pointer event polyfills
- will replace vmouse events except for vclick
- ui starting https://github.com/jquery/jquery-pointer-events
- looked into other fast click solutions : ours seems to be the most robust currently but we need to make it work with pointer events
- Going to look into making this update Kinblas agreed to help with anything i need regarding vClick and vMouse
- Triage & bug fixing
Ecma/TC39 Meeting – May 22 2013
link May 22 Meeting Notes
(by Erik Arvidsson)
John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Brendan Eich (BE), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH) (calling in), Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark Miller (MM), Tom Van Cutsem (TVC), Istvan Sebestyen (IS), Jasvir Naga (JNA)
link 4.16 Spec update
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
YK: ToPositiveInteger
is needed by JSIDL
AI(YK+AWB): Put an algorithm in the spec that DOM can use so that we get the same behavior in JS and DOM.
6 General implementation experiences
ARB: We started implementing generators but things are pretty smooth.
BE: Doing modules at the moment.
AWB: Bunch of bug fixes in the spec related to classes.
link 4.9 Template Strings (Template Literals)
MM: Suggests status quo.
AR: Objects
MM: Controversy related to tag-less templates. Alternatives include making tag-less templates an error, delayed evaluation (contextually provided)
AR: Econics: naked interpolation is too attractive. Should always have a tag to encourage users to think about which behavior is correct.
YK: I cannot support Alex's proposal.
STH: What would the name of this tag be?
AR: Something that is imported from a module.
STH: Concerned about short names and conflicts.
YK: People will just use 's' without thinking.
YK: People should use HTML templating engines.
DC: Alex's testimony about application developer feedback is relevant.
LH: it sounded like Google engineers were using a template system
EA: Correct.
MM: Does anyone prefer taking out TS if they don't get tag-less TS?
Everyone: Agrees that it is better to require tag than to remove TS from ES6.
AR: Strings are always used later in some context. Communicating the intent
AWB: String concat vs string interpolation have the same issue.
LH: Assumes that maybe only 20% of the uses of TS are susceptible to XSS
MM: Removing tag-less does not reduce XSS because people will just use
1
|
|
TS helps people transition to a better world. Once they have have a TS it will be easy to add an html tag at the front as needed.
ST: It will be painful to import String raw and alias that to s.
MM: Maybe put tag-less in appendix? Withdrawn idea because no one likes it.
YK: You should not have use string based APIs.
AR: Willing to abstain but "Y'all are making a big mess"
BM: Half convinced by Alex.
LH: Different code bases will use different tags for normal string interpolation so moving between code bases will be hard to.
AR: That is a good thing. Forces people to think.
MM: Template strings in E.
STH: Lots of contexts where XSS is not an issue.
BM: More ways to XSS is a bad thing.
BE: if people have to import s then the economics change and people will stick to +
link Consensus/Resolution:
- AR and BM sustains.
- Continue with the status quo (tag-less TS is supported)
link JSON
DC: IETF wants to change JSON
MM: The 2 documents should have exactly the same text except for boilerplate.
IS: Should it be done in TC39?
DC: Most of the work will be on the mailing lists
AWB: Who will be the editor?
DC: Hopes they (IETF) will provide an editor.
JN: Should this be fast tracked to ISO?
DC: That makes sense.
JN: How long do you expect this to take?
DC: Has taken a long time to coordinate and get started. 5.1 specs the 2 functions that uses the JSON format.
link 4.10 Modules
STH: Progress since last meeting. Discuss "module naming", "naming standard modules". http://wiki.ecmascript.org/doku.php?id=harmony:modules Wiki is up to date with the current proposal. Spec is "wiki complete".
Jason Orendorff of Mozilla has worked on flushing out semantic issues. Moz is implementing parsing of modules.
STH: Syntax: Made a couple of changes.
A. To support anonymous exports
1
2
3
|
|
If there is no default then the above is an error
1
2
3
|
|
to reduce confusion and to make it clear that this is not destructuring.
1
|
|
- fs is a module instance object
The following is not valid:
1
|
|
Renaming on export:
1
2
3
|
|
The following is not valid:
1
|
|
STH: The only evaluation here is "13". The rest are just bindings that are shared with the outside/module importer.
MM: Bad idea to allow external modules to assign to imports.
DH: Imported bindings are read only to the importer.
AWB: This is new semantics to the language. Is there a list of these new semantics modules introduce?
AWB: Is there a way to get the default export from the instance module obejct.
STH: There will be a well known symbol name to get to it.
AWB: Does module instance objects inherit from Object.prototype.
DH: No. Because we do not want any pollution.
JNA: Is it an error to assign to an imported binding?
1
2
|
|
AR: What is the reason for not extending Object.prototype
or some other
object?
YK: To prevent people from expecting toString
to be there (???)
DH: fs.readFile
We don't want to statically check this deeply inside an expression.
1
|
|
THS: The plan is to allow the above to be a static error in the future.
DH: To keep things clean.
AWB: Concerned about the dot operator
ARB: Don't want less checking if you do not use import.
DH: Do not want refactoring hazards.
ARB: This only affect the static semantics.
AWB: Can you use square bracket?
STH: Square bracket is dynamic.
AR: This is only a static check that is lost. At runtime there will still be errors.
LH: Concerned about default export. Now people will have to decide which approach to use.
STH: This is already the case in Node.js today.
LH: Today you might get any object, it might be callable with properties.
1
2
3
4
5
6
7
8
|
|
Lots of discussion...
1
|
|
alt
1
2
3
|
|
LH: Prefers export =
and lose static checking when people opt in to single anonymous export.
STH/YK: We already agreed that we want static checking.
LH: Even for new things being built, this is causing a confusion.
AWB: It is unclear when and what you want to export as the default export.
BM: Wants
1
|
|
...to ensure that people have to be explicit about what they import.
DH: This is just syntax and we are wasting time "bikeshedding"
AWB: What is the best practice? Is there a single module containing Map, Set & WeakMap or...
YK: WeakMap should be its own import:
1
|
|
BE: We have to pay attention to what Node/AMD do today.
YK: AMD tries to make modules small to reduced byte size of the dependencies.
STH: And now to semantics https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
Major things that changed. Use options object more consistently. The wiki page is up to date. Need to decide whether the browser loader is in the appendix or if it is in some w3c spec. Want core language semantics to treat the names as strings, not the semantics of these strings. Bulk loading. One HTTP request to load multiple modules. Possible to implement. Create fecth hook. Stores module notations in a side table. In the xhr response, split the result and call the different fulfill hooks.
EF: Sounds like what we do today in YUI loaders. How would you write the HTML?
DH: Initial script tag with configuration. Second script tag as usual. Alt 2 is to have configuration and dynamic module load in the same script block.
1
2
3
4
|
|
alt 2
1
2
3
4
|
|
DH: script[async] today have to use an external src.
STH: Naming and declarations of modules.
ARB: Presenting slides...
AWB: The rate that internal vs external names changes is very different.
STH:
1
2
3
4
5
6
|
|
STH: Configuration step is mostly about other people's code.
1
2
3
4
5
6
7
8
9
|
|
m
is fixed at compile time
ARB: Not opposed to logical modules. Wants both lexical and logical
DH: Not opposed to lexical modules.
YK: Too late to work out lexical modules for ES6.
ARB: If we wait we will have redundancy.
YK: Want declarative form to be able to prefetch etc.
BE: I want lexical modules (in the future) but logical modules are easier to use.
ARB: Since I don't seem to be able to convince anyone I'm going to drop this
ARB: For the record. Major concern about the global registry becoming the new global object.
link Consensus/Resolution:
- Move along with Dave and Sam's proposal.
- Work on lexical modules for ES7
jQuery UI Team Meeting – May 22 2013
- Working through plans to remove duplication between jQuery UI build system and download builder.
- Working on Pointer Events special event implementation.
- Determining what testing framework to use.
- Working through individual widget implementations for classes option.
- Working on theming documentation.
Ecma/TC39 Meeting – May 21 2013
link May 21 Meeting Notes
(by Erik Arvidsson)
John Neumann (JN), Allen Wirfs-Brock (AWB), Eric Ferraiuolo (EF), Erik Arvidsson (EA), Luke Hoban (LH), Doug Crockford (DC), Yehuda Katz (YK), Brendan Eich (BE), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave Herman (DH) (calling in), Bernd Mathiske (BM), Andreas Rossberg (ARB), Mark Miller (MM), Tom Van Cutsem (TVC), Jasvir Naga (JNA), Istvan Sebestyen (IS)
JN: Going through the agenda Adding proto Unifying iterator/generator APIs Talking about getting user stats for test-262... YK: Prioritize ES6 items. So that we don't get do ES7+ items before
Minutes approved unanimously
link 4.1 Object.freeze
DC: Today Object.freeze throws when primitives are passed in. Suggesting not throwing when a value type is passed in.
MM: Object.isExtensible would return false for primitives
EA: This would give an inconstint view for primitives.
AWB/YK: (In strict mode) numbers and strings lazily box so the assignment never fails.
MM: Proxies are allowed to be non extensible and throw away.
ARB: Is the suggestion to lazily wrap primitives?
MM: No, then Object.isExtensible(7)
would return true because the wrapper is
extensible.
AWB: In most of the new changes we are not doing unnecessary coercion.
YK: The Chrome dev tools, console.dir(7)
, says "no properties" which
supports treating these as empty objects.
MM: The only observable wrapper is the this
wrapper in non strict mode.
AWB: In the new spec, Object.setPrototypeOf(7)
throws.
MM: Agrees violently!
link Conclusion/Resolution
- DC+AWB to work out the details
link 4.2 WeakSet
Do we need them?
MM: Trivial shim around WeakMap.
YK: Often wanted it
AWB: Adds no new capabilities.
AR: We should not limit ourselves to what is a new primitive capabilities
AI(AWB): add to spec
link Consensus/Resolution:
- Add WeakSet in ES6
link 4.4 Proxies
TVC's presentation on Notification Proxies: https://docs.google.com/file/d/0B9iYRsLxmdqUd1RsdHZtazliWmc/edit?usp=sharing
Arguments against:
- shifts the burden from spec writers/implementors to users (need to use shadow target even for non-frozen objects)
- implementors will deal with spec bugs related to invariant violations as they come up
link Consensus/Resolution:
- Notification proxies are not approved.
- MM & TVC are still happy with direct proxies.
link Proxy Invoke Trap and wrong |this|-binding on built-in methods
AWB: with current default behavior of "get", "Caretaker" will break on built-ins such as Date, because the |this| binding is by default set to the proxy, so the Date built-in method will not find the correct private state.
ARB: Same issue with binary methods
STH: We should add invoke trap but not change the object model
MM: Pleasant to have. Separate from private state.
AWB: used to think this was an issue with proxies, but convinced that it's an API issue: we need to provide default handlers that do the right thing, and which users can subclass. In particular, want a handler that, on forwarding, rebinds |this| to the target.
STH: If you want to proxy a Date method the underlying this
needs to be a non wrapped Date object.
TVC: previously proposed a Handler API that defines derived traps and fundamental traps, allows you to subclass and inherit correct behavior for derived traps. Can be used as the basis.
AWB/TVC: invoke trap would make it easier to control |this|-binding
DH: Never liked breaking the semantics of [[Get]] + [[Call]]
TVC: there already exist invoke-only properties on platforms with __noSuchMethod__
AWB: For a [[Call]] it might be important to control this
but by the time the [[Call]] is happening you do not know what this
to use.
DH: ActionScript has a proxy and they do have an invoke trap.
BM: The most common action is to invoke a method.
? : we already gave up on the |this| invariant for accessors: in ES5, if obj.x is a getter, |this| will always be bound to obj in the getter. With proxies this is no longer true.
AI(AWB, TVC): Add spec for invoke. Tom and Allen to work out details of a Handler API that accommodates both "caretaker" (aka forwarding) and "virtual object" use cases.
link Consensus/Resolution:
- Add invoke trap.
link 4.11
MM: Everybody in this room wants classes and want to post pone private state to after ES6
ARB: Disagrees.
ARB: Based on feedback, people do not want unique symbols, only private symbols.
MM: Private symbols do not work with proxies.
TVC: can still use WeakMap for private state.
DH: The most common cases where true information hiding is self hosting. The stakes are too high for the browser engines.
YK: If "iterator" would be a private symbol, you cannot create a proxy that will work with for-of loops.
ARB: Symbols (unique and private) and relations overlap.
BE: If we add symbols now we are stuck with them.
LH: Future users will be confused. They will not know what to use
BE: Unique symbol is very different from class private syntax.
AWB/MM: If we first did relationships we might not need symbols.
MM: Relationship published but not reflective.
MM: Difference between relationships and symbols: where is the mutability? This forces us to have both relationships and unique symbols.
link Consensus/Resolution:
- ?
link 4.13 Endianness of Typed array
ARB: Remember it as if we should specify this.
BE: Endianness in Typed Arrays is unspecified.
DH: Keep it open for now... Same system to same system. Using data view, which is explicit, there is no problem.
STH: We don't know what WiiU will do?
AWB: Or they decide not to comply to the spec
DH: WebGL is endian agnostic.
link Consensus/Resolution:
- Leaving it unspecified in ES6.
link 4.18 proto
STH: Recollection, first as data property, then as an accessor. Then discussed the power of that setter. Set the [[Prototype]] in the [[Realm]]. Then Allen wrote the spec. Realized that there were some problems with that design. Roughly the same power as Object.setPrototypeOf
.
MM: Existence of a setter... as long as we have the extensibility restriction, that is sufficient.
AWB: Why restrict __proto__
and not other
DH: Objects belonging to a realm is a bad idea.
MM: No more reason to restrict the setter.
STH: Bind __proto__
setter to the object upon extraction
MM: In SES objects that are non extensible. Not going to remove __proto__
going forward.
ARB: If Object.prototype.__proto__
is a data property, making it non writable prevents other objects to use assign to set __proto__
.
AWB: If Object.prototype.__proto__
is an accessor that just calls Object.{set,get}PrototypeOf
.
AR: Best practice on the web is important even in the future.
TVC: If we have Object.prototype.__proto__
do we want Object.setPrototypeOf
or just
Reflect.setPrototypeOf
?
AWB: Makes sense to have Object.setPrototypeOf
for consistency.
EA: Where do we draw the line (Object.x
or Reflect.x
)?
DH: People will need to be able to get this before we have a reflect module.
TVC: We need both because they have different return value (Reflect.setPrototypeOf
returns boolean success value).
link Consensus/Resolution:
__proto__
is an accessor onObject.prototype
.- The setter mutates [[Prototype]].
- There is no "poison pill".
- Add
Object.setPrototypeOf
andstd:reflect setPrototypeOf
.
link Naming of @@iterator
AWB: Suffix with $
STH: Opposed to special naming. People don't do this kind of naming convention. Why do we want to introduce this concept?
1
2
3
4
5
|
|
link Consensus/Resolution:
- No special naming
link Generators and iterators
AWB: send
is gone in favor of next(arg)
(only first arg is passed through in yield*
)
YK: Whether generators return a frozen object or not?
BE: close
is gone
link Consensus/Resolution:
- Removed:
send
andclose
jQuery Core Team Meeting – May 20 2013
Attending: m_gol, rwaldron, gnarf, orkel
link Review/Triage
link jQuery 1.10
- Tickets still needing attention
- http://bugs.jquery.com/ticket/13801
- pull request submitted: https://github.com/jquery/api.jquery.com/pull/308 - api.jquery.com needs to be updated, too!
- http://bugs.jquery.com/ticket/13912
- http://bugs.jquery.com/ticket/13914
- Ship date?
- May 23, 2013
- Need a write up
link jQuery 2.0.1
- Tickets still needing attention
- http://bugs.jquery.com/ticket/13907
- Mentioned by Dave, has since been closed by Scott
- m_gol perf regression/investigation findings
- defineProperties is slow (but this called once per element)
- Firefox is showing perf issues, but hard to track down with available tools. More to come.
- http://jsperf.com/jquery-1-x-vs-2-x/3
- http://jsperf.com/jquery-1-x-vs-2-x/6 (this one’s huge)
- Ship date?
link jQuery 2.1/1.11 changes
- Add tickets for issues you think should be addressed
link Open tickets triage
jQuery UI Team Meeting – May 15 2013
- Working through plans to remove duplication between jQuery UI build system and download builder.
- Working on Pointer Events special event implementation.
- Created jquery-pointer-events repo.
- MS Open Tech feels that a jQuery-specific implementation makes more sense for us than hand.js.
- Working through individual widget implementations for classes option.
- Working on theming documentation.
jQuery Core Team Meeting – May 13 2013
Attending: DaveMethvin, timmywil, orkel, m_gol, gibson042, rwaldron
link jQuery 1.10
- Any tickets needing work before RC/Final?
- https://github.com/jquery/jquery/pull/1265 (line-height, gibson042)
- Need to migrate the build/release.js change (dave)
- Ship date?
- Could do a release this week (16th) if everything is wrapped up
- Fallback to (23rd)
link jQuery 2.0.1
- Tickets still needing attention
- http://bugs.jquery.com/ticket/13835 (gibson042)
- needs fixing, should be easy
- http://bugs.jquery.com/ticket/13793 (dave)
- Fix landed, just need to verify map is correct
- http://bugs.jquery.com/ticket/13789 (dave)
- Not critical but dave will add
- rwaldron's perf improvement for data
- rwaldron rebased and did a pull request
- m_gol to do some digging on further perf regressions
- Ship date?
- 16th, fallback to 23rd
link jQuery Migrate
- 1.2.1 shipped last week, all quiet
link jQuery 2.1/1.11 changes
- Add tickets for issues you think should be addressed
- Need to do a blog post after 1.10/2.0.1 ship