Skip to end of metadata
Go to start of metadata

[09:15:36 CDT(-0500)] <alexn1> colinclark: ayt?

[09:15:42 CDT(-0500)] <colinclark> I am, yes

[09:17:42 CDT(-0500)] <alexn1> I have few branches ready to submit for a pull request to OER Commons. But before submitting it would be great if you can review them.

[09:17:56 CDT(-0500)] <alexn1> This is my first branch https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-794

[09:19:12 CDT(-0500)] <alexn1> let me know what you think whenever you have time to review it. In the meantime I will be working on another OER issues.

[09:27:54 CDT(-0500)] <jhung> justin_o and cindyli - this is taking a little longer than expected. Will message you when the images are ready.

[09:28:20 CDT(-0500)] <Justin_o> jhung: thanks

[09:30:36 CDT(-0500)] <colinclark> alexn1: sure thing

[09:36:04 CDT(-0500)] <jhung> justin_o and cindyli - ready. Hop on skype?

[09:36:28 CDT(-0500)] <cindyli> ok, jhung, Justin_o, collab room?

[09:37:38 CDT(-0500)] <Justin_o> cindyli: sure

[10:06:46 CDT(-0500)] <jessm> anastasiac: colinclark and I are trying to figure something out

[10:07:16 CDT(-0500)] <jessm> anastasiac: i joined the idi mailing list from the homepage and never got a confirmation email, so i don't know 1. where that goes, 2. if it's working, or 3. what the name of the list is

[10:07:28 CDT(-0500)] <jessm> anastasiac: do you have a way to find answers to some of that?

[10:07:46 CDT(-0500)] <anastasiac> let me check, jessm

[10:10:22 CDT(-0500)] <colinclark> alexn1: Can you fire me a link to the assemble ticket that describes your pull request?

[10:11:48 CDT(-0500)] <alexn1> colinclark: for sure https://www.assembla.com/spaces/iskme/tickets/794#/activity/ticket:794

[10:12:27 CDT(-0500)] <anastasiac> jessm, the mailing list name is "idi-discuss". It's administered by iris, so I can't go in and check if you're subscribed. Iris would have to do that. If the list is moderated, Iris might have to confirm your request before you'd get the email.

[10:12:43 CDT(-0500)] <jessm> ok

[10:12:45 CDT(-0500)] <jessm> thanks anastasiac

[10:17:20 CDT(-0500)] <anastasiac> fluid-everyone: the Toronto crew will be missing stand-up today

[10:17:38 CDT(-0500)] <colinclark> how come, anastasiac?

[10:18:27 CDT(-0500)] <anastasiac> we're going to momofuku, and some people think we need to get there early

[10:23:13 CDT(-0500)] <avtar> jessm: i took a look at that list

[10:23:28 CDT(-0500)] <avtar> your address isn't in the membership list

[10:24:01 CDT(-0500)] <avtar> that list being idi-discuss

[10:25:20 CDT(-0500)] <colinclark> wow, cool anastasiac (smile)

[11:02:22 CDT(-0500)] <colinclark> alexn1 and michelled, when you guys get back from your amazing lunch, I have a quick Sass question for you both.

[11:30:35 CDT(-0500)] <alexn1> colinclark: sure. what is the question?

[11:32:15 CDT(-0500)] <colinclark> Does Sass give us any way to reuse certain style declarations in multiple places? It would be really great, since this change is basically the same one in four places. With ordinary CSS, this is the best we could do

[11:32:24 CDT(-0500)] <colinclark> but maybe Sass has some kind of reusability in this regard?

[11:35:04 CDT(-0500)] <alexn1> colinclark: I do not have an extensive experience with sass but I think it is mainly targeted to write nested css styles more conveniently. I do not know any kind of specially reusability in sass. Maybe michelled knows.

[11:38:32 CDT(-0500)] <colinclark> I wonder if Sass mixins are designed for this? http://sass-lang.com/tutorial.html

[11:38:43 CDT(-0500)] <colinclark> I'm not sure whether or not they're used much in OER Commons

[11:38:52 CDT(-0500)] <colinclark> but a mixin seems like it would do the trick

[11:39:13 CDT(-0500)] <michelled> colinclark: yeah, I haven't used them but there are definitely supports in Sass for this

[11:39:27 CDT(-0500)] <colinclark> michelled: How would Andrey feel about us using them?

[11:39:35 CDT(-0500)] <michelled> he's be happy

[11:39:42 CDT(-0500)] <michelled> he likes it when the code improves

[11:39:54 CDT(-0500)] <colinclark> Seems like it'd be really nice to define a "no background" mixin

[11:39:59 CDT(-0500)] <colinclark> alexn1: What do you think?

[11:41:17 CDT(-0500)] <alexn1> I think it is a good idea to have less rules possible. I will research more about mixins and will try to apply them in this example.

[11:42:03 CDT(-0500)] <colinclark> I'm almost sold on Sass just with this particular issue

[11:42:05 CDT(-0500)] <colinclark> very cool

[11:42:15 CDT(-0500)] <colinclark> thanks, alexn1

[11:43:16 CDT(-0500)] <colinclark> michelled: I've been contemplating your pull request here: https://github.com/fluid-project/Captionator/pull/1/files

[11:43:25 CDT(-0500)] <jessm> avtar: so, it could still be the case that iris needs to approve it, right?

[11:44:47 CDT(-0500)] <michelled> what are you thinking colinclark?

[11:45:11 CDT(-0500)] <colinclark> I wonder if we should do a bit more robust Data URL parsing

[11:45:26 CDT(-0500)] <michelled> yes, I think we should

[11:45:41 CDT(-0500)] <michelled> do you think it should happen before this goes into our fork?

[11:45:52 CDT(-0500)] <colinclark> Possibly

[11:45:56 CDT(-0500)] <colinclark> I wouldn't mind talking it through

[11:46:02 CDT(-0500)] <colinclark> So, I guess the first question is...

[11:46:18 CDT(-0500)] <colinclark> is it possible that someone might legitimately include a data URL in the track source attribute that wasn't a VTT file?

[11:47:28 CDT(-0500)] <michelled> colinclark: on my reading of the spec, I didn't think that would be valid

[11:47:35 CDT(-0500)] <michelled> but I'm not sure I read it closely enough

[11:47:37 CDT(-0500)] <colinclark> ok

[11:47:51 CDT(-0500)] <colinclark> I guess if we wanted to be really robust, we should probably be ready for a few cases

[11:48:07 CDT(-0500)] <colinclark> 1. What happens if the Data URL's MIME type is incorrectly specified?

[11:48:27 CDT(-0500)] <colinclark> 2. What happens if the Data URL doesn't contain a WebVTT document?

[11:48:42 CDT(-0500)] <colinclark> 3. What happens if it's Base64 encoded?

[11:49:21 CDT(-0500)] <colinclark> I guess part of the answer to #3 is another question… Is WebVTT a strictly text-based format?

[11:49:36 CDT(-0500)] <colinclark> Or is can binary data be somehow included in it (e.g. image data or something?)

[11:49:44 CDT(-0500)] <colinclark> I'm imagining that it is strictly text-based

[11:50:31 CDT(-0500)] <avtar> jessm: i just tried subscribing to idi-discuss and received the confirmation email

[11:51:39 CDT(-0500)] <michelled> I just realized I put the wrong mime type in the example in the pull request

[11:52:24 CDT(-0500)] <jessm> avtar: via the idi homepage or just via some mailman jobby?

[11:53:17 CDT(-0500)] <avtar> ah nm, not through the home page

[11:53:26 CDT(-0500)] <avtar> i used the mailman interface

[11:54:51 CDT(-0500)] <michelled> colinclark: it looks like WebVTT is UTF-8

[11:54:58 CDT(-0500)] <michelled> http://dev.w3.org/html5/webvtt/

[11:55:11 CDT(-0500)] <michelled> A WebVTT file must consist of a WebVTT file body encoded as UTF-8

[11:55:31 CDT(-0500)] <jessm> avtar: well, that's helpful actually – we know where the problem is

[11:55:34 CDT(-0500)] <jessm> anastasiac: ^

[11:56:13 CDT(-0500)] <colinclark> michelled: So it's guaranteed to be text

[11:56:16 CDT(-0500)] <anastasiac> jessm, I'll look into it.

[11:56:20 CDT(-0500)] <jessm> it also occurred to me jameswy and jvass that the mailing list sign up has no submit (which might be intentional)

[11:56:28 CDT(-0500)] <michelled> yeah

[11:56:43 CDT(-0500)] <anastasiac> avtar, are you able to see if I'm subscribed to the idi-discuss list (in any one of my three email addresses)?

[11:57:34 CDT(-0500)] <jameswy> jessm, michelled: Not entirely. It's still waiting on full implementation. See design here: http://wiki.fluidproject.org/download/attachments/29954412/idi_mailinglist.jpg?version=2&amp;modificationDate=1335304990583

[11:58:02 CDT(-0500)] <jameswy> In a nutshell: submit slides in when text has been entered.

[11:58:19 CDT(-0500)] <anastasiac> the sliding submit has not been implemented yet (sad)

[11:58:23 CDT(-0500)] <jessm> yes, i see

[11:58:37 CDT(-0500)] <avtar> anastasiac: no, your addresses aren't here

[11:58:39 CDT(-0500)] <colinclark> michelled: And an encoded URL can represent the full UTF-8 character set, right?

[11:58:48 CDT(-0500)] <anastasiac> ok, avtar, thanks for checking

[11:58:55 CDT(-0500)] <michelled> colinclark: yes

[11:59:02 CDT(-0500)] <colinclark> ok

[11:59:14 CDT(-0500)] <anastasiac> jessm, was it very weird without the submit button? is it important to address that soon?

[11:59:15 CDT(-0500)] <colinclark> so it would be bizarre for someone to base64 encode their WebVTT data URL

[11:59:23 CDT(-0500)] <michelled> it would be

[11:59:27 CDT(-0500)] <jessm> anastasiac: i didn't feel weird

[11:59:34 CDT(-0500)] <jessm> thought maybe i was being cutting edge

[11:59:39 CDT(-0500)] <jessm> lean design

[11:59:40 CDT(-0500)] <anastasiac> (smile)

[11:59:43 CDT(-0500)] <jessm> lena cuisine

[11:59:54 CDT(-0500)] <anastasiac> ok, I'll focus on the actual signup first

[12:00:40 CDT(-0500)] <michelled> colinclark: but I guess that doesn't mean they won't do that

[12:00:50 CDT(-0500)] <jessm> anastasiac: thanks

[12:01:19 CDT(-0500)] <jessm> jameswy: can you also point to the wiki page that references the sliding submit?

[12:01:30 CDT(-0500)] <jameswy> jessm: http://wiki.fluidproject.org/display/fluid/IDI+website+mockups+%28April+2012+ratified%29

[12:03:18 CDT(-0500)] <michelled> colinclark: so, I can parse the mime type, but I'm not really sure what I should do if they give me something other than VTT

[12:03:22 CDT(-0500)] <colinclark> michelled: It's true

[12:03:40 CDT(-0500)] <colinclark> and base64 encoded strings don't just "pass through," they are actually encoded

[12:03:50 CDT(-0500)] <colinclark> So my thought is that we should, at some point, do the following:

[12:04:31 CDT(-0500)] <colinclark> Check that the string actually contains a WEBVTT header

[12:04:36 CDT(-0500)] <colinclark> throw an error if now

[12:04:37 CDT(-0500)] <colinclark> not

[12:04:56 CDT(-0500)] <colinclark> and support base64 decoding of the dataurl

[12:05:19 CDT(-0500)] <colinclark> My sense, though I may be wrong, is that there isn't a lot of point in following the MIME type slavishly

[12:05:28 CDT(-0500)] <colinclark> if it quacks like a WEBVTT...

[12:05:44 CDT(-0500)] <colinclark> the question now, michelled, is when is "at some point?"

[12:06:34 CDT(-0500)] <michelled> yeah, I'm not sure about that colinclark. I know "at some point" is before we can share this back with Captionator

[12:07:06 CDT(-0500)] <colinclark> right, that's what I was thinking

[12:07:10 CDT(-0500)] <colinclark> I don't know if this will help...

[12:07:18 CDT(-0500)] <colinclark> https://github.com/colinbdclark/Flocking/blob/master/flocking/flocking-audiofile.js#L104-119

[12:07:25 CDT(-0500)] <colinclark> This utility isn't factored right for you needs

[12:07:31 CDT(-0500)] <colinclark> but I'm happy to share the implementation

[12:08:24 CDT(-0500)] <colinclark> And here's a basic unit test that captured most of the variations in data URLs that a parser would need, michelled: https://github.com/colinbdclark/Flocking/blob/master/tests/flocking/js/audiofile-tests.js#L24-52

[12:08:48 CDT(-0500)] <michelled> this is really useful colinclark!

[12:09:02 CDT(-0500)] <colinclark> I make no guarantees that it's particularly well-factored or working (smile)

[12:09:23 CDT(-0500)] <michelled> ha - well, a starting point is always good

[12:09:55 CDT(-0500)] <colinclark> michelled: If you improve it, I'd love a pull request (smile)

[12:10:18 CDT(-0500)] <michelled> of course

[12:10:32 CDT(-0500)] <michelled> so, do you think the time is now?

[12:13:18 CDT(-0500)] <michelled> colinclark: the reason I was putting this off is because I'm really trying to get the video player out of the demo branch. The main thing holding it back at this point is the hacked up version of Captionator that we are using. The pull request I made was supposed to be drop in ready. It wasn't quite that easy - some issue in initialization I think - but I was expected to have another pull in to you today for update the video play

[12:13:45 CDT(-0500)] <michelled> player - then I think we'd be in a position to consider merging in the demo branch and working of master

[12:13:59 CDT(-0500)] <colinclark> you make quite the argument (tongue)

[12:14:35 CDT(-0500)] <colinclark> I'll file a bug

[12:14:43 CDT(-0500)] <colinclark> carry on

[12:15:48 CDT(-0500)] <michelled> thanks colinclark - I can be convinced to fix this up now though - I just realized that although I told you in the pull request that I knew the parsing was inadequate, I didn't tell you why I hadn't dealt with it

[12:18:16 CDT(-0500)] <alexn1> colinclark: I changed my pull request to use mixins. I also used variables to bring copy paste of CSS rules for that section to the minimum. Let me know what do you think when you have a minute https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-794

[12:18:39 CDT(-0500)] <alexn1> sorry not the pull request but my branch. I have not submitted any pull requests yet

[12:19:08 CDT(-0500)] <colinclark> michelled: Does this seem suitable? http://issues.fluidproject.org/browse/FLUID-4800

[12:24:40 CDT(-0500)] <michelled> colinclark: yep, looks great

[12:39:33 CDT(-0500)] <colinclark> hey alexn1, does it look like the #write-toolbar is getting added twice?

[12:39:50 CDT(-0500)] <colinclark> or rather, id

[12:40:36 CDT(-0500)] <colinclark> I guess it always was, but I wonder why

[12:41:27 CDT(-0500)] <colinclark> Other than that, this looks good

[12:41:35 CDT(-0500)] <alexn1> colinclark: are you looking into scss or generated css ?

[12:41:44 CDT(-0500)] <colinclark> the generated css, alexn1

[12:46:34 CDT(-0500)] <alexn1> I guess it is the way how css is been generated after reading scss rules. scss rules look rather clean. I could possibly modify css by hand but usually Andrey tells us not to touch it and rather modify scss. Since css always being generated by compiling scss any manual changes will be lost over time.

[12:47:03 CDT(-0500)] <alexn1> but yes it looks odd why .fl-theme-uio-by rule looks slightly different from others

[12:47:46 CDT(-0500)] <alexn1> from other similar rules in this block, I mean

[12:49:16 CDT(-0500)] <colinclark> yeah, touching generated code is a no-no

[12:49:26 CDT(-0500)] <colinclark> since it'll all disappear when someone regenerates the code

[12:49:39 CDT(-0500)] <colinclark> looks fine to me, alexn1. Let's see what Andrey thinks.

[12:51:08 CDT(-0500)] <alexn1> colinclark: I tried to regenerate css using scss rules we were looking at but still the same result. Not quiet sure what causes it to behave so oddly. I will submit a pull request to Andrey.

[12:53:22 CDT(-0500)] <alexn1> colinclark: I have another branch here. https://github.com/anvk/OER-Commons/compare/ISKME:staging...OER-795 it is for the following ticket https://www.assembla.com/spaces/iskme/tickets/795#/activity/ticket:795 . It would be great if you can take a look in it and tell me if it looks fine whenever you have a moment.

[12:55:10 CDT(-0500)] <colinclark> How did you convert the pixel sizes to ems, alexn1?

[12:55:40 CDT(-0500)] <alexn1> colinclark: I used the following website http://pxtoem.com/

[12:56:23 CDT(-0500)] <alexn1> the pixel base for that dialog is 13px

[12:56:32 CDT(-0500)] <colinclark> cool

[13:00:04 CDT(-0500)] <colinclark> alexn1: Looks fine to me

[13:00:51 CDT(-0500)] <alexn1> colinclark: ok thanks.

[13:01:51 CDT(-0500)] <colinclark> alexn1: I'm assuming you'll do the work of testing and verification, since I'm not set up to run OER Commons. Presumably you just want an extra pare of eyes in regards to how these things are factored, right?

[13:02:31 CDT(-0500)] <alexn1> colinclark: that is correct. I will be testing it on locally, on staging and on master

[13:02:36 CDT(-0500)] <colinclark> great

  • No labels