fluid-work IRC Logs-2008-08-12

Owned by Fluid IRC Log Bot
Last updated: Aug 12, 2008Version comment
8 min read

[02:06:51 EDT(-0400)] * apetro-_ (n=apetro@ip68-98-37-188.ph.ph.cox.net) has joined #fluid-work
[08:09:55 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:32:58 EDT(-0400)] * jhung (n=Administ@H236.C194.cci.switchworks.net) has joined #fluid-work
[08:54:29 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:36:48 EDT(-0400)] * athena7 (n=athena7@adsl-76-248-151-157.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[10:12:18 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:33:57 EDT(-0400)] * apetro-_ (n=apetro@ip68-98-37-188.ph.ph.cox.net) has joined #fluid-work
[10:59:35 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:14:00 EDT(-0400)] * jhung (n=Administ@H236.C194.cci.switchworks.net) has joined #fluid-work
[11:25:22 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[11:39:09 EDT(-0400)] <Bosmon> Ping
[12:20:30 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-104.LIPS.Berkeley.EDU) has joined #fluid-work
[12:35:06 EDT(-0400)] * apetro-_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[13:14:46 EDT(-0400)] <Bosmon> Droser!
[13:14:47 EDT(-0400)] <Bosmon> a
[13:18:11 EDT(-0400)] * apetro-- (n=apetro@12.164.139.7) has joined #fluid-work
[13:33:43 EDT(-0400)] * apetro--_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[13:35:45 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-104.LIPS.Berkeley.EDU) has joined #fluid-work
[13:44:27 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[13:47:38 EDT(-0400)] <jacobfarber1> Bosmon: did you build it (Drosera)?
[14:09:38 EDT(-0400)] <Bosmon> No, unfortunately little time for exploration at the moment
[14:09:48 EDT(-0400)] <Bosmon> Also the day I get a Mac Satan skates to work
[14:16:21 EDT(-0400)] <jacobfarber1> (smile)
[14:16:38 EDT(-0400)] <jacobfarber1> i would be skinned alive if I were to say that!
[14:17:05 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:32:30 EDT(-0400)] * apetr_u_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[14:42:18 EDT(-0400)] <Bosmon> colinclark: (or other) - we have an opportunity at this point to do something about http://issues.fluidproject.org/browse/FLUID-132 and http://issues.fluidproject.org/browse/FLUID-981
[14:42:30 EDT(-0400)] <Bosmon> I mean, at the moment, this "hover" style seems to be mainly used for updating the mouse cursor
[14:42:40 EDT(-0400)] <Bosmon> And the problem with it, is that it seems to be somewhat defined in the wrong way
[14:42:46 EDT(-0400)] <Bosmon> That is, it is a simple "style name"
[14:43:01 EDT(-0400)] <Bosmon> Whereas from what I can see, the only sensible way to implemented it would be a "synthesized style rule"
[14:43:02 EDT(-0400)] <colinclark> Bosmon: Let me take a look.
[14:43:06 EDT(-0400)] <anastasiac> yes, it is basically for styling - more than just the cursor, but styling
[14:43:22 EDT(-0400)] * colinclark is single threaded and stuck using setTimeout() a lot. (tongue)
[14:43:24 EDT(-0400)] <Bosmon> Since you cannot "invent" a style name which automatically applies a rule "to element and all descendents"
[14:45:00 EDT(-0400)] <Bosmon> Really this should be a "style rule" which jams in a "hover" pseudoclass
[14:45:10 EDT(-0400)] <Bosmon> It would a) actually work, and b) be much less CPU intensive...
[14:45:22 EDT(-0400)] <Bosmon> But I'm not quite sure how we would set about doing this (tongue)
[14:45:34 EDT(-0400)] <Bosmon> Perhaps something degrading like a raw jQuery.css (tongue)
[14:46:47 EDT(-0400)] <Bosmon> I mean, perhaps this really is one of those situations where we could simply advise our users to "structure their CSS better" (tongue)
[14:47:48 EDT(-0400)] <Bosmon> The thing which has the role of ".orderable-hover" should simplly be statically applied to the grab Handle, and it will have to be the user's business to pseudoclass it with "hover"
[14:50:24 EDT(-0400)] <Bosmon> Well....
[14:50:34 EDT(-0400)] <Bosmon> ?
[14:50:35 EDT(-0400)] <Bosmon> (tongue)
[14:53:38 EDT(-0400)] <colinclark> maybe jacobfarber1 has some ideas.
[14:54:31 EDT(-0400)] <jacobfarber1> sorry, just coming into this one
[14:54:45 EDT(-0400)] <Bosmon> My proposal is that we simply trash this entire "hover" aspect of the Reorderer...
[14:54:55 EDT(-0400)] <Bosmon> Since it is something the users can do much more quickly and directly for themselves
[14:55:19 EDT(-0400)] <jacobfarber1> as a css effect?
[14:55:22 EDT(-0400)] <Bosmon> Yes
[14:55:24 EDT(-0400)] <Bosmon> As one of those
[14:55:46 EDT(-0400)] <jacobfarber1> well....its something slated to be omptimized in the Fluid.States.css file....
[14:55:51 EDT(-0400)] <jacobfarber1> but there is nothing there yet...
[14:56:04 EDT(-0400)] <colinclark> jacobfarber1: tell us more about what you're thinking here
[14:56:05 EDT(-0400)] <colinclark> (smile)
[14:56:32 EDT(-0400)] <jacobfarber1> ok, so here is where we started with the idea http://wiki.fluidproject.org/display/fluid/Fluid+Component+Sample+Code
[14:56:58 EDT(-0400)] <jacobfarber1> where we collect all states (including this like hovers, disabled, etc )
[14:57:06 EDT(-0400)] <anastasiac> Bosmon, what do you mean by trashing the hover aspect since users can do it for themselves??
[14:57:20 EDT(-0400)] <Bosmon> I mean by simply asking them to write it as a CSS rule
[14:57:29 EDT(-0400)] <jacobfarber1> into a neat package to either modify or whatever
[14:57:32 EDT(-0400)] <Bosmon> The current behaviour is not only incredibly unreliable but also fantastically expensive in CPU
[14:57:42 EDT(-0400)] <jacobfarber1> whats the current way?
[14:57:47 EDT(-0400)] <jacobfarber1> through JS?
[14:57:50 EDT(-0400)] <Bosmon> yes
[14:57:52 EDT(-0400)] <jacobfarber1> ouch
[14:57:56 EDT(-0400)] <Bosmon> Indeed
[14:58:01 EDT(-0400)] <jacobfarber1> see ^
[14:58:19 EDT(-0400)] <anastasiac> ok, I need some catching up - are we not just talking about adding a class name while hovering, and removing it while not?
[14:58:26 EDT(-0400)] <Bosmon> Yes
[14:58:28 EDT(-0400)] <Bosmon> "just" that
[14:58:38 EDT(-0400)] <Bosmon> All the same, it is terrible compared to the alternative
[14:58:42 EDT(-0400)] <Bosmon> And it doesn't really work...
[14:58:46 EDT(-0400)] <jacobfarber1> so thats where Fluid.States.css hepls
[14:58:50 EDT(-0400)] <anastasiac> and what would the user do alternatively? how is this not a css rule?
[14:59:04 EDT(-0400)] <Bosmon> They would use the :hover pseudoselector
[14:59:14 EDT(-0400)] <Bosmon> Which, being serviced inside the browser is fantastically more efficient
[14:59:37 EDT(-0400)] <anastasiac> ah, ok, now I'm understanding your suggestion
[14:59:42 EDT(-0400)] <Bosmon> I mean, just hovering over the Jquery-tabs example, we generally get the wrong cursor more often than not at present
[14:59:42 EDT(-0400)] <anastasiac> how is this different than adding a class name?
[15:00:07 EDT(-0400)] <Bosmon> Well, it is a bit awkward, since it would become more of a "recommendation" more than anything
[15:00:22 EDT(-0400)] <Bosmon> For example, look at http://issues.fluidproject.org/browse/FLUID-132
[15:00:57 EDT(-0400)] <Bosmon> This is caused because adding a simple class name to an element isn't sufficient to get the effect we are after, if the element itself is composite
[15:01:10 EDT(-0400)] <jacobfarber1> you need to see this page... we're working on this http://wiki.fluidproject.org/display/fluid/Fluid+Component+Sample+Code
[15:01:18 EDT(-0400)] <Bosmon> And this is the sort of thing that the user could far more effectively take care of themselves, by writing the proper alternation in the CSS rule
[15:01:22 EDT(-0400)] <jacobfarber1> and we can utilize pseudo-selectors
[15:01:33 EDT(-0400)] * anastasiac looks at jacobfarber1's link
[15:01:40 EDT(-0400)] <Bosmon> jacobfarber1: What are we doing about the IE6 issue? (smile)
[15:02:03 EDT(-0400)] <jacobfarber1> :hover on non <a> els?
[15:02:07 EDT(-0400)] <jacobfarber1> that one?
[15:02:11 EDT(-0400)] <Bosmon> No
[15:02:14 EDT(-0400)] <Bosmon> Multiple class selection bug
[15:02:22 EDT(-0400)] <jacobfarber1> oh, the chaining one
[15:02:51 EDT(-0400)] <jacobfarber1> as far as I can tell, with proper inheritance and order in CSS declarations, you can micick it somewhat
[15:03:00 EDT(-0400)] <jacobfarber1> *mimick
[15:03:48 EDT(-0400)] <Bosmon> jacobfarber1: So how will our "recommendation", say for a Reorderer, be expressed?
[15:03:50 EDT(-0400)] <jacobfarber1> or, of course
[15:03:58 EDT(-0400)] <jacobfarber1> the ugly way
[15:04:06 EDT(-0400)] <jacobfarber1> would be to write somehting explicit (sad)
[15:04:13 EDT(-0400)] <Bosmon> For example, say in "sortable styled todo list" we have this definition
[15:04:14 EDT(-0400)] <Bosmon> .orderable-hover{
[15:04:15 EDT(-0400)] <Bosmon> background-color: lightyellow;
[15:04:15 EDT(-0400)] <Bosmon> cursor: move;
[15:04:15 EDT(-0400)] <Bosmon> }
[15:05:01 EDT(-0400)] <Bosmon> My plan is, at the moment, to simply rename this style .orderable-grabhandle
[15:05:06 EDT(-0400)] <Bosmon> And tell people to slap a :hover in it
[15:05:18 EDT(-0400)] <Bosmon> Or even, not to give it any name at all (tongue)
[15:05:18 EDT(-0400)] <jacobfarber1> but it wont have any effect in IE6
[15:05:19 EDT(-0400)] <Bosmon> I don't know
[15:05:31 EDT(-0400)] <Bosmon> IE6 doesn't support :hover?
[15:05:41 EDT(-0400)] <jacobfarber1> not on non <a> els
[15:05:44 EDT(-0400)] <Bosmon> blech
[15:05:48 EDT(-0400)] <jacobfarber1> yup
[15:05:56 EDT(-0400)] <Bosmon> Kicks us in the nuts twice...
[15:06:03 EDT(-0400)] <jacobfarber1> you need to wrap them inside a block <a> to "cheat"
[15:06:09 EDT(-0400)] <Bosmon> Any a?
[15:06:14 EDT(-0400)] <jacobfarber1> yes
[15:06:19 EDT(-0400)] <Bosmon> Even an <a name will do?
[15:06:33 EDT(-0400)] <jacobfarber1> I think so
[15:06:36 EDT(-0400)] <Bosmon> OK
[15:06:40 EDT(-0400)] <Bosmon> Well I suggest we do that then
[15:06:46 EDT(-0400)] <jacobfarber1> but isnt that a little dangerous?
[15:06:54 EDT(-0400)] <Bosmon> Using IE6 is in itself a little dangerous (smile)
[15:06:57 EDT(-0400)] <Bosmon> And more than a little...
[15:07:04 EDT(-0400)] <jacobfarber1> (smile)
[15:07:05 EDT(-0400)] <jacobfarber1> but
[15:07:15 EDT(-0400)] <jacobfarber1> what if they overwrite your <a> definition?
[15:07:18 EDT(-0400)] <jacobfarber1> for example
[15:07:20 EDT(-0400)] <Bosmon> What do you mean?
[15:07:27 EDT(-0400)] <jacobfarber1> they force your <a> to render inline
[15:07:34 EDT(-0400)] <jacobfarber1> when you would need it to be a block
[15:07:34 EDT(-0400)] <Bosmon> ?!
[15:08:25 EDT(-0400)] <Bosmon> Then we would have to trounce them by writing a more specific rule...
[15:08:26 EDT(-0400)] <Bosmon> (tongue)
[15:08:39 EDT(-0400)] <jacobfarber1> # overwrites . anytime
[15:08:46 EDT(-0400)] <Bosmon> "I see"
[15:09:01 EDT(-0400)] <jacobfarber1> so, you COULD write something tricksy though
[15:09:12 EDT(-0400)] <Bosmon> All the same, we need to find some way of doing this using CSS (smile)
[15:09:30 EDT(-0400)] <Bosmon> Making the entire world suffer from a manual hover event handler just because of IE6 is ridiculous
[15:09:43 EDT(-0400)] <Bosmon> Added to the fact that, it just doesn't work (tongue)
[15:09:47 EDT(-0400)] <jacobfarber1> actually
[15:09:56 EDT(-0400)] <jacobfarber1> "!important" may help out with this
[15:10:03 EDT(-0400)] <Bosmon> OK
[15:10:05 EDT(-0400)] <jacobfarber1> maybe you could trounce all other rules
[15:10:09 EDT(-0400)] <jacobfarber1> no matter what
[15:10:24 EDT(-0400)] <jacobfarber1> but that still doesnt gurantee you a desired effect
[15:10:27 EDT(-0400)] <Bosmon> The final wrinkle will be...
[15:10:30 EDT(-0400)] <Bosmon> Where will this CSS be written
[15:10:52 EDT(-0400)] <Bosmon> All I can think of right now is something completely disgraceful, as to synthesise it by hand and then inject it into the document
[15:12:21 EDT(-0400)] <jacobfarber1> help me understand - all this to avoid swapping classnames?
[15:12:59 EDT(-0400)] <Bosmon> Partly that
[15:13:07 EDT(-0400)] <Bosmon> And partly the fact that the event handler just isn't reliable enough
[15:13:13 EDT(-0400)] <jacobfarber1> oh
[15:13:13 EDT(-0400)] <Bosmon> Or quick enough
[15:13:22 EDT(-0400)] <Bosmon> And doesn't do the right thing (smile)
[15:13:36 EDT(-0400)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-132 is caused by the fact that the rule does not apply to nested elements
[15:13:48 EDT(-0400)] <Bosmon> Sorry, I don't mean that one
[15:14:03 EDT(-0400)] <Bosmon> I mean this one
[15:14:04 EDT(-0400)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-981
[15:14:20 EDT(-0400)] <Bosmon> The text is on a nested element
[15:14:25 EDT(-0400)] <Bosmon> And so the cursor rule doesn't apply to it
[15:14:50 EDT(-0400)] <jacobfarber1> so, is there no way to re-write the rule to be properly inclusive?
[15:15:06 EDT(-0400)] <Bosmon> yes, there is
[15:15:11 EDT(-0400)] <Bosmon> But who would do this rewriting?
[15:15:18 EDT(-0400)] <Bosmon> Surely the user had best do it themselves
[15:15:29 EDT(-0400)] <jacobfarber1> very true
[15:15:39 EDT(-0400)] <Bosmon> At it stands, all we offer them is the affordance to slap a classname on an element at an unreliably chosen moment (tongue)
[15:16:12 EDT(-0400)] <Bosmon> And at the moment burn 15ms a throw to do it (tongue)
[15:16:46 EDT(-0400)] <Bosmon> Actually, closer to 20....
[15:16:57 EDT(-0400)] <jacobfarber1> wow....that doesnt sound right at all
[15:17:16 EDT(-0400)] <Bosmon> Well, I was just going to optimise it to use the new "caching Dom binder" that Colin and I have discussed
[15:17:21 EDT(-0400)] <Bosmon> But then looked at all these other bugs
[15:17:30 EDT(-0400)] <Bosmon> And it occurs to me that we are polishing a turd here (tongue)
[15:17:51 EDT(-0400)] <jacobfarber1> always a master of eloquence
[15:18:21 EDT(-0400)] <Bosmon> At the moment the portal sample burns a jQuery object on every hover
[15:18:42 EDT(-0400)] <jacobfarber1> a new one each time?
[15:19:07 EDT(-0400)] <Bosmon> Yes
[15:19:14 EDT(-0400)] <Bosmon> I would optimise this now to use the cache
[15:19:18 EDT(-0400)] <Bosmon> But it just doesn't seem worth it
[15:19:23 EDT(-0400)] <Bosmon> IMO this entire functionality should go...
[15:19:52 EDT(-0400)] <jacobfarber1> to be sure I understand you .... this is in the hover/avatar effect?
[15:20:00 EDT(-0400)] <Bosmon> Not even the avatar
[15:20:03 EDT(-0400)] <Bosmon> Just hovering over the titlebar
[15:20:14 EDT(-0400)] <jacobfarber1> ohhh
[15:20:16 EDT(-0400)] <Bosmon> Currently is meant to have the effect of causing a style change.... that of turning the cursor to "move" (tongue)
[15:20:32 EDT(-0400)] <Bosmon> Yes, just for general reference to everyone, a JQuery.find typically burns 15ms
[15:20:34 EDT(-0400)] <jacobfarber1> that should happen in a fraction
[15:20:40 EDT(-0400)] <Bosmon> So think twice before putting these in event loops (tongue)
[15:21:17 EDT(-0400)] <Bosmon> What kind of "should" is this, jacobfarber1? (tongue)
[15:22:03 EDT(-0400)] <jacobfarber1> the effect of finding hover target (in this case the title bar) and changing the cursor
[15:22:08 EDT(-0400)] <Bosmon> Yes
[15:22:33 EDT(-0400)] <jacobfarber1> does the titlebar have an event handler on it?
[15:22:37 EDT(-0400)] <Bosmon> Yes
[15:22:39 EDT(-0400)] <Bosmon> We put them there
[15:22:47 EDT(-0400)] <jacobfarber1> and the event handler is this slow??
[15:22:58 EDT(-0400)] <Bosmon> Yes
[15:24:57 EDT(-0400)] <Bosmon> And it also suffers from this bug
[15:24:58 EDT(-0400)] <Bosmon> http://issues.fluidproject.org/browse/FLUID-132
[15:25:15 EDT(-0400)] <Bosmon> Although to be fair, a hover pseudoclass might also suffer from this
[15:25:22 EDT(-0400)] <Bosmon> But I would guess it would be less likely...
[15:25:43 EDT(-0400)] <jacobfarber1> does the above bug happen in all browsers?
[15:25:58 EDT(-0400)] <Bosmon> Browsers have never been terribly "smart" about detecting the case where an element is autonomously moved from under the mouse pointer, rather than the pointer moving from over it (tongue)
[15:25:59 EDT(-0400)] <Bosmon> I don't know
[15:26:08 EDT(-0400)] <Bosmon> It was reported before Justin_o's tenancy (smile)
[15:26:46 EDT(-0400)] <jacobfarber1> its usually on IE when it suffers from this "lack of intelligence" ... safari, opera and FF3 see pretty good following changes when the cursor is static and influential
[15:28:17 EDT(-0400)] <jacobfarber1> should I be able to see the delay here:
[15:28:18 EDT(-0400)] <jacobfarber1> http://build.fluidproject.org/fluid/sample-code/reorderer/portal/portal.html
[15:28:19 EDT(-0400)] <jacobfarber1> ?
[15:28:31 EDT(-0400)] <jacobfarber1> or at least profile it?
[15:28:33 EDT(-0400)] <Bosmon> Well, 15ms is not really very much in brain cycle terms
[15:28:36 EDT(-0400)] <Bosmon> But yes, you can profile it
[15:28:40 EDT(-0400)] <jacobfarber1> ok
[15:28:40 EDT(-0400)] <Bosmon> Just wave the mouse pointer around a lot
[15:28:51 EDT(-0400)] <Bosmon> And watch your CPU meter balloon up like crazy (smile)
[16:32:11 EDT(-0400)] * apetr_u (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[16:42:06 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[16:58:26 EDT(-0400)] * apetr_u- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[17:00:05 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[17:49:25 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-74.LIPS.Berkeley.EDU) has joined #fluid-work
[23:28:34 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279543344.dsl.bell.ca) has joined #fluid-work