fluid-work IRC Logs-2012-09-11

Owned by Fluid IRC Log Bot
Last updated: Sept 11, 2012Version comment
20 min read

[11:36:05 CDT(-0500)] <alexn1> colinclark: ayt?

[11:36:12 CDT(-0500)] <colinclark> yup

[11:36:57 CDT(-0500)] <alexn1> I was working on 4779 - a JIRA where I need to hide a fullscreen button depending on the browser fullscreen capabilities

[11:37:26 CDT(-0500)] <alexn1> I managed to instantiate fullscreen toggleButton as an empty component of type fluid.emptySubcomponent

[11:37:31 CDT(-0500)] <alexn1> through the depends block

[11:37:33 CDT(-0500)] <colinclark> that's cool

[11:37:36 CDT(-0500)] <alexn1> but there is one little problem

[11:37:56 CDT(-0500)] <alexn1> this toggleButton component attaches itself to a button in the videoPlayer markup

[11:38:17 CDT(-0500)] <alexn1> if I make this toggleButton component, button is still present in the markup with all its css classes

[11:38:24 CDT(-0500)] <colinclark> right

[11:38:39 CDT(-0500)] <colinclark> What kinds of strategies have you been mulling over so far to deal with this issue?

[11:38:47 CDT(-0500)] <alexn1> right !

[11:38:52 CDT(-0500)] <alexn1> I was about to type them here

[11:39:06 CDT(-0500)] <alexn1> basically I have 3 ideas in my head so far

[11:40:19 CDT(-0500)] <alexn1> 1 - is to put an empty div instead of the button and let the toggleComponent render itself in produceTree and if empty component is provided then nothing is being rendered at all. This approach looks clean but might ruin an overall videoPlayer template once button is not there or empty div is in its place

[11:40:20 CDT(-0500)] <colinclark> ok, fire away

[11:41:54 CDT(-0500)] <alexn1> 2 - I was thinking that buttons in videoPlayer have a defaul CSS class which would make them not tab accessible and completely invisible using the css styles. And only in the toggleButton finalInit some css classes (e.g. activeButton) will be applied which would make it tabbable and visible for the user. So if empty component was passed then the button container stays out of the reach by users and screen readers

[11:42:21 CDT(-0500)] <colinclark> ok

[11:42:34 CDT(-0500)] <alexn1> let me remember the 3rd one

[11:42:52 CDT(-0500)] <colinclark> (smile)

[11:43:36 CDT(-0500)] <alexn1> actually my 3rd is a not a good one (smile)

[11:44:01 CDT(-0500)] <alexn1> so I guess I have 2 options in mind

[11:44:03 CDT(-0500)] <colinclark> lol

[11:44:04 CDT(-0500)] <colinclark> ok

[11:44:19 CDT(-0500)] <colinclark> We can categorize these two ideas first

[11:44:23 CDT(-0500)] <colinclark> and I can add a third potential solution

[11:45:01 CDT(-0500)] <colinclark> The first involves refactoring the markup relationship between the top-level VideoPlayer component and the ToggleButton component

[11:45:17 CDT(-0500)] <colinclark> Turning ToggleButton into a "self-rendering" component that is responsible for its own markup

[11:45:49 CDT(-0500)] <colinclark> I actually think that it's a good solution for many typical "small components" that our users might want to use on their own

[11:46:18 CDT(-0500)] <colinclark> Your second scenario I would describe as a "progressive enhancement" approach

[11:46:35 CDT(-0500)] <colinclark> Are you familiar with how progressive enhancement is often implemented in HTML, CSS, and JavaScript, alexn1?

[11:47:20 CDT(-0500)] <alexn1> colinclark: maybe I've seen it before… I just never encountered this term "progressive enhancement"

[11:47:33 CDT(-0500)] <colinclark> Ok

[11:48:03 CDT(-0500)] <colinclark> So, the simplest case of progressive enhancement is one that we are facing less and less

[11:48:17 CDT(-0500)] <colinclark> but it is still interesting as an illustrative example for more complex cases

[11:49:04 CDT(-0500)] <colinclark> Our Uploader is a good example of this approach in action

[11:49:05 CDT(-0500)] <colinclark> http://fluidproject.org/releases/1.4/demos/uploader/html/uploader.html

[11:49:13 CDT(-0500)] <colinclark> Do you have the Web Developer toolbar installed on Firefox, alexn1?

[11:49:25 CDT(-0500)] <alexn1> yes I do (smile)

[11:49:53 CDT(-0500)] <colinclark> So go to that page, and you'll see our Uploader component

[11:50:07 CDT(-0500)] <colinclark> in a modern browser, you get a nice HTML5-based implementation

[11:50:14 CDT(-0500)] <colinclark> you can upload multiple files, you get fancy progress bars as they upload, etc.

[11:50:37 CDT(-0500)] <colinclark> Now, if you disable JavaScript in the Web Developer Toolbar in Firefox and then reload the page, take a look at what happens

[11:51:34 CDT(-0500)] <alexn1> interesting...

[11:52:45 CDT(-0500)] <colinclark> You get a much simpler user interface

[11:53:16 CDT(-0500)] <colinclark> back to the old, boring HTML <input type="file"> element that any browser made in the last 15 years can handle

[11:53:32 CDT(-0500)] <colinclark> the Uploader actually has several other layers of progressive enhancement

[11:53:54 CDT(-0500)] <colinclark> If it detects a browser that isn't HTML5-compatible, but can run Flash, it will deliver a SWFUpload-based implementation

[11:54:07 CDT(-0500)] <colinclark> Different implementations for different contexts

[11:54:34 CDT(-0500)] <colinclark> Anyway, in that most basic progressive enhancement scenario, the workflow is something like this...

[11:54:57 CDT(-0500)] <colinclark> The page contains the markup for the basic, plain HTML input

[11:55:03 CDT(-0500)] <colinclark> and that's visible by default

[11:55:25 CDT(-0500)] <colinclark> it also contains the template for the multi-file Uploader, which is by default hidden

[11:55:39 CDT(-0500)] <colinclark> So, if we get a browser that, say, doesn't support JavaScript

[11:55:44 CDT(-0500)] <colinclark> everything is how they'd want it

[11:55:51 CDT(-0500)] <colinclark> they can see the plain form element

[11:55:58 CDT(-0500)] <colinclark> and the fancy, JavaScript-powered stuff is hidden

[11:56:06 CDT(-0500)] <colinclark> some of it, perhaps, not even rendered yet

[11:56:19 CDT(-0500)] <colinclark> Now, if JavaScript is available and turned on

[11:56:33 CDT(-0500)] <colinclark> it's the job of some code to go ahead and flip this situation around

[11:57:00 CDT(-0500)] <colinclark> to hide the simple stuff and show the more complex, JavaScript-powered interface

[11:57:18 CDT(-0500)] <colinclark> and it needs to do this very quickly, so the user doesn't see any flicker or "bank" as Alex Russell calls it

[11:57:28 CDT(-0500)] <alexn1> (smile)

[11:57:44 CDT(-0500)] <colinclark> (He's the guy who created Dojo, and now works on the Chrome team)

[11:57:58 CDT(-0500)] <colinclark> So, your idea #2 fits into the category of something roughly like this

[11:58:24 CDT(-0500)] <colinclark> If I understand it correctly, you're advocating that mark should be initially hidden and only shown if it's appropriate for the context

[11:59:00 CDT(-0500)] <alexn1> colinclark: exactly. This is my #2 possible solution for the problem I'm facing

[11:59:20 CDT(-0500)] <colinclark> So the third idea that struck me, thinking only casually about the problem...

[12:00:06 CDT(-0500)] <colinclark> 3 - Create a component whose primary responsibility is to "tidy up" in cases where a particular piece of markup is inappropriate for the context

[12:04:19 CDT(-0500)] <alexn1> colinclark: I'm just thinking if we need this component… in the end this fullscreen button hiding there is only for the time being until we implement a proper fullscreen mode planned for our videoPlayer

[12:04:40 CDT(-0500)] <colinclark> That's actually an interesting segue, alexn1

[12:04:54 CDT(-0500)] <alexn1> for some reason I cannot come up with another instance of the related problem

[12:05:08 CDT(-0500)] <colinclark> You have mentioned several times, in comments in code and here, about "proper full screen mode" or "our own full screen mode"

[12:05:16 CDT(-0500)] <colinclark> this probably something you and michelled have chatted about some time in the past

[12:05:23 CDT(-0500)] <alexn1> yup we did

[12:05:32 CDT(-0500)] <colinclark> but I find myself completely unclear about what this actually means

[12:05:42 CDT(-0500)] <colinclark> What is "proper full screen mode?"

[12:06:51 CDT(-0500)] <alexn1> it is a fullscreen mode which will be implemented most likely without built in browser fullscreen functionality with the presence of our own controls when this functionality is envoked.

[12:07:08 CDT(-0500)] <colinclark> How would that work?

[12:07:17 CDT(-0500)] <colinclark> How could one implement a full screen mode without using the browser APIs?

[12:09:21 CDT(-0500)] <alexn1> well I always thought that it would be something similar to what youtube does (their fullscreen functionality is so different from what RequestFullScreen does

[12:10:06 CDT(-0500)] <colinclark> How do they accomplish it, in your estimation?

[12:11:20 CDT(-0500)] <alexn1> most likely by browser occupying the whole browsable space with combination of some of the fullscreen browser compatibility (set flags that video is a fullscreen mode already)

[12:11:26 CDT(-0500)] <alexn1> just an idea

[12:11:41 CDT(-0500)] <colinclark> Well, it's interesting to break it down a bit

[12:11:57 CDT(-0500)] <colinclark> First, by default, YouTube is still entirely Flash-based by default

[12:12:03 CDT(-0500)] <colinclark> So in Flash, anything is possible

[12:12:11 CDT(-0500)] <colinclark> with all of the costs and terror associated with it

[12:12:32 CDT(-0500)] <colinclark> If you opt into the HTML5 trial, it gets a bit more interesting

[12:12:46 CDT(-0500)] <colinclark> http://www.youtube.com/html5

[12:13:10 CDT(-0500)] <colinclark> It's actually really exciting

[12:13:25 CDT(-0500)] <colinclark> Last I looked at this, YouTube wasn't really supporting anything meaningful in terms of full screen mode

[12:13:32 CDT(-0500)] <colinclark> they were doing the old "make the window really big" trick

[12:13:38 CDT(-0500)] <colinclark> it looks like support has evolved quite a bit

[12:13:49 CDT(-0500)] <colinclark> and they're clearly using requestFullScreen()

[12:14:03 CDT(-0500)] <colinclark> since that's the only API available for making a genuine full screen experience in HTML

[12:14:11 CDT(-0500)] <colinclark> but they're also able to add their own controls and styling

[12:15:34 CDT(-0500)] <alexn1> colinclark: that sounds pretty positive since I always thought that my fullscreen work will be completely removed at some point.. but what you are saying gives me a hope (smile)

[12:15:41 CDT(-0500)] <colinclark> Yeah

[12:16:02 CDT(-0500)] <colinclark> My point here is that we shouldn't be imagining that somehow code we're writing is going to get thrown away

[12:16:10 CDT(-0500)] <colinclark> Code is really, really expensive

[12:16:18 CDT(-0500)] <colinclark> Don't write it to throw it away

[12:16:38 CDT(-0500)] <colinclark> So, best as I can tell from this is that we've got something we want to keep going for the long term

[12:17:48 CDT(-0500)] <colinclark> So the next question is what to do about this

[12:18:09 CDT(-0500)] <colinclark> I guess the first thing we've got to sort through is what the trajectory is for this ToggleButton

[12:18:12 CDT(-0500)] <colinclark> it was written fast

[12:18:20 CDT(-0500)] <colinclark> perhaps not with a mind to general reusability

[12:18:26 CDT(-0500)] <colinclark> which is a bit of a problem

[12:18:33 CDT(-0500)] <colinclark> michelled: I don't know if you had a chance to catch up on the discussion

[12:18:44 CDT(-0500)] <colinclark> and if you have some sense of where ToggleButton will go in the long run

[12:18:45 CDT(-0500)] <michelled> colinclark: I have

[12:18:53 CDT(-0500)] <colinclark> and if any of these three scenarios seem particularly resonant with you

[12:20:25 CDT(-0500)] <michelled> colinclark: ToggleButton seems like a generally useful thing so I'd like to see it become a bit more robust and perhaps even move up to Infusion if the KING and the community thinks that makes sense

[12:20:49 CDT(-0500)] <colinclark> michelled: Do you think that argues for it being self-rendering?

[12:20:51 CDT(-0500)] <colinclark> at least optionally?

[12:20:54 CDT(-0500)] <michelled> colinclark: in that sense, it seems to be the type of component that would handle its own markup

[12:20:59 CDT(-0500)] <colinclark> yeah

[12:21:04 CDT(-0500)] <michelled> yes, I'd want it to be optional

[12:21:33 CDT(-0500)] <michelled> because I can imagine that if I'm making markup for my page, I'd probably want to put a button in there

[12:21:49 CDT(-0500)] <michelled> so I'd want the component to be smart enough to determine what it should create and when

[12:22:03 CDT(-0500)] <michelled> do you think that makes sense?

[12:22:11 CDT(-0500)] <colinclark> I do, yes

[12:22:31 CDT(-0500)] <colinclark> Though I am still vaguely of the mind that the filament group had some nice widgets for this a while ago

[12:22:43 CDT(-0500)] <colinclark> and at some point, we'll see them emerging in jQuery UI

[12:23:09 CDT(-0500)] <colinclark> but even still, there's an interesting amount of nice model-oriented logic in here, which would inevitably have to stay

[12:23:41 CDT(-0500)] <michelled> yeah, I'm not really sure when we'll see it in jQuery UI, but as you say, we would still have an Infusion wrapper like we do for Tooltip

[12:23:53 CDT(-0500)] <michelled> so a certain amount of our work would remain

[12:24:08 CDT(-0500)] <colinclark> michelled: I'm curious about these lines of code: https://github.com/fluid-project/videoPlayer/blob/demo/js/ToggleButton.js#L58-63

[12:24:16 CDT(-0500)] <colinclark> From a log, it looks like they might be yours

[12:26:29 CDT(-0500)] <michelled> really? I don't recall them - it certainly looks very odd

[12:26:41 CDT(-0500)] <colinclark> who knows (smile)

[12:26:51 CDT(-0500)] <colinclark> I'm just curious about that comparison

[12:27:00 CDT(-0500)] <colinclark> to see if the "init" style is the same as the "pressed" style

[12:27:45 CDT(-0500)] <colinclark> I was hoping that perhaps the init style might actually be a nice place for us to hang a bit of progressive enhancement-y styling

[12:27:50 CDT(-0500)] <colinclark> without changing any code

[12:29:28 CDT(-0500)] <alexn1> it sounds as #2 approach where the button styling will be applied only if the button is being initialized, correct me if I'm wrong

[12:29:30 CDT(-0500)] <colinclark> init and pressed both seem to get overridden in a curious way by the subcomponent configuration in the Controllers object

[12:29:54 CDT(-0500)] <colinclark> alexn1: Yes, my hope was that you'd get this behaviour for free

[12:31:17 CDT(-0500)] <colinclark> I'm also a bit worried about "jank" in most of these cases

[12:31:30 CDT(-0500)] <colinclark> but it might be just fine

[12:32:40 CDT(-0500)] <colinclark> it's interesting to look at the factoring of these components

[12:33:03 CDT(-0500)] <colinclark> the Toggle Button has a container that it does nothing with

[12:33:11 CDT(-0500)] <colinclark> and a selector to find the "button" in it

[12:33:33 CDT(-0500)] <colinclark> so, in this instance, the Controllers component just hands off its own container to all the buttons

[12:33:41 CDT(-0500)] <colinclark> trusting them to do their thing

[12:39:00 CDT(-0500)] <colinclark> alexn1: What does your demands block look like?

[12:39:23 CDT(-0500)] <alexn1> fluid.demands("fluid.videoPlayer.controllers", "fluid.browser.noFullScreenMode", {

[12:39:24 CDT(-0500)] <alexn1> options: {

[12:39:24 CDT(-0500)] <alexn1> components: {

[12:39:24 CDT(-0500)] <alexn1> fullScreenButton: {

[12:39:24 CDT(-0500)] <alexn1> type: "fluid.emptySubcomponent"

[12:39:24 CDT(-0500)] <alexn1> }

[12:39:24 CDT(-0500)] <alexn1> }

[12:39:25 CDT(-0500)] <alexn1> }

[12:39:25 CDT(-0500)] <alexn1> });

[12:40:01 CDT(-0500)] <alexn1> and I changed hasFullScreenMode into noFullScreenMode

[12:40:33 CDT(-0500)] <alexn1> so that it would be a context in which the button will be empty

[12:42:07 CDT(-0500)] <alexn1> and if noFullScreenMode is present then the full configuration will be left as it is in VideoPlayer_controllers.js

[12:44:31 CDT(-0500)] <colinclark> Yeah, as it stands, you could accomplish #2 quite easily by introducing a new class

[12:44:43 CDT(-0500)] <colinclark> something to the effect of "fl-videoPlayer-optional"

[12:44:48 CDT(-0500)] <colinclark> which hides the control by default

[12:45:05 CDT(-0500)] <colinclark> and updating the init style for this toggle button to include the appropriate override

[12:45:37 CDT(-0500)] <colinclark> michelled: I have a vague sense that, given the early factoring of the ToggleButton component, this approach might be preferable

[12:45:46 CDT(-0500)] <colinclark> but I'm open to suggestions

[12:45:50 CDT(-0500)] <colinclark> you too, alexn1

[12:46:58 CDT(-0500)] <michelled> colinclark: I guess from a longer term perspective I like the idea of alexn1's first suggestion, but since it is more work to implement it seems like going with this strategy is better

[12:48:08 CDT(-0500)] <michelled> alexn1: what do you think?

[12:55:24 CDT(-0500)] <alexn1> I like the first idea as well… it just I'm not sure what is going to happen to videoPlayer layout once we change toggleButton implementation. We might face lots of visual artifacts soon after we do it

[12:58:21 CDT(-0500)] <michelled> alexn1: I'm thinking that in the spirit of incremental, small change that we should go with the solution colinclark suggested for now

[12:59:05 CDT(-0500)] <michelled> alexn1: we can consider the questions of improving the moving ToggleButton up to Infusion in the future - particularly when we want to reuse it in another project

[12:59:16 CDT(-0500)] <alexn1> I also +1 the first option since toggleButton should be changed further (e.g. upcoming change to pass a tooltip as a component instead of its initialization in setUpToggleButton)

[12:59:37 CDT(-0500)] <alexn1> michelled: yes smaller incremental change would be much safer

[12:59:57 CDT(-0500)] <alexn1> but we should keep toggleButton on our horizon for the upcoming improvements

[13:00:03 CDT(-0500)] <alexn1> michelled: agreed

[13:59:29 CDT(-0500)] <colinclark> alexn1, michelled: Go for it

[13:59:34 CDT(-0500)] <colinclark> I'll review the pull request

[13:59:41 CDT(-0500)] <michelled> thx colinclark

[14:11:05 CDT(-0500)] <sgithens> colinclark: Is the regular meeting on tomorrow?

[14:17:36 CDT(-0500)] <colinclark> sgithens: yup

[14:26:33 CDT(-0500)] <alexn1> michelled, colinclark: let me know what you think https://github.com/fluid-project/videoPlayer/pull/45/files

[14:29:52 CDT(-0500)] <michelled> alexn1: I'm surprised you made all the buttons optional - don't we just want to make the full screen optional?

[14:30:48 CDT(-0500)] <alexn1> good observation. I just thought that if for any reason user wants to set an empty subcomponent for any of the buttons it won't be shown/rendered

[14:31:04 CDT(-0500)] <alexn1> although as I pointed out - I wanted your and colin's feedback on this (smile)

[14:31:10 CDT(-0500)] <michelled> I was also under the impression that you were going to use the optional class as the 'init' style instead of adding a not created style

[14:32:39 CDT(-0500)] <alexn1> another good point. I also thought that I would just use init but immediately found few issues. One of them that this init class is not present all the time and is present only when the button is not in a "pressed" state. Which means I need to write 2 rules for a button to overwrite optional class styling. (e.g. notpressed.optional and pressed.optional) in my CSS file

[14:33:02 CDT(-0500)] <alexn1> then it seems that every single button has its own custom init style class

[14:33:50 CDT(-0500)] <alexn1> which means I would have to write a 2 rules per button, for every button. Nothing against it but sounds as our CSS style sheet will be increased in sizes for those overwrite rules

[14:34:20 CDT(-0500)] <alexn1> personally not against it, I just made it through 1 class added to the markup of the toggleButton.

[14:34:58 CDT(-0500)] <alexn1> so wanted to know what you think about it. If you think that more CSS rules is better and declare optional css styling only for fullscreen button I will redo the code accordingly

[14:37:35 CDT(-0500)] <alexn1> colinclark: what do you think (smile) ?

[14:38:06 CDT(-0500)] <michelled> alexn1: how does the button get to pressed state when it isn't visible? is it by clicking where you know it to be?

[14:39:35 CDT(-0500)] <alexn1> actually right now the button does not have a pressed state if it is invisible…. to be more precise if toggleButton is an empty component then there is no model associated with the button and it would have display:none in the markup

[14:39:44 CDT(-0500)] <colinclark> just catching up

[14:42:50 CDT(-0500)] <colinclark> Ok, alexn1 and michelled

[14:43:04 CDT(-0500)] <colinclark> This isn't really what I was thinking of

[14:43:23 CDT(-0500)] <colinclark> The idea was not to modify the implementation of the ToggleButton component at all

[14:43:42 CDT(-0500)] <colinclark> but rather to use an existing aspect of its lifecycle to what you need

[14:44:03 CDT(-0500)] <colinclark> the key aspect of this lifecycle is the fact that there is this "init" style which gets set upon initialization of the component

[14:44:37 CDT(-0500)] <colinclark> and use that style to make this particular ToggleButton-the full screen button-visible

[14:44:53 CDT(-0500)] <colinclark> So I agree with michelled that only the toggle button should be made optional

[14:45:28 CDT(-0500)] <colinclark> And all this can be done simply by adjusting a bit of CSS and adding the "optional" class name to the appropriate button element in the markup

[14:46:07 CDT(-0500)] <colinclark> this notion of "not created yet" is far too specific and unnecessary

[14:46:17 CDT(-0500)] <alexn1> colinclark: ok got it

[14:46:20 CDT(-0500)] <colinclark> great

[14:46:23 CDT(-0500)] <colinclark> go for it

[14:46:40 CDT(-0500)] <alexn1> let me change the code to be what you are saying. give me few minutes I will be fast as a lightning

[14:47:32 CDT(-0500)] <colinclark> no problem

[15:01:27 CDT(-0500)] <alexn1> colinclark, michelled: changed https://github.com/fluid-project/videoPlayer/pull/45/files now I'm using combination of optional css class and init class for the fullscreen button to be present in the layout

[15:01:51 CDT(-0500)] <alexn1> I tested in Opera and IE9 and both of them do not show the button. Also tested with a screen readers and they do not read out the hidden button

[15:01:58 CDT(-0500)] <alexn1> tested included in the pull request

[15:02:23 CDT(-0500)] <colinclark> out of curiosity, why did you scope your "optional" style as button.fl-videoPlayer-optional instead of just using a class?

[15:02:59 CDT(-0500)] <alexn1> oh because there is a stronger rule

[15:03:12 CDT(-0500)] <alexn1> *looking for it

[15:04:14 CDT(-0500)] <alexn1> .fl-videoPlayer-controller-buttons * {

[15:04:14 CDT(-0500)] <alexn1>     display: inline;

[15:04:14 CDT(-0500)] <alexn1> }

[15:04:16 CDT(-0500)] <alexn1> this is the one

[15:05:41 CDT(-0500)] <alexn1> colinclark: are you thinking to use something similar like

[15:05:41 CDT(-0500)] <alexn1> .fl-videoPlayer-controller-buttons .fl-videoPlayer-optional {

[15:05:42 CDT(-0500)] <alexn1> display: none;

[15:05:42 CDT(-0500)] <alexn1> }

[15:05:44 CDT(-0500)] <alexn1> instead

[15:06:00 CDT(-0500)] <alexn1> actually the one ^ might be better

[15:06:02 CDT(-0500)] <colinclark> not in particular

[15:06:41 CDT(-0500)] <colinclark> I was simply hoping you could avoid having to scope the "optional" style by element type, so that it would be potentially usable by other types of elements

[15:07:01 CDT(-0500)] <colinclark> are you sure it doesn't work if you take off the type part of those two selectors?

[15:07:57 CDT(-0500)] <alexn1> well the second rule would work and it does not have a type in it

[15:08:16 CDT(-0500)] <alexn1> it only has this additional css class .fl-videoPlayer-controller-buttons

[15:09:26 CDT(-0500)] <colinclark> Just out of curiosity, have you actually tried it?

[15:09:32 CDT(-0500)] <alexn1> yes

[15:09:59 CDT(-0500)] <alexn1> I tired .fl-videoPlayer-controller-buttons .fl-videoPlayer-optional {

[15:09:59 CDT(-0500)] <alexn1>     display: none;

[15:09:59 CDT(-0500)] <alexn1> }

[15:10:00 CDT(-0500)] <alexn1> it worked

[15:10:14 CDT(-0500)] <alexn1> I also tried just .fl-videoPlayer-optional {

[15:10:14 CDT(-0500)] <alexn1> display: none;

[15:10:14 CDT(-0500)] <alexn1> }

[15:10:18 CDT(-0500)] <alexn1> and it does not work

[15:10:35 CDT(-0500)] <colinclark> I wonder why it worked for me

[15:10:36 CDT(-0500)] <colinclark> hmm

[15:12:00 CDT(-0500)] <colinclark> So two other things

[15:12:06 CDT(-0500)] <alexn1> oh I know why

[15:12:14 CDT(-0500)] <alexn1> it is the position of the rule

[15:12:28 CDT(-0500)] <alexn1> I tried to add the rule at the end of my CSS file and it just worked

[15:12:46 CDT(-0500)] <alexn1> but I start modify the rule at the place in my pull request it won't be applied

[15:12:53 CDT(-0500)] <colinclark> yes, order matters in CSS

[15:13:18 CDT(-0500)] <colinclark> michelled: Any opinions on this one?

[15:13:25 CDT(-0500)] <colinclark> alexn1: In the meantime, two other things

[15:13:42 CDT(-0500)] <alexn1> well .fl-videoPlayer-optional {

[15:13:42 CDT(-0500)] <alexn1>     display: none;

[15:13:42 CDT(-0500)] <alexn1> } looks as a stronger rule than fl-videoPlayer-controller-buttons * {

[15:13:49 CDT(-0500)] <colinclark> Line 45 of VideoPlayer.js--you're still putting this "feature" in the features block

[15:13:59 CDT(-0500)] <colinclark> Is there a reason?

[15:14:12 CDT(-0500)] <alexn1> I do not know why the order even matters here when the rule is simply stronger

[15:14:13 CDT(-0500)] <colinclark> Now that you've changed the strategy for how we deal with the toggle button

[15:14:17 CDT(-0500)] <alexn1> line 45 let me take a look

[15:14:30 CDT(-0500)] <colinclark> 2. Do you think "noFullScreenMode" is sufficiently descriptive of what this feature actually is?

[15:15:34 CDT(-0500)] <alexn1> colinclark: it is still a feature just as html5 one

[15:15:50 CDT(-0500)] <colinclark> which issue are you referring to?

[15:16:26 CDT(-0500)] <alexn1> concerning line 45 − 46. that noFullScreenMode is still a feature

[15:17:04 CDT(-0500)] <colinclark> sure

[15:17:10 CDT(-0500)] <colinclark> But do we want it to be?

[15:17:17 CDT(-0500)] <alexn1> we wanted to develop a strategy for moving html5 and noFullScreenMode features out of there but it should better be a separate JIRA for this work. Just we always trying to split bigger problems into smaller ones

[15:17:46 CDT(-0500)] <colinclark> So where's the other JIRA? Where's the pull request to go with that?

[15:18:02 CDT(-0500)] <colinclark> We don't need to get pedantic--if we're removing the use of something, it's safe to simply remove it as well

[15:18:49 CDT(-0500)] <alexn1> oh… I think we were talking about this just recently. No concrete actions were taken yet towards those features. But yes there should be a JIRA and a pull request to resolve it

[15:18:52 CDT(-0500)] <alexn1> at some point

[15:19:07 CDT(-0500)] <colinclark> Okay

[15:19:25 CDT(-0500)] <colinclark> features.noFullScreenMode used in the code any more?

[15:19:35 CDT(-0500)] <alexn1> only for a fullscreen button

[15:19:42 CDT(-0500)] <alexn1> and its tests

[15:19:43 CDT(-0500)] <colinclark> where is it used?

[15:20:25 CDT(-0500)] <colinclark> is it ever used by calling fluid.hasFeature("fluid.browser.noFullScreenMode")?

[15:20:48 CDT(-0500)] <alexn1> it is used in the demands block as fluid.browser.noFullScreenMode

[15:21:35 CDT(-0500)] <colinclark> That's the only place where it's used?

[15:22:23 CDT(-0500)] <alexn1> I'm pretty sure so + tests

[15:22:37 CDT(-0500)] <colinclark> Okay

[15:22:53 CDT(-0500)] <colinclark> So why would you add it to this hasFeature() stuff at line 45?

[15:23:02 CDT(-0500)] <colinclark> If it's only being used the way it should be--via a demands block?

[15:23:31 CDT(-0500)] <alexn1> colinclark: legacy !

[15:23:35 CDT(-0500)] <alexn1> no need it to be there

[15:23:37 CDT(-0500)] <alexn1> I will remove it

[15:23:39 CDT(-0500)] <colinclark> thanks

[15:23:40 CDT(-0500)] <alexn1> just kidding

[15:24:03 CDT(-0500)] <colinclark> the next question is if we think "hasFullScreenMode" is appropriately descriptive

[15:24:22 CDT(-0500)] <colinclark> I'm a bit worried about it myself, since browsers have different types of full screen modes

[15:24:38 CDT(-0500)] <colinclark> one for the browser chrome itself (those two litter arrows in the top right corner of every window)

[15:24:50 CDT(-0500)] <colinclark> or are they in fact the same thing?

[15:24:54 CDT(-0500)] <colinclark> perhaps they are

[15:25:27 CDT(-0500)] <alexn1> I think those 2 arrows are OS X specific

[15:25:59 CDT(-0500)] <alexn1> because when I open videoPlayer in Chrome in Windows those arrows should not be there

[15:26:15 CDT(-0500)] <alexn1> *if we are talking about the same thing of course (smile)

[15:27:12 CDT(-0500)] <alexn1> have not used Windows in years… let me check if those arrows are present there… but I feel a little bit embarrassed not to be sure about it (smile)

[15:28:08 CDT(-0500)] <alexn1> in OS X I'm not sure if this full screen feature is the same as a browser full screen as well

[15:28:34 CDT(-0500)] <colinclark> My advice, alexn1--the place to look for these kinds of things is typically MDN

[15:28:45 CDT(-0500)] <colinclark> This is, for example, very helpful information:

[15:28:46 CDT(-0500)] <colinclark> https://developer.mozilla.org/en-US/docs/DOM/Using_full-screen_mode

[15:28:58 CDT(-0500)] <colinclark> Something quite notable struck me, reading it

[15:29:11 CDT(-0500)] <colinclark> You'll see that ANY element can have requestFullScreen() called on it

[15:29:17 CDT(-0500)] <colinclark> and the result is to show only that element

[15:29:58 CDT(-0500)] <colinclark> As a fun experiment, I changed the VideoPlayer's fullscreen() method to call requestFullScreen() on the entire Video Player container, rather than just the video element

[15:30:10 CDT(-0500)] <colinclark> and voila, the video plus our controls!

[15:30:23 CDT(-0500)] <alexn1> fascinating

[15:31:06 CDT(-0500)] <colinclark> So from this, it's clear that there is one full screen mode

[15:31:13 CDT(-0500)] <colinclark> rather than something specific to media elements, as I had thought

[15:32:30 CDT(-0500)] <colinclark> yura: Do you have a quick second for a question?

[15:32:50 CDT(-0500)] <yura> colinclark: sure

[15:33:10 CDT(-0500)] <colinclark> alexn1's pull request here has one curious aspect to it that I thought you might have some thoughts on.

[15:33:14 CDT(-0500)] <colinclark> https://github.com/fluid-project/videoPlayer/pull/45/files

[15:33:23 CDT(-0500)] <colinclark> Notice how he has flipped a feature detection around

[15:33:40 CDT(-0500)] <colinclark> on line 40 of VideoPlayer.js

[15:33:46 CDT(-0500)] <colinclark> and for good reason

[15:34:15 CDT(-0500)] <colinclark> there's a demands block that replaces a particular instance of a toggle button with an emptySubcomponent

[15:34:36 CDT(-0500)] <colinclark> but it does feel odd to have "reverse feature detection"

[15:34:58 CDT(-0500)] <colinclark> is there a way, through nicknames or something else, that we could write this demands block differently?

[15:37:45 CDT(-0500)] <yura> well i wonder if another alternative could be embedding fullScreenButton component in context of [controllers, fullScreenMode]

[15:37:47 CDT(-0500)] <yura> ?

[15:37:55 CDT(-0500)] <yura> and only then

[15:38:23 CDT(-0500)] <colinclark> yes, i thought of that

[15:38:28 CDT(-0500)] <colinclark> good point

[15:38:39 CDT(-0500)] <colinclark> but given that demands blocks aren't really overridable

[15:38:52 CDT(-0500)] <colinclark> do you imagine that this will cause a problem for users customizing the VideoPlayer?

[15:38:59 CDT(-0500)] <colinclark> Or do you think that's not a big deal in this case?

[15:40:09 CDT(-0500)] <yura> one thing confusing is calling a variabel noFullScreenMode there since it actually takes value of "fullScreenModeAvailable" on lines 39-40

[15:40:16 CDT(-0500)] <alexn1> colinclark: what exactly did you change so that you have a videoplayer in a full screen with our controls because it does not work for me :S

[15:41:33 CDT(-0500)] <yura> colinclark: ya you are right, you d have to write a stronger rule to override that demands block

[15:41:35 CDT(-0500)] <colinclark> yura: yes

[15:42:09 CDT(-0500)] <colinclark> alexn1: I just changed videoEl to be that.container[0] instead, as a quick test

[15:43:16 CDT(-0500)] <yura> colinclark: to be honest it feels fine to do that, since we have no DELETE option within demands.

[15:43:27 CDT(-0500)] <yura> which is what this thing essentially is

[15:43:37 CDT(-0500)] <colinclark> yes

[15:43:55 CDT(-0500)] <colinclark> it seems fine to do which thing specifically, yura?

[15:45:32 CDT(-0500)] <yura> to provide demands block with delete instruction like that where you have a flag that there's no full screen mode available

[15:46:13 CDT(-0500)] <yura> oh well

[15:46:17 CDT(-0500)] <colinclark> ok, fair enough

[15:46:23 CDT(-0500)] <colinclark> I appreciate your advice

[15:46:24 CDT(-0500)] <yura> i guess you can reverse this too

[15:46:41 CDT(-0500)] <yura> e.g. have fullScreenMode in static environment

[15:46:58 CDT(-0500)] <yura> that way your default demands will be with 2 contexts

[15:47:04 CDT(-0500)] <yura> where non-default one will be with 1

[15:47:48 CDT(-0500)] <colinclark> In this particular case, what would we target the demands block to?

[15:48:11 CDT(-0500)] <colinclark> to the Controllers component, I guess?

[15:48:18 CDT(-0500)] <yura> ya

[15:48:23 CDT(-0500)] <colinclark> as it is now

[15:48:37 CDT(-0500)] <yura> the thing here actually it looks like you have 1 demands block ?

[15:48:40 CDT(-0500)] <yura> is that right ?

[15:48:46 CDT(-0500)] <colinclark> yes, that's right

[15:48:47 CDT(-0500)] <colinclark> a

[15:48:57 CDT(-0500)] <colinclark> a single demands block overriding the component's options

[15:49:04 CDT(-0500)] <colinclark> alexn1: Any interest in seeing how it looks to flip it around?

[15:49:08 CDT(-0500)] <yura> this will not work with 1 demands block i think

[15:49:44 CDT(-0500)] <alexn1> colinclark yura: would be interesting to see it

[15:49:53 CDT(-0500)] <colinclark> it seems to, but what's your rationale, yura?

[15:50:15 CDT(-0500)] <colinclark> alexn1: Go for it. Express the feature in the positive and see what the two competing demands blocks will look like

[15:50:38 CDT(-0500)] <yura> you ll need these 2 http://pastie.org/4703959 but then it is 2 demands instead of 1

[15:51:02 CDT(-0500)] <alexn1> interesting....

[15:51:10 CDT(-0500)] <alexn1> I will give it a shot

[15:52:14 CDT(-0500)] <colinclark> alexn1: Here is an example of other similar feature checks in Infusion: https://github.com/fluid-project/infusion/blob/master/src/webapp/framework/enhancement/js/ProgressiveEnhancement.js

[15:52:20 CDT(-0500)] <colinclark> So you might choose to follow this naming convention

[15:52:30 CDT(-0500)] <colinclark> fluid.browser.supports<feature>

[15:52:51 CDT(-0500)] <colinclark> yura: thanks so much for your help

[15:53:02 CDT(-0500)] <colinclark> Can I call you Dr. Demands Blocks

[15:53:03 CDT(-0500)] <colinclark> ?

[15:53:14 CDT(-0500)] <yura> hah

[15:53:15 CDT(-0500)] <alexn1> or Dr D

[16:00:07 CDT(-0500)] <alexn1> yura: tried the code you provided but it does not seem to work

[16:17:20 CDT(-0500)] <thealphanerd> colinclark: you see this https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/

[16:17:32 CDT(-0500)] <colinclark> i did yes

[16:17:35 CDT(-0500)] <colinclark> very cool

[16:22:29 CDT(-0500)] <thealphanerd> indeed

[16:22:39 CDT(-0500)] <thealphanerd> 6 kb/s bit rate

[16:22:40 CDT(-0500)] <thealphanerd> lol

[16:22:55 CDT(-0500)] <thealphanerd> really broad spectrum of use

[16:23:30 CDT(-0500)] <thealphanerd> you think this will effect audio api?

[16:50:18 CDT(-0500)] <colinclark> i doubt it, no, thealphanerd

[16:50:21 CDT(-0500)] <colinclark> but it looks like a great codec

[16:50:24 CDT(-0500)] <thealphanerd> btw

[16:50:26 CDT(-0500)] <thealphanerd> https://support.apple.com/downloads/Apple_ProRes_QuickTime_Decoder_1_0_for_Windows

[16:50:27 CDT(-0500)] <thealphanerd> oooppps

[16:50:29 CDT(-0500)] <thealphanerd> wrong copy pasta

[16:50:33 CDT(-0500)] <colinclark> how is stanford?

[16:50:35 CDT(-0500)] <thealphanerd> http://chunkhost.com/r/alphaChunk

[16:50:37 CDT(-0500)] <thealphanerd> referal link

[16:50:43 CDT(-0500)] <thealphanerd> free 128 meg vps for life

[16:50:56 CDT(-0500)] <thealphanerd> 3 gigs space, 128 megs ram

[16:51:17 CDT(-0500)] <thealphanerd> get to stanford on thursday

[16:51:26 CDT(-0500)] <thealphanerd> very excited

[16:51:26 CDT(-0500)] <thealphanerd> (big grin)