/
fluid-work IRC Logs-2008-10-08

fluid-work IRC Logs-2008-10-08

Oct 08, 2008

[01:02:27 EDT(-0400)] * apetro (n=apetro@h69-128-111-235.mdsnwi.dedicated.static.tds.net) has joined #fluid-work
[01:04:05 EDT(-0400)] * apetro- (n=apetro@h69-128-111-235.mdsnwi.dedicated.static.tds.net) has joined #fluid-work
[07:59:37 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-67-245.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[08:01:42 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:06:51 EDT(-0400)] * jacobfarber1 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:01:33 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[09:08:35 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work
[09:08:39 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined #fluid-work
[09:12:05 EDT(-0400)] * athena7 (n=athena7@adsl-75-58-126-207.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[09:25:19 EDT(-0400)] * apetro (n=apetro@72.33.23.236) has joined #fluid-work
[09:42:20 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined #fluid-work
[09:43:31 EDT(-0400)] * JohnNorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[09:47:51 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined #fluid-work
[09:56:54 EDT(-0400)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[10:00:26 EDT(-0400)] * apetro (n=apetro@72.33.23.236) has joined #fluid-work
[10:27:45 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined #fluid-work
[10:48:39 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:54:31 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:56:25 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work
[11:09:00 EDT(-0400)] <Bosmon> ping
[11:15:53 EDT(-0400)] <athena7> pong
[11:23:27 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[12:04:04 EDT(-0400)] <Bosmon> OK, so we are talking about the underlying architecture for Preferable II
[12:04:10 EDT(-0400)] <jacobfarber1> aha
[12:04:18 EDT(-0400)] <Bosmon> (17:01:49) Antranig: We were kicking around some ideas last night
[12:04:18 EDT(-0400)] <Bosmon> (17:02:06) Antranig: I'm not sure that all the effects of a "style wodge" can be achieved by simply a class name
[12:04:18 EDT(-0400)] <Bosmon> (17:02:09) Antranig: Though I could be wrong...
[12:04:18 EDT(-0400)] <Bosmon> (17:02:18) Antranig: Well, they could, in the case we had document control
[12:04:26 EDT(-0400)] <Bosmon> (16:57:57) Michelle : so I was thinking we'd be going the css class route
[12:04:26 EDT(-0400)] <Bosmon> (16:58:33) Michelle : meaning that jacob has put together groupings of classes that are 'high viz' etc and preferable would just need to know the class names
[12:04:55 EDT(-0400)] <jacobfarber1> this is a transcript?
[12:05:26 EDT(-0400)] <Bosmon> Yes
[12:06:03 EDT(-0400)] <jacobfarber1> is there anything I can help with here? Michelle is correct from what I gather....
[12:06:38 EDT(-0400)] * jrnorman (n=john@ginger.caret.cam.ac.uk) has joined #fluid-work
[12:06:54 EDT(-0400)] * apetro (n=apetro@72.33.23.236) has joined #fluid-work
[12:08:06 EDT(-0400)] <Bosmon> Well
[12:08:30 EDT(-0400)] <Bosmon> The issue is whether we really always expect to have sufficient control over the document structures that preferable is meant to be configuring over
[12:08:46 EDT(-0400)] <jacobfarber1> i wouldnt think so....
[12:09:03 EDT(-0400)] <Bosmon> I have checked in some of the style sheets that the BBC tool operates, and I'd be interested in your opinions on them
[12:09:12 EDT(-0400)] <jacobfarber1> do you have a link?
[12:09:14 EDT(-0400)] <Bosmon> For example https://source.fluidproject.org/svn/fluid/components/trunk/src/webapp/fluid-components/css/preferable/colour_scheme01.css
[12:09:30 EDT(-0400)] <Bosmon> I "grabbed" all the colour scheme ones (11) and started on the text size ones
[12:09:44 EDT(-0400)] <Bosmon> The point is that they randomly address all sorts of bits of selector space, not just those scoped to a particular classname
[12:10:10 EDT(-0400)] <Bosmon> So this suggests to me that the underlying model for Preferable II should really just be "named chunks of CSS"
[12:10:16 EDT(-0400)] <colinclark> I am distracted, but will try to occasionally clarify...
[12:10:19 EDT(-0400)] <colinclark> Or muddy things.
[12:10:31 EDT(-0400)] <colinclark> I think there are two scenarios that StyleAble will have to cope with:
[12:10:43 EDT(-0400)] <colinclark> 1. The best, is where we can assume the document conforms to our lovely new skinning system.
[12:10:59 EDT(-0400)] <colinclark> Such transformations become trivial, since it's just a matter of adjusting a class here or there.
[12:11:34 EDT(-0400)] <jacobfarber1> I would like to add something after your done...
[12:11:47 EDT(-0400)] <colinclark> 2. In cases where we've got a "foreign" document that doesn't conform to any real known structure or skin. In those cases, we're going to fail. The question is how we can fail decently, and provide a place for people who are adding StyleAble to their apps to give us additional "hints."
[12:11:53 EDT(-0400)] <colinclark> I'm done now.
[12:12:21 EDT(-0400)] <jacobfarber1> ok, after looking at the bbc stuff, heres my thoughts
[12:12:27 EDT(-0400)] <jacobfarber1> we already do something like this
[12:12:46 EDT(-0400)] <jacobfarber1> with fluid.layout and fluid.theme.core
[12:12:53 EDT(-0400)] <jacobfarber1> css files
[12:13:23 EDT(-0400)] <jacobfarber1> we use it for the most influential declarations
[12:13:53 EDT(-0400)] <jacobfarber1> that are meant to cascade and be inherited by everything within it
[12:14:36 EDT(-0400)] * ecochran (n=ecochran@adsl-70-137-130-162.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[12:15:08 EDT(-0400)] <jacobfarber1> note their use of !important in their files
[12:15:32 EDT(-0400)] <Bosmon> Yes
[12:15:37 EDT(-0400)] <jacobfarber1> this is a heavy handed approach
[12:15:48 EDT(-0400)] <Bosmon> So, my impression is, will our tool not be required to operate in both of these modes, sometimes?
[12:15:49 EDT(-0400)] <jacobfarber1> we use inheritance to do this for us
[12:16:00 EDT(-0400)] <jacobfarber1> i dont know
[12:16:11 EDT(-0400)] <jacobfarber1> i would think so
[12:16:50 EDT(-0400)] <michelled> yes, we would have to
[12:17:22 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[12:17:25 EDT(-0400)] <michelled> Gary just gave me his current design thinking which might help, let me put it in here
[12:17:28 EDT(-0400)] <Bosmon> But now, on the other hand, might we not also operate where our model was simply CSS class names?
[12:17:39 EDT(-0400)] <michelled> a couple of quick things
[12:17:39 EDT(-0400)] <michelled> it is not a "skinning" mechanism
[12:17:39 EDT(-0400)] <michelled> it is not a "color chooser free-for-all"
[12:17:39 EDT(-0400)] <michelled> it is primarily aimed at users with disabilities
[12:17:40 EDT(-0400)] <michelled> like low vision and imprecise pointing
[12:17:40 EDT(-0400)] <michelled> and there might be an edge case of low computer performance or connectivity
[12:17:41 EDT(-0400)] <michelled> i am thinking first iteration
[12:17:43 EDT(-0400)] <michelled> is a two pane interface
[12:17:45 EDT(-0400)] <michelled> pick from template thumbnails on the right
[12:17:47 EDT(-0400)] <michelled> see a preview of the transformation on the left
[12:17:49 EDT(-0400)] <michelled> submit when done
[12:17:51 EDT(-0400)] <michelled> oh, and there also was a question about the extent of the transformation
[12:17:53 EDT(-0400)] <michelled> it really needs to be cross platform
[12:17:55 EDT(-0400)] <michelled> or it may cause more problems than it solves
[12:17:57 EDT(-0400)] <michelled> so once picking a template
[12:17:59 EDT(-0400)] <michelled> it should transform all of sakai or uportal
[12:18:01 EDT(-0400)] <michelled> but that may not be reality
[12:18:03 EDT(-0400)] <michelled> depending on implementation
[12:18:05 EDT(-0400)] <michelled> 12:14 as far as i understand it
[12:18:14 EDT(-0400)] <Bosmon> 12:14?
[12:18:30 EDT(-0400)] <michelled> cut and paste time
[12:18:43 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work
[12:19:08 EDT(-0400)] <Bosmon> ok
[12:19:34 EDT(-0400)] <Bosmon> I am still thinking, looking at this app, that the BBC have thought through a few more issues than we have
[12:19:47 EDT(-0400)] <Bosmon> Given that we indeed expect that various aspects of the "transformation" to be orthogonal
[12:19:56 EDT(-0400)] <michelled> so, one thing we need to keep in the back of our minds is that it isn't only going to be css transformations that we deal with
[12:19:57 EDT(-0400)] <Bosmon> For example, text sizes, colours, spacing
[12:20:23 EDT(-0400)] <Bosmon> Even though it is not a "skinning" mechanism, these are still aspects that the user will want to choose independently
[12:20:47 EDT(-0400)] <jacobfarber1> Bosmon: for sure
[12:21:02 EDT(-0400)] <jacobfarber1> but notice they dont isolate every single thing into its own class name
[12:21:07 EDT(-0400)] <jacobfarber1> they do it within reason
[12:21:13 EDT(-0400)] <jacobfarber1> as we might
[12:21:20 EDT(-0400)] <Bosmon> Yes
[12:21:36 EDT(-0400)] <jacobfarber1> font sizes, basic color information, etc is all there already
[12:21:45 EDT(-0400)] <Bosmon> OK, so we are not actually thinking that a model where choice --> class name will ever be appropriate?
[12:22:05 EDT(-0400)] <jacobfarber1> it more like
[12:22:18 EDT(-0400)] <jacobfarber1> choice => "class + class + class"
[12:22:24 EDT(-0400)] <Bosmon> OK
[12:22:34 EDT(-0400)] <colinclark> Bosmon: Can you clarify something for me?
[12:22:35 EDT(-0400)] <michelled> or even choice => some javascript behaviour
[12:22:35 EDT(-0400)] <Bosmon> So it does seem that our basic model then is as it is for BBC
[12:23:00 EDT(-0400)] <michelled> for example with the insertion of a table of contents
[12:23:00 EDT(-0400)] <colinclark> Clarify what you're thinking in terms of aspects of transformation being orthogonal?
[12:23:43 EDT(-0400)] <Bosmon> Well, for example just these things that we see here
[12:23:50 EDT(-0400)] <Bosmon> text sizes, colours, spacing
[12:24:06 EDT(-0400)] <Bosmon> These are 3 kinds of choices that are orthogonal, and can helpfully be "seen" to be orthogonal by users
[12:24:43 EDT(-0400)] <Bosmon> font face
[12:26:00 EDT(-0400)] <colinclark> Ah, meaning...
[12:26:11 EDT(-0400)] <colinclark> these choices should be separately controllable...
[12:26:26 EDT(-0400)] <colinclark> or grouped into a theme.
[12:26:26 EDT(-0400)] <colinclark> Yes?
[12:26:36 EDT(-0400)] <colinclark> I am pointing out the obvious here, but I just want to make sure we're all clear.
[12:26:39 EDT(-0400)] <Bosmon> Well, which one
[12:26:50 EDT(-0400)] <Bosmon> I mean yes, they "should" be separately controllable
[12:26:52 EDT(-0400)] <colinclark>
[12:26:53 EDT(-0400)] <colinclark> Right.
[12:26:56 EDT(-0400)] <colinclark> That's what I meant to say.
[12:27:03 EDT(-0400)] <colinclark> I have failed in clarifying
[12:27:12 EDT(-0400)] <colinclark> Anyway, I think we all get it now.
[12:27:36 EDT(-0400)] <colinclark> Yes, I expect that users will want to be able to adjust individual settings, and indeed to even build up their own personalized theme as needed.
[12:27:58 EDT(-0400)] <Bosmon> OK
[12:28:07 EDT(-0400)] <colinclark> michelled's point about non-display transformations is also noteworthy...
[12:28:16 EDT(-0400)] <Bosmon> So we agree on a model of "String -> CSS fragment" as a "first pass"?
[12:28:34 EDT(-0400)] <Bosmon> I guess we can annotate the value type to make room for expansion for other kinds of "contribution"
[12:29:12 EDT(-0400)] <jacobfarber1> can you clarify a "css fragment"?
[12:29:16 EDT(-0400)] <michelled> where 'String' would be what?
[12:29:40 EDT(-0400)]

<Bosmon> "Blue 2" ->

Unknown macro: {type}


[12:29:46 EDT(-0400)] <Bosmon> Like that
[12:30:18 EDT(-0400)] <Bosmon> Only probably without the global file reference
[12:30:20 EDT(-0400)] <ecochran> hi, I'm just catching up here... I'm curious what things other than display would be transformable... I can imagine that a user might want to say "I prefer datepicker A over datepicker B" but what other things are people thinking of?
[12:30:57 EDT(-0400)] <michelled> well, at first pass we are tasked at replacing the current functionality in transformable 1.
[12:31:00 EDT(-0400)] <jacobfarber1> Bosmon: Im not I agree 100%, from what I understand
[12:31:13 EDT(-0400)] <michelled> I think that includes table of contents and list of links
[12:32:15 EDT(-0400)] <colinclark> ecochran: Good question. I want to let these guys clarify the current discussion, and then I can explain some ideas I have.
[12:32:30 EDT(-0400)] <Bosmon> Perhaps "behavioural" transformations might include an automated selector + event binding sweep of the document
[12:32:45 EDT(-0400)] <jacobfarber1> Bosmon: why pull in css files?
[12:32:45 EDT(-0400)] <Bosmon> To add/modify the default keyboard/mouse semantics etc.
[12:32:49 EDT(-0400)] <colinclark> Yeah, let's set aside the behavioural stuff just for a second.
[12:32:54 EDT(-0400)] <Bosmon> Is that the kind of thing you were thinking of, michelled?
[12:33:03 EDT(-0400)] <Bosmon> jacobfarber1: to help YOU!
[12:33:03 EDT(-0400)] <ecochran> michelled: I'm not familiar with the feature set of Transformable 1 so I'll go back and read the spec
[12:33:17 EDT(-0400)] <Bosmon> How would you prefer to write your styling rules for a document?
[12:33:28 EDT(-0400)] <jacobfarber1> Bosmon: why wouldnt everything already be assembled into a single file, like Fluid-all ?
[12:33:46 EDT(-0400)] <jacobfarber1> in the css ?
[12:34:19 EDT(-0400)] <jacobfarber1> meh, I mean why pull in individual css files when they could already be there?
[12:34:31 EDT(-0400)] <jacobfarber1> isnt that the way we work?
[12:34:38 EDT(-0400)] <Bosmon> It is the way we want to work
[12:34:49 EDT(-0400)] <colinclark>
[12:34:51 EDT(-0400)] <Bosmon> But I thought we conceded that in some kinds of terrains, we wouldn't get sufficient document control
[12:35:10 EDT(-0400)] <Bosmon> That is, sufficient control over the markup structure of the target documents
[12:35:32 EDT(-0400)] <Bosmon> How could we make a model work where all of the CSS was always there, without becoming "fascists"?
[12:35:56 EDT(-0400)] <jacobfarber1> i think we're talking about 2 separate things
[12:36:02 EDT(-0400)] <Bosmon> Perhaps we are
[12:36:02 EDT(-0400)] <michelled> hmmm... I think jacobfarber1 meant that the styles would be there but not necessarily applied
[12:36:02 EDT(-0400)] <ecochran> Bosmon and jacobfarber : to clarify are you talking about the difference between assembling the css server-side or client-side
[12:36:07 EDT(-0400)] <ecochran> ?
[12:36:10 EDT(-0400)] <Bosmon> But we are only building one tool
[12:36:11 EDT(-0400)] <jacobfarber1> michelled: exactly
[12:36:27 EDT(-0400)] <Bosmon> How does one not "apply" a style in a CSS sheet?
[12:36:31 EDT(-0400)] <Bosmon> Without modifying the document?
[12:36:42 EDT(-0400)] <jacobfarber1> ok
[12:37:01 EDT(-0400)] <jacobfarber1> so your saying we cannot expect our css files to be included in the head or otherwise?
[12:37:12 EDT(-0400)] <Bosmon> No, we can expect "nothing", or "everything"
[12:37:15 EDT(-0400)] <Bosmon> Or anything in between
[12:37:15 EDT(-0400)] <jacobfarber1> along side our javascript?
[12:37:21 EDT(-0400)] <Bosmon> But all the same, we are just building one tool
[12:37:52 EDT(-0400)] <Bosmon> Sometimes our clients are NICE...... and sometimes.... they are NASTY (neeear!)
[12:38:23 EDT(-0400)] <Bosmon> Anyway, yes, they may include our CSS, or not
[12:38:44 EDT(-0400)] <Bosmon> But all the same, how do we make some of a stylesheet "inactive", in cases where we have no control over the target markup?
[12:38:52 EDT(-0400)] <michelled> I think the tool can assume it has it's own css included, no?
[12:39:45 EDT(-0400)] <jacobfarber1> michelled, Bosmon: I would think if the implementor has downloaded this component, the css files would be bundled with it
[12:39:48 EDT(-0400)] <michelled> well, if the stylesheet is build with classes we don't have to apply the classes to anything
[12:40:07 EDT(-0400)] <jacobfarber1> and Bosmon: you make it "inactive" by namespacing everything the best you can
[12:40:24 EDT(-0400)] <Bosmon> OK then jacobfarber1 - once you have made it "inactive", how do you then make it "act" on things?
[12:40:26 EDT(-0400)] <jacobfarber1> michelled: yup
[12:40:36 EDT(-0400)] <jacobfarber1> you use that namespace
[12:40:38 EDT(-0400)] <jacobfarber1> for example
[12:40:46 EDT(-0400)] <Bosmon> How do you "use" it?
[12:40:49 EDT(-0400)] <jacobfarber1> I can include ALL the css files we have made so far
[12:40:54 EDT(-0400)] <jacobfarber1> but I wont see a thing
[12:41:00 EDT(-0400)] <jacobfarber1> until I enter the core class name
[12:41:05 EDT(-0400)] <Bosmon> "enter"
[12:41:06 EDT(-0400)] <Bosmon> Where!
[12:41:08 EDT(-0400)] <jacobfarber1> that triggers everything else to cascade
[12:41:11 EDT(-0400)] <jacobfarber1> anywhere
[12:41:12 EDT(-0400)] <jacobfarber1> body
[12:41:13 EDT(-0400)] <Bosmon> You mean, by changing the target markup, don't you
[12:41:15 EDT(-0400)] <jacobfarber1> div
[12:41:26 EDT(-0400)] <ecochran> Bosmon: yes
[12:41:29 EDT(-0400)] <jacobfarber1> yes, somwhere where you want it
[12:41:36 EDT(-0400)] <Bosmon> Well, that is the very thing we can't depend on being able to do
[12:41:38 EDT(-0400)] <Bosmon> In every case
[12:41:46 EDT(-0400)] <jacobfarber1> it doesnt need every case
[12:41:47 EDT(-0400)] <Bosmon> The target markup may simply be a "morass"
[12:41:56 EDT(-0400)] <jacobfarber1> it will work as best it can with what you give it
[12:42:06 EDT(-0400)] <Bosmon> If we can't even do it in any case, we need to adopt an underlying model which will always work
[12:42:14 EDT(-0400)] <jacobfarber1> depending on how much you allow it to influence
[12:42:16 EDT(-0400)] <colinclark> So the point here is that, in the case where we have skin-compliant markup, Jacob's strategy should work just fine.
[12:42:29 EDT(-0400)] <jacobfarber1> even in skin non-compliant!
[12:42:30 EDT(-0400)] <colinclark> In cases where we're facing more hostile markup, we need more at our dispoal.
[12:42:30 EDT(-0400)] <ecochran> that is the key "skin-complaint"
[12:42:37 EDT(-0400)] <colinclark> disposal
[12:42:38 EDT(-0400)] <jacobfarber1> its got some basics
[12:42:44 EDT(-0400)] <colinclark> jacobfarber1: Tell us more about what you're thinking here.
[12:43:01 EDT(-0400)] <colinclark> How could the skin be applied to documents that aren't using our classes already?
[12:43:32 EDT(-0400)] <jacobfarber1> think of the classes as helpers
[12:43:41 EDT(-0400)] <jacobfarber1> they make it all the more useful and influential
[12:43:45 EDT(-0400)] <jacobfarber1> but they are not needed at all
[12:43:50 EDT(-0400)] <jacobfarber1> to make an implression
[12:44:00 EDT(-0400)] <jacobfarber1> as long as you employ the core theme class name
[12:44:03 EDT(-0400)] <jacobfarber1> at some point
[12:44:12 EDT(-0400)] <Bosmon> jacobfarber1: What if you don't?
[12:44:21 EDT(-0400)] <jacobfarber1> the higher up the node with the theme class, the more it takes effect
[12:44:32 EDT(-0400)] <ecochran> so the transformations would be made at the base HTML tag level?
[12:44:38 EDT(-0400)] <jacobfarber1> if you dont employ the theme class, you get nothing
[12:44:51 EDT(-0400)] <jacobfarber1> echochran: in some very simple ways, yes
[12:44:55 EDT(-0400)] <jacobfarber1> like an anchor tag
[12:45:01 EDT(-0400)] <michelled> I think jacobfarber1 is saying that we can dynamically add classes to things if we want to.
[12:45:03 EDT(-0400)] <Bosmon> So, how do we plan for a world in which every user at least stands a fighting chance of getting something?
[12:45:11 EDT(-0400)] <Bosmon> michelled: But what will we add them to?
[12:45:14 EDT(-0400)] <ecochran> it would have to be very limited, we wouldn't know the context
[12:45:33 EDT(-0400)] <jacobfarber1> ecochran: yes- and so there are 2 things happening here
[12:45:37 EDT(-0400)] <jacobfarber1> one
[12:45:42 EDT(-0400)] <jacobfarber1> you get super basic stuff
[12:45:59 EDT(-0400)] <jacobfarber1> 2 you use more helpers, your page is getting more stuff
[12:46:08 EDT(-0400)] <ecochran> we could use the three semantic contexts that are already built into html: tag, css, and aria to define context
[12:46:47 EDT(-0400)] <ecochran> (yes, I know that ARIA is not ubiquitous...)
[12:47:53 EDT(-0400)] <michelled> Bosmon: maybe I don't understand what you're thinking. when a user makes a choice what would happen?
[12:48:44 EDT(-0400)] <Bosmon> Under one model, a different set of CSS blocks would be injected into the target file
[12:48:45 EDT(-0400)] <ecochran> I totally think that we're reaching for the stars here but we could say "if elem x is a foo and it has area state of bar then inject class fluid-menu"
[12:49:04 EDT(-0400)] <ecochran> aria
[12:49:16 EDT(-0400)] <jacobfarber1> ecochran: i had a conversation with David B the other day along those lines
[12:49:30 EDT(-0400)] <Bosmon> We could consider jacobfarber's concept as a separate "model"
[12:49:37 EDT(-0400)] <Bosmon> Or rather, a different "value type"
[12:49:49 EDT(-0400)] <Bosmon> Which is as different from this one as the Javascript "behaviour type" is
[12:50:31 EDT(-0400)] <Bosmon> But the question is, given there are some types of client that approach II could not reach, and that I can do everything that II can do, is there value in delivering on both approaches?
[12:50:33 EDT(-0400)] <michelled> by injecting the CSS blocks would the new styles get precedence?
[12:50:48 EDT(-0400)] <Bosmon> Well, there is the "!important" "cesspit" model
[12:50:56 EDT(-0400)] <Bosmon> And then there is our "nice" "class-oriented" model
[12:51:04 EDT(-0400)] <Bosmon> Both of these need to be modes which can be used by the tool
[12:51:08 EDT(-0400)] <jacobfarber1> i would stay away from the !important way of doing things
[12:51:11 EDT(-0400)] <Bosmon> And we need to minimise the overall cost of maintaining both of them
[12:51:30 EDT(-0400)] <Bosmon> I'm sure everyone would, if they could
[12:51:42 EDT(-0400)] <jacobfarber1> we could easily wreak havoc with "!important" being used everywhere
[12:51:47 EDT(-0400)] <Bosmon> But we have to maximise the usefulness of this tool to people who are prepared to do nothing
[12:51:57 EDT(-0400)] <colinclark> I agree with that.
[12:52:00 EDT(-0400)] <Bosmon> Which believe me, corresponds to the vastest part of our audience
[12:52:28 EDT(-0400)] <colinclark> Recognizing that we won't get it perfect in the "do nothing" case, and that we'll need to provide easy options for people to tell us more about their markup/styles.
[12:52:38 EDT(-0400)] <Bosmon> These perhaps could be two different "top-level" configurations for the overall tool we deliver
[12:53:00 EDT(-0400)] <Bosmon> But how could we keep the two different sets of packagings of the styling rules from becoming a maintenance burden?
[12:53:10 EDT(-0400)] <jacobfarber1> if we use important, we have to use it everywhere
[12:53:24 EDT(-0400)] <Bosmon> jacobfarber1: In one configuration, yes
[12:53:36 EDT(-0400)] <Bosmon> I imagine a user will be able to decide for themselves whether they are prepared to do "nothing", or "something"
[12:53:52 EDT(-0400)] <Bosmon> If they do "nothing", they get "!important" all the way
[12:54:03 EDT(-0400)] <Bosmon> And we have to be able to adapt to that without it costing us
[12:54:05 EDT(-0400)] <jacobfarber1> how would we know if they did "nothing"?
[12:54:13 EDT(-0400)] <Bosmon> The overall tool would have a configuration
[12:54:14 EDT(-0400)] <jacobfarber1> would it be an option?
[12:54:19 EDT(-0400)] <jacobfarber1> ok
[12:54:35 EDT(-0400)] <Bosmon> var preferable = fluid.preferable("I_am_an_idle_cesspit");
[12:54:44 EDT(-0400)] <colinclark> lol
[12:54:57 EDT(-0400)] <jacobfarber1> there are a few things that would need to change
[12:55:10 EDT(-0400)] <Bosmon> Now, clearly we wouldn't write "!important" everywhere in all our stylesheets
[12:55:11 EDT(-0400)] <jacobfarber1> if we're to go with the approach that there is a "nothing" mode
[12:55:24 EDT(-0400)] <jacobfarber1> Bosmon: thats just it
[12:55:25 EDT(-0400)] <Bosmon> This is "maintenance reduction point1" - at least that part will be jiggered by the tool
[12:55:38 EDT(-0400)] <Bosmon> We can parse and adapt the CSS if required
[12:55:43 EDT(-0400)] <Bosmon> But that is just mechanical
[12:55:48 EDT(-0400)] <jacobfarber1> oh
[12:55:58 EDT(-0400)] <Bosmon> Is there anything else we would need to do
[12:55:59 EDT(-0400)] <colinclark> The core challenge we face, I think, is how to graduate users of StyleAble from "nothing" to something. Nothing will, by nature, be a sub-optimal transformation. But it should still have some effect. Where we fail, we want to be able to let implementors (or even conceivably end-users) fill in the gaps for us.
[12:56:18 EDT(-0400)] <jacobfarber1> well, here is the thing
[12:56:38 EDT(-0400)] <jacobfarber1> you cannot say for certain you can ever override anything else in css
[12:56:52 EDT(-0400)] <jacobfarber1> so eve your "idle cesspit" scenario, we could still fall flat
[12:57:02 EDT(-0400)] <jacobfarber1> which negates the point of using !important
[12:57:21 EDT(-0400)] <michelled> even with injecting !important styles at the last moment?
[12:57:26 EDT(-0400)] <jacobfarber1> yup
[12:57:29 EDT(-0400)] <jacobfarber1> heres the thing
[12:57:39 EDT(-0400)] <jacobfarber1> if you use !important to say something is read
[12:57:41 EDT(-0400)] <jacobfarber1> red
[12:57:47 EDT(-0400)] <jacobfarber1> and I do the same thing
[12:58:04 EDT(-0400)] <jacobfarber1> which ever is closest to the element MIGHT win (inline vs. a selector)
[12:58:07 EDT(-0400)] <jacobfarber1> however
[12:58:19 EDT(-0400)] <jacobfarber1> if I use an ID to get at something
[12:58:29 EDT(-0400)] <jacobfarber1> I automatically have preference in a lot of cases
[12:58:42 EDT(-0400)] <jacobfarber1> so my !important would trump the js-assigned one
[12:58:56 EDT(-0400)] <jacobfarber1> its just not very easy to predict
[12:58:59 EDT(-0400)] <Bosmon> Well, we "could" fail
[12:59:10 EDT(-0400)] <Bosmon> But the point is, our idle user could not fault us for trying
[12:59:13 EDT(-0400)] <Bosmon> We had done our best
[12:59:37 EDT(-0400)] <Bosmon> If they run into the inconsistencies of this model, it would hopefully encourage them to graduate to using styles more properly
[12:59:56 EDT(-0400)] <Bosmon> But I suspect that in a "great majority" of cases, "something sensible" would happen
[13:00:00 EDT(-0400)] <Bosmon> After all, it does for the BBC
[13:00:08 EDT(-0400)] <Bosmon> Who have rather more users than we could possibly hope to have
[13:00:11 EDT(-0400)] <jacobfarber1> but the BBC knows their internals
[13:00:13 EDT(-0400)] <jacobfarber1> we dont
[13:00:25 EDT(-0400)] <jacobfarber1> who knows what they mandate people to write
[13:00:36 EDT(-0400)] <Bosmon> Well, surely they adopted this strategy precisely because they don't have very much control over generated markup?
[13:00:40 EDT(-0400)] <michelled> well, we did have some success in transformable 1 in Sakai
[13:00:45 EDT(-0400)] <Bosmon> They probably have a zillion correspondents and maintainers
[13:00:49 EDT(-0400)] <Bosmon> michelled: Quite
[13:00:59 EDT(-0400)] <Bosmon> Our "first client" for transformable II wants simply this approach
[13:01:00 EDT(-0400)] <colinclark> jacobfarber1: Yes, I agree with your point that we have to deal with the messiness of not being able to fully control the markup we operate on. The question is, how do we accomplish this?
[13:01:28 EDT(-0400)] <Bosmon> They are "happy" with the current effects of transformable 1 and simply want a tool that, initially, just does this again, only in a slighly more portable and less expensive manner...
[13:01:33 EDT(-0400)] <jacobfarber1> there are 2 ways
[13:01:58 EDT(-0400)] <jacobfarber1> we take a more passive role, shouldering the burden on the site owner to change
[13:02:20 EDT(-0400)] <jacobfarber1> or we go hyper aggressive-like and try to take over as much as possible in the first shot we have
[13:02:40 EDT(-0400)] <Bosmon> jacobfarber: There is no "first shot"
[13:02:48 EDT(-0400)] <Bosmon> This will be a bitter battle that will extend over our working lifetimes
[13:02:53 EDT(-0400)] <jacobfarber1>
[13:03:18 EDT(-0400)] <Bosmon> As I say, we need to imagine "different personalities" for our different clients [13:03:21 EDT(-0400)] <Bosmon> "PERSONNAS" if you will [13:03:23 EDT(-0400)] <jacobfarber1> break it but try hard VS. passive-agressiveness with little effect [13:03:34 EDT(-0400)] <jacobfarber1> yet no broken bones [13:03:34 EDT(-0400)] <Bosmon> To each of them, we must deliver as much as possible [13:03:40 EDT(-0400)] <Bosmon> But overall, with as little cost to ourselves [13:03:49 EDT(-0400)] <colinclark> Ok, so... [13:04:14 EDT(-0400)] <colinclark> We can undoubtedly agree on a first point: [13:04:35 EDT(-0400)] <Bosmon> So, what I am seeing here, is that perhaps we will adopt a "packaging strategy" for CSS, just as we do for JS [13:04:35 EDT(-0400)] <jacobfarber1> standup? [13:04:48 EDT(-0400)] <colinclark> 1. For authors who are willing to implement some simple conventions in their markup and styles, we can deliver a fully optimal transformation experience. [13:04:53 EDT(-0400)] <Bosmon> There will be a "CSS-all" which contains class-scoped, non-"!important"ised versions of all of our sheets [13:04:54 EDT(-0400)] <colinclark> There's no question about that. [13:05:19 EDT(-0400)] <Bosmon> But this CSS-all is actually derived at build time by concatenation a whole heap of much smaller, orthogonal sheets [13:05:34 EDT(-0400)] <colinclark> The reality is that we need to be able to contend with content that was not authored with us in mind. Or with accessibility in mind. Or with good semantics in mind. [13:05:36 EDT(-0400)] <Bosmon> For "idle" clients, they get the smaller sheets, un-classed, forcibly "injected" into them and "!important"-ised [13:06:05 EDT(-0400)] <Bosmon> For "active" clients, they could simply get CSS-all, and perhaps "agree" to have class-names injected onto their root element, or perhaps to even use them themselves [13:06:28 EDT(-0400)] <colinclark> Dealing with the muckiness of real, non-ideal markup is absolutely a requirement: people need this sort of re-styling and transformation to even be able to use our sites and applications. [13:06:51 EDT(-0400)] <colinclark> It is a more significant problem to handle, so we'll have to make decisions about how good is "good enough" in these cases. [13:07:04 EDT(-0400)] <jacobfarber1> exactly [13:07:06 EDT(-0400)] <colinclark> And provide a graduation path towards the optimal experience. [13:07:18 EDT(-0400)] <Bosmon> Although still, for transformable itself, this still seems to be to require our clients to "agree" to a quite dangerous quantity of markup injection [13:07:21 EDT(-0400)] <jacobfarber1> plus. offset that with the burden of a large codebase [13:07:21 EDT(-0400)] <colinclark> It's not reasonable to just say "do it our way, or you get nothing." [13:07:25 EDT(-0400)] <colinclark> But we will have to set our limits. [13:07:35 EDT(-0400)] <colinclark> And give people easy strategies for improving our accuracy. [13:08:05 EDT(-0400)] <colinclark> There are just so many different authoring tools, so much legacy content that is important, etc. to assume that we can control our markup environment. [13:08:35 EDT(-0400)] <colinclark> It's going to be a bit of a tough challenge, but michelled's point is a good one: we've done the basics in the first version of StyleAble, so that gives us some cues. [13:08:41 EDT(-0400)] <colinclark> But there's lots of room to rethink this. [13:09:00 EDT(-0400)] <colinclark> I just don't think we can get away from the scenario where we can't control the documents. Not easy, but it's reality. [13:09:09 EDT(-0400)] <colinclark> Make sense? [13:09:29 EDT(-0400)] <michelled> yes [13:09:32 EDT(-0400)] <colinclark> We're not going to do the impossible here. That's why we have to set limits on what is feasible. [13:09:42 EDT(-0400)] <colinclark> (in the "nothing" scenario especially) [13:26:50 EDT(-0400)] <colinclark> Hokay, so. [13:27:00 EDT(-0400)] <colinclark> jacobfarber1: When do you knock off for the day? [13:27:16 EDT(-0400)] <jacobfarber1> very very soon [13:27:20 EDT(-0400)] <colinclark> urg [13:27:21 EDT(-0400)] <jacobfarber1> actually [13:27:24 EDT(-0400)] <jacobfarber1> its only 130 [13:27:26 EDT(-0400)] <jacobfarber1> sorry [13:27:29 EDT(-0400)] <jacobfarber1> lost track of time [13:27:36 EDT(-0400)] <colinclark> Would a Skype chat a 2 pm work for anyone who's interested in continuing the TransformAble discussion? [13:27:45 EDT(-0400)] <Bosmon> Yes, that is fine [13:27:49 EDT(-0400)] <jacobfarber1> i got a bout 1.5 hours before things get messy [13:27:50 EDT(-0400)] <colinclark> 2 pm EDT, that is. [13:27:50 EDT(-0400)] <jacobfarber1> [13:28:12 EDT(-0400)] <colinclark> jacobfarber: So 2 pm would work? [13:28:16 EDT(-0400)] <jacobfarber1> yup! [13:28:20 EDT(-0400)] <colinclark> michelled, ecochran are you guys in? [13:28:33 EDT(-0400)] <ecochran> I'm here, is that what you mean? [13:28:34 EDT(-0400)] <colinclark> Let's do skype because breeze is evil [13:28:39 EDT(-0400)] <ecochran> yes [13:28:48 EDT(-0400)] <ecochran> oh, sorry didn't see the above [13:28:50 EDT(-0400)] <jacobfarber1> im going to step out for a moment... [13:28:58 EDT(-0400)] <colinclark> jacobfarber1: k [13:29:01 EDT(-0400)] <colinclark> Can you give me your skype name? [13:29:06 EDT(-0400)] <colinclark> I think I have the rest of you. [13:29:20 EDT(-0400)] <ecochran> I may have to take Hannah to the doctor [13:29:24 EDT(-0400)] <ecochran> I'm trying to find out now [13:29:27 EDT(-0400)] <colinclark> [13:29:33 EDT(-0400)] <colinclark> I hope she's feeling better soon. [13:29:40 EDT(-0400)] <colinclark> Join us if you can, no pressure if not. [13:30:10 EDT(-0400)] <ecochran> Char's going to go... [13:30:14 EDT(-0400)] <jacobfarber1> colinclark [13:30:22 EDT(-0400)] <jacobfarber1> i need to install it first [13:30:23 EDT(-0400)] <ecochran> I'm good for 11am [13:30:26 EDT(-0400)] <ecochran> em, 2 [13:30:34 EDT(-0400)] <colinclark> wicked [13:30:44 EDT(-0400)] <colinclark> jacobfarber1: Installing it is easy. [13:31:53 EDT(-0400)] <michelled> sorry - was distracted. yes, I'm in [13:33:08 EDT(-0400)] <colinclark> wicked [13:34:20 EDT(-0400)] <Bosmon> As wicked as DR. MARVIN CANDLE! [13:36:25 EDT(-0400)] <jacobfarber1> colinclark: jacob.farber [13:56:14 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work [13:58:21 EDT(-0400)] <Bosmon> Do our packaging scripts strip out comments? [13:58:39 EDT(-0400)] <michelled> yes [13:58:43 EDT(-0400)] <Bosmon> Cool [13:58:49 EDT(-0400)] <Bosmon> Then I needn't feel guilty about writing more [14:01:30 EDT(-0400)] <colinclark> Bosmon: Not guilty at all. You should feel awesome about writing comments. [14:02:01 EDT(-0400)] <colinclark> I'll be skyping y'all in a second for our voice conversation. [14:02:36 EDT(-0400)] <colinclark> I'm just trying to quickly scarf down pizza [14:06:46 EDT(-0400)] <Bosmon> I passed the night at a wayside inn, and could scarcely sleep a moment for the fleas. [14:07:28 EDT(-0400)] <ecochran> just how many connectivity tools do you have open at once? right now i have Skype, Adium, Colloquy, and Mail open, and I just closed Connect and I haven't opened iChat today... but I'm sure that I will... [14:10:24 EDT(-0400)] <colinclark> [14:11:31 EDT(-0400)] <Bosmon> Well, i have Gaim and Skype [14:11:35 EDT(-0400)] <Bosmon> Not including Netscape 4 [14:11:42 EDT(-0400)] <Bosmon> If you consider that a form of "connectivity tool" [14:20:24 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work [14:28:40 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined #fluid-work [14:43:00 EDT(-0400)] <anastasiac> ecochran, got a sec? [14:43:19 EDT(-0400)] <anastasiac> for a css/IE question? [14:43:28 EDT(-0400)] <ecochran> on Skype with michelled colinclark jacobfarber Bosmon [14:43:30 EDT(-0400)] <ecochran> can it wait [14:43:35 EDT(-0400)] <anastasiac> yes, no prob [14:43:41 EDT(-0400)] <ecochran> or send it and I'll answer when I get a chance [14:43:57 EDT(-0400)] <anastasiac> np - jacobfarber could help, too, so I'll wait [14:50:07 EDT(-0400)] * apetro (n=apetro@72.33.23.236) has joined #fluid-work [16:03:46 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work [16:13:14 EDT(-0400)] <michelled> anastasiac: I saw that you created a sandbox space for some pager work [16:13:43 EDT(-0400)] <anastasiac> yes, michelled [16:13:46 EDT(-0400)] <michelled> did you see my commit yesterday? Basically I was trying out the renderer a little [16:13:55 EDT(-0400)] <anastasiac> yes, I've been looking at it closely [16:14:01 EDT(-0400)] <michelled> cool [16:14:11 EDT(-0400)] <anastasiac> it's not helping, though [16:14:32 EDT(-0400)] <Bosmon> [16:14:37 EDT(-0400)] <michelled> one thing to note is that in my example I'm using a label with a 'for' attribute and that functionality is not yet implemented [16:14:42 EDT(-0400)] <Bosmon> Yes [16:14:46 EDT(-0400)] <Bosmon> I am porting it over now... [16:14:55 EDT(-0400)] <anastasiac> that's ok, I'm not trying to do anything vaguely like that [16:15:00 EDT(-0400)] <michelled> so, what are you having issues with? [16:15:02 EDT(-0400)] <Bosmon> It is actually easier to convert Java to Javascript than you would think [16:15:08 EDT(-0400)] <anastasiac> I'm just trying to fill in some list elements (<li>) [16:15:15 EDT(-0400)] <anastasiac> but they're all showing up inside their own <ul> [16:15:22 EDT(-0400)] <colinclark> anastasiac: I don't expect the renderer to be easy to use this early in its evolution. So do take some notes about the things that confuse you, things you are looking for, etc. [16:15:39 EDT(-0400)] <anastasiac> that's exactly what I'm doing with this exercise [16:15:42 EDT(-0400)] <Bosmon> btw, michelled: Cool though selector-based rendering is, I am thinking that we should fall back to using rsf:ids for now? Especially since we are controlling our own markup strongly [16:15:44 EDT(-0400)] <michelled> do you know about the ':'? [16:16:04 EDT(-0400)] <Bosmon> And we do want this tool to be capable of rendering from the server someday... [16:16:05 EDT(-0400)] <anastasiac> yes - at least, I think I do, but it's possible that I could be mis-understanding [16:16:14 EDT(-0400)] <colinclark> ecochran: wicked [16:16:21 EDT(-0400)] <anastasiac> the colon is used on ids of things that contain other things, basically - is that right? [16:16:35 EDT(-0400)] <Bosmon> anastasiac: Not really, no [16:16:41 EDT(-0400)] * colinclark laughs. [16:16:43 EDT(-0400)] <anastasiac> ah [16:16:45 EDT(-0400)] <ecochran> colinclark: huh? [16:16:48 EDT(-0400)] <Bosmon> anastasiac: The colon is a marker that indicates either repetition or branching [16:17:03 EDT(-0400)] <anastasiac> ok, cool [16:17:12 EDT(-0400)] <Bosmon> I mean, typically that "goes along" with containment [16:17:23 EDT(-0400)] <anastasiac> so I'd use the colon on the id for the <ul> element? or on the <li> element? [16:17:33 EDT(-0400)] <Bosmon> But there are many cases where you have containment but no colon [16:17:39 EDT(-0400)] <colinclark> ecochran: I'm just laughing pleasantly at the conversation. It's a good one to have. [16:17:43 EDT(-0400)] <Bosmon> You use the colon on the one you want to repeat [16:17:45 EDT(-0400)] <colinclark> And funny, in a certain way. [16:17:55 EDT(-0400)] <Bosmon> The one that you will have multiple components for, but only one tag [16:18:00 EDT(-0400)] <anastasiac> ah, that might help, Bosmon, let me try that [16:18:07 EDT(-0400)] <michelled> what do you mean by branching? [16:18:23 EDT(-0400)] <anastasiac> that's what I wanted - one <li> in the template, but the renderer to replace that with multple <li>s [16:18:28 EDT(-0400)] <Bosmon> michelled: For example, when you want to branch to another point in the same template, or perhaps a compeltely different template [16:18:46 EDT(-0400)] <michelled> good to know [16:18:47 EDT(-0400)] <Bosmon> The colon basically says, "the renderer can make a choice about going somewhere else here" [16:18:58 EDT(-0400)] <Bosmon> Absence of colon means "The renderer will carry on from here in the markup" [16:19:21 EDT(-0400)] <Bosmon> The only choice about a tag with no colon is whether to render it or not [16:19:28 EDT(-0400)] <Bosmon> THat is, you can skip it, or not skip it [16:19:37 EDT(-0400)] <michelled> I wonder if we need two different markers for repetition and branching. I think from a user of the renderer's perspective they are very different things [16:19:55 EDT(-0400)] <Bosmon> If it has a colon, you can not only skip it, but repeat it, or branch elsewhere [16:20:05 EDT(-0400)] <anastasiac> yes, I was thinking that - looking at a template with a colon, what should you interpret? [16:20:05 EDT(-0400)] <Bosmon> Well, it is a discussion we had a lot [16:20:11 EDT(-0400)] <ecochran> anastasiac: do you still have a css question for me, or have you jumped on jacobfarber [16:20:23 EDT(-0400)] <michelled> repetition feels like the common loop - perhaps we need a loop construct [16:20:30 EDT(-0400)] <anastasiac> no, ecochran, still have the question [16:20:33 EDT(-0400)] <Bosmon> I've often wondered whether there would be a way to even get rid of the colon altogether [16:20:44 EDT(-0400)] <Bosmon> But usually I've managed to convince myself that it is necessary, for some reason or other [16:21:02 EDT(-0400)] <anastasiac> someone here was trying to make the tbody scrollable with a height and overflow=auto [16:21:04 EDT(-0400)] <Bosmon> But it would be a bit ugly to think of a second "strange character"... [16:21:07 EDT(-0400)] <anastasiac> it wasn't working in IE [16:21:14 EDT(-0400)] <anastasiac> does this sound familiar, ecochran? [16:21:30 EDT(-0400)] <Bosmon> We have used :, -, and = with some special meanings [16:21:33 EDT(-0400)] <ecochran> yeah, scrolling bodies is really the job of the browser [16:21:35 EDT(-0400)] <Bosmon> It would be awful to have another one [16:21:44 EDT(-0400)] <Bosmon> Oh yes, also ~ and ! for some special cases [16:22:05 EDT(-0400)] <Bosmon> But really you can get by just knowing : or absence of : [16:22:09 EDT(-0400)] <anastasiac> ecochran, it worked in all browsers but IE7 - know of any workarounds? [16:22:21 EDT(-0400)] <colinclark> Hey Bosmon... on the subject of branching. Can you give us an example of when you might branch to another point in the same template? [16:22:22 EDT(-0400)] <ecochran> the body doesn't really have a height [16:22:30 EDT(-0400)] <colinclark> Conditionals and that sort of thing? [16:22:35 EDT(-0400)] <ecochran> anastasiac: yes, put the whole thing in a div [16:22:40 EDT(-0400)] <Bosmon> colinclark: Well, this use would really amount to a kind of "fat template" [16:22:41 EDT(-0400)] <ecochran> and scroll the div [16:22:49 EDT(-0400)] <anastasiac> this person wanted to restrict the height to a max,and scroll if taller [16:22:56 EDT(-0400)] <anastasiac> put exactly what in a div, the tbody? [16:22:59 EDT(-0400)] <Bosmon> That is, when you had decided to concatenate things which would really be functionally multiple templates into a single document [16:23:05 EDT(-0400)] <colinclark> Yes, that makes sense. [16:23:19 EDT(-0400)] <Bosmon> A little like the way the MyCamTools guys sort of "implode" a huge package of stuff into a single document [16:23:24 EDT(-0400)] <Bosmon> Most of which is hidden/armoured [16:23:31 EDT(-0400)] <ecochran> sorry, tbody [16:23:35 EDT(-0400)] <ecochran> I missed the t [16:23:44 EDT(-0400)] <ecochran> IE doesn't support it as you've seen [16:23:47 EDT(-0400)] <colinclark> Bosmon: Yep, totally. Makes sense. [16:23:48 EDT(-0400)] <anastasiac> can you put a tbody inside a div, inside a table?? [16:23:53 EDT(-0400)] <ecochran> no [16:23:54 EDT(-0400)] <Bosmon> "Original FlowTalk" used only this method, since we didn't actually implement branching at all before RSF 0.7 [16:23:55 EDT(-0400)] <ecochran> can't [16:23:57 EDT(-0400)] <ecochran> not good [16:24:03 EDT(-0400)] <ecochran> this is broken functionality in IE [16:24:05 EDT(-0400)] <ecochran> sucks [16:24:11 EDT(-0400)] <Bosmon> But it led to the templates being very hard to understand, which is what I think Ian was alluding to in his list complaint [16:24:18 EDT(-0400)] <ecochran> The only real workaround is to break the table up [16:24:19 EDT(-0400)] <Bosmon> The "designers who were unhappy" were really Hatti [16:24:21 EDT(-0400)] <Bosmon> e [16:24:32 EDT(-0400)] <ecochran> see what I've done with the Uploader [16:24:34 EDT(-0400)] <anastasiac> ecochran, how would you recommend breaking it up? [16:24:35 EDT(-0400)] <Bosmon> And it truly was very hard to manage a 800-line HTML template [16:24:38 EDT(-0400)] * colinclark thinks Bosmon's use of quotation marks is funny. [16:24:48 EDT(-0400)] <ecochran> separate head, body, and foot tables [16:24:59 EDT(-0400)] <Bosmon> In theory, easier than the equivalent 800-line PHP/Smarty file [16:24:59 EDT(-0400)] <ecochran> then wrap the div around the body table [16:25:03 EDT(-0400)] <Bosmon> But still, very hard [16:25:04 EDT(-0400)] <ecochran> scroll the div [16:25:08 EDT(-0400)] <colinclark> ecochran: Can anastasiac use the Scroller? [16:25:13 EDT(-0400)] <ecochran> yes [16:25:16 EDT(-0400)] <colinclark> wicke [16:25:17 EDT(-0400)] <colinclark> d [16:25:18 EDT(-0400)] <anastasiac> ok, I'll suggest that [16:25:21 EDT(-0400)] <ecochran> if this is in Fluid [16:25:25 EDT(-0400)] <ecochran> wait [16:25:26 EDT(-0400)] <anastasiac> the Scroller is still in the sandbox, right? [16:25:35 EDT(-0400)] <colinclark> anastasiac: Yep. [16:25:36 EDT(-0400)] <Bosmon> So yes, "branching within the same template" is really not used very much in the "modern world" [16:25:44 EDT(-0400)] <ecochran> the Scroller still wont do this unless the markup is correct [16:25:47 EDT(-0400)] <colinclark> ah [16:25:56 EDT(-0400)] <ecochran> our scroller doesn't fix the table problem [16:25:58 EDT(-0400)] <Bosmon> But it is there as a possibility [16:26:01 EDT(-0400)] <anastasiac> colinclark and ecochran: while you're here: [16:26:02 EDT(-0400)] <ecochran> it's intractable [16:26:11 EDT(-0400)] <anastasiac> will uploader2 api be different than 0.5? [16:26:18 EDT(-0400)] <ecochran> yep [16:26:29 EDT(-0400)] <ecochran> but not by much [16:26:36 EDT(-0400)] <anastasiac> so if someone here is interested in adding uploader to a portlet: [16:26:42 EDT(-0400)] <ecochran> maybe I spoke too soon [16:26:50 EDT(-0400)] <anastasiac> they might want to wait for uploader2, but portal has 0.5 built-in [16:27:10 EDT(-0400)] <colinclark> anastasiac: hmm [16:27:17 EDT(-0400)] * sgithens342f (n=sgithens@in-143-211.dhcp-149-166.iupui.edu) has joined #fluid-work [16:27:18 EDT(-0400)] <colinclark> In a sense, it will just have more of an API. [16:27:28 EDT(-0400)] <anastasiac> it's an interesting issue that was raised wrt versioning [16:27:31 EDT(-0400)] <ecochran> anastasiac: I would recommend that they get their feet wet [16:27:44 EDT(-0400)] <colinclark> anastasiac: It will be slightly different, in that it will conform to the API style guide. But generally, not much. [16:27:46 EDT(-0400)] <anastasiac> portlet writers shouldn't have to impose requirements on the portal [16:28:07 EDT(-0400)] <michelled> I thought the portal only has the reorderer built in [16:28:11 EDT(-0400)] <anastasiac> it would be nice if a portlet writer can just use the fluid that the portal has [16:28:13 EDT(-0400)] <michelled> does it have fluid-all? [16:28:16 EDT(-0400)] <ecochran> the hardest part for them is going to be writing their server code [16:28:18 EDT(-0400)] <Bosmon> Greetings RESPECTABLE HENS [16:28:23 EDT(-0400)] <anastasiac> ah,I think it's only LR [16:28:30 EDT(-0400)] <anastasiac> ok, another question: [16:28:32 EDT(-0400)] <ecochran> Bosmon: who you callin' respectable [16:28:45 EDT(-0400)] * anastasiac is interrupted [16:29:17 EDT(-0400)] <ecochran> ecochran: listening [16:29:25 EDT(-0400)] * colinclark is catching up. Wow, lots of good chatter here. [16:29:29 EDT(-0400)] <colinclark> anastasiac: Okay, so. [16:29:34 EDT(-0400)] * anastasiac is talking to someone here [16:29:57 EDT(-0400)] <colinclark> I agree with ecochran. If someone likes the Uploader now, they should play around with Uploader 1. Uploader 2 will be even cooler, but Uploader 1 is here today. [16:30:14 EDT(-0400)] <michelled> Bosmon: so going back to your earlier point - yes, no issues with us using ids. any reason you want those prefaced with rsf? [16:30:15 EDT(-0400)] <colinclark> As for versioning, 0.5 and beyond are versioned... [16:30:37 EDT(-0400)] <colinclark> anastasiac: So a portlet writer should have no problems if they want to link against a newer version of the Uploader. [16:30:41 EDT(-0400)] <Bosmon> michelled: I am talking about the template attribute you write, rather than the id value itself [16:30:52 EDT(-0400)] <Bosmon> The template attribute has to be namespaced somehow, since it is not actually part of HTML [16:31:14 EDT(-0400)] <Bosmon> And "historically" the namespace value has been rsf, that is <li rsf:id="my-id:"> [16:32:05 EDT(-0400)] <Bosmon> We could switch it to "fluid:id" I guess quite easily [16:32:20 EDT(-0400)] <Bosmon> But it would mean rebranding everything [16:32:55 EDT(-0400)] <michelled> why not just use an id? [16:33:05 EDT(-0400)] <Bosmon> Because ids have to be unique [16:33:09 EDT(-0400)] <Bosmon> As we recently discussed [16:33:35 EDT(-0400)] <Bosmon> For a "fully previewable" document you will often write both an id and an rsf:id [16:33:38 EDT(-0400)] * anastasiac finishes conversation, and returns attention to IRC [16:33:49 EDT(-0400)] <Bosmon> Since the renderer does not generate ids in the output markup on nodes which did not already have them [16:34:06 EDT(-0400)] <anastasiac> colinclark, portlets don't have a <head> tag - can you link to a js file anywhere within html? [16:34:30 EDT(-0400)] <Bosmon> anastasiac: Yes, you can [16:34:37 EDT(-0400)] <Bosmon> That is, "practically" [16:34:39 EDT(-0400)] <Bosmon> If not "morally" [16:34:41 EDT(-0400)] * anastasiac knows she should know this, but her head is in several plces right now [16:34:46 EDT(-0400)] <Bosmon> I have never seen an environment in which it does not work [16:35:05 EDT(-0400)] <Bosmon> We used this trick in the uPortal version of the "Gallery" tool.... [16:35:12 EDT(-0400)] <anastasiac> ok, excellent - this is good to know for portlet developers, that they're not bound to the version of fluid used by the portal [16:35:17 EDT(-0400)] <Bosmon> Yes [16:35:28 EDT(-0400)] <colinclark> anastasiac: Exactly. But they should feel welcome to take advantage of its presence. [16:35:36 EDT(-0400)] <colinclark> And probably feel encouraged, since it will be faster. [16:35:36 EDT(-0400)] <Bosmon> One of the main reason for all our head-scratching over our versioning strategy [16:35:43 EDT(-0400)] <colinclark> [16:35:48 EDT(-0400)] <anastasiac> right - but they can't really know which version it is! [16:35:50 EDT(-0400)] <Bosmon> When we have the "Fluid Loader" for 0.8, all of this insanity will go away [16:36:05 EDT(-0400)] <colinclark> anastasiac: But they can, yes. [16:36:23 EDT(-0400)] <michelled> so I'm still not getting this Bosmon - why wouldn't I just put ids in my template and use those. Why does it matter that they need to be unique? If I do some repetition, the renderer will take care of the ids for me. [16:36:44 EDT(-0400)] <Bosmon> michelled: I think you are mixing up HTML ids and RSF ids [16:36:52 EDT(-0400)] <michelled> well, yes [16:36:57 EDT(-0400)] <anastasiac> ok - I'll think about this a little bit more, this multi-version in portlet/portal environments [16:37:09 EDT(-0400)] <michelled> I'm saying why don't we use HTML ids instead of using RSF ids [16:37:12 EDT(-0400)] <anastasiac> before I get back to Drew about it [16:37:14 EDT(-0400)] <Bosmon> When you drive the renderer "without" selectors, the RSF ids are written directly onto the markup [16:37:30 EDT(-0400)] <Bosmon> Well yes, we don't use HTML ids because i) someone may be using the ids for some other purpose, and [16:37:33 EDT(-0400)] <Bosmon> ii) HTML ids need to be unique [16:37:39 EDT(-0400)] <Bosmon> Say you have written something like this: [16:38:04 EDT(-0400)] <Bosmon> <ul> [16:38:05 EDT(-0400)] <Bosmon> <li rsf:id="my-item:">My item 1</li> [16:38:05 EDT(-0400)] <Bosmon> <li rsf:id="my-item:">My item 2 </li> [16:38:05 EDT(-0400)] <Bosmon> </ul> [16:38:17 EDT(-0400)] <Bosmon> If we used plain ids for governing rendering, this document would be invalid [16:38:48 EDT(-0400)] <Bosmon> Also, if we were using plain ids for governing rendering, people would be constantly bashing into random stuff elsewhere in the document with the components, that the author never dreamed of re-rendering [16:38:50 EDT(-0400)] <michelled> anastasiac: just keep in mind that while we do have a versioning strategy for fluid, jquery doesn't and it's been known to be an issue, so if we upgrade our version of jquery or jquery ui it will be a problem for users [16:39:10 EDT(-0400)] <Bosmon> michelled: Yes, we really do need to present our strategy to JQuery.... and see if they are interested in it [16:39:21 EDT(-0400)] <colinclark> That would be awesome. [16:40:00 EDT(-0400)] <michelled> ok, that makes sense Bosmon. I hadn't thought of i) [16:40:39 EDT(-0400)] <athena7> is the jquery ui dependency for fluid likely to get upgraded anytime soon? [16:40:48 EDT(-0400)] <athena7> sounds like 1.6 is in the works [16:40:50 EDT(-0400)] <Bosmon> athena7: How stale are we? [16:40:55 EDT(-0400)] <athena7> you're not [16:41:06 EDT(-0400)] <Bosmon> I am sure we will keep abreast of every version released within reasonable time for our QA [16:41:17 EDT(-0400)] <athena7> well, 1.5.1 vs. 1.5.2 - but fluid works with 1.5.2 anyway [16:41:35 EDT(-0400)] <athena7> just curious [16:43:33 EDT(-0400)] <Bosmon> I hope that JQuery UI 1.6 would coincide with JQuery 1.3 .... [16:44:02 EDT(-0400)] <Bosmon> We are still bleeding somewhat from the awful speed of the JQuery.offsets() method [16:46:36 EDT(-0400)] <ecochran> jQuery UI 1.6 was due out a week ago or so... they have been delayed [16:47:26 EDT(-0400)] <michelled> athena7: ya, we'll upgrade to 1.6 when it comes out [16:47:51 EDT(-0400)] <michelled> we have some a11y improvements in the dialog that we depend on for uploader in that version [16:47:57 EDT(-0400)] * anastasiac is starting to understand this rendering stuff! [16:51:36 EDT(-0400)] <colinclark> Hey athena7, have you taken advantage of the versioning support in 0.5 yet? [16:51:50 EDT(-0400)] <athena7> nope [16:51:57 EDT(-0400)] <athena7> haven't really had time to play with anything [16:52:02 EDT(-0400)] <colinclark> understandable [16:52:08 EDT(-0400)] <colinclark> Me neither. [16:55:02 EDT(-0400)] <athena7> lol [16:57:01 EDT(-0400)] * michelled (n=team@142.150.154.197) has left #fluid-work [17:11:37 EDT(-0400)] * Bosmo1 (n=Bosmon@87-194-196-18.bethere.co.uk) has joined #fluid-work [17:12:18 EDT(-0400)] <Bosmo1> It's ALJJJJJJJJVE! [17:13:41 EDT(-0400)] <colinclark> Bosmo1: What's alive? [17:14:43 EDT(-0400)] <Bosmo1> The renderer [17:14:46 EDT(-0400)] <Bosmo1> per the topic [17:14:49 EDT(-0400)] <colinclark> [17:24:57 EDT(-0400)] <anastasiac> Bosmo1, have you seen the preferable example that michelled commited to the sandbox, that uses the renderer? [17:26:36 EDT(-0400)] <anastasiac> can I ask a question about the template/tree/cutpoints relationship in the particular example? [17:29:26 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work [17:29:52 EDT(-0400)] <Bosmo1> Yes, go ahead [17:30:13 EDT(-0400)] <anastasiac> it's about the <span> that surrounds the elements that are to be repeated [17:30:29 EDT(-0400)] <anastasiac> is this <span> really only required so that an id can be attached, and referenced? [17:30:32 EDT(-0400)] <anastasiac> essentially? [17:33:41 EDT(-0400)] <Bosmo1> Well, I'm not sure that even an id is required [17:33:48 EDT(-0400)] <Bosmo1> But any "repeating unit" must have a single tag parent, yes [17:33:58 EDT(-0400)] <Bosmo1> The renderer works entirely in the unit of tags [17:34:23 EDT(-0400)] <anastasiac> by id, I'm referring to the "id" in the cutpoint list [17:34:25 EDT(-0400)] <Bosmo1> You can't just repeat an "arbitrary span of text" as with non-markup oriented renderers [17:34:42 EDT(-0400)] <anastasiac> if there's no single parent tag, what do you put in the cutpoint list - right? [17:35:09 EDT(-0400)] <Bosmo1> Oh yes, you mean the rsf:id [17:35:20 EDT(-0400)] <Bosmo1> It's still funny to me seeing things bare in the tree like that [17:35:27 EDT(-0400)] <Bosmo1> Yes, the rsf:id must be assigned to a particular tag [17:35:46 EDT(-0400)] <anastasiac> I'm trying to conceptualize things without thinking of RSF, since many of our users will not be familiar with it [17:35:53 EDT(-0400)] <Bosmo1> Yes [17:36:01 EDT(-0400)] <Bosmo1> It is a very good thing to do [17:36:09 EDT(-0400)] <Bosmo1> [17:36:11 EDT(-0400)] <anastasiac> so it wouldn't have to be a span, though? [17:36:18 EDT(-0400)] <Bosmo1> No, it could be anything [17:36:46 EDT(-0400)] <Bosmo1> A "trick" which I can't recall if it is fully implemented on the client, is to write for example "~span:" as the id [17:36:49 EDT(-0400)] <anastasiac> my example is a <ul>, with repeating <li>s [17:36:57 EDT(-0400)] <Bosmo1> In which case the <span> level of tags would be stripped out of the rendered markup [17:37:12 EDT(-0400)] <anastasiac> the tree defines the text to put into the <li>s [17:37:31 EDT(-0400)] <Bosmo1> I did recommend earlier though that we fall back to the "rsf:id" style of marking up, rather than continue to use "selector cutpoints" for this app.... [17:37:47 EDT(-0400)] <Bosmo1> Firstly since there is some performance penalty to the selector approach [17:37:54 EDT(-0400)] <anastasiac> I put a span inside the <li> in the template - does that sound right? [17:38:05 EDT(-0400)] <anastasiac> it works, but it's not clear to me that it's necessary [17:38:09 EDT(-0400)] <Bosmo1> And secondly since we don't want to rule out one day rendering this app from the server [17:38:14 EDT(-0400)] * anastasiac searches for pastebing [17:38:19 EDT(-0400)] <Bosmo1> No, a <span> probably would not be necessary here [17:38:52 EDT(-0400)] <anastasiac> http://fluid.pastebin.com/m71d9605b [17:38:53 EDT(-0400)] <Bosmo1> If you are repeating individual tags, then you can just use the tag [17:38:57 EDT(-0400)] <anastasiac> could you crituque? [17:39:02 EDT(-0400)] <anastasiac> critique? [17:39:42 EDT(-0400)] <anastasiac> to clarify, I want a single 'prev', followed by repeated links, then a single 'next' [17:40:01 EDT(-0400)] <Bosmo1> I wonder, if people are going to do this all the time, that we don't just want an "auto-class" mode [17:40:15 EDT(-0400)] <Bosmo1> Apart of course from the odd issue of the colons [17:40:31 EDT(-0400)] <anastasiac> one thing at a time, please? [17:40:36 EDT(-0400)] <Bosmo1> OK yes [17:40:40 EDT(-0400)] <Bosmo1> The span is unnecessary [17:41:00 EDT(-0400)] <Bosmo1> You can just write "link:" [1, 2, 3] here [17:41:10 EDT(-0400)] <Bosmo1> Sorry "link:" : [1, 2, 3] [17:41:24 EDT(-0400)] <anastasiac> ah, ok, i think I see better now [17:41:40 EDT(-0400)] <anastasiac> the contents of the array don't have to be these objects [17:41:45 EDT(-0400)] <anastasiac> that's only the case if necessary [17:41:48 EDT(-0400)] <anastasiac> ok, I'm getting it now [17:41:53 EDT(-0400)] <anastasiac> I think [17:41:55 EDT(-0400)] <Bosmo1> [17:42:03 EDT(-0400)] <anastasiac> cool - thanks so much! [17:42:07 EDT(-0400)] <anastasiac> this rendering is fun! [17:42:11 EDT(-0400)] <Bosmo1> [17:42:27 EDT(-0400)] <Bosmo1> I guess we can make at least a cool "shorthand" for cutpoints of this form [17:43:00 EDT(-0400)] <Bosmo1> fluid.makeCutpoints( ["link-text", "prev-link", "next-link"], ["link"]); [17:43:22 EDT(-0400)] <Bosmo1> YOu hand it two arrays, full of the classes for non-colons, and then the colons [17:43:56 EDT(-0400)] <Bosmo1> Well [17:44:01 EDT(-0400)] <Bosmo1> I guess we don't even need to do that [17:44:05 EDT(-0400)] <Bosmo1> We can just infer it from the component tree [17:44:50 EDT(-0400)]