[10:49:52 CST(-0600)] <colinclark> anastasiac and michelled, would you mind if I talked through a few questions and thoughts about the Video Player here?
[10:50:12 CST(-0600)] <anastasiac> colinclark, that would be great
[10:50:29 CST(-0600)] <colinclark> I find myself staring at this field of markup
[10:50:37 CST(-0600)] <colinclark> with my colour scheme in TextMate, more green than blue
[10:50:53 CST(-0600)] <colinclark> awash in flc-videoPlayer- classes
[10:51:00 CST(-0600)] <colinclark> but that's neither here nor there
[10:51:27 CST(-0600)] <colinclark> Do either of you have some sense of what the "parent component's" markup actually is?
[10:51:45 CST(-0600)] <anastasiac> (aside: the template is modified in my branch, which is currently being reviewed: https://github.com/acheetham/videoPlayer/tree/FLUID-4546-template-cleanup)
[10:51:54 CST(-0600)] <colinclark> sweet
[10:52:12 CST(-0600)] <anastasiac> most of the markup is related to the controls. That's easier to see in my branch
[10:52:13 CST(-0600)] <michelled> colinclark: feel free to add review to that pull request also - I haven't got very far in my review
[10:52:27 CST(-0600)] <anastasiac> the only thing NOT controls is a) the video element and b) a container for captions
[10:53:03 CST(-0600)] <colinclark> Yeah
[10:53:07 CST(-0600)] <colinclark> that's what I was getting at
[10:53:15 CST(-0600)] <colinclark> The video element is not really much
[10:53:23 CST(-0600)] <colinclark> The captions area is really the domain of another component
[10:53:27 CST(-0600)] <colinclark> really none of the parent's business
[10:53:51 CST(-0600)] <colinclark> the controls, I think you've recognized already are a separate concern
[10:54:02 CST(-0600)] <colinclark> and certainly one that would likely benefit from renderization
[10:54:31 CST(-0600)] <colinclark> What do you give a Video Player to start if off?
[10:54:35 CST(-0600)] <colinclark> Presumably a <video> tag?
[10:54:58 CST(-0600)] <michelled> colinclark: we are going with 'div' for now but I was wondering about the same thing
[10:55:20 CST(-0600)] <michelled> do we expect people using an HTML5 video player to put in a video tag or a div?
[10:55:38 CST(-0600)] <colinclark> I guess we'd face the "climbing container" problem with just the video tag
[10:55:58 CST(-0600)] <colinclark> I guess we can think through the use case
[10:56:18 CST(-0600)] <colinclark> Is it safe to assume that the developer of a side knows, ahead of time, that they want to display a video?
[10:56:34 CST(-0600)] <colinclark> I gather the answer should be blatantly obviously "yes"
[10:58:02 CST(-0600)] <colinclark> Sorry, I've got His Royal Vanderheiden phoning
[10:58:02 CST(-0600)] <colinclark> carry on 
[10:58:22 CST(-0600)] <michelled>
[13:18:29 CST(-0600)] <colinclark> anastasiac and michelled I was rambling earlier
[13:19:19 CST(-0600)] <colinclark> I guess we got as far as pretty much determining that the parent component of Video Player doesn't really have any of its own markup
[13:19:33 CST(-0600)] <michelled> yep
[13:19:36 CST(-0600)] <colinclark> that there was markup for the so-called "cationner"
[13:19:40 CST(-0600)] <colinclark> captionner
[13:19:46 CST(-0600)] <colinclark> Very Bosmon-ian
[13:19:51 CST(-0600)] <colinclark> CAPTIONNNERRR
[13:19:54 CST(-0600)] <colinclark> or maybe French
[13:19:58 CST(-0600)] <colinclark> Captioné
[13:20:39 CST(-0600)] <michelled>
[13:20:43 CST(-0600)] <colinclark> anyway, the thing that is responsible for the captions has some markup
[13:20:50 CST(-0600)] <colinclark> and the thing that handles the controls has some markup
[13:21:11 CST(-0600)] <anastasiac> and eventually, the thing that handles transcripts has some markup
[13:22:24 CST(-0600)] <colinclark> indeed
[13:23:00 CST(-0600)] <colinclark> I guess we were starting to get to the point of asking what the right design in terms of "starting up" a Video Player might be
[13:23:24 CST(-0600)] <colinclark> michelled: You mentioned that right now the Video Player's container is not the video tag itself
[13:23:28 CST(-0600)] <colinclark> but a wrapper around it?
[13:24:18 CST(-0600)] <michelled> colinclark: yep - it's a div into which we render the video tag
[13:24:36 CST(-0600)] <colinclark> we actually render the video tag, based on the "sources" blob of JSON, is that right?
[13:25:29 CST(-0600)] <colinclark> So, the "markup contract" for the video player right now is basically "Give us an empty <div> where you want us to put a Video Player"
[13:25:34 CST(-0600)] <colinclark> and, by extension
[13:25:45 CST(-0600)] <colinclark> "provide us with some JSON containing URLs to your video"
[13:25:50 CST(-0600)] <colinclark> Is that correct?
[13:26:36 CST(-0600)] * anastasiac is double-checking details
[13:26:37 CST(-0600)] <michelled> yep, that's correct
[13:28:02 CST(-0600)] <michelled> interestingly we render all the sources including the fallback regardless of the browser capabilities
[13:29:19 CST(-0600)] <anastasiac> just to confirm the specifics: we currently don't actually use the Renderer to render the source tags, we just construct them and .append() them to the dom
[13:29:55 CST(-0600)] <colinclark> right
[13:30:01 CST(-0600)] <colinclark> I vaguely remember writing that code a long time ago
[13:30:21 CST(-0600)] <colinclark> michelled, anastasiac: What do most other video players do?
[13:30:38 CST(-0600)] <colinclark> I'm sort of imagining that you give them a video tag and they "enhance" it for you
[13:31:04 CST(-0600)] <colinclark> but maybe there are lots of different approaches out there
[13:31:24 CST(-0600)] <anastasiac> colinclark, iirc, they actually seemed split into two camps: a) give them <video> and they enhance, and b) give the <div> and they create <video>
[13:31:35 CST(-0600)] <anastasiac> generally
[13:32:09 CST(-0600)] <colinclark> So, trying to "intuit the intentions of the creator"
[13:32:15 CST(-0600)] <colinclark> I'm thinking we chose the latter for two reasons
[13:32:34 CST(-0600)] <colinclark> 1. We didn't have to worry about the "climbing container" problem if we asked the user to give us an overall container
[13:33:13 CST(-0600)] <colinclark> 2. We were assuming that it was quite possible that the result of instantiating a Video Player might be something other than a <video> tag, in the end
[13:33:21 CST(-0600)] <colinclark> though I'm sure the code wasn't yet quite factored that way
[13:34:00 CST(-0600)] <michelled> I think there's a 3 - we imagine a future where the author isn't sure what's going to go there and we find a suitable video OER and stick it in there
[13:34:05 CST(-0600)] <colinclark> Any other reasons we can think of for why we might have gone with approach b) instead of a)?
[13:34:40 CST(-0600)] <colinclark> michelled: Meaning, say, an interactive Canvas exercise might get resolved in that spot on the page instead of a video?
[13:34:52 CST(-0600)] <colinclark> Or a chapter of a textbook? Or whatever?
[13:34:54 CST(-0600)] <michelled> yes
[13:35:21 CST(-0600)] <colinclark> I guess it's that thing's business to put the right stuff into the markup
[13:35:26 CST(-0600)] <michelled> although that doesn't mean that the video player needs to care - there would be other machinery involved
[13:35:31 CST(-0600)] <colinclark> yeah
[13:35:41 CST(-0600)] <colinclark> it's a good point
[13:35:49 CST(-0600)] <colinclark> I just can't really weigh it one way or another
[13:35:52 CST(-0600)] <colinclark> yet, anyway
[13:36:48 CST(-0600)] <colinclark> any other reasons?
[13:36:57 CST(-0600)] <colinclark> for b) vs. a)
[13:37:15 CST(-0600)] <Justin_o> jhung1: hello, i think i've got all the server side tests done for now. They could be expanded on and refactored later, and should be updated as new functionality is added.
[13:37:28 CST(-0600)] <colinclark> I guess at least for now, an author knows a-priori that they've got a video
[13:37:48 CST(-0600)] <colinclark> and, at bare minimum, they've at least encoded it as either H.264/MPEG-4 or VP8/WebM
[13:37:59 CST(-0600)] <jhung1> justin_o: excellent.
[13:38:06 CST(-0600)] <colinclark> We've pretty much excluded the case where if the user gave us something weirder…
[13:38:23 CST(-0600)] <colinclark> like, say, an .flv container, or a Cinepak encoded .mov or whatever
[13:38:27 CST(-0600)] <michelled> yes, the only other things we handle at the moment is a youtube url
[13:38:32 CST(-0600)] <colinclark> that we'd do anything smart
[13:38:47 CST(-0600)] <colinclark> right
[13:38:54 CST(-0600)] <colinclark> and the YouTube URL is somewhat misleading
[13:39:01 CST(-0600)] <colinclark> in the sense that you don't really get a Video Player
[13:39:24 CST(-0600)] <colinclark> it's a bit like the notion of an "Uploader" between the degraded single-file version and the fancy multi-file version
[13:39:36 CST(-0600)] <colinclark> the YouTube URL doesn't really get you a Video Player
[13:39:44 CST(-0600)] <colinclark> in terms of something that satisfies its contract
[13:40:04 CST(-0600)] <colinclark> So, unless anyone thinks this is crazy talk...
[13:40:32 CST(-0600)] <colinclark> we are basically moving to a model where you must give us at least one of: h.264/mp4 or vp8/webm
[13:40:44 CST(-0600)] <colinclark> and otherwise we degrade to, well, whatever you want us to?
[13:41:31 CST(-0600)] <michelled> yes
[13:41:46 CST(-0600)] <colinclark> Do we want to provide any explicit mechanism for the degradation?
[13:41:55 CST(-0600)] <colinclark> We sort of half-do now
[13:42:08 CST(-0600)] <colinclark> But I guess the point is, you shouldn't be asking for our video player if you can't meet that basic requirement
[13:42:11 CST(-0600)] <colinclark> is that correct?
[13:42:25 CST(-0600)] <colinclark> In other words, if you had some video delivery system that had multiple formats of content
[13:42:26 CST(-0600)] <michelled> meaning the file type?
[13:42:32 CST(-0600)] <colinclark> Codec and container, yes
[13:42:40 CST(-0600)] <michelled> right
[13:42:57 CST(-0600)] <colinclark> So, let's say we're making a think we call "Fluid Video Studios"
[13:43:04 CST(-0600)] <colinclark> FluidTube?
[13:43:06 CST(-0600)] <colinclark> scary thought
[13:43:14 CST(-0600)] <colinclark> Anyone can upload video
[13:43:24 CST(-0600)] <colinclark> if someone uploads, say, a .flv movie
[13:43:41 CST(-0600)] <colinclark> presumably it's the delivery system's job to resolve a suitable Flash-based player via IoC
[13:43:48 CST(-0600)] <colinclark> in place of our HTML5 player
[13:44:15 CST(-0600)] <colinclark> Does that seem about right?
[13:44:54 CST(-0600)] <michelled> I thought that the video player would do that
[13:45:31 CST(-0600)] <michelled> although not in the near future
[13:46:06 CST(-0600)] <michelled> does that make sense? basically, it seems to me that anyone using the player would want it to work with any number of codecs and containers
[13:46:20 CST(-0600)] <colinclark> yeah
[13:46:30 CST(-0600)] <colinclark> I think you're anticipating exactly where I was going to go
[13:46:38 CST(-0600)] <colinclark> So let's say someone has a really good collection of .flvs
[13:46:53 CST(-0600)] <colinclark> but they've also got all the captions in, say, WebVTT
[13:46:56 CST(-0600)] <colinclark> and a good transcript
[13:46:59 CST(-0600)] <colinclark> and some audio descriptions
[13:47:13 CST(-0600)] <colinclark> At that point, we'd probably look at the Flash players out there
[13:47:19 CST(-0600)] <colinclark> find one with a good JavaScript API
[13:47:22 CST(-0600)] <colinclark> many of them are quite good
[13:47:38 CST(-0600)] <colinclark> and then we'd create a new "engine" implementation
[13:47:52 CST(-0600)] <colinclark> Meaning the thing that is responsible for playback, etc.
[13:48:00 CST(-0600)] <colinclark> and it's possible that this thing would have some of its own controls
[13:48:03 CST(-0600)] <colinclark> or we'd use our controls
[13:48:09 CST(-0600)] <colinclark> Does that make sense, michelled?
[13:48:20 CST(-0600)] <michelled> yes
[13:48:31 CST(-0600)] <colinclark> This is where we start getting into cindyli's world
[13:49:01 CST(-0600)] <colinclark> There is, currently latent in our design, some essential thing that represents the HTML5-ness
[13:49:30 CST(-0600)] <colinclark> In other words, there's a component in the system...
[13:49:41 CST(-0600)] <colinclark> responsible for things like the core API of video playback
[13:49:59 CST(-0600)] <colinclark> i.e. play(), pause(), scrubbing
[13:50:03 CST(-0600)] <colinclark> and the "tick"
[13:51:28 CST(-0600)] <colinclark> is this making sense?
[13:51:43 CST(-0600)] <michelled> yes
[13:52:38 CST(-0600)] <colinclark> and so if we got into this Flash situation in the future, we'd grab some excellent Flash player and build an alternative implementation of the HTML5Media component
[13:52:42 CST(-0600)] <colinclark> for lack of a better term
[13:52:53 CST(-0600)] <colinclark> which would be the, say, YouTubeMedia
[13:52:59 CST(-0600)] <colinclark> or JWPlayerMedia
[13:53:02 CST(-0600)] <colinclark> or whatever
[13:53:53 CST(-0600)] <michelled> colinclark: how does this change when we integrate media element.js?
[13:54:01 CST(-0600)] <colinclark> I suppose it doesn't
[13:54:16 CST(-0600)] <colinclark> since MediaElement.js runs at a much lower level
[13:54:38 CST(-0600)] <colinclark> in the sense that it's there to make an old browser look like it's compatible with the HTML5Media implementation
[13:54:48 CST(-0600)] <colinclark> it gives us that universal engine to support modern formats
[13:55:13 CST(-0600)] <colinclark> So the variation here is largely one of format support
[13:55:19 CST(-0600)] <colinclark> different players for different formats
[13:55:33 CST(-0600)] <michelled> rather than different browsers
[13:55:36 CST(-0600)] <colinclark> yes
[13:55:38 CST(-0600)] <colinclark> exactly
[13:56:04 CST(-0600)] <colinclark> So, whatever we call it, there is is this thing inside our video player that represents a thing that can play back a format
[13:56:21 CST(-0600)] <colinclark> I guess we just call it a Player, confusingly enough
[13:56:26 CST(-0600)] <michelled> lol
[13:58:00 CST(-0600)] <colinclark> anyway
[13:58:00 CST(-0600)] <michelled> this makes sense colinclark - thanks for clarifying
[13:58:22 CST(-0600)] <colinclark> I guess the point is that the "VideoPlayer" component is really nothing
[13:58:31 CST(-0600)] <colinclark> it's a means for aggregation
[13:58:43 CST(-0600)] <colinclark> we've met this of course many times as we designed things
[13:58:56 CST(-0600)] <colinclark> and then we've got three separate components at the next tier
[13:59:21 CST(-0600)] <colinclark> The PlayerStrategy, the CAPTIONNER, and the controls
[14:00:01 CST(-0600)] <colinclark> So from the markup perspective
[14:00:07 CST(-0600)] <colinclark> I can imagine that the PlayerStrategy for HTML5 doesn't do terribly much… just renders a <video> tag, etc.
[14:00:16 CST(-0600)] <colinclark> The controls will be super busy with various rendering work
[14:00:24 CST(-0600)] <colinclark> perhaps, too, the captioner
[14:02:18 CST(-0600)] <colinclark> michelled, anastasiac: Today, we've got a piece of that PlayerStrategy in place, I believe
[14:02:45 CST(-0600)] <colinclark> cindyli can probably confirm, but that looks largely like the concern of the fluid.videoPlayer.media component
[14:03:10 CST(-0600)] <cindyli> catching up the conversation
[14:04:17 CST(-0600)] <colinclark> cindyli: it was a bit rambly, so take your time
[14:05:21 CST(-0600)] <cindyli> yes, colinclark, your so called PlayerStrategy should be the concern of the fluid.videoPlayer.media component
[14:05:40 CST(-0600)] <colinclark> okay, cool
[14:05:51 CST(-0600)] <colinclark> I think with some time and refactoring, we'll start to get the factoring right
[14:06:09 CST(-0600)] <colinclark> so that all the HTML5-y concerns are there in the videoPlayer.media component
[14:06:21 CST(-0600)] <colinclark> presumably we'll call it the videoPlayer.html5Media component or whatever
[14:06:31 CST(-0600)] <colinclark> cindyli: The same caveats as yesterday apply
[14:06:39 CST(-0600)] <colinclark> I could be a babbling, raving lunatic at the moment
[14:06:45 CST(-0600)] <colinclark> though I am feeling a lot better
[14:07:36 CST(-0600)] <colinclark> so, ultimately, all of this babbling is to resolve anastasiac's question on the mailing list
[14:07:46 CST(-0600)] <colinclark> as to the nature of our various components and their relationship to the markup
[14:08:13 CST(-0600)] <anastasiac> yes, the babbling is very helpful
[14:16:32 CST(-0600)] <michelled> I'm back now - sounds like we have the beginnings of a plan forward.
[14:16:45 CST(-0600)] <colinclark> michelled: Do you feel like summarizing all that here?
[14:17:10 CST(-0600)] <michelled> oh, I asked for that, didn't I 
[14:18:10 CST(-0600)] <michelled> ok, 1. we will pull out all the HTML5 concerns into its own component. this will allow us to swap in another component when playing other video types or using non-html5 browsers
[14:20:14 CST(-0600)] <michelled> 2. we will build a player strategy for other formats so that we are not restricted to mp4 and webm
[14:22:12 CST(-0600)] <michelled> I think that's it for the player strategy - did I miss anything?
[14:22:15 CST(-0600)] <michelled> I think we still need to talk a bit more about the other two components - the captioner and the controls
[14:24:47 CST(-0600)] <anastasiac> also, by formalizing the media component's responsibilities, we'll convert the parent videoPlayer component into something less involved: Some of its current responsibilities will be offloaded and it will become a more simple aggregator
[14:30:05 CST(-0600)] <michelled> colinclark: does that all seem right? ^
[14:31:24 CST(-0600)] <colinclark> sorry, i'm on a call
[14:31:28 CST(-0600)] <colinclark> but i'll respond real soon
[14:31:28 CST(-0600)] <colinclark>
[14:34:38 CST(-0600)] <michelled>
[14:53:58 CST(-0600)] <colinclark> michelled, anastasiac That sounds right
[14:54:07 CST(-0600)] <colinclark> I guess in terms of the questions asked this morning
[14:54:20 CST(-0600)] <colinclark> 1. Yes, the parent Video Player is a bit odd for having this "not really rendering" quality to it
[14:54:41 CST(-0600)] <colinclark> 2. Yes, the child components should have their own templates and be responsible for managing them appropriately
[14:55:08 CST(-0600)] <colinclark> We've just refined the notion of what this "parent component" really is, since we know that some of its current responsibility actually belongs elsewhere
[14:58:05 CST(-0600)] <cindyli> Bosmon: r u there?
[14:58:22 CST(-0600)] <michelled> I haven't seen him yet cindyli
[14:58:30 CST(-0600)] <cindyli> ok, thanks, michelled
[14:59:03 CST(-0600)] <michelled> sounds good colinclark
[14:59:14 CST(-0600)] <colinclark> cool
[14:59:28 CST(-0600)] <colinclark> I can respond to the mailing list thread with a quick summary and a link to the chat logs
[14:59:41 CST(-0600)] <michelled> thanks!
[14:59:54 CST(-0600)] <anastasiac> thanks, this has been great
[15:28:04 CST(-0600)] <michelled> alexn, anastasiac, cindyli, colinclark, jameswy: allison sent me a link to this open source accessible media player: http://www.nomensa.com/about/news-items/nomensas-accessible-media-player-20-now-free-download
[15:28:27 CST(-0600)] <michelled> unfortunately it's license doesn't play well with ours but I'm sure it's still worth looking at
[15:28:52 CST(-0600)] <cindyli> nice. thanks, michelled, and thanks —— > to allison
[15:30:24 CST(-0600)] <michelled> Alison I mean - I beginning to pick up Bosmon's use of extra consonants
[15:35:47 CST(-0600)] <alexn> michelled, alison: thanks. will be interesting to look at this accessible media player
[16:38:03 CST(-0600)] <colinclark> Hey avtar, Bosmon and yura have been doing some investigation into the latest state of CouchDB
[16:38:06 CST(-0600)] <colinclark> or what was CouchDB
[16:38:09 CST(-0600)] <colinclark> and is now CouchBase
[16:38:18 CST(-0600)] <colinclark> this mashup of Membase and CouchDB
[16:38:46 CST(-0600)] <colinclark> Bosmon is slowly puzzling through the established wisdom of various high-availability database designs
[16:38:59 CST(-0600)] <colinclark> "established wisdom"
[16:39:20 CST(-0600)] <colinclark> just sent me an article on "vbuckets"
[16:39:22 CST(-0600)] <colinclark> http://dustin.github.com/2010/06/29/memcached-vbuckets.html
[16:40:24 CST(-0600)] <colinclark> thought you might be curious to follow along
[17:05:10 CST(-0600)] <avtar> neat
[17:05:14 CST(-0600)] <avtar> thanks for the url
[17:05:55 CST(-0600)] <avtar> have you guys been discussing that in this channel or on lists?
[17:25:27 CST(-0600)] <colinclark> avtar: Well, this is the thing about Bosmon
[17:25:30 CST(-0600)] <colinclark> and often me
[17:25:40 CST(-0600)] <colinclark> it's so easy to get lost in IM instead of public channels
[17:25:47 CST(-0600)] <colinclark> So he IM'ed me about it
[17:25:56 CST(-0600)] <colinclark> I "retweeted" it here in the channel
[17:26:05 CST(-0600)] <colinclark> we'll make sure the conversation moves to a public forum, avtar
[17:26:12 CST(-0600)] <colinclark> and that you can participate
[17:27:05 CST(-0600)] <avtar> ok
[17:27:19 CST(-0600)] <avtar> just wanted to see if i could check out the logs and catch up
[17:27:38 CST(-0600)] <colinclark> I think it started with Yura and Bosmon chatting
[17:27:43 CST(-0600)] <colinclark> and then me and Bosmon chatting
[17:27:49 CST(-0600)] <colinclark> but from now on, we'll do it here
[17:30:42 CST(-0600)] <colinclark> hey michelled
[17:30:45 CST(-0600)] <colinclark> we kind of suck, too
[17:30:49 CST(-0600)] <colinclark> chatting away
[17:30:59 CST(-0600)] <colinclark> you were asking about swapping class names for focus states
[17:31:06 CST(-0600)] <colinclark> and how it shouldn't be necessary in most cases
[17:31:16 CST(-0600)] <colinclark> I mentioned the fact that IE6 doesn't support pseudo selectors
[17:31:19 CST(-0600)] <colinclark> including :focus
[17:31:26 CST(-0600)] <colinclark> You speculated on the presence of a polyfill
[17:31:32 CST(-0600)] <colinclark> I googled and found this: http://selectivizr.com/
[17:31:45 CST(-0600)] <colinclark> Yet another library that omits vowels for Awesomeness
[17:33:36 CST(-0600)] <colinclark> I can't quite imagine how it works--looks like it does some CSS rewriting
[17:34:25 CST(-0600)] <michelled> wow - lots of reg exp in there
[17:34:53 CST(-0600)] <colinclark> yeah
[17:34:59 CST(-0600)] <colinclark> and ad-hoc parsing
[17:35:02 CST(-0600)] <michelled> colinclark: I'm tempted to try this out in the video player
[17:35:12 CST(-0600)] <colinclark> I don't see why you couldn't
[17:35:19 CST(-0600)] <colinclark> it's one of those subtle risks, though
[17:35:23 CST(-0600)] <michelled> so we write modern era CSS and use this to bridge our old browser support
[17:35:26 CST(-0600)] <colinclark> you may never trust this thing
[17:35:40 CST(-0600)] <colinclark> a good reason never to read the source code
[17:36:02 CST(-0600)] <colinclark> I guess a decent set of tests should offset most of the risk
[17:36:24 CST(-0600)] <michelled> it's MIT licensed so there's no issue there
[17:38:45 CST(-0600)] <colinclark> great
[17:38:51 CST(-0600)] <colinclark> worth a shot, for sure
[17:40:35 CST(-0600)] <michelled> colinclark: the other option is to add a little code that does some heavy handed focus styling when in IE6.
[17:40:58 CST(-0600)] <colinclark> I wish CSS were JSON
[17:41:10 CST(-0600)] <colinclark> or the browser exposed a parsing API or something
[17:41:14 CST(-0600)] <michelled> it would mean we wouldn't get the beauty that we strive for in the modern browsers but we'd still have things usable with the keyboard in IE6
[17:41:22 CST(-0600)] <colinclark> right
[17:41:27 CST(-0600)] <colinclark> not the end of the world
[17:42:02 CST(-0600)] <michelled> I just feel that the code bloat we are currently getting because of this issue is not worth carrying around and maintaining.
[17:45:07 CST(-0600)] <michelled> colinclark: I'll try to work this into the schedule post demo
[17:45:13 CST(-0600)] <colinclark> cool
[17:45:29 CST(-0600)] <colinclark> yeah IE6-driven code bloat sucks
[17:45:48 CST(-0600)] <colinclark> the polyfill seems like a good start
[17:45:59 CST(-0600)] <Bosmon> Hi michelled, colinclark, just trying to catch up
[17:46:07 CST(-0600)] <Bosmon> Is there a JIRA I can read describing this issue?
[17:46:08 CST(-0600)] <colinclark> oh hey Bosmon
[17:46:18 CST(-0600)] <colinclark> no, it's just an observation from code review
[17:46:34 CST(-0600)] <colinclark> we spend an awful lot of energy twiddling class names
[17:46:43 CST(-0600)] <michelled> actually, there is: http://issues.fluidproject.org/browse/FLUID-4583
[17:46:49 CST(-0600)] <colinclark> nice!
[17:47:10 CST(-0600)] <Bosmon> Cool
[17:47:10 CST(-0600)] <colinclark> michelled: where are some examples of particular annoying bloat?
[17:47:26 CST(-0600)] <michelled> ah, good point - they aren't in the code base yet
[17:47:30 CST(-0600)] <Bosmon> colinclark - just what I was going to ask
[17:47:38 CST(-0600)] <colinclark> Doesn't the keyboard-a11y plugin actually hand some of these cases anyway?
[17:47:41 CST(-0600)] <michelled> let me find a link of ryou
[17:48:01 CST(-0600)] <colinclark> I'm pretty sure one of the things it does is to slap a class on focused elements
[17:48:11 CST(-0600)] <colinclark> though i'd have to go back to the code to know for sure
[17:48:13 CST(-0600)] <colinclark> been a long time
[17:48:51 CST(-0600)] <michelled> I got an angry unicorn from github!
[17:49:00 CST(-0600)] <colinclark> wow
[17:49:04 CST(-0600)] <colinclark> take that!
[17:49:12 CST(-0600)] <colinclark> I guess the plugin doesn't, by default
[17:49:19 CST(-0600)] <colinclark> it just gives you event handlers in case you want to do it yourself
[17:49:25 CST(-0600)] <Bosmon> right
[17:49:26 CST(-0600)] <colinclark> which makes sense
[17:51:17 CST(-0600)] <Bosmon> What did the angry unicorn say? : P
[17:51:22 CST(-0600)] <michelled> https://github.com/acheetham/videoPlayer/blob/5b4451ffe9f079cd53c7eafddd84c61937e85ccf/js/VideoPlayer_controllers.js#L304-306
[17:51:37 CST(-0600)] <michelled> the angry unicorn told me the page took too long to load
[17:51:59 CST(-0600)] <athena> you have an angry unicorn?
[17:52:12 CST(-0600)] <michelled> apparently github does
[17:52:36 CST(-0600)] <athena> aw!
[17:52:47 CST(-0600)] <Bosmon> So michelled, what is the problem with these two highlighted lines?
[17:53:43 CST(-0600)] <michelled> well, those lines plus the actual show and hide functions could go away if we used the focus pseudo selector in our CSS
[17:54:34 CST(-0600)] <Bosmon> I guess you would need the ":hover" pseudoselector to make the first one go away
[17:54:35 CST(-0600)] <michelled> Bosmon: there are other examples as well with plain old focus and not focused styles being swapped
[17:55:26 CST(-0600)] <Bosmon> This actually relates to a part of the framework that has yet to be constructed
[17:55:28 CST(-0600)] <Bosmon> or even planned
[17:55:46 CST(-0600)] <Bosmon> Although knowing the way these things go, this may end up being done first
[17:56:13 CST(-0600)] <colinclark> what part is that, Bosmon?
[17:56:26 CST(-0600)] <Bosmon> Well, I used to refer to this as the "visibility model"
[17:56:34 CST(-0600)] <Bosmon> But it clearly relates to all number of other things
[17:56:53 CST(-0600)] <Bosmon> I guess at least to some extent what they all have in common is depending on some kind of binary state
[17:56:58 CST(-0600)] <Bosmon> But not even that may be necessary
[17:57:16 CST(-0600)] <Bosmon> I observed that the majority of the non-frameworkised code that JURA has left in CSpace consists of this kind of hide/show smear
[17:57:37 CST(-0600)] <Bosmon> And that what we really need is a declarative syntax for a component to be able to describe various pieces of "coordinated view and model state"
[17:58:05 CST(-0600)] <Bosmon> If we had that, it would be easy to have an impl which on IE6 writes out all the smear code, and on all the other browsers, just spits out a pseudoselector
[17:58:38 CST(-0600)] <colinclark> I think we're really going to have to check in with the King again about our browser support
[17:58:41 CST(-0600)] <colinclark> policy
[17:58:55 CST(-0600)] <colinclark> I find myself completely confused as to the nature of the decision we did or didn't make
[17:58:59 CST(-0600)] <colinclark> whenever that was
[17:59:03 CST(-0600)] <Bosmon>
[17:59:05 CST(-0600)] <colinclark> maybe it's just because I didn't get my way 
[17:59:06 CST(-0600)] <colinclark> I'm not sure
[17:59:07 CST(-0600)] <colinclark>
[17:59:11 CST(-0600)] <Bosmon> I thought it was because you did : P
[17:59:18 CST(-0600)] <colinclark> No, I think I was the most radical
[17:59:19 CST(-0600)] <Bosmon> At least, I don't recall anyone arguing against you.....
[17:59:33 CST(-0600)] <colinclark> Advocating for dropping all IE < 9
[17:59:45 CST(-0600)] <Bosmon> Oh, I see
[17:59:52 CST(-0600)] <colinclark> Cindy was my main opponent
[17:59:53 CST(-0600)] <Bosmon> I assumed you were't completely serious about that
[18:00:01 CST(-0600)] <colinclark> well, I'm never completely serious
[18:00:04 CST(-0600)] <Bosmon> hahahaha
[18:00:13 CST(-0600)] <michelled> the king is confused about our decision too
[18:00:15 CST(-0600)] <colinclark> I'd be willing to step down to IE < 8
[18:00:18 CST(-0600)] <michelled> I think we didn't actually make one
[18:00:30 CST(-0600)] <colinclark> I think there's no point in distinguishing IE 7 from 6
[18:00:31 CST(-0600)] <Bosmon> I recall a summary
[18:00:47 CST(-0600)] <colinclark> although in this particular case, I think IE7 does support pseudo selectors
[18:00:58 CST(-0600)] <colinclark> I recall a summary that never quite reflected what I thought happened
[18:00:59 CST(-0600)] <Bosmon> I think it does
[18:01:07 CST(-0600)] <Bosmon> it is missing the really most painfully fatal bugs
[18:01:11 CST(-0600)] <colinclark> CSS bugs
[18:01:14 CST(-0600)] <Bosmon> For example, multiple class selectors
[18:01:15 CST(-0600)] <colinclark> not so much other bugs
[18:01:16 CST(-0600)] <colinclark> yeah
[18:01:26 CST(-0600)] <colinclark> The JS runtime is nearly identical to 6
[18:01:46 CST(-0600)] <colinclark> I think, practically speaking, we'll probably gravitate towards a "try our best to support IE6" model
[18:01:54 CST(-0600)] <colinclark> which I think actually doesn't solve the real problem
[18:01:56 CST(-0600)] <Bosmon> Well, sure
[18:01:59 CST(-0600)] <colinclark> which is the economic question
[18:02:03 CST(-0600)] <Bosmon> The question is.... what that MEANS
[18:02:04 CST(-0600)] <colinclark> "when do we pay?"
[18:02:30 CST(-0600)] <Bosmon> I mean, that has a lot of bearing on the question - "do we try to construct some declarative framework support for model-coordinated view updates"?
[18:02:39 CST(-0600)] <colinclark> yes
[18:02:47 CST(-0600)] <Bosmon> I guess now we have "stronger event boiling" this will be somewhat easier
[18:02:47 CST(-0600)] <colinclark> I'd rather pay for other framework features right now
[18:02:57 CST(-0600)] <Bosmon> A lot of the worse bugs in our event system are gone now
[18:03:02 CST(-0600)] <Bosmon> Such as?
[18:03:24 CST(-0600)] <Bosmon> I guess in the end, it does come down to "pay or don't pay"
[18:03:33 CST(-0600)] <colinclark> Anything that supports UIO, server-side development for GPII, and rapid development of the Video Player into something very personalizable
[18:03:39 CST(-0600)] <Bosmon> If we don't consider these things are strategic now, we may still pay incompatibility costs down the line
[18:03:42 CST(-0600)] <colinclark> yes
[18:03:45 CST(-0600)] <colinclark> that's exactly it
[18:04:11 CST(-0600)] <colinclark> I think at this point I'd probably advocate for a "pay for it later, at risk of a higher cost"
[18:04:12 CST(-0600)] <Bosmon> Well, I'll bear it in mind when doing the UIO refactoring
[18:04:20 CST(-0600)] <colinclark> In other words, stop actively developing for IE6 and 7
[18:04:26 CST(-0600)] <Bosmon> There may be a way to make a small deviation which takes in something
[18:04:32 CST(-0600)] <Bosmon> My mind is too addled to be sure
[18:04:36 CST(-0600)] <colinclark> and make fixes on demand to help support it
[18:04:45 CST(-0600)] <Bosmon> yes
[18:04:51 CST(-0600)] <Bosmon> In this case, the cost of the fixes is fairly onerous
[18:04:54 CST(-0600)] <colinclark> we know that the cost will be higher later
[18:04:55 CST(-0600)] <colinclark> yes
[18:04:57 CST(-0600)] <Bosmon> And amounts to having 2 versions of the component
[18:05:05 CST(-0600)] <colinclark> but the benefit is twofold:
[18:05:13 CST(-0600)] <colinclark> 1) we pay the cost after having a solid working version
[18:05:22 CST(-0600)] <colinclark> 2) we only pay if there's a high user demand
[18:05:29 CST(-0600)] <Bosmon> Ok
[18:05:31 CST(-0600)] <Bosmon> Seems reasonable
[18:05:33 CST(-0600)] <colinclark> I'm not sure we'd necessarily have two versions of the component
[18:05:39 CST(-0600)] <colinclark> but we'd run the risk of heavy refactoring
[18:05:42 CST(-0600)] <Bosmon> Yes
[18:05:44 CST(-0600)] <colinclark> in order to support IE6/7 later
[18:06:01 CST(-0600)] <colinclark> For modern new components like Video Player, I think it's a safe bet
[18:06:07 CST(-0600)] <Bosmon> So, does this mean we will start to make a heavy push to recommend the use of pseudoselectors?
[18:06:08 CST(-0600)] <colinclark> for UIO, we'll have to have a more refined debate
[18:06:28 CST(-0600)] <colinclark> yeah, I think we'd push to use as many effective modern CSS techniques as IE 8 will bear
[18:06:37 CST(-0600)] <Bosmon> I'd have no problems with that
[18:06:54 CST(-0600)] <colinclark> dunno what the king would say
[18:06:55 CST(-0600)] <colinclark> or cindy
[18:07:04 CST(-0600)] <colinclark> i don't even dare ask athena what she'd say
[18:07:13 CST(-0600)] <colinclark> but i think we did once before anyway
[18:07:20 CST(-0600)] <colinclark> this is all a bit of deja vu for me
[18:07:31 CST(-0600)] <colinclark> but maybe it's just the cold
[18:07:44 CST(-0600)] <Bosmon>
[18:08:02 CST(-0600)] <Bosmon> I had a fit of that yesterday.... whilst seeing a section of an episode of that TV show, "Frasier" : P
[18:08:36 CST(-0600)] <Bosmon> IE7 market share has dropped significantly over 2011... from 12% to about 3.7%
[18:08:37 CST(-0600)] <colinclark> Watching reruns will do that to you
[18:09:00 CST(-0600)] <colinclark> I dunno, Fish
[18:09:05 CST(-0600)] <Bosmon> IE6 dropped from 5.8% to 1.6%
[18:09:08 CST(-0600)] <colinclark> Do you think we should bring this topic up at some point again?
[18:09:13 CST(-0600)] * athena thinks IE6 is evil and should go away
[18:09:17 CST(-0600)] <colinclark> +1
[18:09:23 CST(-0600)] <athena> and something about someone owing someone beer
[18:09:27 CST(-0600)] <colinclark> yes
[18:09:28 CST(-0600)] <colinclark> that too
[18:09:33 CST(-0600)] <colinclark> I'm always happy to owe people beer
[18:09:37 CST(-0600)] <athena> heh
[18:09:44 CST(-0600)] <athena> i just got in a bet with a neighbor that will end in beer
[18:09:46 CST(-0600)] <colinclark> and always dumb enough to make optimistic bets
[18:09:54 CST(-0600)] <colinclark> athena: awesome, what about?
[18:09:55 CST(-0600)] <athena> said bet being that i can create pajamas that look good with a sword
[18:10:01 CST(-0600)] <Bosmon> !!!!!
[18:10:01 CST(-0600)] <colinclark> oh
[18:10:02 CST(-0600)] <colinclark> wow
[18:10:05 CST(-0600)] <colinclark> umm
[18:10:05 CST(-0600)] <athena> lol
[18:10:09 CST(-0600)] <Bosmon> Only GODD can make pyjamas!
[18:10:18 CST(-0600)] <colinclark> If anyone could, it'd be you, athena
[18:10:25 CST(-0600)] <colinclark> michelled might be able to as well
[18:10:37 CST(-0600)] <colinclark> though I imagine she might try to make a sweater or something instead
[18:10:39 CST(-0600)] <athena> well i do work from home - my love of pajamas is a running neighborhood joke
[18:10:50 CST(-0600)] <colinclark> you and Bosmon have so much in common
[18:10:57 CST(-0600)] <athena> and i did make some pj pants this winter after buying a new serger
[18:10:57 CST(-0600)] <Bosmon> I try to make sure I am unobserved when making a run for the mail : P
[18:11:08 CST(-0600)] <athena> and then promptly announced i was never getting dressed again
[18:11:09 CST(-0600)] <Bosmon> But I don't talk to the neighbours enough to determine whether I am a running joke or not
[18:11:13 CST(-0600)] <athena> lol Bosmon
[18:11:25 CST(-0600)] <athena> i live in a busy neighborhood and don't have a backyard to walk the dog, so . ..
[18:12:55 CST(-0600)] <Bosmon> It seems clear that Chrome will overtake all versions of IE some time during 2012.....
[18:12:57 CST(-0600)] <michelled> lol
[18:13:16 CST(-0600)] <colinclark> Bosmon: Such a sad statistic 
[18:13:32 CST(-0600)] <colinclark> michelled: Any thoughts on how/if we should reopen our browser support debate
[18:13:37 CST(-0600)] <colinclark> and if my proposal is sane?
[18:13:58 CST(-0600)] <Bosmon> Can we recover some writeup from the previous debate?
[18:14:12 CST(-0600)] <colinclark> there was something to the list
[18:14:15 CST(-0600)] <colinclark> let me see
[18:14:48 CST(-0600)] <colinclark> this seem about right? http://old.nabble.com/Browser-Support-and-Testing-td32799659.html
[18:15:21 CST(-0600)] <Bosmon> I see, yes
[18:15:23 CST(-0600)] <Bosmon> It is quite vague
[18:15:36 CST(-0600)] <Bosmon> Well worth reopening the debate
[18:15:57 CST(-0600)] <Bosmon> It's ripe for a followup message, saying what it actually means, in terms of specific commitments
[18:16:04 CST(-0600)] <colinclark> It hints at what we're suggesting tonight, actually
[18:16:12 CST(-0600)] <colinclark> just doesn't say "this is what we'll do," I think
[18:16:55 CST(-0600)] <Bosmon> Yes
[18:17:57 CST(-0600)] <michelled> I think a follow up from you would be perfect colinclark
[18:18:05 CST(-0600)] <Bosmon> I agree
[18:18:28 CST(-0600)] <colinclark> okay
[18:18:36 CST(-0600)] <colinclark> I guess the conservative approach is this:
[18:18:59 CST(-0600)] <colinclark> 1. For new components, we adopt this new plan of developing for and supporting IE8+ and the modern browsers
[18:19:34 CST(-0600)] <colinclark> 2. For existing, stable components, we continue to test, develop, and support IE6+, with the option of "promoting" them to this new modern status as needed
[18:19:44 CST(-0600)] <colinclark> Meaning, we'll keep up the Reorderer as is, say
[18:19:49 CST(-0600)] <Bosmon> I like that
[18:19:54 CST(-0600)] <colinclark> But UIO may legitimately evolve to this modern status
[18:19:59 CST(-0600)] <colinclark> based on upcoming development costs
[18:19:59 CST(-0600)] <Bosmon> Although my head spins a bit at the thought of "promotion" : P
[18:20:07 CST(-0600)] <colinclark> yeah, it's not the right word
[18:20:13 CST(-0600)] <colinclark> Ascendence?
[18:20:17 CST(-0600)] <Bosmon> hahahaha
[18:20:25 CST(-0600)] <Bosmon> Well, in fact, they become "degraded"
[18:20:32 CST(-0600)] <Bosmon> Since their support profile becomes narrower....
[18:20:39 CST(-0600)] <colinclark> yes
[18:20:46 CST(-0600)] <Bosmon> We need one of these kind of modern management-speak type words that covers these situations
[18:20:51 CST(-0600)] <Bosmon> Like "rightsizing"
[18:20:51 CST(-0600)] <colinclark> though arguably they take on some good new characterists
[18:20:56 CST(-0600)] <colinclark> characteristics
[18:21:05 CST(-0600)] <colinclark> such as thinner code profiles
[18:21:13 CST(-0600)] <colinclark> perhaps fancier styling and features
[18:21:44 CST(-0600)] <Bosmon> "rationalised"