fluid-work IRC Logs-2012-09-11

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

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