[08:00:32] <santhosh> Hello rxaviers
[08:00:45] <rxaviers> Hi!
[08:01:02] <siebrand> Hallo
[08:01:58] <rxaviers> Hi santhosh siebrand.. Is Krinkle|detached, jzaefferer, scott_gonzalez iskren, joining today?
[08:02:09] <scott_gonzalez> I'm lurking :-)
[08:02:12] <rxaviers> anyone else?
[08:02:12] <rxaviers> :)
[08:03:03] <rxaviers> Well, hello everyone. From last meeting:
[08:03:59] <rxaviers> Iskren said he was going to design the interface (split moment-cldr i18n independent code vs. moment-core). We've been talking these past two weeks about CLDR, and we've been also exchanging questions to the CLDR group
[08:04:58] <rxaviers> We also had Krinkle and Siebrand in the last meeting. They were representing wikipedia's effort in getting involved.
[08:05:22] <siebrand> Now santhosh is here, too.
[08:05:43] <siebrand> I'm a product manager, and not really able to spar with you on a deep technical level. I can do tactical level, though :)
[08:05:57] <siebrand> Looks like Krinkle|detached isn't here yet.
[08:06:01] <siebrand> Ill try to text him.
[08:06:11] <rxaviers> Excellent. I had the opportunity to change thoughts with santhosh in the past weeks too :)
[08:06:39] <rxaviers> Ok. I want to start with Globalize's updates, and I then I pass the word to you siebrand, and santhosh...
[08:06:40] <santhosh> https://github.com/santhoshtr/CLDRPluralRuleParser/issues/6 :)
[08:07:20] <rxaviers> We've been working on a Globalize branch on the migration to CLDR, and we finally landed it on master.
[08:07:33] <rxaviers> It supports date parse and format (except timezones).
[08:08:10] <rxaviers> which fully follows tr35 specs / CLDR
[08:08:18] <rxaviers> It supports basic translation.
[08:09:03] <rxaviers> And all that have been modularized and we had idealized. So, user can load globalize.js, and the module he wants, eg. `globalize/date.js`
[08:09:23] <rxaviers> Our next step will be the implementation of number format and date.
[08:10:35] <rxaviers> So, if anyone has any question please just let me know.
[08:10:59] <rxaviers> siebrand, please feel free to go ahead if you have any updates you'd like to share with us (or questions)
[08:11:29] <santhosh> rxaviers: Mediawiki follows TR35 number formatting for comma/period rules
[08:11:47] <santhosh> if code is helpful, here it is https://github.com/wikimedia/mediawiki-core/blob/master/resources/mediawiki.language/mediawiki.language.numbers.js#L210-L238
[08:14:44] <Nikerabbit> in globalize.js, when you say you follow cldr, does that mean the data format or also the data?
[08:15:27] <rxaviers> We follow both: the specs (the tr35 one), and we use their data (their official JSON data)
[08:15:45] <rxaviers> santhosh, thanks for letting me know
[08:16:13] <Nikerabbit> is there a way to extend cldr data with your own locales and override the cldr data?
[08:16:23] <rxaviers> We don't embed any cldr data in Globalize. But, we defer that to the end-user.
[08:16:25] <rxaviers> Absolutely
[08:16:42] <rxaviers> Since this is a task we defer to the end-user. He's able to do something in these lines:
[08:16:50] <rxaviers> Globalize.load( officialCLDRJSONData );
[08:16:59] <rxaviers> Globalize.load( customData );
[08:17:11] <rxaviers> The way we merge is deep, so eg:
[08:17:11] <Nikerabbit> that's very neat
[08:18:05] <rxaviers> It follows this algorithm:
[08:18:06] <rxaviers> https://github.com/rxaviers/cldr/blob/master/src/util/json/merge.js#L8-L10
[08:18:17] <rxaviers> So:
[08:18:30] <rxaviers> Globalize.load( a: { b: 1, c: 2 } } );
[08:18:40] <rxaviers> Globalize.load( a: { b: 3, d: 4 } } );
[08:18:42] <rxaviers> will produce
[08:18:46] <rxaviers> -> { a: { b: 3, c: 2, d: 4 } }
[08:19:06] <rxaviers> only for exemplification purposes
[08:19:42] <rxaviers> I just waned to point out it's deep, because it makes it easy to overload custom parts without messing with other CLDR parts
[08:22:02] <rxaviers> In the previous meeting, we had talked about a possible collaboration, and merging efforts. So, I'm specially interested in knowing if you guys had a chance to look at what we've been doing in Globalize (https://github.com/jquery/globalize/), and in cldr.js (https://github.com/rxaviers/cldr)
[08:22:24] <rxaviers> If you have any thoughts, any more questions, any suggestions. How do you see we could join efforts :)
[08:23:13] <Nikerabbit> I feel like we are getting close to complete i18n solution by putting together locale data, message loading and message parsing (+ something for handling text direction in the UI) (+fonts and input methods)
[08:25:00] <Nikerabbit> that could be something like globalize.js + jquery.i18n + ??? + ??? + jquery.uls + jquery.ime + jquery.webfonts
[08:25:17] <santhosh> We are missing Krinkle here, he had some plans about date formatting with moment.js and he had identified some areas to work on
[08:25:49] <Nikerabbit> I'm not sure but isn't there some overlap currently with globalize.js and jquery.i18n... would it make sense to have jquery.i18n to be just message loader (and a parser?)?
[08:26:16] <Nikerabbit> and sorry if I'm repeating stuff, I haven't read the previous discussions very carefully
[08:26:33] <rxaviers> don't worry, so far it's all news :)
[08:26:38] <rxaviers> (to me)
[08:27:16] <siebrand> (I texted him, but no response)
[08:27:56] <rxaviers> You said you are getting close to a complete i18n solution. What specifically you need
[08:28:14] <rxaviers> Where the gap is
[08:28:53] <rxaviers> Please, just let me know if you think it would be good to postpone with Krinkle in
[08:29:02] <santhosh> rxaviers: date formatting at js, what moment.js provides, but with a wide standard based language support
[08:29:36] <santhosh> rxaviers: this is what Krinkle was trying to achieve
[08:30:11] <Nikerabbit> rxaviers: for instance if we had all these components and have them working together well, it could be a thing I could recommend to my "clients"
[08:30:19] <scott_gonzalez> moment.js has agreed to created a branch which uses CLDR.
[08:30:33] <scott_gonzalez> And eventually make that the main implementation.
[08:31:19] <rxaviers> Unfortunately, iskren is not here (I was trying to ping him). So, he could give us better updates on his plans about the CLDR adoption.
[08:31:43] <rxaviers> There are plans for moment.js to use Globalize for the date format/parse task.
[08:31:57] <santhosh> scott_gonzalez: great, so as per my reading it need a plural rule processor and that was _one_ of the objective of rxavier's discussion with me, am I right?
[08:32:10] <rxaviers> correct
[08:32:27] <rxaviers> plural is another CLDR area that moment.js needs as far as I know.
[08:34:23] <siebrand> Just a side question for the near future: Are any of you going to be at FOSDEM?
[08:34:25] <santhosh> rxaviers: So with CLDR parser, is there  anything you would like to see from us? improvemnts/features/bugs?
[08:34:34] <santhosh> I would be happy to help in that area
[08:34:37] <Nikerabbit> rxaviers: it might be too early yet, but would be nice to have these components released as a bundle
[08:35:58] <rxaviers> Im not. Where's this going to happen?
[08:36:17] <scott_gonzalez> I won't be at FOSDEM.
[08:37:43] <rxaviers> Brussels? oh, far away.. We'll have a jQuery team meeting in San Diego in mid Feb :)
[08:38:12] <rxaviers> Nikerabbit, with all these components you mean what you have said previously (locale data, message loading and message parsing (+ something for handling text direction in the UI))?
[08:39:43] <santhosh> Hi Krinkle
[08:40:16] <Krinkle> Hi
[08:40:45] <rxaviers> santhosh, that's a good question. I will get to that soon ok
[08:40:50] <rxaviers> Hey Krinkle
[08:40:58] <siebrand> Hey Timo.
[08:41:24] <Nikerabbit> rxaviers: yeah most of them at least
[08:41:38] <rxaviers> Basically, we would enjoy any help. That's why I'd like to understand your need better. So, I could think how we could cooperate.
[08:42:41] * Krinkle has catched up on the buffer
[08:43:06] <rxaviers> For instance, I would love to see all these components released as a bundle.
[08:44:35] <Krinkle> After the MediaWiki architecture meeting in SF in 2014, 2 weeks after is the jQuery Team meeting in San Diego, I'll be attending both.
[08:45:04] <rxaviers> Krinkle, basically I was asking "How do you see we could join efforts". If you have any thoughts, go ahead, we are all ears :)
[08:46:34] <Krinkle> Well, my initial plans were only to have mediawiki stick to what it's already doing (other than what the language team intends on changing), and in addition plugin moment.js for date/time parsing and formatting (because we don't have anything good at the moment to easily parse iso and custom date formats) as well as things like "time ago", and relative date computations etc.
[08:46:52] <Krinkle> but moment.js would have to support more languages for us to use it properly.
[08:48:00] <Krinkle> since I then figured out that the existing moment by all of you behind moment.js's cldr is much wider than cldr itself, it became clear that though moment.js will likely offer a standalone download with a minimal bundle of (parts of?) cldr+globalize, we should consider re-using the parts underneath moment.js in our parts
[08:48:03] <Krinkle> to reduce duplication
[08:48:33] <siebrand> Nikerabbit and santhosh will also be in SF for MediaWiki Architecture Summit January 23/24
[08:48:35] <Krinkle> but I don't have the expertise in language to know whether we can or want to switch to cldr.js or globalize, hence siebrand, Nikerabbit and santhosh now being here :)
[08:48:37] <siebrand> (as will I)
[08:49:15] <Nikerabbit> Krinkle: I think we can do that
[08:49:40] <Nikerabbit> there is pretty little on frontend i18n currently that we provide, would not be too hard to replace it
[08:50:04] <siebrand> This will have some impact on the planned RfC.
[08:50:21] <Krinkle> Nikerabbit: I found it especially interesting because you are currently also refactoring a lot of this (jquery.i18n, CLDRPluralRuleParser etc. are all still relatively new and changing rapidly)
[08:50:23] <siebrand> We haven't published it yet, but to get it put on the summit's agenda, we MUST put something on the page by tomorrow end of day.
[08:50:37] <Krinkle> So I feel like it's a little late to change internals, but better late than never.
[08:50:53] <Krinkle> and this should be a great oppertunity to join efforts.
[08:51:23] <santhosh> Niklas, what specific front i18n feature are you talking about?
[08:51:30] <siebrand> Krinkle: Your team has to be weary of possible lock-ins for VE.
[08:51:37] <siebrand> Krinkle: Do talk to Roan about that.
[08:51:42] <Nikerabbit> santhosh: mostly about the non-message locale specific data and functions
[08:51:55] <Nikerabbit> we already have pretty solid plans for message delivery
[08:51:57] <Krinkle> siebrand: yeah, will do.
[08:52:24] <santhosh> Nikerabbit: like number/date formatting etc ?
[08:52:32] <Nikerabbit> santhosh: yes
[08:52:34] <siebrand> if it's only non-message stuff, I don't really identify any threats, but if message delivery and plural/grammar is affected, it's important to do an impact analysis.
[08:53:16] <Nikerabbit> santhosh: if we start using globalize.js or other thing, we probably should reduce the scope of jquery.i18n just to message delivery and parsing
[08:53:40] <scott_gonzalez> What's VE?
[08:53:42] <rxaviers> What's message delivery/parse?
[08:53:57] <Nemo_bis> scott_gonzalez: visualeditor for mediawiki
[08:54:16] <Nikerabbit> rxaviers: in our case loading json blobs from the server, handling markup like There {{PLURAL:$1|is one car|are $1 cars}}
[08:54:30] <Nikerabbit> json blobs containing key value pairs for messages
[08:54:58] <rxaviers> gotcha
[08:55:27] <santhosh> Nikerabbit: message parsing is dependent on CLDR data for plural and number conversions. Yes it can depend on globalize for that requirements
[08:55:56] <rxaviers> siebrand, Nikerabbit, santhosh, Krinkle, correct me if I am wrong. But, I understood your urgent need on frontend i18n  is: date format/parse. But, you are also looking for a better way to make the parts work as a bundle together.
[08:55:58] <rxaviers> Is that correct?
[08:56:47] <Nikerabbit> for WMF I think we are looking for a comprehensive and maintainable i18n solution for the frontend
[08:57:13] <Krinkle> Yep
[08:57:51] <rxaviers> May I summarize our recent Globalize story very quick?
[08:58:20] <Krinkle> It'd be okay to have that bundle be a liberal composition. i18n can be though to integrate, I imagine established projects may not be able to switch all parts over (they probably have at least one of the features deeply coupled in their app). But yeah, let's try to be efficient in sharing logic.
[08:58:28] <Nikerabbit> secondary goal could be to unify server side (PHP) and frontend side (JavaScript) data as much as possible and provide equal support
[08:58:41] <Krinkle> rxaviers: I liked your story from last time with cldr being js-global and detected by different libs at run time.
[08:58:59] <Krinkle> That one (as long as you compose it properly server-side) allow one to do this without code knowing too much about one another.
[08:59:02] <Nikerabbit> Krinkle: completely argree that users could be able to choose what parts of it to use
[08:59:21] <Nikerabbit> (users as in projects, not end users)
[08:59:28] <rxaviers> Ok
[08:59:47] <rxaviers> Globalize use to embed I18n data (initially populated from .NET).
[08:59:50] <rxaviers> used*
[09:00:00] <rxaviers> We had maintainability issues, and coverage issues too
[09:00:13] <rxaviers> jzaefferer pointed out CLDR, and after discussing with the team our goal became this:
[09:00:27] <Nikerabbit> interesting discussion here, but I have to go to sauna... I will be popping back during the breaks if this discussion continues
[09:00:29] <rxaviers> - Provide a set of tools that leverage the official CLDR JSON data;
[09:00:44] <rxaviers> - Allow users to load as much or as little data as they need;
[09:00:45] <siebrand> I think the meeting is scheduled to end about now.
[09:00:52] <rxaviers> - Avoid duplicating data if using multiple i18n libraries that leverage CLDR;
[09:00:54] <siebrand> We should honour that time box.
[09:00:56] <rxaviers> - Run in browsers and node.js;
[09:01:00] <rxaviers> Yeap, correct
[09:01:02] <rxaviers> We ran over.
[09:01:11] <rxaviers> In a brief,
[09:01:16] <siebrand> I think we're having a very useful conversation here. We should not stop talking :)
[09:01:24] <rxaviers> In globalize, we are working toward the same goal as I hear you need.
[09:01:49] <rxaviers> Soon is Christmas and New Year
[09:01:58] <rxaviers> When do you think we could meet again?
[09:02:27] <siebrand> Given that we have the architecture summit, I'd hope before Jan 20th.
[09:02:42] <siebrand> Preferably twice, so 1st week of Jan, and again 14 days later.
[09:03:02] <rxaviers> I wont be available until Jan 8th
[09:03:04] <siebrand> Same time, Jan 2 and Jan 16?
[09:03:09] <siebrand> oh, too bad.
[09:03:30] <siebrand> Jan 9 and Jan 23?
[09:03:35] <rxaviers> works for me ;)
[09:03:47] <Krinkle> Jan >= 8
[09:03:53] <Krinkle> works for me
[09:04:00] <siebrand> Krinkle: you sent invites last time. Can you do that again for the two meetings? Please also add Nikerabbit .
[09:04:00] <santhosh> santhosh: fine with me
[09:04:08] <Krinkle> OK
[09:04:16] <siebrand> Awesome.
[09:04:24] <rxaviers> Perhaps as a homework, we could exchange information via email.
[09:04:42] <Krinkle> Same time, same channel?
[09:04:43] <siebrand> yes, and there's also the thread on GitHub.
[09:04:57] <rxaviers> which thread the santhosh one?
[09:05:24] <Krinkle> link?
[09:05:33] <santhosh> https://github.com/santhoshtr/CLDRPluralRuleParser/issues/6
[09:05:56] <rxaviers> That works for me instead of the email.
[09:06:16] <rxaviers> It will be a pleasure to summarize to you guys there what I was going to talk here.
[09:06:26] <rxaviers> So, talk to you guys on the thread.
[09:06:33] <rxaviers> See you again on Jan 9
[09:06:44] <rxaviers> Have a great Christmas and Happy New Year :)
[09:06:52] <Krinkle> So only change in guest list is +Niklas?
[09:08:17] <rxaviers> I guess so Krinkle
[09:08:34] <Krinkle> invites sent
[09:08:37] <rxaviers> ;)
[11:00:11] <_|Nix|_> Yo ho ho and a barrel of grog!
[11:00:21] <uGoMobi> hey _|Nix|_
[11:00:26] <_|Nix|_> Hey :)
[11:01:10] <uGoMobi> arschmitz agcolom gseguin toddmparker RWhitbec-
[11:01:32] <agcolom> hey :-)
[11:01:42] <uGoMobi> agenda/updates https://docs.google.com/document/d/1we7ubFQBCeanJjhnyyBG1SiIhVt-uXa0RrjDgFu29dw/edit#
[11:01:44] <uGoMobi> hi agcolom
[11:01:45] <arschmitz> Hi
[11:01:55] <uGoMobi> hey arschmitz
[11:02:37] <uGoMobi> I know I said we were going to switch to new weekly meeting doc this week
[11:02:45] <uGoMobi> but then I realized it's last meeting of this year
[11:02:59] <uGoMobi> so makes sense to start with that in 2014 :)
[11:03:14] <uGoMobi> next week no meeting because of holidays
[11:03:31] <uGoMobi> so...
[11:03:42] <uGoMobi> we are releasing 1.4 final today!
[11:03:59] <arschmitz> yay
[11:04:19] <uGoMobi> finally final :)
[11:04:42] <uGoMobi> gseguin already tagged and pushed to the CDN
[11:04:44] <_|Nix|_> *pop* ... blubblubblubblubbnlubb ...
[11:05:06] <gseguin> it wasn't me
[11:05:14] <gseguin> it was the jquery-release script
[11:05:21] <uGoMobi> even better
[11:05:29] <gseguin> big props to scott_gonzalez for the awesome job on that project
[11:05:44] <uGoMobi> we can remove that from the roadmap already even before we start working on 1.5
[11:05:55] <uGoMobi> yeah, thanks scott_gonzalez !!
[11:06:10] <_|Nix|_> Awesome!
[11:06:21] <scott_gonzalez> Sorry it blew up on you :-/
[11:06:25] <uGoMobi> we still have to switch to new web site and switch the API docs
[11:06:34] <scott_gonzalez> But it's good to know it's mostly working :-)
[11:06:34] <uGoMobi> will ask scott_gonzalez and gnarf for help with that
[11:07:18] <uGoMobi> I am updating the ThemeRoller at the moment
[11:07:26] <uGoMobi> gseguin: how about the download builder?
[11:07:29] <uGoMobi> still issues?
[11:07:48] <gseguin> scott_gonzalez: hey no worries man, I guess you can only really test some code paths when you actually release
[11:07:58] <gseguin> uGoMobi: don't know yet
[11:08:03] <gseguin> I need to look into it
[11:08:07] <uGoMobi> ok
[11:08:21] <uGoMobi> arschmitz: how's the changelog?
[11:08:28] <gseguin> I suspect that the 1.4.0 version hasn't been checked out on tagging
[11:08:36] <arschmitz> almost there
[11:08:43] <scott_gonzalez> gseguin: I've got ideas for being able to test the whole process :-)
[11:08:45] <uGoMobi> arschmitz: ok great
[11:08:57] <arschmitz> i got through all the commits and issues and rewrote them all conistantly and readable
[11:09:13] <gseguin> BTW I just tagged demos.jquerymobile.com so http://demos.jquerymobile.com now defaults to 1.4.0 demos
[11:09:16] <arschmitz> now i just have to go through the wiki change log and make sure nothing is missing
[11:09:21] <uGoMobi> arschmitz: there is already a changelog that we used for the pre releases so we can just replace when you are ready
[11:09:22] <agcolom> just to let you know we're having a big storm with thunder and everything so the power or the internet could go out anytime
[11:10:04] <uGoMobi> agcolom: stay safe
[11:10:11] <agcolom> thanks :-)
[11:10:15] <uGoMobi> and charge all your batteries :)
[11:11:01] <uGoMobi> when the new site is live and everything is working I will publish the blog post
[11:11:20] <uGoMobi> anything else we need to discuss regarding the 1.4 release?
[11:12:03] <uGoMobi> silence means no
[11:12:30] <uGoMobi> next topic is about the way we work
[11:12:51] <uGoMobi> we already talked about that in Amsterdam
[11:13:17] <uGoMobi> about working on code, docs, demos, etc in sync
[11:13:33] <_|Nix|_> I like the commit message convention.
[11:13:40] <uGoMobi> but there are some more things we need to improve
[11:14:08] <uGoMobi> yeah, so we have a new standard for commit messages for all projects
[11:14:35] <uGoMobi> but we are also going to do everything via PR's
[11:14:43] <uGoMobi> arschmitz: maybe you want to chime in
[11:14:53] <uGoMobi> (I talk too much)
[11:14:56] <uGoMobi> ;-)
[11:15:27] <arschmitz> sure
[11:15:56] <arschmitz> so on all mobile repos from now on all changes no matter how trivial must be in a branch with a PR
[11:16:18] <arschmitz> and i will be reviewing all PR's before they go to master
[11:17:28] <uGoMobi> ok
[11:17:38] <_|Nix|_> OK.
[11:18:01] <uGoMobi> arschmitz discussed this with scott_gonzalez and DaveMethvin
[11:18:37] <arschmitz> our commit history is pretty bad in some places and thats something we need to work on
[11:19:01] <agcolom> is that including the docs as well?
[11:19:16] <arschmitz> and we want to be more through in our rebasing and working in branches until things are 100% ready
[11:19:23] <arschmitz> agcolom: yes its for all mobile repos
[11:19:34] <agcolom> ok thx
[11:20:11] <arschmitz> something we have not been good at is making sure that if you were to pick any one random commit that things should not be broken
[11:21:29] <uGoMobi> sounds good
[11:21:39] <uGoMobi> gseguin: still there?
[11:22:42] <uGoMobi> gseguin: I just want to be sure you saw this too
[11:22:53] <gseguin> yup
[11:22:55] <gseguin> saw it
[11:23:00] <uGoMobi> ok great
[11:23:40] <gseguin> The real question is can you land your own PR ? :-P
[11:24:01] <arschmitz> as long as its been reviewed and you got the ok
[11:24:09] <uGoMobi> right
[11:24:15] <uGoMobi> and don't hit the green button
[11:24:46] <arschmitz> uGoMobi: exactly needs to be rebased
[11:24:47] <gseguin> command line FTW!
[11:24:55] <uGoMobi> yeahhh
[11:24:55] <_|Nix|_> Right, I think the green button generates a merge commit even if the PR is against the current topmost commit..
[11:25:05] <arschmitz> yup
[11:25:46] <uGoMobi> next item that I put on the agenda is planning
[11:26:08] <uGoMobi> I think it's good if we focus on triage and bug fixing first
[11:26:14] <_|Nix|_> Also, I guess it makes sense to work in our own clones, unless more than one person is working on the same PR/branch, right?
[11:26:24] <uGoMobi> also need to do some cleanup (delete branches, etc)
[11:27:18] <arschmitz> _|Nix|_: thats up to you branches make it more visiable to others and easy for review and contribution
[11:27:20] <uGoMobi> _|Nix|_: do you mean not pushing until you're completely doen?
[11:27:23] <uGoMobi> done*
[11:27:43] <_|Nix|_> uGoMobi: I mean creating the branches in my own clone of jQM.
[11:28:07] <arschmitz> _|Nix|_: thats up to you
[11:28:36] <_|Nix|_> I guess we can link commits to API docs and the library via the new ref jquery/project #abc convention, right?
[11:29:44] <uGoMobi> I don't think that changed
[11:30:36] <_|Nix|_> What I mean is that, if we have an issue on jqm that requires a change to the API docs, we shouldn't make a separate issue on the API docs, but we should instead refer back to the jqm issue.
[11:31:09] <arschmitz> no there should be an issue on the right repo
[11:31:26] <uGoMobi> arschmitz: you type faster than me
[11:31:42] <uGoMobi> _|Nix|_: that isn't any different than it is now
[11:32:04] <uGoMobi> and I don't see the benefit of working in forked repo
[11:32:56] <_|Nix|_> arschmitz: OK, so lemme get this straight. If a code change in the library requires a modification to the API docs, do I create a separate issue against the API docs?
[11:32:59] <uGoMobi> let's not make it more complicated than it is... we did work in branches + PR's already, only change is that it goes for every change from now on
[11:33:16] <arschmitz> _|Nix|_: yes
[11:33:29] <_|Nix|_> OK ...
[11:35:20] <uGoMobi> back to planning... let's also do triage, PR reviews, and branches cleanup on the API docs, TR, and DB repos
[11:37:03] <uGoMobi> I spoke with the web-ui-framework team this morning
[11:37:23] <uGoMobi> they are going to work on removing style options from the JS for 1.5
[11:38:43] <uGoMobi> we might want to wait with changing file structure and removing deprecated code until they are done
[11:38:57] <uGoMobi> to avoid big merge conflicts
[11:39:05] <arschmitz> yes it will be easier that way
[11:39:17] <uGoMobi> arschmitz want to discuss something about button?
[11:40:14] <arschmitz> uGoMobi: does any one have any oppinion on going back to spans?
[11:40:16] <uGoMobi> button icons I mean
[11:40:51] <arschmitz> they have the advantage of being able to apply classes directly to them
[11:40:56] <arschmitz> you can target them with js
[11:41:17] <uGoMobi> right
[11:41:28] <uGoMobi> arschmitz: spans need to be present in markup?
[11:41:34] <uGoMobi> arschmitz: we don't generate them
[11:41:52] <arschmitz> uGoMobi: well with widget they are generated
[11:41:59] <arschmitz> and without you add them your self
[11:42:11] <arschmitz> this is how bootstrap does it and people seem pretty happy with it
[11:43:45] <uGoMobi> arschmitz: I am thinking about how this would work with other widgets
[11:44:11] <_|Nix|_> OK, if you add them yourself that sounds fine ...
[11:44:25] <uGoMobi> arschmitz: with buttons you only need the widget to dynamically change things, right?
[11:44:27] <_|Nix|_> After all, people can always data-enhanced="true" on a widget.
[11:44:36] <arschmitz> uGoMobi: pretty much
[11:44:45] <uGoMobi> _|Nix|_: I don't think that UI/Mobile widgets will get enhanced option
[11:44:54] <uGoMobi> arschmitz: or do they?
[11:45:04] <_|Nix|_> OK ... hooray for performance ... ?
[11:45:05] <arschmitz> uGoMobi: thats correct
[11:45:29] <arschmitz> _|Nix|_: for icons you lose out really
[11:45:40] <arschmitz> because a span is only added once
[11:46:02] <arschmitz> an :after element is re done on every reflow because its css
[11:46:38] <_|Nix|_> arschmitz: OK, that's fine, but without an enhanced option, startup is going to return to sucking. Not that I'm convinced that we've improved it much ...
[11:47:17] <_|Nix|_> arschmitz: ... and startup is the most critical part of any app ...
[11:47:22] <arschmitz> _|Nix|_: the better solution is widgets that dont need to be initalized at all
[11:47:27] <arschmitz> which is being worked on
[11:48:02] <_|Nix|_> arschmitz: You mean doing away with _create()?
[11:48:12] <_|Nix|_> arschmitz: ... and the DOM setup and class application that go with it?
[11:48:13] <arschmitz> _|Nix|_: not exactly
[11:48:36] <arschmitz> this is a whole new way to write a widget
[11:48:44] <arschmitz> and is not a part of the widget factory
[11:48:56] <_|Nix|_> arschmitz: Got some URLs?
[11:49:13] <arschmitz> scott_gonzalez: got a link to the article you wrote about it handy?
[11:50:20] <arschmitz> http://tech.pro/tutorial/1660/initialization-free-widgets
[11:50:40] <uGoMobi> I am not worried about using span for button widgets, but we have to be consistent so what would this mean for something like listview
[11:50:58] <arschmitz> yeah would have to switch back everywhere
[11:52:11] <uGoMobi> yeah, so I would like to make it possible to use a widget but add the span in the markup yourself
[11:52:20] <uGoMobi> more or less the enhanced option
[11:52:45] <uGoMobi> but I will look into that initialization-free-widgets first
[11:53:14] <scott_gonzalez> arschmitz: Yeah, hold on.
[11:53:32] <scott_gonzalez> http://tech.pro/tutorial/1660/initialization-free-widgets
[11:53:47] <arschmitz> not that this will be soon of course
[11:54:05] <uGoMobi> right
[11:54:18] <gseguin> uGoMobi: fixed the builder
[11:54:29] <arschmitz> but i also think we should see real perf numbers on adding icons or not via js
[11:54:38] <arschmitz> to make sure this really even makes a difference
[11:54:45] <uGoMobi> gseguin: awesome!
[11:55:21] <uGoMobi> arschmitz: for which version did we plan the new button widget to land in Mobile?
[11:55:41] <arschmitz> i think 1.6 would need to check roadmap
[11:55:55] <uGoMobi> because we can't use spans and :after next to each other
[11:56:04] <uGoMobi> I mean, all widgets need to use the same
[11:56:18] <uGoMobi> unless we duplicate all our icon CSS
[11:56:27] <uGoMobi> one for spans, one for :after
[11:56:31] <arschmitz> yeah its a bad situation
[11:56:34] <uGoMobi> which sounds bad
[11:56:48] <arschmitz> but for ui to switch to before after is same issue
[11:57:02] <uGoMobi> yes I can imagine
[11:57:15] <arschmitz> and the real issue is which way is better
[11:57:53] <uGoMobi> to be honest I prefer spans as long as I can add them in my markup
[11:58:00] <_|Nix|_> I agree that performance should decide.
[11:58:42] <arschmitz> with spans to be honest you would not even need a js option for it
[11:58:54] <uGoMobi> right
[11:59:01] <arschmitz> because you dont ever have to care what the old one was you can just replace the whole span
[11:59:43] <arschmitz> thats actually how the current ui one works
[12:00:06] <arschmitz> performance is a win for spans
[12:00:12] <arschmitz> because you dont need the widget
[12:00:25] <arschmitz> and a direct class selector is miles faster then :after
[12:01:47] <_|Nix|_> arschmitz: Maybe I'm missing something. Is replacing a span not slower than replacing a class on a span?
[12:02:13] <_|Nix|_> arschmitz: I guess they both involve a reflow ...
[12:02:19] <arschmitz> _|Nix|_: exactly
[12:02:28] <arschmitz> and if the only thing on the span is a class...
[12:03:31] <uGoMobi> maybe we have to look into the roadmap again and wait with adopting the widgets that use icons
[12:03:40] <uGoMobi> until all of them are done
[12:03:49] <_|Nix|_> arschmitz: Ummm ... is there a "then, ... " following? Please?
[12:04:47] <uGoMobi> I see our time is up
[12:05:14] <_|Nix|_> Meh ... time, shmime ...
[12:05:44] <arschmitz> to be clear this is not fully decided yet
[12:05:59] <arschmitz> its just another branch im working on thats looking like it might be the way things go
[12:06:31] <uGoMobi> we can continue discussion about pros and cons on -dev
[12:07:02] <uGoMobi> but after we finished the 1.4 final release ;)
[12:07:41] <uGoMobi> anything else we need to talk about here and now?
[12:08:40] <_|Nix|_> Gues not ...
[12:08:48] <uGoMobi> think so too
[12:09:23] <uGoMobi> ok see you on -dev
[12:09:26] <uGoMobi> thanks all!!