fluid-work IRC Logs-2012-01-26

Owned by Fluid IRC Log Bot
Last updated: Jan 26, 2012Version comment
22 min read

[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 (smile)

[10:58:22 CST(-0600)] <michelled> (smile)

[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> (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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 (wink)

[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> (smile)

[14:34:38 CST(-0600)] <michelled> (smile)

[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 (smile)

[15:30:24 CST(-0600)] <michelled> Alison I mean - I beginning to pick up Bosmon's use of extra consonants (smile)

[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 (smile)

[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 (wink)

[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 (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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> (smile)

[17:59:05 CST(-0600)] <colinclark> maybe it's just because I didn't get my way (tongue)

[17:59:06 CST(-0600)] <colinclark> I'm not sure

[17:59:07 CST(-0600)] <colinclark> (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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 (wink)

[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> (smile)

[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 (wink)

[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 (tongue)

[18:10:50 CST(-0600)] <colinclark> you and Bosmon have so much in common (smile)

[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 (smile)

[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 (sad)

[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 (smile)

[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"

[18:22:08 CST(-0600)] <Bosmon> As happened to Britain's railways in the 1960s, when 2/3 of them were destroyed....

[18:34:15 CST(-0600)] <colinclark> ok, sent